tullmann at cs.utah.edu
Tue Sep 24 19:04:30 PDT 2002
> Hah. I didn't fully understand how bizarre and complicated
> serialization can get, and the problem is bit more complex. It turns
> out the that right way to solve these problems is by using the
> ObjectInputStream.GetField and ObjectOutputStream.PutField hackery.
> However, none of that per-field serialization magic is implemented in
> Kaffe. So, I'll just push the current work on my personal Kaffe
> stack, and fix GetField/PutField....
I've had my fill of Serialization. Its way uglier and more
complicated than I ever imagined! And some of the classes and
interfaces defined by the JDK are just lame... But, I it seems to
work for me now.
I've put a diff (200K) here:
I've attached a detailed description of the changes. I've got a
little more testing and some code cleanup to do, but any feedback
would be appreciated.
----- ----- ---- --- --- -- - - - - -
Pat Tullmann www.tullmann.org
Your research fills a much needed gap.
Updated Kaffe serialization from 1.1-level support to include a number
of 1.2 and 1.3 serialization features. There are still a number of
Serialization features that are not supported. (See
ObjectStreamClass.java for a list.) Specifically, this patch adds
support for the 'serialPersistentFields' magic field, implements the
ObjectInputStream.GetField and ObjectOutputStream.PutField (and the
associated methods to use them), and provides the class
ObjectStreamField. Also, included are six new tests of this new
Now, BigInteger, HashMap and HashTable are all serialization-
compatible with JDK1.4. This is accomplished using the standard
serialization customization APIs, and there is no longer any
kaffe-specific magic inner class involved.
Here are some details on the diff:
Removed awkward split between java.io. and kaffe.io. serialization
classes. There were many public methods that shouldn't have been
public, and a good bit of redundant indirection. I believe the
motivation for that structure was to allow multiple serialization
back-ends. However, the JDK-compliant serialization APIs now support
different serialization "back-ends" via subclassing the main
serialization classes. (Though I doubt such usage currently works
The "new" class java.io.ObjectStreamField replaces some of the
kaffe.io. magic with standard Java. This class is pretty poorly
designed, however and supporting it causes more of its own pain (and
Technically, all of serialization could be pure Java because of the
refelection support that now exists in Kaffe. However, the existing
native methods were mostly still useful, and are much faster than a
pure-java approach would be, so I left that (all the native
serialization-related code is in clib/native/ObjectStreamClassImpl.c).
The native code got a good bit simpler, too.
I cleaned up the exception messages generated by Kaffe, so they're
generally better than those provided by JDK1.4. The exception types
thrown by Kaffe match JDK1.4 now (for those situtations that I've
java.io.ObjectStreamField was added to the bootstrap jar, as we
generate a .h from it, and its used by a couple of the core classes to
implement JDK-compatible serializations. All the kaffe.io.Object*
classes were nuked.
The 'make bootstrap' command will now work if the source tree is
distinct from the object tree.
java/awt/Component claims it isn't compatible with Sun's serialization
format, so I removed the serialVersionUID so it won't even try to be
There are some pretty lame O(N*M) algorithms. But N and M are field
counts (which shouldn't get very large), and the costs are only for
the first time a class is encountered. And, its only really ugly if
the in-stream class is fairly different from the in-VM version.
Added six new tests that expose corner cases in serialization,
especially with the GetField and PutField classes. Kaffe even does a
couple things right that the JDK gets wrong. :)
More information about the kaffe