[8] Code Review Request for 8004044: Lazily instantiate SunJCE.RANDOM

[Brad Wetmore]

Sean,

Could you please provide a little more background for the motivation for 
this fix?  I'm not quite following yet how we get into this situation. 
(Bear with me, I'm not familiar with ServiceLoader yet, so this may be a 
beginner's question.)

In our current implementation, there's always been the assumption that 
the order of providers is specified by the java.security file, and 
possibly tweaked by Security.*provider() code, thus ensuring that 
requested algs will come from the highest ordered provider at the time 
of initialization.  Is this going away?

FYI, the current behavior when no providers have been registered as 
Security Providers is to directly create a SHA1PRNG.

The code itself is ok, even without the upcoming change to ServiceLoader.

Brad


On 11/28/2012 8:53 AM, Sean Mullan wrote:
> Please review the following webrev which lazily initializes the
> SecureRandom object used by the SunJCE provider.
>
> In JDK 9, we want to load JCE providers with java.util.ServiceLoader as
> part of the transition to modules. This can cause potential recursive
> loading issues if the Sun provider for SecureRandom has not been loaded
> yet (since providers are loaded in no specific order using
> ServiceLoader). The fix is to lazily instantiate SunJCE.RANDOM. This is
> a proactive fix that will smooth the transition to modules.
>
> There is no regression test as this is a small refactoring that is
> covered by existing tests. The bug has been tagged with the
> noreg-cleanup label.
>
> The bug is not up on bugs.sun.com yet.
> bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004044
> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8004044/webrev.00
>
> Thanks,
> Sean