random streams (original) (raw)

Brian Goetz brian.goetz at oracle.com
Mon Dec 31 11:49:47 PST 2012

• Previous message: random streams
• Next message: Background: pipeline architecture
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

(Initially, thread-local randoms were available only as a utility method in FJ, then made stand-alone for JDK7.) We'd sorta rather not let this lesson be lost :-)

Right. Of course, we have this problem today with Random.nextInt. Is your argument that Random.ints() will be such an attractive nuisance that the situation is going to be far worse than with the existing Random/ThreadLocalRandom divide?

ThreadLocalRandom can override this to implement:

public IntStream ints() { return PrimitiveStreams.repeatedly( () -> TLR.current().nextInt()); } How about ONLY adding to TLR?

Several potential objections come to mind:

• The above TLR formulation puts a ThreadLocal.get on the path to every random number. Is that an overhead we need to impose on the serial case just so people don't shoot themselves in the foot in the parallel case?
• Discoverability. It will be much easier to find on Random.
• Non-uniformity. Since SecureRandom and TLR extend Random, having it on the base class, where subclasses can provide a better implementation, seems more predictable and complete.

These basically boil down to "seems kinda like we're hosing the folks who just want a serial stream of random numbers for test programs, just because someone might misuse it in the parallel case (in exactly the same way they can still misuse it without stream sugar.)"

• Previous message: random streams
• Next message: Background: pipeline architecture
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the lambda-libs-spec-experts mailing list