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.
