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

Weijun Wang weijun.wang at oracle.com
Wed Feb 17 13:24:32 UTC 2016

On 2/17/2016 18:33, Alan Bateman wrote:
> On 17/02/2016 01:20, Weijun Wang wrote:
>> :
>> 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.
> What would you think about keeping them independent? That is, the value
> to -providerName is a security provider name, the value to
> -providerClass is a class name. The -providerArg can work with both, at
> least I assume it can because this was the motive for the configure
> method that Valerie added.

-providerClass can be provided multiple times but -providerName can only 
appear once. If we reuse -providerName as -providerClass in the module 
era, the existing usage of -providerName (used in getInstance) will break.

> I ask because the only reason for the java.security file behavior is to
> preserve legacy usage for those that configured it with class names in
> the past.

In fact, -providerClass has an alias -provider but it's not documented. 
I don't know about the history but this name seems more appropriate now 
if my code change is adopted.


> -Alan

More information about the security-dev mailing list