Consider / evaluate non-native Serialization to session

[davidsowerby]

To capture our conversation about Serialization performance and specifically Kryo

Here are some benchmarks - Kryo does well, but maybe protostuff may be even quicker..

[mcollovati]

Interesting benchmarks.

At a first look it seems that, apart from performance, Kryo seems easier to customize, has better documentation and also some OOB serializer implementation in a side project (eg CGLib proxy).
Protostuff seems more oriented on a scenario of messages serialization.

One thing we also should considered is the possibility to have in session some objects with custom serialization logic that should be executed; this happens for some Vaadin classes but could also happen for application specific classes (maybe from third party libraries).

In a custom serialization process (Kryo, protostuff or whatever) this cases should be somehow intercepted in order to apply default java serialization.
To find out what classes should use default serialization there should be a better check than a simple instanceof Serializable; I'm thinking about inspecting class for at least one serialization method (writeObject, readObject, writeReplace,readResolve`)

[davidsowerby]

One thing we also should considered is the possibility to have in session some objects with custom serialization logic that should be executed

I agree, there could be a requirement to Serialise almost anything, so ease of customisation would be a significant factor

In a custom serialization process (Kryo, protostuff or whatever) this cases should be somehow intercepted in order to apply default java serialization.

There are many use cases for custom Serialization, but once a serialiser (eg, Kryo) is employed, I cannot think of a reason to drop back into native Java serialisation. Could you give an example of what you are thinking of?

For Kryo certainly, and possibly others, it might be interesting to see how the registration of common Vaadin classes might affect performance - but that could be left for a second iteration.

[mcollovati]

There are many use cases for custom Serialization, but once a serialiser (eg, Kryo) is employed, I cannot think of a reason to drop back into native Java serialisation. Could you give an example of what you are thinking of?

Here I'm thinking more about deserialization; a class could have some transient fileds that will be reinitialized in readObject. As an example we can take vaadin ConnectorTracker class where in readObject there is some logic that fills the transient diffStates map.
In this case if we don't rely on default java serialization we must add a custom serializer reimplementing the existing logic; and this should be done for every class with custom logic.

So my concern is not about performance but about object integrity after deserialization

[davidsowerby]

Ah, now I understand your concern.

At a quick look, the main difference here is that native deserialisation does not use a constructor, Kryo does. Ironically, most transient field initialisation does the same as object construction, but that cannot be guaranteed - some cases may do something completely different. So you are right, potentially there is a need to replicate all readObject() implementations.

This could be a major problem when used with code which you do not control. I wonder if it is worth a question to the Kryo forum - this must surely be a common problem?