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

[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