7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException
Sean Mullan
sean.mullan at oracle.com
Tue Sep 27 15:38:14 UTC 2011
On 9/24/11 5:55 AM, Sebastian Sickelmann wrote:
> Am 23.09.2011 20:54, schrieb Sean Mullan:
>> On 9/17/11 3:09 PM, Sebastian Sickelmann wrote:
>>
>>>> i have updated the webrev [0].
>>>> But i think that L69 and L72 of the test should be changed to
>>>> checkMutable and the implementation of the exceptions accordantly.
>> That's an interesting question. The current implementation in your code is
>> consistent with java.lang.ClassNotFoundException. I'm curious as to why they
>> disallowed initCause to be called even if they were created using the
>> constructors without Throwables. Any idea? Was this discussed in the other lists?
> I don't know. I can't find anything in the archives (don't know in which
> time i must search; The commit in ClassNotFoundException is prior rev 0)
>
> @core-libs-dev: Does someone remember why this solution was preferred
> for ClassNotFound?
See: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4385429
I think I know the reason. If you allow initCause to be called when a cause is
not initially provided, then getCause will still return null, which seems wrong.
> For javax/xml/crypto i would change it to my suggestion (to L69 and L72)
> above to not break behavior for JSR105. On the other side it would be
> nice to have a common behavoir on this for all Exceptions in JDK.
>
> There are 2 solutions that sound reasonable for me:
> 1. Preventing initCause when cause is given. And allowing initCause once
> (if created with an ctor without cause).
> 2. Preventing initCause in every exception class that has the 4 standard
> ctors. Only for those Exceptions without the "ctors with cause" the
> initCause can be called.
>
> I like both.
> No.1 is nearer to the behavoir we actually have and is more flexible
> than No.2.
> No.2 is more "secure". You cannot "inject" an cause in ex. after you
> catches the exception. But you must have the cause to initialize it
> before you create the exception, this is slightly more inflexible, even
> if i think this flexibility is not needed anywhere.
>
>
>>>> [0] http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/7011804_3
>>>>
>>>> -- Sebastian
>>> Any comments / progress on this?
>> Just a couple of minor comments on the test:
>>
>> - the copyright date should only include 2011
>> - some minor typos (line number in []):
>>
>> [26] s/in/is
>> [43] s/validating/validate
>> [98] s/checkImutable/checkImmutable
>>
> Updated webrev:
>
> http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/7011804_4
BTW, the popup ads on this site are very annoying. Can you move your webrev to a
different site?
--Sean
More information about the security-dev
mailing list