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

[Weijun Wang]

On May 14, 2010, at 2:40 PM, Mandy Chung wrote:

> Hi Max,
> 
> Wang Weijun wrote:
>> Hi Mandy
>> 
>> Sorry for late comment. My email client on Nokia E71 keeps crashing. (Hope it's good this time).
>> 
> 
> It's good.  Thanks for the comment.
> 
>> I'm quite sure there are people out there calling KeyTool the same way. Also, I feel a little weird that one tool is treated diffrently from others.
>> 
>> Is it possible to leave all current class unchanged, and create new packages called sun.security.tools.xxx (xxx can be keytool, jarsigner, policytool), each with a single Xxx class whose main() simply calls sun.securiry.tools.Xxx.main()?
>> 
> 
> 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.

> 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.

>   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?

> 
>> Also, there are 3 Windows-only security tools (kinit, klist, ktab) in sun.security.krb5.internal.tools. Should they be isolated the same way?
> 
> Thanks for pointing that out.   All sun.security.krb5 classes are currently in the kerberos module which is required by these windows security tools.  I think the krb5 implementation is well isolated (in the sun.security.krb5.** package).

Good to hear that.

Thanks
Max

> 
> Mandy
>> 
>> Thanks
>> Max
>> 
>> ------- Original message -------
>>> From: Mandy Chung <mandy.chung at oracle.com>
>>> To: security-dev at openjdk.java.net
>>> Sent: 14.5.'10,  13:16
>>> 
>>> I revised the fix to rename the package of keytool instead of jarsigner. Apparently, there are customers who depend on the jarsigner class.
>>> 
>>> Webrev at:
>>>  http://cr.openjdk.java.net/~mchung/6951599/webrev.01/
>>> 
>>> I also updated the copyright year (thanks Brad for pointing that out).
>>> 
>>> Thanks
>>> Mandy
>>> 
>>> Mandy Chung wrote:
>>>> Hi,
>>>> 
>>>> Please review the fix for:
>>>>  6951599: Rename package of security tools for modularization
>>>> 
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mchung/6951599/webrev.00/
>>>> 
>>>> Move KeyTool, PolicyTool and JarSigner classes to its own package so that the classes can be placed in its own module while eliminating the split package (that requires such modules be locally connected and loaded by the same class loader).
>>>> 
>>>> Thanks
>>>> Mandy
>>>> 
>>> 
>> 
>