[
https://issues.apache.org/jira/browse/RNG-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16921057#comment-16921057
]
Gilles commented on RNG-19:
---------------------------
bq. wrapper essentially the same as JDKRandom
The intention was that {{JDKRandom}} is "safe" because the delegate is
encapsulated.
While the wrapper is error-prone (interface can be bypassed).
I agree about code duplication but that was not the main point...
bq. {{next(int bits)}} [vs] {{nextBytes}}
I had missed that.
IMHO, it makes the API/implementation of {{Random}} even more confusing.
bq. state function of a SecureRandom configured to read from /dev/urandom would
not function as I would expect
Right. This was noted by the OP, and not considered a problem. But I agree
with you that it is from an API consistency POV.
So let's go with the initial idea: a simple wrapper (as in the current PR).
bq. error [...] can be fixed by also saving the state size to the state
Thanks.
> System generator (/dev/random)
> ------------------------------
>
> Key: RNG-19
> URL: https://issues.apache.org/jira/browse/RNG-19
> Project: Commons RNG
> Issue Type: Wish
> Reporter: Emmanuel Bourg
> Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Commons RNG could include a random number generator based on the output of
> /dev/random or /dev/urandom on Unix systems.
> Commons Crypto has an implementation that could be used as a starting point:
> https://github.com/apache/commons-crypto/blob/master/src/main/java/org/apache/commons/crypto/random/OsCryptoRandom.java
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
