I was talking with Vincent off the list, but it seems better to be back. Here is Vincent's mail on how he thinks of the new API we are about to provide in JDK-8058778.
> The new API is interesting but if it's not available in Java SE I'm afraid it > does not fit our use case. We cannot make JOSM depend on a JDK at runtime > just for this feature :( There might be some confusion on what "JDK" means. It used to be the developer's toolkit versus JRE the runtime, but as for module names, a jdk.* module contains APIs defined by OpenJDK instead of Java SE. In fact, most of them are not especially designed for developers. That said, I am not exactly sure what kind of images we will release after jigsaw. If there is still a JRE, I think it will include not only the java.* modules but also some jdk.* ones. I hope jdk.security.cert is one of them. Personally I am not afraid of using jdk.* modules, since almost every JDK distribution is based on OpenJDK. At least it is now a supported API of OpenJDK instead of old sun.* classes that were never claimed to be supported by anyone. In fact, keytool was not defined in Java SE either. It was in JRE though. Thanks Max > On Oct 31, 2015, at 12:34 AM, Mandy Chung <mandy.ch...@oracle.com> wrote: > >> >> - We'd like to know if it can be expected to see the >> package sun.security.x509 become a public JDK API, for example in >> javax.security.cert? We currently use it to generate a self-signed >> certificate in order to create a local https server. That's our only use of >> private JDK API. > > There are two RFEs related to signing and certificates > 8058778: New APIs for some keytool functions > 8056174: New APIs for jar signing > > I have added this comment in 8058778 for the security team to look into. You > can subscribe to security-...@openjdk.java.net where the discussion for > these RFEs will be. > > Mandy >
