Thanks Thomas and Sean for your review comments. KeyStoreDelegator matches the JDK 9 version. I’ve moved it to the sun.security.package and modified it as suggested. I also made JavaKeyStore package-private but DualFormatJKS needs to remain public. The cert in trusted.pem is an arbitrary X.509 cert and I’ve added a comment in the TestKeystoreCompat test.
A new webrev is available at: http://cr.openjdk.java.net/~vinnie/8062552/webrev.02/ <http://cr.openjdk.java.net/~vinnie/8062552/webrev.02/> > On 22 May 2015, at 16:27, Sean Mullan <sean.mul...@oracle.com> wrote: > > Just a couple of other comments: > > - Both JavaKeyStore and JavaKeyStore$DualFormatJKS can be package-private > since they are only referenced from SunEntries which is in the same package. > I would also move KeyStoreDelegator into sun.security.provider and make it > package-private. > > - Can you add a comment describing the contents of the trusted.pem cert in > case we need to re-create it at some point in the future? > > - In KeyStoreDelegator, I think most/all of the fields can be made final. > > --Sean > > On 05/21/2015 11:44 AM, Vincent Ryan wrote: >> Please review this enhancement to JDK 8u that addresses a compatibility risk >> for certain applications that access >> keystores across JDK 8 and JDK 9 releases. The issue arises because the >> default keystore type is now PKCS12 in >> JDK 9 but is JKS in earlier releases. The problem can occur when a keystore >> is created on JDK 9 using the default >> keystore type but accessed on JDK 8 also using the default keystore type. >> This keystore type mismatch results in >> an error. >> >> The change introduces a keystore compatibility mode for JKS keystores where >> both JKS and PKCS12 file formats are >> understood. Similar behaviour is already present in JDK 9 (JEP-229). The >> keystore.type.compat security property >> controls whether the mode is enabled or not. By default it is enabled. >> >> This enhancement enables at risk applications to continue to function across >> JDK 8 and JDK 9 without requiring any >> application code changes. >> >> Thanks. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8062552 >> Webrev: http://cr.openjdk.java.net/~vinnie/8062552/webrev.01/ >>
