Rheinwerk Computing < openbook >


 
Inhaltsverzeichnis
Materialien
Vorwort
1 Java ist auch eine Sprache
2 Imperative Sprachkonzepte
3 Klassen und Objekte
4 Arrays und ihre Anwendungen
5 Der Umgang mit Zeichenketten
6 Eigene Klassen schreiben
7 Objektorientierte Beziehungsfragen
8 Ausnahmen müssen sein
9 Geschachtelte Typen
10 Besondere Typen der Java SE
11 Generics<T>
12 Lambda-Ausdrücke und funktionale Programmierung
13 Architektur, Design und angewandte Objektorientierung
14 Java Platform Module System
15 Die Klassenbibliothek
16 Einführung in die nebenläufige Programmierung
17 Einführung in Datenstrukturen und Algorithmen
18 Einführung in grafische Oberflächen
19 Einführung in Dateien und Datenströme
20 Einführung ins Datenbankmanagement mit JDBC
21 Bits und Bytes, Mathematisches und Geld
22 Testen mit JUnit
23 Die Werkzeuge des JDK
A Java SE-Module und Paketübersicht
Stichwortverzeichnis


Download:

- Listings, ca. 2,7 MB


Buch bestellen
Ihre Meinung?



Spacer
<< zurück
Java ist auch eine Insel von Christian Ullenboom

Einführung, Ausbildung, Praxis
Buch: Java ist auch eine Insel


Java ist auch eine Insel

Pfeil 10 Besondere Typen der Java SE
Pfeil 10.1 Object ist die Mutter aller Klassen
Pfeil 10.1.1 Klassenobjekte
Pfeil 10.1.2 Objektidentifikation mit toString()
Pfeil 10.1.3 Objektgleichwertigkeit mit equals(…) und Identität
Pfeil 10.1.4 Klonen eines Objekts mit clone() *
Pfeil 10.1.5 Hashwerte über hashCode() liefern *
Pfeil 10.1.6 System.identityHashCode(…) und das Problem der nicht eindeutigen Objektverweise *
Pfeil 10.1.7 Aufräumen mit finalize() *
Pfeil 10.1.8 Synchronisation *
Pfeil 10.2 Schwache Referenzen und Cleaner
Pfeil 10.3 Die Utility-Klasse java.util.Objects
Pfeil 10.3.1 Eingebaute null-Tests für equals(…)/hashCode()
Pfeil 10.3.2 Objects.toString(…)
Pfeil 10.3.3 null-Prüfungen mit eingebauter Ausnahmebehandlung
Pfeil 10.3.4 Tests auf null
Pfeil 10.3.5 Indexbezogene Programmargumente auf Korrektheit prüfen
Pfeil 10.4 Vergleichen von Objekten und Ordnung herstellen
Pfeil 10.4.1 Natürlich geordnet oder nicht?
Pfeil 10.4.2 compareXXX()-Methode der Schnittstellen Comparable und Comparator
Pfeil 10.4.3 Rückgabewerte kodieren die Ordnung
Pfeil 10.4.4 Beispiel-Comparator: den kleinsten Raum einer Sammlung finden
Pfeil 10.4.5 Tipps für Comparator und Comparable-Implementierungen
Pfeil 10.4.6 Statische und Default-Methoden in Comparator
Pfeil 10.5 Wrapper-Klassen und Autoboxing
Pfeil 10.5.1 Wrapper-Objekte erzeugen
Pfeil 10.5.2 Konvertierungen in eine String-Repräsentation
Pfeil 10.5.3 Von einer String-Repräsentation parsen
Pfeil 10.5.4 Die Basisklasse Number für numerische Wrapper-Objekte
Pfeil 10.5.5 Vergleiche durchführen mit compareXXX(…), compareTo(…), equals(…) und Hashwerten
Pfeil 10.5.6 Statische Reduzierungsmethoden in Wrapper-Klassen
Pfeil 10.5.7 Konstanten für die Größe eines primitiven Typs
Pfeil 10.5.8 Behandeln von vorzeichenlosen Zahlen *
Pfeil 10.5.9 Die Klasse Integer
Pfeil 10.5.10 Die Klassen Double und Float für Fließkommazahlen
Pfeil 10.5.11 Die Long-Klasse
Pfeil 10.5.12 Die Boolean-Klasse
Pfeil 10.5.13 Autoboxing: Boxing und Unboxing
Pfeil 10.6 Iterator, Iterable *
Pfeil 10.6.1 Die Schnittstelle Iterator
Pfeil 10.6.2 Wer den Iterator liefert
Pfeil 10.6.3 Die Schnittstelle Iterable
Pfeil 10.6.4 Erweitertes for und Iterable
Pfeil 10.6.5 Interne Iteration
Pfeil 10.6.6 Eine eigene Iterable implementieren *
Pfeil 10.7 Die Spezial-Oberklasse Enum
Pfeil 10.7.1 Methoden auf Enum-Objekten
Pfeil 10.7.2 Aufzählungen mit eigenen Methoden und Initialisierern *
Pfeil 10.7.3 enum mit eigenen Konstruktoren *
Pfeil 10.8 Annotationen in der Java SE
Pfeil 10.8.1 Orte für Annotationen
Pfeil 10.8.2 Annotationstypen aus java.lang
Pfeil 10.8.3 @Deprecated
Pfeil 10.8.4 Annotationen mit zusätzlichen Informationen
Pfeil 10.8.5 @SuppressWarnings
Pfeil 10.9 Zum Weiterlesen
 

