> On Feb 18, 2016, at 9:21 AM, Mandy Chung <[email protected]> wrote:
>
>>
>> On Feb 17, 2016, at 4:46 PM, Wang Weijun <[email protected]> wrote:
>>
>>
>>> On Feb 18, 2016, at 5:15 AM, Mandy Chung <[email protected]> wrote:
>>>
>>> Can I say -providerClass <NAME> -providerArg <ARG> is equivalent to
>>> extending java.security to add “security.provider.N=NAME ARG”?
>>
>> Yes.
>>
>>>
>>> I suggest to keep -providerClass and -providerArg only for legacy security
>>> provider (i.e. not a service provider to java.security.Provider).
>>>
>>> For security providers that are converted to service provider:
>>>
>>> What about updating -provider <NAME>[:<ARG>] option such that (1) it
>>> accepts “provider name” only (not class name) and (2) an optional argument?
>>> Although it’s an incompatible change, for legacy security provider, they
>>> can still use -providerClass option.
>>
>> Why must only "provider name”?
>
> Consistent with security.provider.<N> specified in java.security.
>
> For security providers in a named module, they must be a service provider.
> Security providers can also be a service provider that will help migration.
>
> security.provider.<N> must specify the name of the security provider which is
> used to compare with the providers loaded by ServiceLoader. A security
> provider can choose to use its fully-qualified classname be the provider name
> if you like. Provider::getName is used to match the specified name (see
> sun.security.jca.ProviderConfig.ProviderLoader)
>
> If the provider is not found via service loader, i.e.
> security.provider.<N>=<fully-qualified classname> for legacy security
> providers in unnamed module, it will call Class.forName and newInstance to
> construct the security provider instance. All packages in unnamed modules
> are exported and so Class::newInstance call will succeed (java.base can read
> unnamed module in the implementation).
In keytool help, we will write
-provider <providername> Add a security provider with its name
-providerArg <arg> Optional argument for -provider above
-providerClass <providerclass> Add a security provider with its class name
-providerArg <arg> Optional argument for -providerClass above
This is also what you are thinking about, right?
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.
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.
--Max
>
>>
>> We can document this way (-providerClass for legacy and -provider for new)
>> and still treat -providerClass and -provider the same (which is what we are
>> doing now) internally. I cannot see any harm and it is compatible.
>>
>> Even java.security supports both name and class now, right?
>>
>
> See above.
>
> Mandy
>
>> Thanks
>> Max
>>
>>>
>>> Mandy
