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
