From: Tim Wilkinson (tim@transvirtual.com)
Date: Mon Jan 25 1999 - 20:14:36 EST
Godmar,
Well the new methods would be public so Sun could complain about that (after
all there are no readObject methods which take an option string identifier).
More to the point though, does being able to serialize in XML seems like a
good idea? Also, does allowing the use of a simple tag in the serialization
operation seems a good way to do this, and could it be useful for other
things?
Tim
> 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
-- 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