harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@gmail.com>
Subject Re: [classlib][swing] Serialization of Swing classes
Date Sat, 11 Nov 2006 19:30:41 GMT
Well, if a consumer is looking for 'serialVersionUID' fields to
indicate the strength of the serialization contract, then they're
going to be thrown off by the fact that the class implements
Serializable in the first place.

As for regenerating the 'serialVersionUID' field when a class is
changed, I would consider this of little concern, since there are no
guarantees between the serialization interop of VMs and the interop
between different versions of a single VM.

I would say there are really only two valid considerations in this
discussion: code style and the possibility of a small runtime

Code style - It would clean up the code a bit remove the fields, but
I'd also add @SuppressWarnings() annotations to the respective
classes, so if anyone doesn't like that it could weigh on this.

Runtime optimization - I'm not positive of this, nor do I completely
understand the actual affect, but wouldn't explicit 'serialVersionUID'
fields mean that when those classes are actually serialized, a UID
wouldn't need to be generated at runtime, correct? Now, I'll be the
first to admit, this is a micro optimization, so it doesn't carry to
much weight. However, I am curious about the details of the reality
behind this thought, so if anyone knows, please post.


On 11/11/06, Zakharov, Vasily M <vasily.m.zakharov@intel.com> wrote:
> Nathan,
> Yes, there is some harm - someone could change the classes in future and
> forget
> to change the serialVersionUID. Also adding serialVersionUID implies the
> serialization
> compatibility is important, which is not the case.
> Regards,
> Vasily Zakharov
> Intel Middleware Products Division
> -----Original Message-----
> From: Nathan Beyer [mailto:nbeyer@gmail.com]
> Sent: Saturday, November 11, 2006 7:48 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classlib][swing] Serialization of Swing classes
> If there's no need for serialization compatability between VMs and
> versions of a VM, then is there any harm in adding explicit
> serialVersionUID fields?
> On 11/10/06, Ivanov, Alexey A <alexey.a.ivanov@intel.com> wrote:
> > Nathan, all,
> >
> > You shouldn't add explicit serialVersionUID because Sun explicitly
> states that serialized form of Swing classes maybe incompatible with
> future Swing releases. And there's no description of serialized form for
> any Swing class.
> >
> > I'm pretty sure Harmony is not compatible with Sun classes with regard
> to serialized from of Swing classes. And new fields can be added to a
> class or removed, which will break the serialized form.
> >
> > See the Warning in JTree JavaDoc:
> http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/JTree.html
> >
> > The serialVersionUID declarations were intentionally missed.
> >
> > Regards,
> > Alexey.
> >
> >
> > P.S. Thanks for cleaning up the code to use parameterized types where
> possible.
> > I've looked through j.s.BasicSwingTestCase and restricted the type
> parameter, as well as refactored the code accessing Swing components so
> that it always runs on the Event Dispatch Thread. See
> https://issues.apache.org/jira/browse/HARMONY-2078.
> >
> > Also I've cleaned up some classes where I fixed bugs:
> > https://issues.apache.org/jira/browse/HARMONY-2089
> > https://issues.apache.org/jira/browse/HARMONY-2119
> > https://issues.apache.org/jira/browse/HARMONY-2121
> >
> > --
> > Alexey A. Ivanov
> > Intel EnterpriseSolutions SoftwareDivision
> >

View raw message