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

[Sebastian Sickelmann]

Am 22.08.2011 17:28, schrieb Sean Mullan:
> (dropping core-libs-dev)
>
> On 8/22/11 9:03 AM, Sebastian Sickelmann wrote:
>> Hi,
>>
>> while making some change for using exception-chaining on RuntimeException in
>> more cases, i found that javax.xml.crypto.NoSuchMechnismException had a private
>> cause field that isn't necessary since throwable can handle it. But just
>> removing isn't that simple as Alan pointed out[1].
> The history behind this is that this API is part of JSR 105. JSR 105 was
> released independently of Java SE as a "standalone JSR" and later integrated
> into Java SE 6 as part of the platform JSR. Thus as I understand, all JSR 105
> API changes need to first go through a maintenance revision of JSR 105.
>
> JSR 105 was designed to be used by applications using JDK 1.2 and up, thus there
> are no API dependencies on any releases later than that. Therefore, this class
> (and other exception classes in JSR 105) included their own methods to capture
> the cause.
>
> I've been aware of this issue for a little while but I did not have the cycles
> to analyze it thoroughly so I am glad you are looking into it.
>
> I think you will find the same issue in the other Exception classes in the
> javax.xml.crypto package and its subpackages. Have you looked at those yet?
>
> I am not sure if removing the 3 overloaded methods qualifies as an API change.
> If so, it would first require it go through a maintenance JSR. I will need to
> ask someone else about that and get back to you.
I checked it for binary compatibility and source compatibility and it 
seems to me that both are preserved. So i don't see any reason cause 
this should be handled as API change.
Have you heard something about this topic?

I have a discussion with Peter Jones and Alan Bateman in this Thread 
(swapped over to core-libs-dev again, cause i made bigger CR) there is 
also a other way of handling cause chaining in a way more like 
Trowable.cause.

I think we should consider to choose this type of change for 
javax/xml/crypto too. So we got only one pattern how to use 
Throwable.cause in cases where a cause-chain was available long time before.

-- Sebastian