Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules

[Mandy Chung]

Max,

Since the new APIs you're working on are still in design phase, I think 
it's a bit early to discuss where these new APIs should be in.

Just one thing to say about the new JarSigner API from your webrev.   
com.sun.jarsigner is an existing exported package that you should 
consider whether the new APIs should be added there rather than a new 
package.  Anyway, we can discuss that when your work is further along.

For this review request, are you okay with this patch moving policytool 
and jarsigner tools to the new home?

Mandy
[1] 
http://hg.openjdk.java.net/jdk9/dev/jdk/file/85b61f4eee66/src/jdk.dev/share/classes/com/sun/jarsigner/package-info.java

On 3/5/15 1:13 AM, Weijun Wang wrote:
> There is no problem the new API be in a separate module. It is 
> independent of keytool now.
>
> Said that, I've been thinking about rewriting keytool to use this new 
> API.
>
> --Max
>
> On 3/5/2015 16:23, Alan Bateman wrote:
>> On 05/03/2015 02:55, Wang Weijun wrote:
>>> - Move keytool to jdk.security.util, it's now in java.base but keytool
>>> is not part of Java SE spec (Of course, if that means keytool will be
>>> in JDK instead of JRE please stop. But will there will the name
>>> difference anymore? I am thinking of an installer like cygwin that you
>>> can choose anything except that java.base is checked grayed).
>>>
>>>
>> The reason that keytool is in java.base is so that keys and certificates
>> can be managed on a small runtime. It's the same reason that it is in
>> our compact1 builds too. I wasn't aware of JDK-8058778 but it can't
>> result in java.base exporting a JDK-specific API.
>>
>> -Alan