serialVersionUID update

Larry O'Leary loleary at redhat.com
Thu Apr 11 15:08:10 UTC 2013


On Thu, 2013-04-11 at 10:05 -0500, Larry O'Leary wrote:
> On Thu, 2013-04-11 at 11:00 -0400, Jiri Kremser wrote:
> > > 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
> 
> That is my point. User's don't use the CLI. They use the remote API
> within their own "compiled" applications. 

I should have said, user's don't "just use" the CLI...


> This changes will result in my applications breaking due to an API
> change (class signature). Thus, we would require them to rebuild all
> their code. Thus meaning they can not upgrade until they do so. Thus
> meaning that it is a breaking change. Thus meaning that the animal
> sniffer is reporting exactly what it should be. That this is a breaking
> change that will require any dependent class/application to be modified
> and/or rebuilt.
> 




More information about the rhq-devel mailing list