[9] RFR 8157489: AppleProvider in java.base/macosx/classes/module-info.java.extra

Mandy Chung mandy.chung at oracle.com
Thu Jun 9 23:31:35 UTC 2016


> On Jun 9, 2016, at 4:22 PM, Valerie Peng <valerie.peng at oracle.com> wrote:
> 
> 
> Thanks for the comments. I will update the reg test, i.e. test/java/security/Provider/DefaultProviderList.java, to check that they are from java.base.
> 

To clarify: what I mean is that you should remove the logic that skips the built-in security provider if found.  Also for the security provider, it should check it comes from a module other than java.base.

> I don't see a need for built-in security providers to be found through ServiceLoader.load(Provider.class) though. The expected API usage is to get the provider instance through Security.getProvider(String provName).

Right that’s implementation details.  I have no issue with that.

Mandy

> Regards,
> Valerie
> 
> On 6/9/2016 3:31 PM, Mandy Chung wrote:
>>> On Jun 9, 2016, at 3:22 PM, Valerie Peng<valerie.peng at oracle.com>  wrote:
>>> 
>>> 
>>> Anyone can help reviewing this one-line change which removes a redundant declaration?
>>> 
>>> As Apple provider is instantiated directly (see sun.security.jca.ProviderConfig.java) and not loaded through ServiceLoader , we can safely remove the line for ServiceLoader lookup. No new regression test as this is just a minor performance fix.
>>> 
>>> Webrev: http://cr.openjdk.java.net/~valeriep/8157489/
>> So all builtin security providers in java.base will not be found from ServiceLoader.load(Provider.class).
>> 
>> test/java/security/Provider/DefaultProviderList.java should then be updated to expect all providers are not from java.base and check Class::getModule().  Currently the test simply skips some builtin security providers.
>> 
>> Mandy
>> 




More information about the security-dev mailing list