[14] RFR JDK-8228613 "java.security.Provider#getServices order is no longer deterministic"

Anyone can help review this fix? SUN provider supports multiple impls of SecureRandom and rely on the ordering of the set returned by Provider.getServices() to choose the most preferred RNG algo for new SecureRandom() calls. Instead of maintaining the ordering, I think it's faster and more r

[14] RFR JDK-8228835 "Memory leak in PKCS11 provider when using AES GCM"

Anyone have spare cycles for reviewing this? The current PKCS11 JNI code for handling native mechanism and its parameters is a bit too all over the place. To make the tracing and verification easier, I consolidated the memory deallocation to the freeCKMechanismPtr(...) method in p11_util.c (so

[14] RFR JDK-8229214 "Don't use GCM with PKCS5Padding in test/micro/org/openjdk/bench/javax/crypto/"

Anyone can help review this trivial test update? Bug: https://bugs.openjdk.java.net/browse/JDK-8229214 Webrev: http://cr.openjdk.java.net/~valeriep/8229214/webrev.00/ Thanks, Valerie

Re: [14] RFR JDK-8229214 "Don't use GCM with PKCS5Padding in test/micro/org/openjdk/bench/javax/crypto/"

Looks good to me. Xuelei > On Aug 6, 2019, at 7:34 PM, Valerie Peng wrote: > > > Anyone can help review this trivial test update? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8229214 > > Webrev: http://cr.openjdk.java.net/~valeriep/8229214/webrev.00/ > > Thanks, > Valerie