From: Godmar Back (gback@cs.utah.edu)
Date: Mon Jan 25 1999 - 19:43:02 EST
Upfront, I admit I don't fully understand the issues.
>
> I'm planning to revisit object serialization soon and got to thinking
> about how it should be done....
>
> First off, we obviously need a complete readObject/writeObject method
> per class since we can't guarnatee (nor do I want to guarantee) that
> Kaffe classes match Java classes. In some sense this renders the
> default read and write mechanisms fairly useless, except as a fall back
> for 'user' objects. I'm half inclined (but I won't do it) to force
> applications to implement read/writeObject too - but this would
> obviously break too much.
My take is that it is of course such that you have to either match
Sun's serial form through the default mechanism or you have to write
a writeObject/readObject method. However, I do not think it renders
writeObject/readObject practically useless. Classes such as
java.lang.Number and subclasses should not need a custom method,
for instance.
Also, keep in mind that you can use the transient keyword to exclude
variables from default serialization. By doing that, you may be able
to serialize Exceptions properly using default serialization.
>
> Then I had another thought- I should split out the actual serialization
> protocol from the serializing objects - so we get both a
> Object{Output,Input}Stream which passes on to an
> BasicObject{Output,Input}StreamImpl. This is kind of like Sockets so
> the actual interface to the serialization system is seperate from the
> implementation. The reason I want to do this is so that I can also
> implement a XMLObject{Output,Input}StreamImpl - that is a serialization
> format with looks like XML. I'm not sure why I want to do this except
> that it seems rather cool to be able to serialize object to and from XML
> - must be useful for something.
>
> What this means is that a writeObject method might look like this:
>
> private void writeObject(ObjectOutputStream s) throws IOException {
> s.writeFloat("LOADFACTOR", loadFactor);
> ...
> }
>
> This obviously introduces new methods to a java.io class (Sun won't be
> happy - there may be ways to avoid this) and they must be used in the
> standard object serialization for all classes. Of course the extra tag
> will just be ignored for standard serialization.
I don't think Sun should care about private or even package-private
methods in java.io.
But other than, it sounds like a good idea to separate the two.
Also, I think what you may want to consider is to use this opportunity
to fix the redundant definitions of functions such as writeDouble
in ObjectOutputStream, RandomAccessFile, and DataOutputStream --- there
should only be one implementation in DataOutputStream IMO, and
ObjectOutputStream and RandomAccessFile should be changed to use it.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:48 EDT