directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: [jira] Created: (DIREVE-170) Standarzied serialization and deserialization of Name, Attribute, and Attributes.
Date Sat, 25 Jun 2005 05:55:24 GMT
On Friday 24 June 2005 22:11, Trustin Lee (JIRA) wrote:

Couple of notes;

> Using Java serialization has couple of cons:
>
> * Slow

That is a very relative term. Compared to other generic serialization 
mechanisms I don't think it fairs much better or worse.

> * Resulting data is big

Again, very relative term. There is only one way to make it smaller than it 
already is, and that is to introduce sensible defaults for primitives, which 
are not serialized if it can be avoided. This tend to only work for 
JavaBeans, and the java.beans.XMLEncoder/XMLDecoder is utilizing this 
strategy.

Now, MOST of the cases I have looked into when claims of "data is big", and 
often related to "slow", is that people have code that are coupled together, 
so that more objects are serialized than one thought. Instead of a small 
vector of objects, the entire application gets serialized due to some 
listeners, for instance.

> * Serialized data might be unable to read due to class signature changes

This is not true. If you do your home work properly, you can make fairly 
extensive changes without becoming incompatible, both forward and backward.


Also, making proper Serializable code is not only a matter of adding 
java.io.Serializable to every class. That will most likely not work well. It 
takes quite some thinking of figuring out the purpose, patterns and usages of 
transient and/or the use of readObject/writeObject.

I must say I don't know where you are using Serialization in DS, so I don't 
know where this have bearing, and whether it is worthwhile bothering about. 
End of the day, many of the same issues will take center-stage even with your 
own package.


Cheers
Niclas

Mime
View raw message