11.3 Die Utility-Klasse java.util.Objects
Die Klasse Objects hält einige statische Utility-Funktionen bereit. Sie führen in erster Linie null-Tests durch, um eine spätere NullPointerException beim Aufruf von Objektmethoden zu vermeiden.
11.3.1 Eingebaute null-Tests für equals(…)/hashCode()
Ist zum Beispiel eine Objektvariable name einer Person null, so kann nicht einfach name.hashCode() aufgerufen werden, ohne dass eine NullPointerException folgt. Drei Methoden von Objects führen null-Tests durch, bevor sie an die Object-Methode equals(…)/hashCode()/toString() weiterleiten. Eine zusätzliche Hilfsmethode arbeitet mit Comparatoren, die wir in Abschnitt 11.4, »Vergleichen von Objekten und Ordnung herstellen«, kennenlernen werden.
class java.util.Objects
-
static boolean equals(Object a, Object b)
Liefert true, wenn beide Argumente entweder null sind oder a.equals(b) ebenfalls true ergibt, andernfalls liefert es false. Dass Objects.equals(null, null) die Rückgabe true ergibt, ist sinnvoll, und so erspart die Methode einige händische Tests. -
static int hashCode(Object o)
Liefert 0, wenn o gleich null ist, sonst o.hashCode(). -
static int hash(Object… values)
Ruft hashCode() auf jedem Objekt der Sammlung values auf und verbindet es zu einem neuen Hashwert. Die Implementierung ist einfach ein return Arrays.hashCode(values). Die Nutzung der Methode ist eher teuer durch den Aufbau des Varargs-Arrays und mögliche Boxing-Operationen für primitive Werte. -
static <T> int compare(T a, T b, Comparator<? super T> c)
Liefert 0, wenn a und b beide entweder null sind oder der Comparator die Objekte a und b für gleich erklärt. Sind a und b beide ungleich null, so ist die Rückgabe c.compare(a, b). Ist nur a oder b gleich null, so hängt das Ergebnis vom Comparator und von der Reihenfolge der Parameter ab.
[zB] Beispiel
Erinnern wir uns an die überschriebene Methode hashCode() des Spielers, bei der der Spielername in den Hashwert eingehen soll:
result = 31 * result + ((name == null) ? 0 : name.hashCode());
Mit Objects.hashCode(Object) kann der null-Test entfallen, da er schon in der statischen Methode vorgenommen wird:
result = 31 * result + Objects.hashCode( name );
11.3.2 Objects.toString(…)
Eine weitere statische Methode ist Objects.toString(Object). Sie ist aus Symmetriegründen in der Klasse, da toString() zu den Standardmethoden der Klasse Object zählt. Genutzt werden muss die Methode nicht, da es mit String.valueOf(…) schon eine entsprechende Methode gibt.
class java.util.Objects
-
static String toString(Object o)
Liefert den String "null", wenn das Argument null ist, sonst o.toString().
[»] Hinweis
Die Methode String.valueOf(…) ist überladen und für primitive Argumente besser geeignet als Objects.toString(Object), bei der immer erst Wrapper-Objekte aufgebaut werden müssen. Zwar sehen String.valueOf(3.14) und Objects.toString(3.14) gleich aus, aber im zweiten Fall kommt ein Wrapper-Double-Objekt mit ins Spiel.
11.3.3 null-Prüfungen mit eingebauter Ausnahmebehandlung
Bei den vorangehenden Methoden wird null als Sonderfall behandelt, und Ausnahmen werden vermieden. So sind etwa Objects.toString(null) oder Objects.hashCode(null) in Ordnung, und es wird um null »herumgearbeitet«. Das ist nicht immer sinnvoll, denn traditionell gilt es, null als Argument und in den Rückgaben zu vermeiden. Es ist daher gut, als Erstes in einem Methodenrumpf zu testen, ob die Argumente ungleich null sind – es sei denn, das ist unbedingt gewünscht.
Für diese Tests, dass Referenzen ungleich null sind, bietet Objects ein paar requireNonNull*(…)-Methoden, die null-Prüfungen übernehmen und im Fehlerfall eine NullPointerException auslösen. Diese Tests sind praktisch bei Konstruktoren oder Settern, die Werte initialisieren sollen, aber verhindern möchten, dass null durchgeleitet wird.
[zB] Beispiel
Die Methode setName(…) soll kein name-Argument gleich null erlauben:
Alternativ ist eine Fehlermeldung möglich:
public void setName( String name ) {
this.name = Objects.requireNonNull( name, "Name darf nicht null sein!" );
}
class java.util.Objects
-
static <T> T requireNonNull(T obj)
Löst eine NullPointerException aus, wenn obj gleich null ist. Sonst liefert sie obj als Rückgabe. Die Deklaration ist generisch und so zu verstehen, dass der Parametertyp gleich dem Rückgabetyp ist. -
static <T> T requireNonNull(T obj, String message)
Wie requireNonNull(obj), nur dass die Meldung der NullPointerException bestimmt wird. -
static <T> T requireNonNull(T obj, Supplier<String> messageSupplier)
Wie requireNonNull(obj, message), nur kommt die Meldung aus dem messageSupplier. Das ist praktisch für Nachrichten, deren Aufbau teurer ist, denn der Supplier schiebt die Kosten für die Erstellung des Strings so lange hinaus, bis es wirklich zu einer NullPointerException kommt, denn erst dann ist die Meldung nötig. -
static <T> T requireNonNullElse(T obj, T defaultObj)
Liefert das erste Objekt, das nicht null ist. defaultObj darf nicht null sein, sonst folgt eine NullPointerException. Implementiert als return (obj != null) ? obj : requireNonNull (defaultObj, "defaultObj");. Seit Java 9. -
static <T> T requireNonNullElseGet(T obj, Supplier<? extends T> supplier)
Liefert das erste Objekt, das nicht null ist. Ist obj gleich null, holt sich die Methode die Referenz aus dem Supplier, der dann kein null liefern darf, sonst folgt eine NullPointerException. Seit Java 9.
11.3.4 Tests auf null
Hinter isNull(Object o) und nonNull(Object o) verbirgt sich ein einfacher Test auf o == null bzw. o != null.
class java.util.Objects
-
static boolean isNull(Object obj)
-
static boolean nonNull(Object obj)
Liefert true, wenn obj gleich null bzw. nicht null ist, sonst false.
Im normalen Programmcode werden Entwickler diese Methoden nicht nutzen, doch sind sie praktisch für Methodenreferenzen, sodass es dann zum Beispiel heißen kann: stream. filter(Objects::nonNull) usw. Auf Methodenreferenzen kommen wir in Kapitel 13, »Lambda-Ausdrücke und funktionale Programmierung«, und in Kapitel 18, »Einführung in Datenstrukturen und Algorithmen«, noch einmal zu sprechen.
11.3.5 Indexbezogene Programmargumente auf Korrektheit prüfen
In Kapitel 9, »Ausnahmen müssen sein«, haben wir schon auf die Notwendigkeit hingewiesen, Wertebereiche zu prüfen und im Fehlerfall Ausnahmen wie IllegalArgumentException oder IndexOutOfBoundsException auszulösen, um keine falschen Werte in das Objekt zu lassen.
Weitere Methoden aus Objects prüfen ab Java 9 (und für long ab Java 16) die gültigen Wertebereiche von indexbasierten Methoden und lösen im Fehlerfall eine IndexOutOfBoundsException aus.
class java.util.Objects
-
static int checkIndex(int index, int length)
-
static long checkIndex(long index, long length)
-
static int checkFromToIndex(int fromIndex, int toIndex, int length)
-
static long checkFromToIndex(long fromIndex, long toIndex, long length)
-
static int checkFromIndexSize(int fromIndex, int size, int length)
-
static long checkFromIndexSize(long fromIndex, long size, long length)
[zB] Beispiel
Implementierung der get(int)-Methode in java.util.ArrayList:
public E get(int index) {
Objects.checkIndex(index, size);
return elementData(index);
}
Die private Methode elementData(int index) greift mit elementData[index] direkt auf das interne Array zurück, das allerdings größer sein könnte, da die Implementierung von ArrayList eine gewisse Puffergröße besitzt. Daher ist die vorherige Prüfung notwendig.