> On Feb 16, 2016, at 5:20 PM, Weijun Wang <weijun.w...@oracle.com> wrote: > > > > 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. >
-providerName is only used to specify the provider name for KeyStore.getInstance(storetype, providerName) call. I think it’s best to keep this as it is. > 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. Can I say -providerClass <NAME> -providerArg <ARG> is equivalent to extending java.security to add “security.provider.N=NAME ARG”? I suggest to keep -providerClass and -providerArg only for legacy security provider (i.e. not a service provider to java.security.Provider). For security providers that are converted to service provider: What about updating -provider <NAME>[:<ARG>] option such that (1) it accepts “provider name” only (not class name) and (2) an optional argument? Although it’s an incompatible change, for legacy security provider, they can still use -providerClass option. Mandy
