Well as we are using SExpressions for the serialisation the class UID
actually has no real effect on whether a class is compatible as it is
purely up to the Sexp parser/unparser to cope and has no bearing on
whether the class method/field signatures have changed.
(P.S. I do have a maven script to generate a file listing all the
current UID's - currently it would be a hand-job to then edit the java
source files)
Sean
On Wed, 2004-06-09 at 17:03, Sameer Ajmani wrote:
> The problem with this is if the classes change in an incompatible way, the
> coder needs to remember to change the serialVersionUID or else there could
> be strange runtime failures. The purpose of UIDs is to detect when these
> changes occur automatically (and throw an exception when incompatible
> deserialization happens), so I hesitate to change this. Perhaps there's a
> way to pre-process the code for your purposes (using a script, e.g.) so
> that you can speed things up without changing the JSDSI mainline?
>
> Sameer
>
> > Any objections to me placing serialVersionUID's on the Serializable
> > classes to speed things up (and help class compatibility)?
> >
> > Sean
> >
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> > http://www.aegeus-technology.com
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: GNOME Foundation
> > Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
> > GNOME Users and Developers European Conference, 28-30th June in Norway
> > http://2004/guadec.org
> > _______________________________________________
> > Jsdsi-devel mailing list
> > Jsd...@li...
> > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
>
>
> http://ajmani.net
>
--
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com
|
