Review Request and Testing Question on: Remove unnecessary field and methods from NoSuchMechanismException

Alan Bateman Alan.Bateman at oracle.com
Mon Aug 22 09:56:03 UTC 2011


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].
> First of all i thought just changing the serialversionUID was the 
> right solution, but Alan disagreed and i actually think that too. 
> Unfortunatly Alan doen't had the time to explain it in detail, but i 
> think that we must search for a solution that doen't break backward 
> serialization compatability.
As you've found then changing the serialVersionUID would is an 
incompatible change and removing a field is usually problematic too. I 
see you've got an updated webrev where you implement readObject and 
writeObject and that seems the right approach to me. I think it makes 
sense to split this one out from the other clean-ups and to that end 
I've created a separate bug for it:

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

As this exception class came via JSR-105 (XML-DSIG) then I think it's 
best to get it reviewed on security-dev as that is where the XML-DSIG 
code is maintained.

I see in your other mail that you asked about creating an automated 
test. I think the best you can do is save the serialized form of the 
exception with a build of openjdk6 or 7 and use that in the test that 
will go into jdk8's test directory. We try to avoid checking in binary 
files into the repository so having a byte[] in the test with the bytes 
is probably the only thing you can do.

-Alan.



More information about the core-libs-dev mailing list