RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom

[Bradford Wetmore]

> the Microsoft C Runtime Library makes use of this function in its
> implementation of "rand_s", so it's removal would break a lot of
> programs. I think this is a relative guarantee that the function is here
> to stay.

Ok.

>>>> What are the fallbacks for SystemRandomImpl if /dev/urandom or the
>>>> rtlGenRandomFN/CryptGenRandom aren't available?  Is that something
>>>> you'll bake into TLR or will you do it here?
>> >
>>> I think it's better to leave it to consumers (TLR/SplittableRandom) as
>>> they know what's good-enough for them. The API allows for arbitrary
>>> number of bytes to be generated and I don't have an easy means of
>>> generating more than 8 "random" bytes just from System.nanoTime() and
>>> System.currentTimeMillis() short of using SecureRandom as a fall-back.
>>
>> webrev.03 only has new code, no changes yet to TLR/SplittableRandom,
>> so I'm not yet quite following where TLR/SR will be changing.  Also,
>> what is proposed for platforms that aren't Unix/Windows?  Should there
>> be a generic fallback mechanism like ThreadedSeedGenerator?  (Note,
>> I'm not suggesting using it, it's rather...SSLLLOOOWWWW...)
>
> Are there other non-Unix and non-Windows platforms?

I'm not an expert in non-Oracle Java offerings, but what about the 
various Java ME devices?  Some of the embedded devices are 
Linux/Windows, but are there others?  JavaCard?

I know IBM has a large number of OS's they support, for example IBM i.

http://en.wikipedia.org/wiki/IBM_i
https://www.ibm.com/developerworks/community/wikis/home?lang=en#/wiki/IBM%20i%20Technology%20Updates/page/Java%20on%20IBM%20i

I know IBM supports Java on z/OS, but apparently that uses a Linux-style 
filesystem via UNIX_System_Services. http://en.wikipedia.org/?title=Z/OS

Not sure about others.

I saw a couple of other non-unix/windows OSs in a wikipedia comparison 
of JVM's, but most of them seem to be discontinued.

> I think the planned
> fall-back for TLR/SplittableRandom is to just use
> System.currentTimeMillis() & System.nanoTime() - these are the defaults
> now unless SecureRandom is requested.

Ok.  Since this isn't security-critical, IMHO there just needs to be a 
"reasonable" fall-back option in case /dev/urandom or rtlGenRandomFN 
can't be used.

I don't always closely monitor core-libs-dev, so please cc me if further 
discussion occurs in a different thread.

Cheers, and HNY to you and everyone else here,

Brad