Java 17: instanceof

Aus MimiPedia

Die Diskussion ob instanceof gut oder schlecht, ob Downcasting un-objektorientiert ist oder nicht, soll ein anderesmal geführt werden, hier soll es nur darum gehen, was Java 17 neues für den umstrittensten aller Java-Operatoren bringt.

instanceof wird meist zusammen mit einem Downcast verwendet um zu prüfen, ob dieser überhaupt möglich ist. zur Erinnerung: Downcasting heißt, ein Objekt auf eine Subclass der Klasse zu casten unter der man es erhalten hat. Am einfachsten sieht man das an einem Beispiel:

void foo(Object obj) {
    if (obj instanceof Integer) {
        Integer zahl = (Integer)obj;
        system.out.println("Wert:" + zahl.intValue());
    }
 }

Ohne den Downcast könnte man nicht auf die Methode intValue zugreifen und ohne die Prüfung mit instanceof liefe man gefahr eine ClassCastException zu werfen.

Java 17 erlaubt uns nun, die Prüfung und den Cast zusammenzufassen und dabei die Variable anzugeben:

void foo(Object obj) {
    if (obj instanceof Integer zahl) {
        system.out.println("Wert:" + zahl.intValue());
    }
 }

Nicht viel, spart nur eine Zeile -- aber immerhin eine Zeile weniger.

Dieser etwas merkwürdige Scope (Bereich der Sichtbarkeit) der Variable ist uns seit Java 7 vom try...with resources her vertraut: er erstreckt sich aus den runden Klammern der if-Bedingung hinaus über den nachfolgenden Block.

Etwas bizarr wird's allerdings hier:

void foo(Object obj) {
    if (! obj instanceof Integer zahl) {
        throw new RuntimeException();
    }
    system.out.println("Wert:" + zahl.intValue());
 }

Der Compiler erkennt, daß das Casting im if-Block keinen Sinn ergiebt und verzichtet auf die Erzeugung der lokalen Variable. Dafür merkt er, daß das Cast nach dem if-Block möglich ist und stellt sie dort auch zur Verfügung. Ob dieses Feature wirklich sinnvolle Anwendungen hat sei mal dahingestellt, an das Konstrukt an sich muß man sich aber erstmal gewöhnen. Ohne IDE hat man da schlechte Karten den Überblick zu wahren.

In der Java-Spec ist da auch von "Type Pattern Matching" die Rede. Ein Hinweis darauf, daß es sich hier nur um die Spitze eines neuen Konzept-Eisbergs handelt. in Java 21 sieht man denn auch, wie das pattern matching das switch-Konstrukt so richtig aufzumischen vermag.

Bis dahin nehmen wir aber auf jeden Fall die Ein-Zeilen-Ersparnis gerne mit.