serialVersionUID update

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


On Thu, 2013-04-11 at 10:59 -0400, Michael Foley wrote:
> 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?
Yes and yes.

This change would require the developer to rebuild and release a new
version of their plug-in or client code.
> 
> ______________________________________________________________________
> 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
> 
> 
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel

-- 
Larry O'Leary
https://plus.google.com/u/0/112645929986009801513



More information about the rhq-devel mailing list