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 optimization. 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. -Nathan On 11/11/06, Zakharov, Vasily M <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 >
