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-r...@openjdk.java.net> im Auftrag von Jim Laskey <james.las...@oracle.com> Gesendet: Thursday, November 5, 2020 2:02:24 PM An: core-libs-dev <core-libs-...@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>
