RFR JDK-8209553: ExceptionInInitializerError can have a default detail message if the cause is given
mandy chung
mandy.chung at oracle.com
Thu Aug 16 23:54:37 UTC 2018
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
More information about the core-libs-dev
mailing list