RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

[Mandy Chung]

> On Feb 17, 2016, at 8:04 PM, Wang Weijun <weijun.wang at oracle.com> wrote:
> 
>> 
>> On Feb 18, 2016, at 9:21 AM, Mandy Chung <mandy.chung at oracle.com> wrote:
>> 
>>> 
>>> On Feb 17, 2016, at 4:46 PM, Wang Weijun <weijun.wang at oracle.com> wrote:
>>> 
>>> 
>>>> On Feb 18, 2016, at 5:15 AM, Mandy Chung <mandy.chung at oracle.com> 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

“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.

Mandy

> --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