serialVersionUID update

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


On Thu, 2013-04-11 at 11:38 -0400, Jay Shaughnessy wrote:
> I may be wrong but I don't think the plugins are affected.  I don't 
> think there is any serialization going on there.  I think only API 
> changes will affect the plugins, not serialized form changes. The Agent 
> of course is affected but the Agent must be updated, so that's not an issue.

I don't think you are wrong. My statement was general but your thinking
is correct. It wouldn't make sense for a plug-in to
serialize/deserialize these object. And even if it did, it would be
relying on the classes provided by the agent.

> As for client code, it will need to be rebuilt.  That could be 
> considered an API break to some degree.  But the code does not need to 
> change.  I don't think this is any change in the way we've handled 
> remote client apps.  Whether that is an approach we want to revisit, I'm 
> not sure.

This is where my concern is. If the change is necessary and we can't
code around it (which is one of the reasons one should explicitly set
serialVersionUID) then we need to make sure that everyone is aware that
the version this change lands in will require a rebuild of all client
code that uses the remote API.prior to an upgrade being performed. In
other words, if you upgrade, your client code will no longer work. 

>From a developer's perspective, rebuilding doesn't seem like a big deal.
But in the real world, a rebuild usually involves other vendors, release
cycles, testing cycles, etc. In many cases, the process takes three or
more months. Just food for thought.
-- 
Larry O'Leary
https://plus.google.com/u/0/112645929986009801513




More information about the rhq-devel mailing list