In keytool help, we will write
-provider <providername> Add a security provider with its name
“Add a security provider by the provider’s name”
-providerArg <arg> Optional argument for -provider above
-providerClass <providerclass> Add a security provider with its class name
“Add a security provider by a fully-qualified classname”
-providerArg <arg> Optional argument for -providerClass above
This is also what you are thinking about, right?
Yes this matches what I suggest.
You think the implementation should strictly match the help above, and I think
we can treat -provider and -providerClass the same and perform a
try-name-first-try-class-second trick just like what
sun.security.jca.ProviderConfig.ProviderLoader::load is doing.
You may consider adding a method in sun.security.jca.ProviderConfig for keytool
to call rather than duplicating the logic.
The -providerClass was introduced in
https://bugs.openjdk.java.net/browse/JDK-4938224:
To avoid confusion, the -provider option should
be renamed to -providerClass. The -provider should still
be supported (although not documented) for compatibility.
I still see 3 regression tests using -provider this way and I don't want to
break them.
The option is not documented and repurpose -provider option may not be commonly
used. These regression tests should be re-examined whether they can be updated
to use -providerClass.
Yes, they can be updated, but I can imagine there are external customer
doing the same.
There is another compatibility issue which is more important:
Today, we tell users to load their own PKCS11 provider with
-providerClass sun.security.pkcs11.SunPKCS11 -providerArg some.cfg
and seems the new options should be
-provider SunPKCS11 -providerArg some.cfg
Why not just support all these formats? It's not really difficult and I
don't think it's harmful, no ambiguity, simple code...
--Max
