Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6336049

(rand) Better pseudo random number generators

    Details

    • Type: Enhancement
    • Status: Open
    • Priority: P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: core-libs
    • Labels:
      None
    • Subcomponent:
    • Understanding:
      Cause Known

      Description

      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.")
      --------------------------------------------------------------------

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                martin Martin Buchholz
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Imported:
                  Indexed: