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?
The main challegne, I think, would be the deserialization of an old
ExceptionInInitializerError.exception into new Throwable.cause in case
the stream did not have Throwable.cause (which is the case for old
ExceptionInInitializerError(s))
Ragards, Peter
On 08/15/2018 11:46 PM, mandy chung wrote:
ExceptionInInitializerError(Throwable cause) sets the detail message
to null. It'd be helpful to include a detail message rather than null
as in Throwable(Throwable cause) that constructs a new throwable
with a default message cause==null ? null : cause.toString().
This would help troubleshooting of writing new bootstrap methods
where VM currently asserts non-null linkage error message [1] where
there are other solutions such as constructing the message in
the VM or removing the assert.
This patch proposes to change ExceptionInInitializerError(Throwable
cause)
to default the detail message to cause.toString() if cause is not null.
It's an incompatibility change; for example existing code that expects
a null message will now see a detail message. But the compatibility
risk should be low as EIIE should be fatal.
This also proposes to add new LinkageError(Throwable cause) constructor
to retrofit the exception chaining mechanism and that allows to clean up
the current ExceptionInInitializerError implementation.
Webrev:
http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8209553/webrev.00
I will create a CSR.
Mandy
[1] https://bugs.openjdk.java.net/browse/JDK-8208172
