11.7    Annotationen in der Java SE 

Wir haben Annotationen als benutzerdefinierte Modifizierer kennengelernt. Dabei ist uns @Override schon mehrfach begegnet. Die Annotation wird nur vom Compiler betrachtet und ist auch nur an Methoden gültig.

 

11.7.1    Orte für Annotationen 

Annotationen lassen sich setzen an Deklarationen von:

• Typen: Klassen, Schnittstellen, Aufzählungen, andere Annotationstypen

• Eigenschaften: Konstruktoren, Methoden, Klassen-/Objektvariablen

Eine Annotation von einem Typ kann zum Beispiel gesetzt werden bei:

• Variablendeklarationen

• new

• Typumwandlung

• der implements-Klausel

• der throws-Klausel bei Methoden

Die Annotationen bei der Typnutzung nennen sich kurz Typ-Annotationen. Diese Form ermöglicht noch weitere Prüfungen von insbesondere externen Werkzeugen.

Java bringt einige Annotationstypen mit, doch die werden bisher ausschließlich für Deklarationen eingesetzt, wie das bekannte @Override. Vordefinierte Typ-Annotationen sind bisher in der Java SE nicht zu finden.

@NonNull Object ref = new Object();

public int compareTo(@NonNull String other) { ... }

boolean lessThan(double[] arr1, double @SameLen("#1") [] arr2) { ... }

Optional<@Past LocalDate> getBirthday() { ... }

@Min(value = 18) @Max(value = 150) int age;

 

11.7.2    Annotationstypen aus java.lang 

Das Paket java.lang deklariert fünf Annotationstypen, wobei uns @Override schon oft begleitet hat.

Tabelle 11.10     Annotationen aus dem Paket »java.lang«

Die fünf Annotationen haben für den Compiler bzw. das Laufzeitsystem eine besondere Semantik. Die Java SE deklariert in anderen Paketen (wie dem java.lang.annotation- und javax.annotation-Paket) noch weitere Annotationstypen, doch die sind an dieser Stelle nicht relevant. Dazu kommen spezielle technologiespezifische Annotationstypen wie für die XML-Objekt-Abbildung oder Webservice-Deklarationen.

 

11.7.3    @Deprecated 

Die Annotation @Deprecated übernimmt die gleiche Aufgabe wie das Javadoc-Tag @deprecated: Die markierten Elemente werden als veraltet markiert und drücken damit aus, dass der Entwickler Alternativen nutzen soll.

@Deprecated

public void fubar() { ... }

Die Übersetzung mit dem Schalter -Xlint:deprecation liefert die genauen Warnungen; im Moment liefert -deprecation die gleiche Ausgabe.

Auch über ein Javadoc-Tag kann ein Element als veraltet markiert werden. Ein Unterschied bleibt: Das Javadoc-Tag kann nur von Javadoc (oder einem anderen Doclet) ausgewertet werden, während Annotationen auch andere Tools auswerten können.

 

11.7.4    Annotationen mit zusätzlichen Informationen 

Die Annotationen @Override und @Deprecated gehören zur Klasse der Marker-Annotationen, weil keine zusätzlichen Angaben nötig (und erlaubt) sind. Zusätzlich gibt es die Single-Value-Annotation, die genau eine zusätzliche Information bekommt, sowie eine volle Annotation mit beliebigen Schlüssel-Wert-Paaren.

Tabelle 11.11     Annotationen mit und ohne zusätzliche Informationen

Klammern sind bei einer Marker-Annotation optional.

 

11.7.5    @SuppressWarnings 

Die Annotation @SuppressWarnings steuert Compilerwarnungen. Unterschiedliche Werte bestimmen genauer, welche Hinweise unterdrückt werden. Nützlich ist die Annotation bei der Umstellung von Quellcode, der vor Java 5 entwickelt wurde, denn mit Java 5 zogen Generics ein, eine Möglichkeit, dem Compiler noch mehr Informationen über Typen zu geben. Die Java-API-Designer haben daraufhin die Deklaration der Datenstrukturen überarbeitet und Generics eingeführt, was dazu führt, dass vor Java 5 entwickelter Quellcode mit einem aktuellen Java-Compiler eine Vielzahl von Warnungen ausgibt. Nehmen wir folgenden Programmcode:

ArrayList list;

list = new ArrayList();

list.add( "SuppressWarnings" );

Eclipse zeigt die Meldungen direkt an (siehe Abbildung 11.9), IntelliJ dagegen standardmäßig nicht.

Abbildung 11.9     Warnungen in Eclipse

Der Compiler javac meldet über die Kommandozeile recht unspezifisch:

Note: ABC.java uses unchecked or unsafe operations.

Note: Recompile with -Xlint:unchecked for details.

Mit dem gesetzten Schalter -Xlint heißt es dann genauer:

