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

[Sean Mullan]

Looks good to me.

--Sean

On 10/02/2013 12:28 AM, Bradford Wetmore wrote:
> 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