directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <>
Subject Re: [jira] Created: (DIREVE-170) Standarzied serialization and deserialization of Name, Attribute, and Attributes.
Date Tue, 28 Jun 2005 00:23:11 GMT
Hi Nick,
 2005/6/25, Niclas Hedhman <>: 
> 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.

 Yes, using Externalizable interface will boost up this, but it requires a 
default constructor.

> * 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.

 The biggest problem is the class descriptors written by ObjectOutputStream. 
It is sometimes even bigger than actual object data. We can override some 
protected methods to store the descriptors somewhere else, and it makes the 
serialized data dependent to the descriptor database.
  I even saw the case that SMS message object is serialized 2kB data because 
its class descriptor took up 1.4kB.

> * 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
> 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.

 What if the name of class changes? And if we implement readObject and 
writeObject by ourselves, why do we use ObjectOutputStream? Moreover, it 
adds extra metadata that indicates each field's type that increases the size 
of serialized data. If we implement readObject and writeObject manually, 
there's no need to include those metadata IMHO.

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.

 My aim is to create compact and fast codec for LDAP-specific entities 
(LdapName, Attribute, Attributes) that is Java-independent so that they are 
used to create another protocol based on ApacheDS or to store data in 
Java-independent way.
what we call human nature is actually human habit

View raw message