Zum Seitenanfang

10.8    Annotationen in der Java SE Zur vorigen ÜberschriftZur nächsten Überschrift

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.

 

Zum Seitenanfang

10.8.1    Orte für Annotationen Zur vorigen ÜberschriftZur nächsten Überschrift

Annotationen lassen sich setzen an Deklarationen von:

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

  • Eigenschaften: Konstruktoren, Methoden, Attributen

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.

[+]  Ausblick

Ein Beispiel für eine externe Bibliothek ist das Checker Framework (http://checkerframework.org/), das eine große Anzahl von Annotationstypen und ein Werkzeug zur Prüfung von Eigenschaften bereitstellt. Damit lässt sich zum Beispiel Folgendes schreiben:

@NonNull Object ref = new Object();

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

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

Ein anderes Beispiel ist Beans Validation (http://beanvalidation.org/), mit dem sich zum Beispiel Folgendes schreiben lässt:

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

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

Zum Seitenanfang

10.8.2    Annotationstypen aus java.lang Zur vorigen ÜberschriftZur nächsten Überschrift

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

Annotationstyp

Wirkung

@Override

Die annotierte Methode überschreibt eine Methode aus der Oberklasse oder implementiert eine Methode einer Schnittstelle.

@Deprecated

Das markierte Element ist veraltet und sollte nicht mehr verwendet werden.

@SuppressWarnings

Unterdrückt bestimmte Compilerwarnungen.

@SafeVarargs

Besondere Markierung für Methoden mit variabler Argumentzahl und generischem Argumenttyp

@FunctionalInterface

Für Schnittstellen, die nur genau eine (abstrakte) Methode besitzen

Tabelle 10.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.

 

Zum Seitenanfang

10.8.3    @Deprecated Zur vorigen ÜberschriftZur nächsten Überschrift

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.

[zB]  Beispiel

Die Methode fubar()[ 205 ](Im US-Militär-Slang steht das für: »Fucked up beyond any recognition« – »vollkommen ruiniert«. ) soll als veraltet markiert werden:

@Deprecated

public void fubar() { ... }

Ruft irgendein Programmstück fubar() auf, gibt der Compiler eine einfache Meldung aus.

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.

 

Zum Seitenanfang

10.8.4    Annotationen mit zusätzlichen Informationen Zur vorigen ÜberschriftZur nächsten Überschrift

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.

Schreibweise der Annotation

Funktion

@Annotationstyp

(Marker-)Annotation

@Annotationstyp( Wert )

Annotation mit genau einem Wert

@Annotationstyp( Schlüssel1=Wert1,

                 Schlüssel2=Wert2, ... )

Annotation mit Schlüssel-Wert-Paaren

Tabelle 10.11    Annotationen mit und ohne zusätzliche Informationen

Klammern sind bei einer Marker-Annotation optional.

 

Zum Seitenanfang

10.8.5    @SuppressWarnings Zur vorigen ÜberschriftZur nächsten Überschrift

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 10.10), IntelliJ dagegen standardmäßig nicht.

Warnungen in Eclipse

Abbildung 10.10    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.

[zB]  Beispiel

Der Compiler soll keine Meldungen für die Klasse ausgeben:

Listing 10.46    src/main/java/com/tutego/insel/annotation/SuppressAllWarnings.java

@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. Eclipse unterstützt uns mit einem Quick Fix und schlägt für unser Beispiel Folgendes vor:

  • @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.

[zB]  Beispiel

Der Compiler soll für die ungenerisch verwendete Liste und ihre Methoden keine Meldungen geben:

@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.

[»]  Hinweis

Die Schreibweise @SuppressWarnings("xyz") ist nur eine Abkürzung von @SuppressWarnings({"xzy"}), und das wiederum ist nur eine Abkürzung von @SuppressWarnings(value= {"xzy"}).

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.[ 206 ](http://help.eclipse.org/oxygen/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:[ 207 ](AutoCloseable ist eine Schnittstelle, die Klassen implementieren, die über eine close()-Methode verfügen. Abschnitt 8.7.2 stellt diese Schnittstelle vor. )

@SuppressWarnings

Unterdrückt Meldungen für

deprecation

veraltete Elemente, wie new java.util.Date(2012-1970, 3, 3)

incomplete-switch

ausgelassene Aufzählungen in switch-case-Anweisungen

resource

ein nicht geschlossenes AutoCloseable, wie in new java.util. Scanner(System.in).nextLine()15

serial

eine serialisierbare Klasse, die keine Serialisierungs-ID besitzt

unused

nicht benutzte Elemente, etwa nicht aufgerufene private Methoden

Tabelle 10.12    Einige Werte von @SuppressWarnings

 


Ihre Meinung?

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de

<< zurück
 Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Java ist auch eine Insel Java ist auch eine Insel

Jetzt Buch bestellen


 Buchempfehlungen
Zum Rheinwerk-Shop: Captain CiaoCiao erobert Java

Captain CiaoCiao erobert Java




Zum Rheinwerk-Shop: Java SE 9 Standard-Bibliothek

Java SE 9 Standard-Bibliothek




Zum Rheinwerk-Shop: Algorithmen in Java

Algorithmen in Java




Zum Rheinwerk-Shop: Objektorientierte Programmierung

Objektorientierte Programmierung




 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und in die Schweiz

InfoInfo



 

 


Copyright © Rheinwerk Verlag GmbH 2021

Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.

Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

 

[Rheinwerk Computing]



Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de



Cookie-Einstellungen ändern