|
If you want cryptographic-quality random numbers, both Java and Javascript have them. Math.random() is simply a super-fast decent RNG. Example: var buf = new Uint32Array(10);
window.crypto.getRandomValues(buf);
console.log(buf);
Outputs things like: [4027145128, 258543382, 1205615760, 2665675208, 4033127244,
2280027866, 3983484449, 510932333, 1911490534, 2609399642]
This works in Chrome and FF.IE11 has Crypto.getRandomValues(...) Java has SecureRandom: http://docs.oracle.com/javase/6/docs/api/java/security/Secur... |
Actually, java.util.Random is a horrible, horrible RNG. Its least significant bit (for example) is grotesquely nonrandom. See http://www.alife.co.uk/nonrandom/ for a wonderful demonstration of its awfulness. There are other serious bugs in java.util.Random which Sun, er, Oracle, has steadfastly refused to fix or revise for a decade now due to concerns about "backward compatibility" (in an RNG!)
> If you want cryptographic-quality random numbers
I think you're confusing "crytographic-quality" with "high quality".
RNGs tend to break down into two different camps. First, there are RNGs meant for simulation of stochastic processes. These RNGs need to be fast, have good periods, and have a very high degree of statistical randomness in their output.
Second, there are RNGs meant for crypto. Speed is less important. Rather it's important that these RNGs provide good statistical randomness, but also it's crucial that, given some M previous output numbers of the RNG, you cannot predict or make any statistical claims about the next number even if you know how the algorithm works. This isn't important for non-crypto RNGs.
For example, Mersenne Twister is a pretty high quality, widely used RNG. But it is not cryptographically secure: if you have about 1500 of the previous output numbers, you can perfectly predict the next number if you know it's MT producing them.
While there are many applications for crypto RNGs, for a great many tasks, a non-crypto RNG would be a better fit.
java.util.Random was meant for non-crypto tasks. And it completely fails at even those tasks.
But SecureRandom is really bad for those tasks too: it is slow. For example, my MersenneTwister implementation is about 9 times faster than SecureRandom; and my non-threadsafe MT implementation is about 36 times faster. That's a big deal if you're pulling down millions and millions of numbers.