Review Request and Testing Question on: Remove unnecessary field and methods from NoSuchMechanismException
Alan.Bateman at oracle.com
Mon Aug 22 02:56:03 PDT 2011
Sebastian Sickelmann wrote:
> 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.
> 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.
More information about the core-libs-dev