Hi Mandy,
This what we were doing in the past and has examples of removing fields with
expected tests:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051339.html
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017594.html
However, this case is a little different because it actually disallows
subsequent initCause. I would assume that will get tricky if you deserialize
the old binary form in a newer JDK because we would have to jump through some
hoops to update null to the cause exception.
Jason
________________________________________
From: core-libs-dev <core-libs-dev-boun...@openjdk.java.net> on behalf of mandy
chung <mandy.ch...@oracle.com>
Sent: Thursday, August 16, 2018 6:54 PM
To: joe darcy; Peter Levart
Cc: core-libs-dev
Subject: Re: RFR JDK-8209553: ExceptionInInitializerError can have a default
detail message if the cause is given
On 8/16/18 4:48 PM, joe darcy wrote:
>>> Just a question. Why does "private Throwable exception" field in
>>> ExceptionInInitializerError exist? Was it there before there was a
>>> "cause" in Throwable and later still remained there because of
>>> serialization format? Would it be possible to "simulate" its effect
>>> for serialization using "serialPersistentFields" and
>>> ObjectOutputStream.PutField?
>>
>> Thanks for asking. I meant to mention this and it'd be nice to
>> follow up this in a separate issue.
>>
>> The private exception field exists since 1.1 and kept there for
>> serialization. getException in existing releases returns the
>> exception field. I can't think of any way to remove the exception
>> field in JDK n to deserialize it with older JDK x unless JDK x was
>> changed to write the exception field with the cause or getException
>> to return cause.
>
> Just a quick comment, it is possible, although a bit tedious, to remove
> a field and retain serial compatibility if readObject/writeObject
> methods are added to the new version of the class. There are a few
> examples of doing this kind of conversion in the JDK, such as for
> BigInteger.
Thanks Joe. In EIIE case, ideally we should remove the private
exception field and then write that to the serialize stream.
However, PutField::put requires the field to be present in
the current class; otherwise it throws IAE.
ObjectOutputStream.PutField fields = s.putFields();
fields.put("exception", getCause());
I haven't digged the history but I assume a field in BigInteger
was not renamed/removed.
Any other suggestion would be appreciated.
Mandy
