RFR 7191662: JCE providers should be located via ServiceLoader,

Valerie Peng valerie.peng at oracle.com
Wed May 27 23:17:51 UTC 2015

Hi, Mandy,

I have second thought on using the provider name for the java.security 
There are a few things that I want to discuss/brainstorm internally to 
make sure that there is no "surprise" later.
Thus, I had not made the switch in this webrev. It doesn't affect the 
overall functionality.

The legacyLoad() is for finding providers the old-fashioned way, e.g. 
through reflection, instead of ServiceLoader.
The legacyLoad can only work using class name.

Running test/java/lang/SecurityManager/CheckSecurityProvider.java with a 
security manager should cover more than without.
I don't see much value in adding provider name verification? Verifying 
class name seems enough in making sure that the providers are present as 

As for test/tools/launcher/MiscTests.java, it's for verifying a bug in 
launcher, so I have stick with the internal API as I am not sure if 
switching to public API may be too great of a change as the call path 
changed significantly...


On 5/26/2015 3:27 PM, Mandy Chung wrote:
> sun/security/jca/ProviderConfig.java
>  287         /**
>  288          * Loads the provider with the specified class name.
>  289          *
>  290          * @param name the name of the provider class
>  291          * @return the Provider, or null if it cannot be found or 
> loaded
>  292          * @throws ProviderException all other exceptions are 
> ignored
>  293          */
>  294         public Provider load(String classname) {
>                             :
>  305                     if (p.getClass().getName().equals(classname)) {
>  306                         return p;
>  307                     }
> Is this load method supposed to take the provider name instead of the 
> classname?
> line 305 should check against p.getName() instead?  The legacyLoad 
> method is
> for the fallback to the class name.
> java.security now uses classname.  Did you decide to use security 
> provider name instead?
> Even so, the legacyLoader method should be able to find them and the 
> load method
> looks to me should check the provider name instead.
> test/java/lang/SecurityManager/CheckSecurityProvider.java
>    you add this test to run with security manager.  I wonder if you want
>    to run with and without security manager through @run othervm.
>    Now each security provider has a name.  Should this test verify the 
> provider
>    name as well?
> test/tools/launcher/MiscTests.java
>    - does this test need to call sun.security.pkcs11 internal API? Can 
> this be
>      changed to call public API?
> I didn't review other files.
> Mandy
> On 05/26/2015 01:57 PM, Sean Mullan wrote:
>> This all looks fine to me (except for the Makefile stuff which I'll 
>> leave to others).
>> --Sean
>> On 05/21/2015 12:21 AM, Valerie Peng wrote:
>>> Sean,
>>> Could you please review this change? The changes are mostly the same as
>>> the prototype in Jake, but I have to make some modification due to the
>>> difference in ServiceLoader lookup in OpenJDK (corresponding
>>> META-INF/services/java.security.Provider files in each module) and the
>>> related makefile change (merge their content into one for the final
>>> image build). Then, I adjusted the Provider.configure() method to 
>>> take a
>>> single String argument to be consistent with the "providerarg" option
>>> that keytool defined.
>>> In addition, I also made some misc changes, such as configuring the
>>> providers inside ProviderConfig instead of ProviderLoader, add back the
>>> doPrivileged block to all the provider constructors. I also have second
>>> thought on making the switch to privider name (instead of provider 
>>> class
>>> name) in java.security file, so I reverted the changes on that - that
>>> SunPKCS11 provider has its name specified in its configuration file, so
>>> when ServiceLoader loads the PKCS11 provider, the configuration file 
>>> has
>>> not been passed to it, so the name is not known at that time. Thus,
>>> using the class name for the provider list entry seems to fit the flow
>>> better. I also updated the default policy for SunPKCS11 provider given
>>> its recent change of using sun.misc.
>>> Webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.00/
>>> CCC: http://ccc.us.oracle.com/7191662
>>> Thanks,
>>> Valerie

More information about the security-dev mailing list