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 >
