SonarLint: Warum kein Null-Referencing-CodeSmell-Hint hier?

[Zrebna]

Bei dem folgendem CodeSnippet kam es zu einer NPE, falls der (für diesen Thread) auskommentierte Teil gefehlt hat, also die Überprüfung auf NULL:

   // ... more code

        ParentNode parentNode = parents.get(parent);
//        if (parentNode == null) {
//            return;
//        }

        parentNode.addChildNode(childNode);
       
        // ... more code

Wieso "schreit" SonarLint nicht und zeigt mir da einen null-referencing-Hint/Warning an, obwohl parentNode null sein kann und eine Methode referenziert?

Lg
Zrebna

 

[LimDul]

Was ist parents für ein Typ?

 

[Zrebna]

parents ist eine DualLinkedHashBidiMap (hätte ich dazu schreiben sollen).
Bei einer gängigeren Map wie HashMap oder LinkedHashMap, wird glaube ich null returned, wenn der key null ist, sodass parentNode null sein könnte. Bei einer DualLinkedHashBidiMap konnte ich nicht herausfinden wie es sich in dem Fall, dass der key null ist, verhält.
Evtl. ist es ja so implementiert, dass dann ein leeres Objekt returned wird. Ich finde die Stelle in der UI leider nicht, sodass ich das nicht mit dem Debugger testen kann. Aber vermutlich ist es genau so, denn wenn ich einfach 'ParentNode parentNode = parents.get(parent);' durch
'ParentNode parentNode = null' ersetze, dann kommt der hint zuverlässig.

Ich denke mal, dass dieser Thread dann ein Fehlalarm gewesen ist und sich die Sache erledigt hat.

 

[Zrebna]

Hi!

Ich belebe den Thead, weil ein weiter Fall auftretet, indem mir SonarLint nicht bzgl. Null-referencing meckert und ich nicht verstehe wieso nicht:

.findAll().stream().filter(e -> e.getStudent().equals(this.student))

Wenn der Aufruf 'e.getStudent()' NULL liefert, dann fliegt ja eine NPE. Müsste da nicht SonarLint meckern?
Kann ich etwas machen, dass SonarLint hier helfen kann, eine NPE zu verhindern?
Ich weiß nicht, evtl. muss ich etwas konfigurieren, damit alle NPE-bezogenen Sonar Rules aktiv sind?

Das einzige was mir einfällt ist sowas zu machen:

@CheckForNull
public Student getStudent() {
    // Code
}

Leider wird diese Annotation bei mir nicht erkannt. Ist da keine standardmäßige Annotation, die SonarLint kennt und verwenden kann?
Ich kann diese Annotation wohl erstellen, indem ich ein interface erstelle. Aber ist das der normale Weg? Oder muss ich was importieren? Hätte mir vorgestellt, dass es diese Annotationen standardmäßig gibt und SonarLint die verwenden kann.

 

[Zrebna]

Ah, ich kann das oben nicht mehr editieren, weil ich zu spät updaten mag.

Letztlich muss man wohl in seine POM, wenn es sich um ein maven-Projekt handelt, folgende dependency adden:

<dependency>
    <groupId>com.google.code.findbugs</groupId>
    <artifactId>jsr305</artifactId>
    <version>3.0.0</version>
</dependency>

Funktionieren die Annotationen con findbugs/spotbugs (denn sie scheinen zu diesen zu gehören) auch mit SonarLint - weiß das Jemand?

Und weiß Jemand wo man nachgucken kann, ob man die korrekte Version der dependency nutzt bzw. woher weiß man, welche man nutzen soll?

 

[KonradN]

Also SonarLint unterstützt mindestens die jsr 305 Annotations als auch die JetBrains Annotations.
Und da Meta Annotations unterstützt werden, reicht es auch, wenn eine andere Annotation eine solche Annotation hat.

Bezüglich Version musst Du Dir keine Gedanken machen. In der Annotation ist erst einmal absolut nichts kritisches drin. Wenn Du also eine eigene Annotation haben willst, dann könntest Du haben:

@org.jetbrains.annotations.NotNull
@interface MyNotNull {
}

