On Wed, 23 Aug 2000, Mark Wielaard wrote:
> I just committed the following additions to java.util.Collections for new
> 1.3 fields and methods and two small compile patches.
>
> * java/util/Collections.java (EMPTY_MAP) (singletonList(Object)
> (singletonMap(Object,Object)): implemented, new in 1.3.
...
> Note that the new EMPTY_MAP, singletonList and singletonMap are also not
> Serializable just as some other fields and methods in that class. Suns
> spec doesn't give enough information on how the serialized form would
> look. So we cannot easily make them compatible with their version.
> But we should think about how making them serializable anyway.
Yes, Sun's Serialized Form doc leaves much to be desired.
I've been working quite a bit on serialization for libgcj (and will be
sending more patches to it and classpath, for merged classes as
appropriate, over the coming weeks). I've actually been able to achieve
compatibility with the JDK even in cases of non-default serialization and
in spite of the Serialized Form doc. And yes, it is not easy.
To do this I've had to compare the serialized data of the JDK objects to
that of my objects (i.e. from libgcj classes in my case). By following
Sun's serialization spec by hand (and getting good at following the
protocol via hex dumps ;-) I've been able to infer more clearly the
cryptic meaning of the Serialized Form doc based on the differences in the
data.
As this is simply a matter of looking at user data written per a publicly
available spec (and is *not* disassembling any protected code, etc. etc.)
this is in keeping with clean-room practices.
NB: it's not always enough to get the serialized data right; at times
something has to be done in the readObject method to get the object set up
just so. For that, we're pretty much dependent on the Serialized Form doc
(short of deserializing object data and working with the newly
instantiated object to see how it blows up; yes, I've had to do that too).
All in all, serialization is a very tedious thing to get right (as you
well know). I've got some quick & dirty tools I've written for
serialization work/debugging (I'll clean them up a bit and pass them along
to classpath as well as adding them to the libgcj tree). Another good one
is a serialized data dumper (to obviate the need to read hex dumps ;-).
I'll look at making one though if someone is motivated to do this for the
project instead, I won't complain ;-).
BTW, perhaps I misunderstand a statement from the mail sent, but I don't
know what is meant by 'some methods' not being serializable? The methods
themselves are not serialized (though their existance in the class does
affect the serialVersionUID calculated). Sun seems to have been careful
about backwards compatibility when adding new methods to existing classes
such that data serialized by the new class object works fine with the
older version of the class (without the new methods). I believe part of
maintaining that compatibility involves preserving the serialVersionUID
value in the new class (besides careful design of the additional code).
Is there something else I should infer from 'serialized methods'?
Certainly additional class fields affect the serialized data (if they are
non-transient and non-static). The comments in the Sun doc for
java.util.Collections.EMPTY_{SET,LIST,MAP} about these static final fields
being serializable is indeed odd in this regard (as well as the
mentioning of the apparently related inner classes EmptyList and EmptySet
(but NOT EmptyMap) in the 1.3 Serialized Form doc). These are obviously
related (and the lack of EmptyMap in the doc may be an oversight). And
from seeing the slew of java.util.Collections inner classes listed in the
1.3 Serialized Form doc, serialization for Collections certainly is not
trivial to implement; you have my sympathy ;-) as well as my appreciation.
--warrenl
