hg: jdk8/tl/jdk: 7082727: VirtualMachineError should declare its serialVersionUID

Sebastian Sickelmann sebastian.sickelmann at gmx.de
Thu Aug 25 21:48:55 UTC 2011


Am 25.08.2011 22:53, schrieb Dr Andrew John Hughes:
> On 16:43 Thu 25 Aug     , joe.darcy at oracle.com wrote:
>> IChangeset: 624cc18a6cf9
>> Author:    darcy
>> Date:      2011-08-25 09:42 -0700
>> URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/624cc18a6cf9
>>
>> 7082727: VirtualMachineError should declare its serialVersionUID
>> Reviewed-by: alanb
>>
>> ! src/share/classes/java/lang/VirtualMachineError.java
>>
> Is there a general policy on serialVersionUIDs within the JDK i.e. that they are declared?
> I've seen a few warnings during builds, and I'm wondering what the correct fix is in the
> majority of cases.
I think that every Serialezable Class in the jdk should declare a 
serialVersionUID to achieve compatibility  between versions of the jdk.
If not at the moment the default serialVersionUID changes (not only on 
changing non-transient instance-fields as a thought) the compatibility 
will break.

And as 
http://download.oracle.com/javase/7/docs/platform/serialization/spec/class.html#4100 
specifies it breaks on "simply change (add,remove,signature-change) 
non-private constructors. Even changing a non-private method can change 
the default serialVersionUID which is a shock for me. This two 
dependencies(constructors,methods) to serialVersionUID calculation 
doen't make any sence to me.
Does someone know why?
I think that there is no way of changing this in future, isn't it?

-- Sebastian



More information about the core-libs-dev mailing list