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.
Nit: PrivilegedActionException.java
75 *Memory
is missing a space after the *.
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:
http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8210721/webrev.00/
Mandy
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054878.html
