>>>
>>> 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.
>>
>> We discourage it, but there are quite some examples like this on the net. It
>> is the only way to load a SunPKCS11 provider with a user-specified config
>> file.
>
>
> Is there any particular providers you mostly concern about (SUN, PKCS11?)?
SunPKCS11.
-providerClass has 2 usages now:
1. Load a 3rd-party provider. This is not a problem. If it's still on
classpath, -providerClass will still be used. If it's in a module, people will
know to use -provider with name.
2. Load a JDK provider with config. Currently this is only SunPKCS11 which I
want to keep existing command line still working. Some tests have
"-providerClass sun.security.provider.Sun" but it's useless.
> I prefer to keep -providerClass for legacy non-service providers to avoid
> inconsistency with java.security config. Perhaps you can add aliases for few
> specific provider ie. -providerClass sun.security.provider.Sun is alias to
> -provider SUN and document them in the man page to help migration.
You mean not supporting all pre-loaded providers in modules, but only one or
two popular ones?
Thanks
Max
>
> Mandy
