-
-
Notifications
You must be signed in to change notification settings - Fork 8.9k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Added serialVersionUID to all Callables
- Loading branch information
Showing
1 changed file
with
29 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
b807845
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not necessary and possibly undesirable—adding a
serialVersionUID
makes a promise, which you are probably not going to keep, that all future versions of this class will be compatible in their serial form (unless the modifier changes the SVUID too). Omitting the UID just means that the remoting channel will throw an exception when the two sides do not agree on the content of the class, which is much better than the communication silently proceeding but some fields beingnull
without explanation.The real threat is that the serial form of anonymous inner classes is unstable not because of changes in variables in its closure (thus effective fields), but because lexical insertion of another such class above it could change it from e.g.
FilePath$13
toFilePath$14
. (Which would be especially catastrophic if one side has aFilePath$13
with SVUID=1 and the other side has aFilePath$13
also with SVUID=1 which are in fact totally unrelated callables!) Therefore it is safer to refactor all anonymousFileCallable
instances into static nested classes.See also proposed NetBeans plugin hint and examples such as 8a1b069 or 9b0e1fb.
b807845
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Jesse, I generally agree about what you say about serialVersionUIDs. But IMO we usually don't have the problem here that 2 different versions of a class are loaded in different VMs, but that the same version is loaded in 2 VMs of different types and the VMs disagree on the computed versionUID.
I had already such bugs fixed in the past where the master was running on Oracle VM and a slave on J9 VM and they disagreed on the UID.
Setting the serialVersionUID fixed that bug.
b807845
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Converting the callables to static classes is a good idea in any way. It's just that they were too many...
b807845
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a published algorithm for computing the SVUID from a given class, so if J9 gets it wrong then that is a serious bug in that JVM.
(It is fine for alternate compilers to produce subtly different classes from the same source, which could then have different default SVUIDs; but that would not be the issue here since the Jenkins master sends the same
byte[]
bytecode to the slave that it is loading itself—typically whatever the core or plugin developer compiled when performing a Maven release.)Regarding refactoring to static classes, this should be a one-step operation in any modern Java IDE.
b807845
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, be it an error in J9 or not (apparently the algorithm for the UID is not as precise as it looks like on the 1st look - see e.g http://c2.com/cgi/wiki?AlwaysDeclareSerialVersionUid), fact is that we have to cope with it. And as adding a serialversionUID isn't much effort, I see no reason why we shouldn't.
b807845
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just that, as I say, it can be actively harmful if you do add new fields later (or make other important structural changes) and fail to change the SVUID. Declaring an explicit SVUID is necessary if you plan to deserialize objects created by a different version of the code, and are explicitly testing and maintaining serial form compatibility; but this is not the case for Jenkins remoting, where master and slave ought to always be running identical bytecode.
b807845
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW this seems to have caused an error for a dev build user though I am not yet sure why:
b807845
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Never mind, that was from an older build; perhaps this commit corrected it.