serialVersionUID update

Jiri Kremser jkremser at redhat.com
Thu Apr 11 15:00:30 UTC 2013


> I am curious though. Wouldn't a change in serialVersionUID still
> constitute an API change if the affected object is serialized? From what
> I can see, this would be the case and a client using these common
> objects would no longer work.

All the CLI scripts should still work, because there was no _API_ (in terms of language) change. The set of methods for each class is still the same (or larger). If we would allow users to use arbitrary old version of CLI then it would break the compatibility, because the de/serialization wouldn't work. Fortunately, this is not the case, we require the same version on the CLI and RHQ server. By increasing the serialVersionUID we just explicitly say that there was an update in that class and we want the JVM to fail as fast as possible (not to silently do some damage like in bug 950461).

jk


----- Original Message -----
> From: "Thomas Segismont" <tsegismo at redhat.com>
> To: rhq-devel at lists.fedorahosted.org
> Sent: Thursday, April 11, 2013 4:51:22 PM
> Subject: Re: serialVersionUID update
> 
> Le 11/04/2013 16:49, Larry O'Leary a écrit :
> > I am curious though. Wouldn't a change in serialVersionUID still
> > constitute an API change if the affected object is serialized? From what
> > I can see, this would be the case and a client using these common
> > objects would no longer work.
> >
> > Am I missing something?
> >
> 
> It's a static field, so it's not serialized.
> 
> See
> http://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#6250
> 
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>


More information about the rhq-devel mailing list