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