RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

[Weijun Wang]

On 2/16/2016 22:54, Alan Bateman wrote:
>
> On 16/02/2016 14:44, Weijun Wang wrote:
>> Please review the code change at
>>
>>    http://cr.openjdk.java.net/~weijun/8130302/webrev.00/
>>
>> I didn't abandon -providerClass and go all the way to -provideName
>> because -providerClass has a sub-option -providerArg that can be used
>> to further configure the provider. Also I think we still need to
>> support legacy providers that are not defined in modules.
>>
>> With this fix, -providerClass accepts both a provider name and a
>> provider class name. Some doc change will be needed.
> How is -providerName used today? I'm just trying to understand why these
> tools have had both -providerName and -providerClass options when they
> appear to take the same value.

Technically they are independent.

With -providerClass/-providerArg, the provider is added into system and 
getInstance() calls (of keyStore, KeyPairGenerator, etc) can use it.

On the other hand, -providerName can be used to specifically tell 
KeyPairGenerator which provider to use. For example, although both SUN 
and SunPKCS11 providers support RSA key pair generation, you cannot 
store keys generated by SunPKCS11 into a file-based keystore because the 
private key is kept inside the hardware token. In this case, you might 
want to tell keytool which provider should be used.

This bug is about loading providers not registered in java.security, 
which is what -providerClass/-providerArg is doing now. -providerClass 
and -providerName used to take different values, one class name, and one 
provider name. It is after modularization that -providerClass is able to 
take a provider name.

Thanks
Max