JDK-8066397 : Remove network-related seed initialization code in ThreadLocal/SplittableRandom
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Affected Version: 8,8u20,8u40
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-12-02
  • Updated: 2015-06-04
  • Resolved: 2014-12-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u40Fixed 9 b42Fixed
Related Reports
Relates :  
JDK-8060435 - Provide the capability to obtain a system seed to seed PRNGs
Relates :  
JDK-8066931 - SeedGenerator.getSystemEntropy() fails without network adapters
Description
ThreadLocalRandom (and SplittableRandom) by default computes an initial seed to the PRNG using the mac address obtained via NetworkInterface.getNetworkInterfaces(). This unfortunately can result in high very initialization costs on certain platforms (Windows) which in turn can propagate to other classes such as ConcurrentSkipList*.

The fallback mode if a mac address cannot be obtained is to compute an initial seed from the current system time, which is no worse than JDK 7.

The network code should be removed from both classes.  This is compliant with the specification which, by default, does not specify the seed strength. Developers that require a cryptographically random seed should set the system property "java.util.secureRandomSeed" to true.

However, we should revisit this code when there is an enhancement to provide an efficient "system" seed of a certain cryptographic strength that is optimal for the platform and has low initlization costs so it may be used by TLR/SR.