<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Given
          the compatibility risks/impacts with existing providers and
          JSSE implementations, we've decided to withdraw this CSR for
          the time being.</blockquote></div></blockquote></div></blockquote><div><br></div><div>One of the concerns raised by Alan in the CSR was related to SPECjbb2015:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The Grizzly framework is used in SPECjbb2015 for example, will it mean that this benchmark will no longer run on JDK main line?</blockquote><div><br></div><div>I don't have access to SPECjbb2015, but it seems it is using some version of Grizzly 2.x. I decided to check out the 2.4.4-RELEASE branch and it seems the exposure to javax.security.cert is fairly limited and contained to two method implementations in a single class SSLSupportImpl. This class uses SSLSession, but does not implement it.</div><div><br></div><div>An interesting note is that the implementation methods actually do call SSLContext.getPeerCertificateChain(), but then goes on to convert the results to java.security.cert.X509Certificate. This makes no sense, so it is probably an artifact of history. Anyhow, this actually means that Grizzly 2 is already broken on mainline JDKs where the getPeerCertificateChain throws and has no implementation.</div><div><br></div><div>This also means that _if_ SPECjbb2015 works on today's mainline, it will probably continue to do so after the removal, because it's not calling the affected methods in SSLSupportImpl.</div><div><br></div><div>It would be interesting to confirm this by running SPECjbb2015 on a JDK with these APIs removed, but I'm not a licensee so I cannot explore that.</div><div><br></div><div>I'll consider contributing a PR to Grizzly 2.x to replace the SSLSession.getPeerCertificateChain() with SSLSession.getPeerCertificates() and drop the conversion. But I'm not so sure there will be interest in releasing from this branch which seems dormant.</div><div><br></div><div>Cheers,</div><div>Eirik.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite"><div dir="ltr"><div>
        </div>
        <div>I reached out to the BouncyCastle project [3] and they are
          basically OK with the OpenJDK project to go ahead and remove
          the APIs:</div>
        <div><br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It's
          a just cause, so go ahead and deal with it, I think all we
          need is<br>
          someone to let us know when it's done and point us at a JVM so
          we can<br>
          start organising the new jar.</blockquote>
        <div><br>
        </div>
        <div>I have also contributed the following PRs to make Tomcat,
          Netty, Vert.x and Undertow aware of the plans of removal and
          also to provide the actual code changes:</div>
        <div><br>
        </div>
        <div><a href="https://github.com/apache/tomcat/pull/608" target="_blank">https://github.com/apache/tomcat/pull/608</a><br>
        </div>
        <div><a href="https://github.com/netty/netty/pull/13326" target="_blank">https://github.com/netty/netty/pull/13326</a><br>
        </div>
        <div><a href="https://github.com/eclipse-vertx/vert.x/pull/4665" target="_blank">https://github.com/eclipse-vertx/vert.x/pull/4665</a><br>
        </div>
        <div><a href="https://github.com/undertow-io/undertow/pull/1468" target="_blank">https://github.com/undertow-io/undertow/pull/1468</a><br>
        </div>
        <div><br>
        </div>
        <div>Implementing these PRs was mostly straightforward,
          indicating that the impact in these projects would be
          relatively low if these APIs would be removed today.</div>
        <div><br>
        </div>
        <div>I think we are in a bit of a knotty situation where the
          ecosystem is now basically just waiting for OpenJDK to
          actually remove these APIs.</div>
        <div> </div>
        <div>Based on my recent interaction with these projects I'm
          hopeful that the ecosystem impact is lower than what has been
          assessed previously. I believe we should go ahead with this
          removal, sooner rather than later.</div>
        <div><br>
        </div>
        <div>Any thoughts?</div>
        <br>
      </div>
    </blockquote>
    Kudos for reaching out the BC and for creating PRs to several
    projects to remove their usage, this is a great way to contribute!<br>
    <br>
    Removing anything is hard. The changes in JDK-8241047 were intended
    to allow SSLSession implementations drop their dependence on
    javax.security.cert.X509Certificate but it may take time if
    implementations are still expecting to be able to compile to a wide
    range of releases that include JDK 14 or older. I also be concerned
    that existing releases of this frameworks/libs with dependences on
    javax.security.cert.X509Certificate will be in use for some time.
    I'll defer to Sean and Brad but it feels like it might have to stay
    around for another few releases at least.<br>
    <br>
    -Alan.<br>
  </div>

</blockquote></div></div>