random streams

[Brian Goetz]

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