RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom
Paul Sandoz
paul.sandoz at oracle.com
Tue Dec 2 12:41:44 UTC 2014
On Dec 2, 2014, at 1:17 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> On 12/02/2014 05:02 AM, Paul Sandoz wrote:
>> Hi,
>>
>> Please find below a patch to remove the networking code computing a seed in ThreadLocal/SplittableRandom.
>>
>
> Thanks for pushing this through.
> (I also adjusted 166 sources accordingly.)
> One more touch-up for SplittableRandom is to remove mention
> of network interface in internal comments:
>
> ***************
> *** 140,150 ****
> * other cases, this split must be performed in a thread-safe
> * manner, so we use an AtomicLong to represent the seed rather
> * than use an explicit SplittableRandom. To bootstrap the
> ! * defaultGen, we start off using a seed based on current time and
> ! * network interface address unless the java.util.secureRandomSeed
> ! * property is set. This serves as a slimmed-down (and insecure)
> ! * variant of SecureRandom that also avoids stalls that may occur
> ! * when using /dev/random.
> *
> * It is a relatively simple matter to apply the basic design here
> * to use 128 bit seeds. However, emulating 128bit arithmetic and
> --- 139,148 ----
> * other cases, this split must be performed in a thread-safe
> * manner, so we use an AtomicLong to represent the seed rather
> * than use an explicit SplittableRandom. To bootstrap the
> ! * defaultGen, we start off using a seed based on current time
> ! * unless the java.util.secureRandomSeed property is set. This
> ! * serves as a slimmed-down (and insecure) variant of SecureRandom
> ! * that also avoids stalls that may occur when using /dev/random.
> *
> * It is a relatively simple matter to apply the basic design here
> * to use 128 bit seeds. However, emulating 128bit arithmetic and
> ***************
>
Thanks, updated my copy,
Paul.
More information about the core-libs-dev
mailing list