RFR JDK-8209553: ExceptionInInitializerError can have a default detail message if the cause is given

[mandy chung]

On 8/16/18 4:48 PM, joe darcy wrote:
> On 8/15/2018 5:10 PM, mandy chung wrote:
>>
>>
>> On 8/15/18 3:20 PM, Peter Levart wrote:
>>> Hi Mandy,
>>>
>>> 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.
>

Looking at the history, it turns out that these redundant fields were 
removed at one point when the exception chaining support was initially 
implemented but it got reverted to fix JDK-4385429.    I have posted a 
proposed patch to remove the private Throwable exception field and also 
clean up a few other exception classes as a separate JBS issue.

http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055415.html

Mandy