RFR: JDK-8014838: getStrongSecureRandom() should require at least one implementation

[Bradford Wetmore]

During the internal CCC review, the CCC lead suggested a change to the 
method name to more closely follow the existing getInstance() methods, 
so I've changed the name from:

     java.security.SecureRandom.getStrongSecureRandom()

to

     java.security.SecureRandom.getInstanceStrong()

This particular change will be tracked via:

     8025694: Rename getStrongSecureRandom based on feedback

This will collate better (i.e. javadoc/NetBeans) than getStrongInstance().

It was also pointed out that the current strong Window MSCAPI-based 
implementation may not be available under the various profiles, so I've 
added a SHA1PRNG:SUN fallback in case the MSCAPI is not available.

     https://bugs.openjdk.java.net/browse/JDK-8014838
     https://bugs.openjdk.java.net/browse/JDK-8025694
     http://cr.openjdk.java.net/~wetmore/8025694/webrev.00
         (contains both 8025694/8014838)

Even though we are not currently building profiles on Windows currently, 
we could in the future, so the profiles team agrees this is a good 
compromise.

Brad




On 9/26/2013 4:04 PM, Bradford Wetmore wrote:
> This minor suggestion came up in May from our JCK team:
>
>      https://bugs.openjdk.java.net/browse/JDK-8014838
>
>      http://cr.openjdk.java.net/~wetmore/8014838/webrev.00/
>
> JCK suggested all implementations should have at least one strong random
> implementation.
>
> I've also changed the error case to throw NoSuchAlgorithmException
> instead of returning null.
>
> CCC review is also underway concurrently, but I'm not expecting any issues.
>
> Brad