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
