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
