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
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? How about
PolicyTool? 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.
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).
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
