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