Und schon meckert SonarLint:

    @MyNotNull
    static String nonNullString = "abc";

    public static void main( final String[] args) {
        nonNullString = null;

Die Library spielt also gar keine Rolle. Sie muss lediglich vom vollen Namen her passen.

Ich habe es nicht getestet, aber wenn ich MyNotNull in NotNull umbenenne und in org.jetbrains.annotations verschiebe (und die Meta Annotation heraus nehme), dann sollte es auch funktionieren ...

Edit: Habe es getestet mit zwei leeren Annotations org.jetbrains.annotations.NotNull und Nullable und Sonarlint funktioniert auch mit diesen...

 

[Zrebna]

Hi!

Ich hab jetzt einfach als dependency folgende verwendet:

<dependency>
     <groupId>com.google.code.findbugs</groupId>
     <artifactId>jsr305</artifactId>
     <version>3.0.0</version>
</dependency>

Und wenn du sagst, dass da Version nicht kritisch ist, dann sollte es passen.
Ich muss nun alles neu bauen, also maven-install und update und dann teste ich es, aber ggf. eine Frage vorab, denn mir schwant Böses bzw. habe ich wohl hier nicht richtig eingeschätzt, was SonarLint kann und was nicht.

Nochmal folgender Code:

@CheckForNull
public Adress getAdress() {
    // Code
}

public void foo(Student student) {
    Adress adress = student.getAdress();
    // Null-check fehlt
    adress.getStreet();
}

Da hätte ich gehofft, dass SonarLint meckert, weil keine NULL-Prüfung vorhanden ist, also es fehlt konkret sowas wie:

public void foo(Student student) {
    Adress adress = student.getAdress();

    if(address != null {
    adress.getStreet();
   }
}

Mittlerweile bin ich mir da nicht so sicher, ob das so gedacht ist. Na ja, gleich werde ich es ja sehen, sofern das mit den Annotationen dann klappt.

Wenn ich die Dependency inkludiert habe, dann kann ich aber die @CheckForNull-Annotation verwenden, ohne das ich sonst noch irgendwas tun muss? Weil du hast da irgendwie noch eine eigene Annotation erstellt - was das notwendig?

 

[KonradN]

Nein, du verwendest die vorhandenen Annotationen. Das ich da selbst welche erstellt hatte waren nur Tests.

Ich nutze die Annotations von JetBrains. Und da scheint es zu funktionieren:

    @Nullable
    private static String getTestString() {
        if (new Date().getTime() % 10 < 5) {
            return "<5";
        }
        return null;
    }



        String testString = getTestString();
        System.out.println(testString.length());

Also prinzipiell scheint der Check also zu funktionieren.

Das ist aber jetzt die JetBrains Annotation. Da ist kein CheckForNull sondern es wird Nullable genutzt.

Deine Verwendung ist also soweit korrekt und da würde ich auch eine Meldung erwarten, dass eine NPE droht.

Wenn es aktuelle Änderungen sind - mal gespeichert und übersetzt und dann im Editor zu einem anderen File und zurück gewechselt? Wobei das eigentlich unnötig ist - bei mir hat SonarLint - teilweise mit etwas Verspätung - dann die Hinweise aktualisiert.

 

[Zrebna]

private void foo(Long id {
        List<Adress> adresses = findAllAdressesByUniversityId(id);
        Adress adress = adresses.iterator().next();
      
        item.getAdress.equals(this.adress);
}

Da hätte ich gehofft, dass er einen Null-check haben will, weil die Methode getAdress() mit der CheckForNull-Annnotation versehen ist - aber leider nicht

Edit: Habe gerade deinen Post gesehen und die korrekte Annotation in meinem usecase ist wohl @Nullable.
Aber trotzdem kein Hint.


Oder anderes Beispiel: Klappt überhaupt sowas, dass man direkt auf dieser Ebene Annotationen verwenden kann:

@Nullable
List<String> list = something.getMap.get(key);
if(list.isEmpty()) {
        return;
}
String label = list.get(0);

Geht sowas überhaupt mit Annotationen?

Aber in jedem Fall müsste doch das obere erste Beispiel einen Hint anzeigen? Ich sehe da keinen Unterschied zu deinem Beispiel, bei dem du zuverlässig den Hint bekommt, dass 'testString' null sein könnte und daher eine NPE fleigen könnte.

Das ist schon gem. meiner schnellen google-Sucher der korrekte Import:

javax.annotation.Nullable ?​

 

[Zrebna]

Ich versuchs nochmal:
Ein Unterschied in deinem Beispiel ist, dass deine Methode eine Implementierungs-Logik enthält, die auch, falls die if-Abfrage nicht zutrifft, null returned.

Bei mir ist es so (ich poste hier nur andere Bezeichnungen, zwecks Diskretion, da der original Code von dem Unternehmen meiner Werkstudententätigkeit ist - daher wegen den Variablen-und Methodennamen bitte nicht wundern) :

1. Der Methoden-Body der annotierten Methode sieht so aus:

@Nullable
public Adress getAdress() {
    return adress;
}

2. 'adress' ist dabei ein Attribut in einer model-Klasse (also Klasse, die aud Datenbank-Seite eine Tabelle darstellt), nennen wir sie 'Studet' und ist mittels Hibernate-Annotationen folgendermaßen annotiert:

@ManyToOne(optional = true)
@JoinColumn(name = "adress_id", nullable = true)
private Adress adress;

Ich würde ja verstehen, wenn meine @Nullable-Annotation keinen Effekt hätte, wenn da 'nullable = false' stehen würde, aber adress darf ja ganz klar auch NULL sein.

3. Der Code, der die getAdress() in einer anderen Klasse (macht das einen Unterschied?) verwendet:

Student student = findById(id);

Adress adress = student.getAdress();
String street = adress.getStreet();  // Hier sollte doch ein SonarLint warning kommen?

System.out.println(street);

Update
Ich glaube mittlerweile, dass die Annotationen bei mir nicht funktionieren wollen, denn:

@Nullable
List<String> values = map.get(key);
// List<String> values = null;   
if(values.isEmpty()) {
return;
}

String name = values.get(0);

Wenn ich die Zeile

// List<String> values = null;

einkommentiert habe und die darüber auskommentiert, dann erhalte ich endlich den Hint bei 'values.isEmpty()'
-> A "NullPointerException" could be thrown; "valueMap" is nullable here.

Warum nicht, andersrum?

 

[KonradN]

Ich fürchte ich kann da auch nicht mehr zu sagen als dass ich dieses Problem nachvollziehen konnte. Bei mir habe ich ein ähnliches Verhalten feststellen können.

Ich würde ja verstehen, wenn meine @Nullable-Annotation keinen Effekt hätte, wenn da 'nullable = false' stehen würde, aber adress darf ja ganz klar auch NULL sein.

Da nur als kurzer Hinweis: Die Angabe beim JoinColumn wird meines Wissens nur für die Datenbank verwendet. Das hat mit den Checks von SonarLint erst einmal nichts zu tun. Wenn man das wollte, dann müsste man bei dem Field auch ein @Nullable angeben, damit es in der statischen Codeanalyse entsprechen behandelt wird.

Aber die zusätzliche Annotation auf dem Feld hat bei meinen Tests nichts verändert.

 

[Zrebna]

Ich fürchte ich kann da auch nicht mehr zu sagen als dass ich dieses Problem nachvollziehen konnte. Bei mir habe ich ein ähnliches Verhalten feststellen können.

Das heißt, dass bei dir der Hint bei einer Nachstellung von meinem Fall zuverlässig gekommen ist?

Da nur als kurzer Hinweis: Die Angabe beim JoinColumn wird meines Wissens nur für die Datenbank verwendet. Das hat mit den Checks von SonarLint erst einmal nichts zu tun.

Ja, stimmt macht Sinn, da es sich ja explizit auf die Column bezieht.

Wenn man das wollte, dann müsste man bei dem Field auch ein @Nullable angeben, damit es in der statischen Codeanalyse entsprechen behandelt wird.

Aber die zusätzliche Annotation auf dem Feld hat bei meinen Tests nichts verändert.

Bzgl. der zusätzlichen Annotation im Feld meinst du einfach so, oder:

@ManyToOne(optional = true)
@JoinColumn(name = "adress_id", nullable = true)
@Nullable
private Adress adress;

Zusätzlich trotzdem bei der getAdress()_Methode ebenfalls die @Nullable-Annotation belassen?
Also in so einem Fall (wenn die Methode nur ein Getter einer Model-Klasse ist, welche den Wert der Member-Variable returned und sonst keine Logik im Body beinhaltet) benötigt man also 2 Sachen, um dem SonarLint-Hint zu erhalten.

1. @Nullable-Annotation bei der Member-Variable (also im Feld) setzen.
2. @Nullable-Annotation bei der get-Methode setzen.

Ist das richtig so?

Würde ein Sonar-Lint-Hint auch bei sowas funktionieren:

List<Student> students = findAll().stream().filter(e -> e.getAdress.equals(this.adress))

Würde bei richtiger Annotation der getAdress-Methode und des entsprechenden Feldes, SonarLint das kapieren und aufgrund des euqals-Checks einen Null-dereferencing-Hint liefern?

Generelle Frage, weil du dich allgemein bzgl. clean practices gut auskennst:
Man hätte hier ja auch die @CheckForNUll-Annotation nutzen können, die wohl dann zu einem Null-Check auffordert, wann immer die annotierte Methode etwas anderes aufruft bzw. dereferenziert. Das würde ja eigentlich genau das sein, was wir wollen. Wieso nimmt man da nicht generell bei sowas diese Annotation, sondern oft die @Nullable-Annotation?


Lg
Zrebna

 

[KonradN]

Das heißt, dass bei dir der Hint bei einer Nachstellung von meinem Fall zuverlässig gekommen ist?

Das heisst, dass er bei mir das gleiche Problem hat, d.h. SonarLint hat nicht gewarnt. IntelliJ hat mich im Editor gewarnt, wobei ich jetzt nicht weiss, was IntelliJ da derzeit verwendet. Ich meine ich habe da kein weiteres PlugIn installiert.

Man hätte hier ja auch die @CheckForNUll-Annotation nutzen können, die wohl dann zu einem Null-Check auffordert, wann immer die annotierte Methode etwas anderes aufruft bzw. dereferenziert. Das würde ja eigentlich genau das sein, was wir wollen. Wieso nimmt man da nicht generell bei sowas diese Annotation, sondern oft die @Nullable-Annotation?

Die CheckForNull Annotation ist auch aus meiner Sicht korrekt so man JSR 305 folgt.

Ich habe aber die Annotation von JetBrains und da habe ich keine CheckForNull Annotation. Daher habe ich bei mir die @Nullable Annotation verwendet.

Die Dokumentation bei der JSR 305 Implementation ist so, dass @Nullable eigentlich nie verwendet wird sondern nur, wenn da ein @NotNull überschrieben werden muss. Etwas in der Art habe ich zumindest gelesen. Dazu mal die JavaDoc von javax.annotations.NotNull und CheckForNull prüfen. Ich habe da jetzt nicht noch einmal nachgelesen sondern das nur aus dem Kopf geschrieben, was ich da gelesen hatte.

 

[LimDul]

die Javax-Annotationen gehen meines Wissens nicht - da sie nicht im Class-File erhalten bleiben.

 

[Zrebna]

die Javax-Annotationen gehen meines Wissens nicht - da sie nicht im Class-File erhalten bleiben.

Hm, weißt du, wie das Leute, die SonarLint mit Eclipse verwenden fixen können? Bzw. was verwendet man hier?
Von welcher dependency/library verwendet SonarLint diese Annotationen?
Ich mein, irgendwie muss ja SonarLint eigentlich auch mit Eclipse und nicht nur bei Intellij funktionieren...

 

[LimDul]

ich hab gerade mal geschaut - ich hab glaub ich hab das mit @Generated verwechselt, wo die javax Annotation nicht im Code enthalten bleibt. Die Jakarta Variante hat zumindest die Rentention Runtime, so dass es gehen müsste. Sorry, für die Verwirrung.

Wir verwenden bei uns spotbugs + die findbugs Annotationen und funktioniert das sehr zuverlässig, daher muss ich zu sonarlint passen

 

[KonradN]

Hm, weißt du, wie das Leute, die SonarLint mit Eclipse verwenden fixen können? Bzw. was verwendet man hier?
Von welcher dependency/library verwendet SonarLint diese Annotationen?
Ich mein, irgendwie muss ja SonarLint eigentlich auch mit Eclipse und nicht nur bei Intellij funktionieren...

Also das ist erst einmal ein SonarLint Verhalten, denn ich nutze IntelliJ.

Was Du immer probieren kannst, ist die Verwendung von SonarCube, also mit Verbindung zu einem Server. Du kannst ja einen Server auch kostenlos aufsetzen. Ich meine mich zu erinnern, dass auf der Webseite irgendwo stand, dass die Server Variante leistungsstärker ist.

Ansonsten wie auch @LimDul schon meinte: Evtl. SonarLint nicht als einziges Tool verwenden. Mit SpotBugs habe ich auch gute Erfahrungen gesammelt und nutze SpotBugs und PMD in meinen Maven Projekten. SonarLint habe ich nur zusätzlich in IntelliJ eingebunden.

 

[Zrebna]

ich hab gerade mal geschaut - ich hab glaub ich hab das mit @Generated verwechselt, wo die javax Annotation nicht im Code enthalten bleibt. Die Jakarta Variante hat zumindest die Rentention Runtime, so dass es gehen müsste. Sorry, für die Verwirrung.

Wir verwenden bei uns spotbugs + die findbugs Annotationen und funktioniert das sehr zuverlässig, daher muss ich zu sonarlint passen

Ich danke euch beiden sehr! SonarQubeServer möchte ich nach meiner Abschlussarbeit privat in einem eigenem "Pet-Projekt" versuchen und da werde ich dann sehen, ob es evtl. mit SonarQubeServer funktioniert.

Für meine Abschlussarbeit möchte ich statische Codeanalyse erstmal nur lokal in der IDE verwenden.
Ich habe mich gerade über SpotBugs etwas informiert und das Tool interessiert mich sehr. Es scheint genau das richtige zu sein, was ich brauche: Ein Tool für statische Codeanalyse ohne viel setup Aufwand, das bekannt ist und mit Java funktioniert. Außerdem hat genau dieses Tool mein betreuender Professor genannt, weshalb ich das mal ebenfalls testen möchte.

Daher werde ich es damit versuchen @LimDul.

Es scheint wohl ebenfalls ein IDE-Plugin zu sein? Ich hänge ein Bild an, mit der Frage, welche Version da die richtige ist. Ich gehe davon aus, die erste, da ja SpotBugs ein Nachfolger von FindBugs ist, glaube ich.
Braucht man dazu noch irgendwas? Zum Beispiel eine Maven-Dependency in die POM? Falls ja, welche?
Damit die FindBugs-Annnotationen funktionieren, habe ich diese Dependency:

<dependency>
    <groupId>com.google.code.findbugs</groupId>
    <artifactId>jsr305</artifactId>
    <version>3.0.0</version>
</dependency>

Benötige ich sonst noch was oder kostenloses (?) IDE-Plugin installieren und los kanns gehn?

Letzte Frage:
Können sich SonarLint und SpotBugs gegenseitig behindern? Zur Sicherheit denke ich, dass ich SonarLint mal von meinem Eclipse runterwerfe, also vorab deinstalliere...

Danke euch beiden nochmal für euren Support!

 

[KonradN]

Also ich lasse SpotBugs als Maven Plugin laufen - damit ist es ja unabhängig von allen anderen Tools. Das Gleiche gilt für PMD.

Wenn man mehrere Plugins in einer IDE hat, dann kann es natürlich auch zu irgendwelchen Problemen kommen. Aber das kann man in der Regel einfach ausprobieren und dann sieht man, wie es sich verträgt. Oft sind da dann einfach nur Settings umzustellen oder so.

 

[Zrebna]

Also ich habe mir jetzt mal in einer "sicheren" Umgebung (auf meinem alten privaten Laptop) SpotBugs als IDE-Plugin installiert und SonarLint vorab deinstalliert.

Die javax-Annotationen sind wohl nicht die richtigen und mittlerweile habe ich diese maven-dependency in meine POM.xml hinzugefügt und gehe davon aus, dass diese jetzt die richtigen sind:

<!-- https://mvnrepository.com/artifact/com.github.spotbugs/spotbugs-annotations -->
<dependency>
    <groupId>com.github.spotbugs</groupId>
    <artifactId>spotbugs-annotations</artifactId>
    <version>4.8.3</version>
</dependency>

Und Hurra, es hat eeeendlich geklappt

Was ich etwas schade finde, dass es wohl nicht immer so schnell reagiert, wie SonarLint und ich manchmal erst auf die entsprechende Klasse oder auf das entsprechende Projekt rechts-klicken muss und quasi unter 'SpotBugs -> Find Bugs' die Bug/Smell-detection anstoßen muss.

Na ja, immerhin klappt es jetzt ^^
Nochmal vielen Dank für den Support!

 

[Zrebna]

Nochmal ganz kurz, falls Jemand irgendwann mal auf das selbe Problem wie ich stoßen sollte, sofern SonarLint verwendet wird.
Man kann auch die FindBugs-Annotationen mit SonarLint verwenden, weil Annotationen selbst unabhängig vom Analyse-Tool sind.

Also mit der maven-dependency weiter oben, wirds dann auch mit SonarLint klappen - hier nochmal:

<!-- https://mvnrepository.com/artifact/com.github.spotbugs/spotbugs-annotations -->
<dependency>
    <groupId>com.github.spotbugs</groupId>
    <artifactId>spotbugs-annotations</artifactId>
    <version>4.8.3</version>
</dependency>

 

[Zrebna]

Hi!

Ich hole den Thread nochmal kurz hoch:

Ich habe gerade erst herausgefunden, dass die @CHeckForNull-Annotation deprecated ist.
Was nutzt man den als Standard alternativ?

 

[LimDul]

Welche genau? Schonmal ins Javadoc geschaut - in der Regel steht da was die Alternative ist.

 

[Zrebna]

Ich füge mal eine Abbildung ein - da schlägt javadoc keine Alternative vor - oder soll da die '@Nonnull die Alternative sein?
Die Annotation kommt von: edu.umd.cs.findbugs.annotations.CheckForNull

Komisch, dass sie nicht als deprecated markiert gewesen ist - normal ist doch etwas, dass deprecated ist im Code quasi "durchgestrichen".