| Niclas Hedhman 2005-06-28, 2:49 am |
| 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.
import java.io.*;
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 );
oos.close();
}
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?
Cheers
Niclas
|