<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-15">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    Hi,
    <br>
    <br>
    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].
    <br>
    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.
    <br>
    <br>
    I created a webrev for my suggested change here:
    <br>
    <a class="moz-txt-link-freetext"
href="http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_8018d541a7b2/">http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_8018d541a7b2/</a>
    <br>
    <br>
    In a following post Alan writes that this should best be discussed
    here. What is the hg repository for patches in this mailinglist? I
    don't see any security-dev related repository for openjdk8 in
    <a class="moz-txt-link-freetext" href="http://hg.openjdk.java.net/">http://hg.openjdk.java.net/</a> the patch is based on <b><a class="list"
        href="http://hg.openjdk.java.net/jdk8/tl/jdk/"><b></b></a></b>jdk8/tl/jdk
    maybe i should rebase it onto another repository. <br>
    <br>
    Another problem i have is testing. I think we should add some test
    for this. But got no real clue how to do it right. I tested it
    manually with the source here[2] and the files in here[3].<br>
    <br>
    The files are created with an openjdk7 build(Unfortunatly i think
    with an quite old private build) and with an openjdk8(with my
    patches to NoSuchMechanismException). I tested it manually with my
    openjdk 7 and 8 build and in both cases the serialized objects could
    be loaded correctly in all cases.
    <br>
    <br>
    What is the best way to test this automatically. I thought about
    checking if the newly created openjdk8 serialization is binary equal
    to the jdk7 output, but it isn't because of some unavoidable changes
    (ex. jdk8 has the custom-serialization-bit)
    <br>
    <br>
    Alan mentioned that it may be ok to embed some serialized-objects as
    byte[] in testcode.<br>
    I will try to create a jtreg for this. Hope to be back on this soon.
    In the meantime it would be great to have someone reviewed the
    webrev.<br>
    <br>
    @core-libs-dev: I crosspost it to core-libs-dev because the thread
    started there. So the interessted parties can move over to
    security-dev archive[4]<br>
    <br>
    -- Sebastian
    <br>
    <br>
    [1] <a class="moz-txt-link-freetext"
href="http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007462.html">http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007462.html</a>
    <br>
    [2] <a class="moz-txt-link-freetext"
href="http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/SeriallizeTest.java">http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/SeriallizeTest.java</a>
    <br>
    [3] <a class="moz-txt-link-freetext"
      href="http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/">http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/</a><br>
    [4]
<a class="moz-txt-link-freetext" href="http://mail.openjdk.java.net/pipermail/security-dev/2011-August/thread.html">http://mail.openjdk.java.net/pipermail/security-dev/2011-August/thread.html</a><br>
  </body>
</html>