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
