> On Feb 19, 2016, at 2:47 AM, Wang Weijun <weijun.w...@oracle.com> wrote:
>
> Updated at the same URL
>
> http://cr.openjdk.java.net/~weijun/8130302/webrev.01
>
> The help looks like this now:
>
> -provider <name> add security provider by name (e.g. SunPKCS11)
> [-providerArg <arg>] configure argument for -provider
> -providerclass <class> add security provider by fully-qualified classname
> [-providerArg <arg>] configure argument for -providerclass
>
The help message looks good.
On the change, I suggest not to duplicate the code from ProviderConfig (I
mentioned in my previous reply). One way to do is to add
sun.security.jca.Providers.addProvider(String name, String argument) that will
do the same as loading a provider listed in java.security config file
(ProviderConfig::getProvider I believe). I think this change can go into
jdk9/dev as ProviderConfig has the right changes there.
303 // A provider in module can also be use class name
304 if (p.getClass().getName().equals(provClass)) {
ProviderConfig::getProvider doesn’t compare the classname. I thought we agree
to discourage the use of -providerClass to load a provider and also will be
consistent with java.security.
1719 testOK("", "-list -storepass password" +
1720 " -providerClass sun.security.provider.Sun" +
1721 " -keystore x.jks -storetype JKS”);
This should use -providerName. You may want to test both
“sun.security.provider.Sun” and “SUN”.
ProviderConfig::getProvider has some fast path to support both classname and
provider name for our built-in security providers for compatibility because
these names are used in java.security.
Mandy
