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
