Review Request JDK-8210721: Replace legacy serial exception field with Throwable::cause

mandy chung mandy.chung at
Fri Sep 14 17:46:46 UTC 2018

On 9/14/18 4:01 AM, Daniel Fuchs wrote:
> Hi Mandy,
> Looks good to me as well.
> If a JDK 12 exception is deserialized by an earlier version of
> the JDK, then the deserialized exception will have both its
> cause field and custom exception field set to the cause
> (instead of having the cause field null and the custom field
> carrying the cause), but I believe that's benign.

yes that's the implementation of the older JDK and the getCause method 
returns the private exception field.
> Nit:
>   75      *Memory
> is missing a space after the *.

Jason also caught this accidental change in a different thread [1] and also
suggests to call super.getCause since getCause is not final and may be
overridden.  The updated webrev is:

> Obviously no need for another webrev, and no need for a new
> fix if you pushed already...
> best regards,
> -- daniel
> On 13/09/2018 19:44, mandy chung wrote:
>> A few exception classes such as ExceptionInInitializerError, 
>> InvocationTargetException,
>> etc were defined prior to the exception chaining facility and 
>> provides the API to get
>> the cause of the exception. These classes keep its legacy serial 
>> field e.g.
>> ExceptionInInitializerError::exception to get the serialization to 
>> work on older JDK version.
>> During the review of JDK-8209553 [1], Peter and Joe suggest to remove 
>> this legacy
>> serial field and implement the serialization using 
>> serialPersistentFields, readObject
>> and writeObject.   It turns out that these redundant fields were 
>> removed when the
>> exception chaining support was initially implemented but it got 
>> reverted to fix
>> JDK-4385429 since Throwable::setCause rejects any further change as
>> Throwable::cause has been initialized to null.
>> This patch removes these legacy serial field and stores the cause in 
>> Throwable::cause.
>> It's essentially a redo for the fix for JDK-4385429.
>> webrev:
>> Mandy
>> [1] 

More information about the core-libs-dev mailing list