java:S1942 "Simple class names should be used" too relaxed?

Rules and Languages
1

java:S1942 states that:

Java’s import mechanism allows the use of simple class names. Therefore, using a class’ fully qualified name in a file that imports the class is redundant and confusing.

This is fine, but what about classes that are not imported?

We prefer code like this:

import java.io.StringReader;
...
PEMParser pemParser = new PEMParser(new StringReader(pem))

instead of

PEMParser pemParser = new PEMParser(new java.io.StringReader(pem))

but java:S1942 does not cover this case because it only triggers when the class is both imported and referenced by the fully qualified name.

So my suggestion is to either add an option for java:S1942 or create a new rule for this.

2

Hi,

Can you provide a minimal reproducer where and issue is raised that you think should not be?

Also, can you give 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

3

Hi @ganncamp

Thanks for your reply.

I have created a simple class to illustrate the issue:

import java.io.StringReader;

public class S1942Example {

    // Case 1: Class is imported but still used with fully qualified name.
    // S1942 correctly flags this.
    public StringReader case1Detected(String text) {
        return new java.io.StringReader(text);
    }

    // Case 2: Class is NOT imported and used with fully qualified name.
    // S1942 does NOT flag this, but it arguably should — an import would be cleaner.
    public java.io.BufferedReader case2NotDetected(String text) {
        return new java.io.BufferedReader(new StringReader(text));
    }
}

Both SonarQube Enterprise Edition v2025.6.1 and SonarQube Cloud behave as described in the comments.
SonarQube for IDE (VS Code) does not flag any of the two methods.

I hope this clarifies the context :slightly_smiling_face:

5

Hi,

Thanks for the details. I’ve flagged this for the language experts.

 
Ann

7

It should be kept in mind that imports cannot be used if a single source file must use two or more classes with the same simple name in different packages. For example, the JDK has classes named Timer in packages java.util, javax.swing and javax.management.timer. It would probably be rare to need to use multiple of them in the same file, but still possible (especially in large codebases with third party libraries; some developers might use very generic names).

8

You are of course absolutely right: When using classes with the same name from two or more packages, you must use a fully qualified name, so the rule will have to take that into account.
But in the common case where only one class of a given name is used, it would be nice to be able to raise an issue if the fully qualified name is being used.

9

Hello, I think that as a rule of thumb, the standard should be to avoid fully qualified names in most cases. There are some exceptions to this, and one might argue that a developer who is using a FQN knows the reason why, hence this rule is not in the default quality gate. Still, there is margin for improvement for this rule.

When a FQN is present, even without imports, if the corresponding simple name does not collide with any other simple name in the file, the rule could safely trigger.

package myPackage;
// no imports
public class App {

  public java.util.List<String> foo(){ // This should trigger
    var app = new some.other.package.App(); // This should not trigger
    return java.util.List.of(app.getData()); // This should trigger
  }

}

I created a ticket to improve the rule