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

Sebastian Sickelmann sebastian.sickelmann at gmx.de
Thu Aug 25 08:02:25 UTC 2011


Am 25.08.2011 08:28, schrieb Alan Bateman:
> Joe Darcy wrote:
>> Hi Alan.
>>
>> I did check for that point in my review :-)
>>
>> The VirtualMachineError class is abstract so as long as all its 
>> subclasses declare a serialVersionUID, like InternalError does, I 
>> think we're fine.
> We need to check the serialization protocol but I'm pretty the object 
> stream class of the supertype goes into the stream too. Also I quickly 
> checked an an up-to-date build of jdk8/tl and its currently unable to 
> deserialize streams contain any of the virtual machine errors like 
> OutOfMemoryError, StackOverflowError, etc.
>
> -Alan.
Hi,

I understand the problem with the missing serialVersionUID after i read 
the Object Serialization Specification completly. Even if i don't see a 
reason why the signatures of the constructors are part of the 
calculation of the default serialVersionUID.

But i got another problem. I tried to check the serialVersionUID of 
VirtualMachieneError and got always the same results for jdk1.6.0, 
openjdk7 and my freshly build openjdk8 with updated VirtualMachineError.

Am i doing something wrong? I put my output of serialver in the 
following lines.

sebastian at sebastian-laptop:/usr/lib/jvm/jdk1.6.0_25/bin$ serialver 
java.lang.VirtualMachineError
java.lang.VirtualMachineError:    static final long serialVersionUID = 
4161983926571568670L;

sebastian at sebastian-laptop:/usr/lib/jvm/java-7-openjdk/bin$ serialver 
java.lang.VirtualMachineError
java.lang.VirtualMachineError:    static final long serialVersionUID = 
4161983926571568670L;

sebastian at sebastian-laptop:~/deve/openjdk8-jdk-only/build/linux-i586/j2sdk-image/bin$ 
serialver java.lang.VirtualMachineError
java.lang.VirtualMachineError:    static final long serialVersionUID = 
4161983926571568670L;

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?

-- Sebastian



More information about the core-libs-dev mailing list