From: Tim Wilkinson (tim@transvirtual.com)
Date: Mon Jan 25 1999 - 19:02:59 EST
All,
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.
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 raise this issue for comment before I go off and start doing this.
Cheers
Tim
-- Tim Wilkinson Tel: +1 510 704 1660 Transvirtual Technologies, Inc., Fax: +1 510 704 1893 Berkeley, CA, USA. Email: tim@transvirtual.com
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:48 EDT