Wo gehört der Typ Annotation in einen begrenzten Platzhalter?

Question

Ich habe vor kurzem begonnen, meine Java-Projekte mit Eclipse nullability Annotationen zu aktualisieren. Ich habe ein JavaFX-Basisprojekt mit einigen Übersetzungsklassen.

Jetzt in meinem LocalizedList initialisiere ich es mit einem Element in der Dokumentstruktur und es rekursiv fügt alle seine Unterelemente hinzu.

@NonNullByDefault 
private void locChildren(Styleable c) { 
    String localizable = getKey(c); 
    if(localizable != null) { 
     backingMap.put(c, localizable); 
     setText(c, localizable); 
    } 
    if(c instanceof MenuBar) { 
     MenuBar mb = (MenuBar)c; 
     initLoc(mb.getMenus()); 
    } // else if ... 
} 

@NonNullByDefault 
public void initLoc(List<? extends Styleable> s) { 
    for(Styleable c : s) { 
     locChildren(c); 
    } 
} 

---

Nun, wenn ich es mit nur bekomme ich Nachricht

die schrecklich lange Warnung dieses links

Null type safety (type annotations): The expression of type 'ObservableList<Menu>' needs unchecked conversion to conform to '@NonNull List<? extends @NonNull Styleable>', corresponding supertype is 'List<Menu>'

Dieser weil MenuBar#getMenus() ist nicht mit NULL-Zulässigkeit Anmerkungen kommentiert, und zu erwarten.

---

Nach dem Anwenden der Annullierung @Nullable auf die Liste selbst wurde das Problem nicht gelöst. Also habe ich @Nullable zum Platzhalter hinzugefügt. Hier bin ich auf etwas Verwirrendes gestoßen.

@NonNullByDefault 
public void initLoc1(@Nullable List<@Nullable ? extends Styleable> s) { 
    for(Styleable c : s) { 
     locChildren(c); 
    } 
} 

@NonNullByDefault 
public void initLoc2(@Nullable List<@Nullable ? extends @Nullable Styleable> s) { 
    for(Styleable c : s) { 
     locChildren(c); 
    } 
} 

@NonNullByDefault 
public void initLoc3(@Nullable List<? extends @Nullable Styleable> s) { 
    for(Styleable c : s) { 
     locChildren(c); 
    } 
} 

Jede dieser drei Deklarationen ist gültig und kompiliert, aber nur die letzte macht die Warnmeldung verschwinden.

---

Ich hätte die erste als gültig zu erwarten, da sie den „Typ“ tatsächlich annotiert, das sich in dem Verfahren verwendet wird, und bin vollständig von dem zweiten Beispiel verwirrt.

Was genau ist der semantische Unterschied zwischen diesen drei Deklarationen, und warum funktionieren drei, während zwei und eins nicht?

Answer 1

Um das ursprüngliche Codebeispiel zu verstehen, ist es notwendig, den genauen Effekt von @NonNullByDefault zu kennen, der unter Verwendung von enum DefaultLocation fein abgestimmt werden kann. Letzteres erwähnt

Wildcards und die Verwendung von Typvariablen sind immer von NonNullByDefault ausgeschlossen.

Auf der anderen Seite der Platzhalter gebunden extends Styleable von @NonNullByDefault betroffen ist.

Dies erklärt, warum der erwartete Argumenttyp von initLoc@NonNull List<? extends @NonNull Styleable> ist. Die Methode initLoc3 löst den Kompilierfehler auf, weil sie genau diese beiden @NonNull Annotationen wie hier gezeigt überschreibt - indem sie in diesen Positionen explizit @Nullable angibt.

Um eine explizite @Nullable auf den Platzhalter selbst anzuwenden, folgt Eclipse die concepts wie für das Checkers Framework vorgeschlagen. Insbesondere wird @Nullable ? so interpretiert, dass es untere und obere Schranken mit nullbaren Eigenschaften hat.

Dies erklärt, warum initLoc2 unterscheidet sich von initLoc3: Es definiert eine zusätzliche untere gebunden, die dann durch die tatsächliche Argument unerreicht ist.

Um Ihr Problem in Bezug auf MenuBar zu lösen, sollten Sie die Verwendung von external annotations in Erwägung ziehen.

Haftungsausschluss: Ich konnte Ihre Situation nicht genau reproduzieren, weil mir der Klassenkontext der gezeigten Methoden fehlte. Woher kommen getKey, backingMap und setText?