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-boun...@openjdk.java.net> on behalf of mandy chung <mandy.ch...@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
