Please review fix for 6951599 (Rename package of security tools for modularization)

[Mandy Chung]

Weijun Wang wrote:
> On May 14, 2010, at 2:40 PM, Mandy Chung wrote:
>
>   
>> The main reason for this fix is to separate the dependency of each tool.
>>
>> jdk.policytool -> jdk.desktop
>> jdk.keytool -> jdk.jsse
>>     
>
> Why must "keytool -> jsse". Is it about the HostVerifier and TrustManager reference? It's a quite non-essential function of keytool (print cert chain of a SSL site) and just added in JDK 7. If this brings any trouble in modularizing jdk, I can accept removing the function or rewriting it using reflection.
>   

The dependencies are:

sun.security.tools.KeyTool               -> 
javax.net.ssl.HttpsURLConnection (sun.jsse)
sun.security.tools.KeyTool               -> javax.net.ssl.SSLContext 
(sun.jsse)
sun.security.tools.KeyTool               -> javax.net.ssl.TrustManager 
(sun.jsse)
sun.security.tools.KeyTool$1             -> 
javax.net.ssl.X509TrustManager (sun.jsse)
sun.security.tools.KeyTool$2             -> 
javax.net.ssl.HostnameVerifier (sun.jsse)
sun.security.tools.KeyTool$2             -> javax.net.ssl.SSLSession 
(sun.jsse)

Using reflection could turn a hard dependency into an optional 
dependency since it still needs the class.   I'm not worrying too much 
about keytool -> jsse.
>   
>> jdk.jarsigner -> jdk.keytool
>>
>> If there are classes in the sun.security.tools package that references policytool, keytool, and jarsigner modules, it's no different than the current implementation.   There are two alternatives to leave all classes in the same package as it is but they are undesirable:
>> 1) create 3 additional implementation modules (e.g. sun.policytool, sun.keytool, and sun.jarsigner) that are locally connected so that the classes are loaded by the same loader (that's the solution to resolve the split package issue).
>>
>> 2) create 1 module containing all sun.security.tools.* classes to be required by jdk.policytool, jdk.keytool, and jdk.jarsigner - meaning that these tools would depend on the desktop (i.e. client) module while keytool and jarsigner are cli tools.
>>
>> Is there a CCC tracking the KeyTool as an external interface?
>>     
>
> No, but I'm quite sure there are people calling KeyTool.main.
>
>   
>>  How about PolicyTool?
>>     
>
> No, and I'm quite sure NO one calls PolicyTool as a class.
>
>   

That's good.  Let's move just PolicyTool.  Here is the new webrev:
   http://cr.openjdk.java.net/~mchung/6951599/webrev.02/

I added a policytool module in modules.config for now and leave 
security-tools as it is.   There are more clean up in the  jigsaw/jdk 
repository that I will push to TL some time.

>>   Another option is only move PolicyTool to a new package and leave all sun.security.tools in keytool module.  The jarsigner will be an empty module with an entry point to JarSigner class that resides in the keytool module.
>>     
>
> Very nice, but why is the jarsigner module necessary then?
>   

Each tool has its own entry point.  jigsaw currently supports single 
entry point per module and thus it needs to have one module per tool 
(e.g. javac, jar, ...).  When jigsaw supports multiple entry points, we 
could put multiple tools in a single module at that time.

Thanks
Mandy