The java:S2119 rule has a serious issue!

java:S2119 :
Noncompliant Code Example

public void doSomethingCommon() {
  Random rand = new Random();  // Noncompliant; new instance created with each invocation
  int rValue = rand.nextInt();
  //...
Compliant Solution
private Random rand = SecureRandom.getInstanceStrong();  // SecureRandom is preferred to Random

public void doSomethingCommon() {
  int rValue = this.rand.nextInt();
  //...

Modifying the code according to java:S2119’s suggestion, I used SecureRandom.getInstanceStrong(); written inside the method, which caused thread blocking.
Today, when checking the SecureRandom.getInstanceStrong(); method again, I found the following problem:
SecureRandom.getInstanceStrong(); is an enhanced version of random number implementation introduced in JDK 1.8.
If your server is running on the Linux operating system, the culprit here is SecureRandom generateSeed().
It uses /dev/random to generate seeds.
However, /dev/random is a blocking number generator. If it doesn’t have enough random data to provide, it waits indefinitely, forcing the JVM to wait.
Keyboard and mouse inputs, as well as disk activity, can generate the required randomness or entropy.

Hi,

What version of SonarQube are you using?

 
Thx,
Ann

I also question the reasonableness of this rule. In situations where the entropy pool is low, this can cause blocking for more than 30 minutes.

Hi @wsiyuan446,

I never got enough data on this report to queue it for the language team. Would you care to provide some details, starting with your context for this? I.e. are you on SonarQube Cloud? SonarQube for IDE (flavor and version)? SonarQube self-managed (flavor and version)?

 
Thx,
Ann