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

[joe.darcy at oracle.com]

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