directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Re: [jira] Created: (DIREVE-170) Standarzied serialization and deserialization of Name, Attribute, and Attributes.
Date Tue, 28 Jun 2005 04:47:01 GMT
On Tuesday 28 June 2005 08:23, Trustin Lee wrote:

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

Hmmmm... What tests have you actually run? 
You can't do without the FQ classnames of the classes involved. They are 
written in 'clear text' once for each class, then referenced with an index 
(int IIRC). Whether or not you need the field names, is your call, but it 
sounds like a decent system to not depend on knowing the exact ordering.
The codebase URLs is the third item which written out, which of course can be 
very large.


public class Test
    static public void main( String[] args )
        throws Exception
        FileOutputStream fos = new FileOutputStream( "abc.ser" );
        ObjectOutputStream oos = new ObjectOutputStream( fos );
        Abc abc = new Abc();
        oos.writeObject( abc );

    private static class Abc implements Serializable
        String abc = "1";
        String def = "2";

Typically case???  Well, it results in 75 bytes.

>  What if the name of class changes? 

I assume this is a rhetorical question, since I am sure you know the answer. I 
am interesting to know how you are going to handle that in your own 
serialization framework.

>  And if we implement readObject and 
> writeObject by ourselves, why do we use ObjectOutputStream? 

Because you don't need to worry about complex classes, and diving into the 
hierarchies of instances, which you would for both "rolling your own" as well 
as Externalizable.

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

Serialization writes the field names to the stream, so that it can restore the 
fields even if they were re-ordered in the class. I think you have observed 
that when you use writeObject(), the field names are till written to the 
stream. I don't know the answer to that, since the deserialization can not 
possibly know what to do with it. 

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

If they are flat, i.e. basically strings or collections of strings, then I 
agree that serialization is not necessarily any added value. But are you not 
allowed to store any arbitrary Object in attributes? 


View raw message