hg: jdk8/tl/jdk: 7080020: Add conventional constructors to InternalError and VirtualMachineError
sebastian.sickelmann at gmx.de
Fri Aug 26 12:49:47 PDT 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
> 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?
More information about the core-libs-dev