> On Feb 22, 2016, at 5:55 PM, Wang Weijun <weijun.w...@oracle.com> wrote:
>
>>>>
>>>> 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?
>
I meant not support -providerClass for arbitrary providers loaded via service
loader. The only exception is SunPKCS11. In other words, -providerClass can
only be used to load legacy security provider via Class::forName.
The man page should make it clear that -provider SunPKCS11 is recommended
instead of -providerClass sun.security.provider.SunPKCS11. It’s just an alias
to help migration.
Mandy
> Thanks
> Max
>
>
>>
>> Mandy
>
