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
