Ullrich: Die Seite wurde neu angelegt: „category:Java Die Diskussion ob {{java|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. {{java|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 Klas…“

2023-10-21T14:19:40Z

Die Seite wurde neu angelegt: „category:Java Die Diskussion ob {{java|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. {{java|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 Klas…“

Neue Seite

[[category:Java]]
Die Diskussion ob {{java|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.

{{java|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:
{{java|code=
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 {{java|intValue}} zugreifen und ohne die Prüfung mit
{{java| instanceof}} liefe man gefahr eine {{java|ClassCastException}} zu werfen.

Java 17 erlaubt uns nun, die Prüfung und den Cast zusammenzufassen und dabei die Variable anzugeben:
{{java|code=
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:
{{java|code=
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.

Java 17: instanceof - Versionsgeschichte