It isn't terrible, it is just not suitable for cryptographic applications. I suspect most of the time that people want a random number up to some value, it is not for cryptographic purposes.
Mind you, I didn't call it terrible. However, the comment I was replying to -- coincidentally the author of TFA on modulo bias we are discussing -- did:
> java.util.Random is not a CSPRNG at all and is terrible, so even tho the nextInt() method is using rejection sampling, it's still producing biased values and also completely fails to be "unpredictable" because java.util.Random is weak and predictable.
and
> [...] using fast, but bad random generators such as Java's Random was shown to be an issue multiple times in the past already for things such as Monte Carlo, and so on, not just for things related to security.
Of course, "CSPRNG" means "cryptographically secure", but his comment made me think he considers it a terrible implementation regardless.
>his comment made me think he considers it a terrible implementation regardless.
Different people have different standards for what is "terrible". There are much better PRNGs that are just as fast. You should probably avoid java.util.Random if you care about the quality of the randomness it produces.
It's good enough for games that don't involve real money.
Well, the person who claims it's terrible is the author of the very thorough article we are discussing.
> You should probably avoid java.util.Random if you care about the quality of the randomness it produces.
That's pretty much the definition of "bad" ;) If you don't care about quality, I assume you could use a string of numbers without any randomness at all.
As for games, it depends. I'm sure one could make a guess it's bad for some kinds of non-betting games and simulations as well.
