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@sebastian-laptop:/usr/lib/jvm/jdk1.6.0_25/bin$ serialver
java.lang.VirtualMachineError
java.lang.VirtualMachineError: static final long serialVersionUID =
4161983926571568670L;
sebastian@sebastian-laptop:/usr/lib/jvm/java-7-openjdk/bin$ serialver
java.lang.VirtualMachineError
java.lang.VirtualMachineError: static final long serialVersionUID =
4161983926571568670L;
sebastian@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
