JDK-6258213 : Request for the inclusion of a java.random library.
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-04-20
  • Updated: 2014-06-06
  • Resolved: 2012-02-04
Related Reports
Relates :  
JDK-8046113 - JEP 123: Configurable Secure Random-Number Generation
Description
A DESCRIPTION OF THE REQUEST :
The Java API should include a java.random or a java.util.random library, containing implementations of common algorithms (Mersenne Twister, ISAAC, Multiply with Carry, etc.) that generate pseudo-random sequences, a synchronized wrapper class for Random instances, and a utility class containing common operations Random is used for, such as obtaining a number in a given range.

I don't want to change the Random class, I want a random library. I would like to see implementations of high-quality algorithms available in the API, so people don't have to write them themselves.
As example:
A Monte-Carlo simulation is used by a lot of people. It requires a lot of good, random bits, and should be repeatable.
java.util.Random produces a repeatable sequence. Good.
java.util.Random is reasonably fast. Not good enough.
java.util.Random has a small period. Bad.
 
From the current API, one has a choice of java.util.Random (repeatable) and java.security.SecureRandom (repeatable, huge period, way too slow).
 
What this means is that a person wishing to make a (decent) Monte-Carlo simulation is forced to either find a good prng on the web (and I have yet to find one that extends Random) or roll their own using the crappy versions on the web.
 
A lot of people need these prng's. When a lot of people need something, it should be included in the API.

JUSTIFICATION :
1. Not enough people use good quality prng's, a random library would make these more readily available.
2. Many people use algorithms (like Mersenne Twister) which are not well integrated into Java (don't extend Random) and need some work to make useable (the implementations provided are often [poorly] translated C).
Due to this need and common usage, it seems right to provide the generators in in API.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Full implementations for the algorithms (especially proper seeding), quick release (dare to dream, I know), and what I described above.
ACTUAL -
It doesn't exist, it behaves much like something that doesn't exist.

CUSTOMER SUBMITTED WORKAROUND :
Writing your own classes.
###@###.### 2005-04-20 06:11:11 GMT
Comments
EVALUATION Only 1 request for this in 6 years, the need does not seem to be widespread. We can reopen if there is additional resources, but the security team is not interested in taking this one on. For Linux/Solaris, there are provider implementations that go directly to /dev/random&/dev/urandom, so speed is not as much of an issue as it once was. For Windows, there is direct access to the Windows-PRNG, and it's also used as the seed for SHA1PRNG.
04-02-2012