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
> 

Reply via email to