Request for review Remove "private" cause in jdk exceptions

Sebastian Sickelmann sebastian.sickelmann at gmx.de
Fri Aug 26 11:15:17 UTC 2011


Am 26.08.2011 09:22, schrieb Alan Bateman:
> Sebastian Sickelmann wrote:
>>
>> OK. Webrev is there: 
>> http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_8018d541a7b2_2/ 
>>
>>
>> Can someone review this?
> I think this one will require careful review and I'm not even sure 
> that it's worth it. Using serialPersistentFields and overriding the 
> readObject/writeObject method is the right thing for this kind of 
> issue but it's bringing complexity that hardy seems worth it. 
As Peter noted in his reply there is another solution to handle chaining 
as introduced in Throwable for Exceptions that already has an own cause 
field.
Like in InvocationTargetException [1]. The Change is much simple and 
introduces much less complexity, for the cost of one additional 
reference to the cause (which should be no problem).

> There are a few awkward issues in here. I have to admit that I don't 
> know, without checking, what the deal is with APIs that continued life 
> as standalone JSRs after going into Java SE. I also suspect that some 
> of these changes have subtly changed the behavior of a few of the 
> exceptions. On RemoteException the patch removes a public field which 
> we can't do. I think the other clean-up patches that you have posted 
> here in the last week or two are good and we should move forward on them.
I will continue on the other issues too. Thanks for reviewing/supporting 
on my CRs. (Does CR mean Change Request???)

-- Sebastian
>
> -Alan.
[1] 
http://hg.openjdk.java.net/jdk8/tl/jdk/file/37a05a11f281/src/share/classes/java/lang/reflect/InvocationTargetException.java



More information about the security-dev mailing list