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

[Jason Mehrens]

Hi Mandy,

Like in previous patches, I advocated for using 'super.getCause()' in writeObject to avoid any subclass hooking into serialization.  I even lean towards the legacy getXXX methods call super.getCause too so they are compatible with previous behavior.

Does Throwable.setCause need a more obscure name encase there are subclasses of throwable in the wild with that signature?

EIIE has double semi-colon in the constructor and PAE has a random javadoc modification.

Cheers,

Jason


________________________________________
From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of mandy chung <mandy.chung at oracle.com>
Sent: Thursday, September 13, 2018 1:49 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:
> 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