JBSER-84 - Improving serialization

[clebert.suconic]

It is possible to avoid duplication of immutable objects...

Say if in a object tree, you have the same immutable object twice, we could consider it as a single object. That would save streaming size and possibly CPU as the serialization time would be probably higher than looking up in a HashMap.

A question that I have though: Dates are not immutable... Is there any date object known to be immutable?

Michael Nascimento, the one who originally requested this issue is driving a JSR about dates.. I guess he would be able to give some ideas on this subject also.


Clebert

[clebert.suconic]

I talked to Michael privately... and we both agreed it would be nice to have an API to configure that.

We should definetly have a constructor with a list of immutable objects, but it would be nice also to have some sort of annotation... maybe an empty interface (implements org.jboss.jbser.UserImmutable). or any other options.

This way, if an user has a immutable object, such as.. InvoiceID, EAN... or whatever... maybe users would be able to make usage of that even under frameworks such as EJB, Seam or JBossCache.

I'm wondering what would be the simplest and more intuitive API possible here. I will make up something next week and I will post on this thread before coding it.

[clebert.suconic]

I'm adding an interface org.jboss.io.Immutable that can be used to mark Immutable user classes.

If you use that interface and you have two identical objects ( by hashCode and equals definitions) these will be replaced by a single reference when the streaming is being parsed.

This didn't add any incompatibility issues as this change only affects how IDs are generated on writeObject. This didn't cause any change on the protocol.

[mister__m]

I think there are two use cases that would require a different API. First, if you are working with a third-party class, you may not be able to change it to implement Immutable.

Another scenario is when it is safe to replace a Class, but it is not actually immutable. For instance, there might be a JavaBean named Order. When an order is equal to another one, it can be safely replaced, but it is not actually immutable.

So I suggest the interface is renamed to Replaceable and a method is added to JOS that allows use-case replaceable classes to be registered.