java.util.Random has the following problems:

- synchronized when most users simply use each instance confined to a thread.
- 2**48 bits of internal state is too small. This prevents, for example, nextLong from
  returning all possible long values. nextDouble has the same issue,
  although more complicated.
- Since rand48 was created, better random number generators have been discovered.
- The nextGaussian stuff probably belongs in a separate class. Random should
  not have to carry around baggage just for the sake of the rarely used nextGaussian.

Josh Bloch writes:

--------------------------------------------------------------------
(1) Deprecate (or at least denigrate) all the existing constructors in
java.util.Random.

(2) Retrofit an Interface to java.util.Random that captures the
essence of an RNG, and possibly an SPI that captures the essence of
random bit generation (SecureRandom has something like this).

(3) Make a new set of static factories in Random (or perhaps a new
random utility class) that return instances of the new interface. We
should have at least one set of static factories that *aren't*
overspecified: we can describe the current implementation in an
implementation note, but the contract is just reasonable quality
random values. We explicitly reserve the right to change RNGs between
releases, and different vendors can use different algorithms in the
same release. You can no longer depend on the exact sequence, period.

This also allows us to make most RNGs "thread compatible" (i.e.
unsynchronized) by default. We could, of course provide a static
factory to give you a concurrent RNG if you need one.

(4) While we're at it, throw in a utility method somewhere that gives
you an int on [0..n) without the need to allocate an RNG. Sort of
like Math.random(). In fact, how about one for each primitive type,
placed in its wrapper class:

   Integer.random()
   Long.random()
   etc().

These pups would effectively deprecate Math.random(), and then we'd be
freed from the existing Random number generator with its peculiarities
and its unfortunate overspecification.

In the meantime, I do support simply removing the offending sentence
("All 2**64 possible long values are produced with (approximately)
equal probability.")
--------------------------------------------------------------------