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