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

[Weijun Wang]

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.

Thanks
Max

>
> -Alan