On 8/26/2011 12:49 PM, Sebastian Sickelmann wrote:
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?
Yes, such a change *should* be noted during a review, but having the
build break if the policy is broken is a sure way to get the problem
noticed by the integrator is not the developer or reviewer!
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?
Such a script would be a good idea; there would be a few subtleties to
attend to. Our compatibility policies for the JDK is a bit nuanced; the
most detailed writeup of the policies is in this document:
http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy
-Joe