warning: [rawtypes] found raw type: ArrayList

        ArrayList list1;

        ^

  missing type arguments for generic class ArrayList<E>

  where E is a type-variable:

    E extends Object declared in class ArrayList



warning: [rawtypes] found raw type: ArrayList

        list1 = new ArrayList();

                    ^

  missing type arguments for generic class ArrayList<E>

  where E is a type-variable:

    E extends Object declared in class ArrayList



warning: [unchecked] unchecked call to add(E) as a member of the raw type ArrayList

        list1.add("SuppressWarnings");

                 ^

  where E is a type-variable:

    E extends Object declared in class ArrayList

Zwei unterschiedliche Arten von Warnungen treten auf:

• Da die Klasse ArrayList als generischer Typ deklariert ist, melden die ersten beiden Zeilen »found raw type: ArrayList« (javac) bzw. »ArrayList is a raw type. References to generic type ArrayList<E> should be parameterized« (Eclipse).

• Die dritte Zeile nutzt mit add(…) eine Methode, die über Generics einen genaueren Typparameter bekommen könnte. Da wir keinen Typ angegeben haben, folgt die Warnung: »unchecked call to add(E) as a member of the raw type ArrayList« (javac) bzw. »Type safety: The method add(Object) belongs to the raw type ArrayList. References to generic type ArrayList<E> should be parameterized« (Eclipse).

Warnungen lassen sich über die Annotation @SuppressWarnings ausschalten. Als spezieller Modifizierer lässt sich die Annotation an der Variablendeklaration anbringen, an der Methodendeklaration oder an der Klassendeklaration. Die Reichweite ist aufsteigend. Wer bei altem Programmcode kurz und schmerzlos alle Warnungen abschalten möchte, der setzt ein @SuppressWarnings("all") an die Klassendeklaration.

@SuppressWarnings( "all" )

public class SuppressAllWarnings {



  public static void main( String[] args ) {

    java.util.ArrayList list1 = new java.util.ArrayList();

    list1.add( "SuppressWarnings" );



    java.util.ArrayList list2 = new java.util.ArrayList();

  }

}

Anstatt jede Warnung mit @SuppressWarnings("all") zu unterdrücken, ist es eine bessere Strategie, selektiv vorzugehen:

• @SuppressWarnings("rawtypes") für ArrayList list und list = new ArrayList()

• @SuppressWarnings("unchecked") für list.add("...")

Da zwei gleiche Modifizierer nicht erlaubt sind – und auch zweimal @SuppressWarnings nicht –, wird eine besondere Array-Schreibweise gewählt.

@SuppressWarnings( { "rawtypes", "unchecked" } )

public static void main( String[] args ) {

  ArrayList list = new ArrayList();

  list.add( "SuppressWarnings" );

}

Kurz kam bereits zur Sprache, dass die @SuppressWarnings-Annotation auch bei der Variablendeklaration möglich ist. Für unser Beispiel hilft das allerdings wenig, wenn etwa bei der Deklaration der Liste alle Warnungen abgeschaltet werden:

@SuppressWarnings( "all" ) ArrayList list;

list = new ArrayList();          // Warnung: ArrayList is a raw type...

list.add( "SuppressWarnings" );  // Warnung: Type safety ...

Das @SuppressWarnings("all") gilt nur für die eine Deklaration ArrayList list und nicht für folgende Anweisungen, die etwas mit der list machen. Zur Verdeutlichung setzt das Beispiel die Annotation daher in die gleiche Zeile.

Neben den von Generics kommenden Kennungen rawtype und unchecked gibt es weitere, die allerdings nicht sonderlich gut dokumentiert sind. Das liegt auch daran, dass Meldungen während der Programmübersetzung zur Compilerinfrastruktur gehören und nicht zur Laufzeitumgebung, und damit nicht zur traditionellen Java-API. Der Compiler kann im Prinzip beliebige Codeanalysen beliebiger Komplexität vornehmen und bei vermuteten Fehlern Alarm schlagen. Und wir dürfen auch nicht vergessen, dass es nur Warnungen sind: Wer als Programmierer alles richtig macht, wird die Meldungen nicht zu Gesicht bekommen. Dennoch ist es relevant, sie zu kennen, denn der Compiler wird manches Mal etwas anmerken, was Entwickler bewusst nutzen wollen, und dann gilt es, die Meldungen abzuschalten.

Die Entwickler des Eclipse-Compilers (JDT) dokumentieren die unterstützten Warnungen.[ 208 ](https://help.eclipse.org/2021-09/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-suppress_warnings.htm) Neben den aufgeführten Meldungen all, rawtype und unchecked sind folgende interessant:[ 209 ](AutoCloseable ist eine Schnittstelle, die Klassen implementieren, die über eine close()-Methode verfügen. Abschnitt 9.6.2 stellt diese Schnittstelle vor. )

Tabelle 11.12     Einige Werte von @SuppressWarnings