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