hg: jdk8/tl/jdk: 7080020: Add conventional constructors to InternalError and VirtualMachineError

Sebastian Sickelmann sebastian.sickelmann at gmx.de
Fri Aug 26 19:49:47 UTC 2011


Am 25.08.2011 10:46, schrieb Alan Bateman:
> Sebastian Sickelmann wrote:
>> :
>>
>> I have build(make clean, make all, make images) the jdk-repo only. Or 
>> does i have to pull in the changes of my jdk8/tl/jdk clone to my 
>> jdk8/jdk8/jdk clone to check this?
>>
>> Has someone in the past evaluated if there is a good way to do 
>> regression tests for serialVersionUID in jdk-sources?
> To see the issue then you'll need a build of jdk8/tl rather than 
> jdk8/jdk8 as the changes haven't been integrated into the master yet. 
I have tried both jdk8/tl/jdk and jdk8/jdk8/* (with the changes from 
jdk8/tl/jdk pulled in) an in all version it was printed the old 
serialVersionUID. But never mind, I maybe have done something wrong.
> We really need to get to the point where the entire JDK is built with 
> -Xlint:serial -Werror as it's too easy to inadvertently change the SUID.
But this only protectes for forget of defining an explicit 
serialVerionUID, not an change in it. Or do you think if there is an 
explicit serialVersionUID then the change in it would be noted while 
reviewing?
> Aside from a few specified tests, the tests in the jdk repository 
> don't test serialization compatibility.
Maybe an script that collects all serialVersionUID of the classes in JDK 
can compare it with the new ones and print it for documentation (break 
in compatibility). Or is there a real strict "don't break compatiblity 
ever" policy in jdk developement?
>
> -Alan
>
>
-- Sebastian



More information about the core-libs-dev mailing list