7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException

Sebastian Sickelmann sebastian.sickelmann at gmx.de
Sat Sep 17 12:09:17 PDT 2011


Am 09.09.2011 15:24, schrieb Sebastian Sickelmann:
> Am 08.09.2011 19:47, schrieb Sebastian Sickelmann:
>> Am 07.09.2011 19:51, schrieb Sean Mullan:
>>> On 9/3/11 1:04 PM, Sebastian Sickelmann wrote:
>>>> Am 02.09.2011 21:58, schrieb Sean Mullan:
>>>>> On 9/2/11 1:43 AM, Sebastian Sickelmann wrote:
>>>>>>>> Here is the updated webrev:
>>>>>>>> http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/7011804_0/ 
>>>>>>>>
>>>>>>> Hmm, the main problem I have with this change is that the 
>>>>>>> printStackTrace
>>>>>>> methods will no longer print the stack trace of the cause 
>>>>>>> because it will always
>>>>>>> be null. That doesn't seem right to me, as it could be 
>>>>>>> considered an
>>>>>>> incompatible change, and it will make it harder to debug issues.
>>>>>> The printStackTrace in Throwable calls the overridden getCause().
>>>>>> Maybe we should add @Override to it.
>>>>>> Updated the webrev to:
>>>>>> http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/7011804_1/ 
>>>>>>
>>>>> In that case, my main concern is addressed then. I would probably 
>>>>> want someone
>>>>> from our TCK team to also review it with respect to JSR 105 
>>>>> compatibility, so
>>>>> I'll see if I can find someone.
>>>> Fine, that would be good.
>>>>> But first, can you expand your webrev to include the other 
>>>>> Exception classes in
>>>>> javax.xml.crypto.**?
>>>> The new webrev is here:
>>>> http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/7011804_2/
>>> In some classes the initCause comment is misspelled as initCaus. 
>>> What about a
>>> test case, for example testing to make sure initCause throws an 
>>> exception? Can
>>> you write one?
>> While creating an test(suggested code below) for this, i thought a 
>> little bit about if it is really good to change the behavoir of the 
>> ctors without a cause (defaultctor, ctor with message).
>> What is the best behavoir (see DEFAULT and MESSAGE_ONLY cases below) 
>> . Should in the cases DEFAULT and MESSAGE_ONLY the cause mutable? I 
>> actually think this would the better solution, cause it is what the 
>> users can actually do with the exceptions in javax/xml/crypto. Or 
>> should the test check on imutability in all cases?
>>
>>> Also, I have asked someone from the TCK team to look at this and he 
>>> said he will
>>> do that by Friday. It might require a CCC change because the 
>>> behavior of
>>> initCause is different. I am hoping it doesn't require a JSR 105 
>>> maintenance
>>> revision though.
>>>
>>> --Sean
>>
>>
>>
> 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.
>
> [0] http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/7011804_3
>
> -- Sebastian
Any comments / progress on this?
-- Sebastian



More information about the security-dev mailing list