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.ch...@oracle.com> >>> To: security-dev@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 >>>> >>> >> >
