RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom
bradford.wetmore at oracle.com
Fri Jan 2 21:29:49 UTC 2015
> 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.
>>>> 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.
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,
More information about the core-libs-dev