serialVersionUID update

Michael Foley mfoley at redhat.com
Thu Apr 11 14:59:31 UTC 2013


Right. 

I guess the questions for me are: 


    * would a plugin break with this change? 
    * would client code (a java class, or CLI code) break with this change? 



----- Original Message -----

From: "Larry O'Leary" <loleary at redhat.com> 
To: rhq-devel at lists.fedorahosted.org 
Sent: Thursday, April 11, 2013 10:49:11 AM 
Subject: Re: serialVersionUID update 

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? 
-- 
Larry O'Leary 
https://plus.google.com/u/0/112645929986009801513 

On Thu, 2013-04-11 at 10:12 -0400, Jay Shaughnessy wrote: 
> +1. It should be private. 
> 
> On 4/11/2013 9:26 AM, Lukas Krejci wrote: 
> > The api check fails on the serialVersionUID in SavedSearchCriteria, because it is unnecessarily defined as public. This field really should be private. I believe Clirr wouldn't complain in that case. 
> > 
> > I intentionally set the api checks to fail even on warnings, because I believe explicitly ignoring changes that Clirr only reports as warnings is good for documentation purposes. 
> > 
> > In this concrete example, changing a value of a public constant is potentially dangerous, because such values can be inlined by javac. If a 3rd party library was compiled against an older version of the jar with such constant, the library would still use the old value even if the new version of the jar with new value of the constant was present at runtime. 
> > 
> > So, I'd rather change the serialVersionUID to private static final long as it should have been declared from the very beginning (and add an ignored difference for that change, because it is harmless (with 99.999999% certainty, because nobody really should ever be interested in the value of that field) and let Clirr continue report warnings as errors, rather than the other way round. 
> > 
> > Lukas 
> > 
> > ----- Original Message ----- 
> >> From: "Jiri Kremser" <jkremser at redhat.com> 
> >> To: rhq-devel at lists.fedorahosted.org 
> >> Sent: Thursday, April 11, 2013 11:29:53 AM 
> >> Subject: serialVersionUID update 
> >> 
> >> Hi, 
> >> the recent changes to serialVersionUID on criteria classes and few domain 
> >> entities require agent reinstallation. 
> >> So if you see something like this in your server log 
> >> 
> >> 1) java.io.InvalidClassException: org.rhq.core.domain.resource.ResourceType; 
> >> local class incompatible: stream classdesc serialVersionUID = 2, local class 
> >> serialVersionUID = 3 
> >> 
> >> or 
> >> 
> >> 2) Invalid type signature for org.rhq.core.domain.criteria.ResourceCriteria 
> >> 
> >> don't panic, simple agent reinstallation should fix case 1) for 2) I did a 
> >> clean build, but building core/domain, server/jar and coregui is probably 
> >> fine as well 
> >> 
> >> Btw. our api-checks are still failing because the change of serialVersionUID 
> >> on watched classes produces a warning and clirr is set up to fail on 
> >> warnings (this can be turned off). 
> >> 
> >> jk 



_______________________________________________ 
rhq-devel mailing list 
rhq-devel at lists.fedorahosted.org 
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/rhq-devel/attachments/20130411/6c2fd052/attachment-0001.html>


More information about the rhq-devel mailing list