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

[Bradford Wetmore]

>> To the actual proposal:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.03/
>>
>> Overall, I'm ok with what's proposed.  This is more straightforward to
>> parse/understand than trying to adjust NativeSeedGenerator to
>> create/call directly (e.g. UNIX:  new
>> NativeSeedGenerator("/dev/urandom") or Windows:  new
>> NativeSeedGenerator()).  But I'd still like to understand why you
>> moved away from this.
>>
>> One concern is that you're duplicating native libraries in java.base,
>> and it would be the third JDK library overall with this type of call.
>> There's one in libjava (for java.base/WinCAPISeedGenerator for
>> sun.security.provider.NativeSeedGenerator) and sunmscapi (for
>> jdk.crypto.mscapi/SunMSCAPI/sun.security.mscapi).  Would it work to
>> tweak the WinCAPISeedGenerator so you don't have to create a new dll
>> for java.base?
>
> The SystemRandom JNI bindings for Windows are located in:
>
>      java.base/windows/native/libjava/SystemRandomImpl_md.c
>
> ...so as I understand they are also part of libjava. No new DLL here.

True.  My thought should have been about having very similar code 
duplicated in libjava.

I'm ok with this, though it's not really clear if/when MS will drop 
support for ADVAPI32!RtlGenRandom.  This always makes me nervous because 
whatever is put in will likely never change until some MS change breaks it.

I'm not familiar with what Alan/Mandy/company have in mind down the 
road, but I haven't heard of libjava splitting.

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

> The problem is also how to make access to this functionality for
> different consumers that are located in different packages (java.util,
> java.util.concurrent) and make it somehow usable also for external
> access. There is a desire to use this also from stand-alone builds of
> java.util.concurrent utilities. That's why my initial approach for
> SystemRandom used a public API in java.util.
>
> The approach used with sun.misc.Unsafe is probably not going to work for
> user code in JDK9 with modules, as sun.misc will not be globally
> exported. Are any non J2SE packages going to be globally exported? I see
> jdk and jdk.net are already mentioned as such globally exported packages
> in modules.xml...

That's a good question for Alan/Mandy/company.

>> Martin wrote:
>>
>>> https://bugs.openjdk.java.net/browse/JDK-8047769
>>
>> If you've been following this bug, I've figured why the NativePRNG$*
>> classes are initing and thus opening the /dev/random,urandom.  This
>> definitely needs some adjustment.
>
> Something like the following could be used in NativePRNG and
> URLSeedGenerator:
>
> http://cr.openjdk.java.net/~plevart/misc/FileInputStreamPool/FileInputStreamPool.java

(See the other active thread in core-libs-dev.)

Brad