RFR: JDK-8255395 Implement Enhanced Pseudo-Random Number Generators (CSR)

Bernd Eckenfels ecki at zusammenkunft.net
Thu Nov 5 19:11:31 UTC 2020


Hello,

Not sure if it is needed to implement a new RandumGenerator interface instead of extending SecureRandom, but the extensions and the discovery mechanism looks good.

One thing I am wondering about is if reseed() and reseed(Param) should be part of the new RandomGenerator interface as well.

BTW a lot of the random number Discovery and configuration could have been avoided when the actual implementation just would have been stronger and less blocking. The focus should be on the two old factory methods to make them return top quality, it’s hard enough to make everyone use them for the correct use case.

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von Jim Laskey <james.laskey at oracle.com>
Gesendet: Thursday, November 5, 2020 2:02:24 PM
An: core-libs-dev <core-libs-dev at openjdk.java.net>
Betreff: RFR: JDK-8255395 Implement Enhanced Pseudo-Random Number Generators (CSR)

Please review the CSR for JEP-356 Enhanced Pseudo-Random Number Generators.

Thank you.

-- Jim

CSR: https://bugs.openjdk.java.net/browse/JDK-8255395 <https://bugs.openjdk.java.net/browse/JDK-8255395>
JBS: https://bugs.openjdk.java.net/browse/JDK-8248862 <https://bugs.openjdk.java.net/browse/JDK-8248862>
JEP: http://openjdk.java.net/jeps/356 <http://openjdk.java.net/jeps/356>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20201105/8054ef5d/attachment.htm>


More information about the security-dev mailing list