Thomas Dudziak wrote:
There are serveral classes in OJB that implements java.io.Serializable
but do not define explicit serialVersionUID fields.
Any objections if I would go ahead and check generated UID:s in?
Any side-effects with that (other than the JRE i use using generation
beeing normative)?
no objections from me, though we would get a different problem with
this because we have to update the uid when a significant change (for
serialization) was made to the class.
Yes, but that's the whole point of serialVersionUID so I think it's OK
if that is the only issue. As long as we don't change the number, minor
but compatible changes in the code will still make a serialized object
loadable.
When making incompatible changes just update the number and the JRE
will report that older objects are no longer loadable with newer class
files.
Armin replied through private e-mail (due to SMTP problems) and he is
about to port many 1.0.x changes from the branch to trunk and asked
not to make any changes that affect lots of classes in the trunk
so I would only start doing this on the 1.0.x branch and primarily
only the classes involved in OJB-105 (and later extend it to all
Serializable classes and also the trunk).
Cheers,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
