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

[Peter Levart]

Hi Mandy,

On 08/17/2018 05:20 PM, mandy chung wrote:
> Hi Peter, Jason, Joe,
>
> Thanks for the pointers.  I have missed the use of
> serialPersistentFields (thanks to Peter for calling this out).  I read
> the javadoc and serialization spec but that didn't come clearly to me.
> It'd be good to include an example in the javadoc (will file a JBS 
> issue).
>
> W.r.t. the package-private API to set the cause in EIIE [1], yes it's
> needed and it's done in webrev.01.  Let me redo the
> readObject/writeObject part and send a new webrev.
>
> Mandy
> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8209553/webrev.01/src/java.base/share/classes/java/lang/Throwable.java.sdiff.html 
>

I think it would be nicer to keep all the logic in one place 
(EIIE.readObject()) and make Throwable.setCause() plain unconditional 
setter. For example:

void readObject(....

     Throwable exception = ...
     if (getCause() == null && exception != null) {
         setCause(exception);
     }


Regards, Peter

>
> On 8/17/18 8:05 AM, Jason Mehrens wrote:
>> Hi Mandy,
>>
>> This what we were doing in the past and has examples of removing
>> fields with expected tests: 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051339.html
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017594.html 
>> >
>> However, this case is a little different because it actually
>> disallows subsequent initCause.  I would assume that will get tricky
>> if you deserialize the old binary form in a newer JDK because we
>> would have to jump through some hoops to update null to the cause
>> exception.
>>
>> Jason
>>