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
