Не за горами новая, 14-я версия ^[1] Java, а значит самое время посмотреть, какие новые синтаксические возможности будет содержать эта версия Java. Одной из таких синтаксических возможностей является паттерн-матчинг по типу ^[2], который будет осуществляться посредством улучшенного (расширенного) оператора instanceof.

Сегодня я хотел бы поиграться с этим новым оператором и рассмотреть особенности его работы более детально. Так как паттерн-матчинг по типу ещё не вошёл в главный репозиторий JDK, мне пришлось скачать репозиторий проекта Amber ^[3], в котором ведётся разработка новых синтаксических конструкций Java, и собрать JDK ^[4] из этого репозитория.

Итак, первое, что мы сделаем — проверим версию Java, чтобы убедиться, что мы действительно используем JDK 14:

> java -version
openjdk version "14-internal" 2020-03-17
OpenJDK Runtime Environment (build 14-internal+0-adhoc.osboxes.amber-amber)
OpenJDK 64-Bit Server VM (build 14-internal+0-adhoc.osboxes.amber-amber, mixed mode, sharing)

Всё верно.

Теперь напишем небольшой кусок кода со «старым» оператором instanceof и запустим его:

public class A {
    public static void main(String[] args) {
        new A().f("Hello, world!");
    }

    public void f(Object obj) {
        if (obj instanceof String) {
            String str = (String) obj;
            System.out.println(str.toLowerCase());
        }
    }
}

> java A.java
hello, world!

Работает. Это стандартная проверка на тип с последующим приведением. Подобные конструкции мы пишем изо дня в день, какую бы версию Java мы бы не использовали, хоть 1.0, хоть 13.
Но теперь у нас в руках Java 14, и давайте перепишем код с использованием улучшенного оператора instanceof (повторяющиеся строки кода в дальнейшем буду опускать):

if (obj instanceof String str) {
    System.out.println(str.toLowerCase());
}

> java --enable-preview --source 14 A.java
hello, world!

Прекрасно. Код стал чище, короче, безопаснее и читабельнее. Было три повторения слова String, стало одно. Заметьте, что мы не забыли указать аргументы --enable-preview --source 14, т.к. новый оператор является preview feature ^[5]. Кроме того, внимательный читатель, наверное, заметил, что мы запустили исходный файл A.java напрямую, без компиляции. Такая возможность появилась ^[6] в Java 11.

Давайте попробуем написать что-нибудь более навороченное и добавим второе условие, которое использует только что объявленную переменную:

if (obj instanceof String str && str.length() > 5) {
    System.out.println(str.toLowerCase());
}

Компилируется и работает. А что если поменять условия местами?

if (str.length() > 5 && obj instanceof String str) {
    System.out.println(str.toLowerCase());
}

A.java:7: error: cannot find symbol
        if (str.length() > 5 && obj instanceof String str) {
            ^

Ошибка компиляции. Чего и следовало ожидать: переменная str ещё не объявлена, а значит не может быть использована.

Кстати, что с мутабельностью? Переменная final или нет? Пробуем:

if (obj instanceof String str) {
    str = "World, hello!";
    System.out.println(str.toLowerCase());
}

A.java:8: error: pattern binding str may not be assigned
    str = "World, hello!";
    ^

Ага, переменная final. Это что-то новенькое. Первый раз в истории Java что-то по умолчанию является final. До этого всё в Java по умолчанию являлось non-final: поля, классы, методы, параметры методов и даже параметры лямбд. А переменная паттерна может быть только final. Это значит, что слово «переменная» здесь вообще не совсем корректно. Да и компилятор использует специальный термин «pattern binding». Поэтому предлагаю отныне говорить не «переменная», а «биндинг паттерна» (к сожалению, слово «binding» не очень хорошо переводится на русский).

С мутабельностью и терминологией разобрались. Поехали экспериментировать дальше. Вдруг у нас получится «сломать» компилятор?

Что если назвать переменную и биндинг паттерна одним и тем же именем?

if (obj instanceof String obj) {
    System.out.println(obj.toLowerCase());
}

A.java:7: error: variable obj is already defined in method f(Object)
if (obj instanceof String obj) {
                          ^

Логично. Перекрытие переменной из внешней области видимости не работает. Это эквивалентно тому, как если бы мы просто завели переменную obj второй раз в той же области видимости.

А если так:

if (obj instanceof String str && obj instanceof String str) {
    System.out.println(str.toLowerCase());
}

A.java:7: error: illegal attempt to redefine an existing match binding
if (obj instanceof String str && obj instanceof String str) {
                              ^

Компилятор надёжен как бетон.

Что ещё можно попробовать? Давайте поиграемся с областями видимости. Если в ветке if определён биндинг, то будет ли он определён в ветке else, если инвертировать условие?

if (!(obj instanceof String str)) {
    System.out.println("not a string");
} else {
    System.out.println(str.toLowerCase());
}

Сработало. Компилятор не только надёжен, но ещё и умён.

А если так?

if (obj instanceof String str && true) {
    System.out.println(str.toLowerCase());
}

Опять сработало. Компилятор корректно понимает, что условие сводится к простому obj instanceof String str.

Неужели не удастся «сломать» компилятор?

Может, так?

if (obj instanceof String str || false) {
    System.out.println(str.toLowerCase());
}

A.java:8: error: cannot find symbol
    System.out.println(str.toLowerCase());
                       ^

Ага! Вот это уже похоже на баг. Ведь все три условия абсолютно эквивалентны:

• obj instanceof String str
• obj instanceof String str && true
• obj instanceof String str || false

С другой стороны, правила flow scoping довольно нетривиальны ^[7], и возможно такой случай действительно не должен работать. Но если смотреть чисто с человеческой точки зрения, то я считаю, что это баг.

Но да ладно, давайте попробуем ещё что-нибудь. Будет ли работать такое:

if (!(obj instanceof String str)) {
    throw new RuntimeException();
}
System.out.println(str.toLowerCase());

Скомпилировалось. Это хорошо, поскольку этот код эквивалентен следующему:

if (!(obj instanceof String str)) {
    throw new RuntimeException();
} else {
    System.out.println(str.toLowerCase());
}

А так как оба варианта эквивалентны, то и программист ожидает, что они будут работать одинаково.

Что насчёт перекрытия полей?

public class A {
    private String str;

    public void f(Object obj) {
        if (obj instanceof String str) {
            System.out.println(str.toLowerCase());
        } else {
            System.out.println(str.toLowerCase());
        }
    }
}

Компилятор не заругался. Это вполне логично, потому что локальные переменные всегда могли перекрывать поля. Для биндингов паттернов, видимо, тоже решили не делать исключения. С другой стороны, такой код довольно хрупок. Одно неосторожное движение, и вы можете не заметить, как ваша ветка if сломалась:

private boolean isOK() {
    return false;
}

public void f(Object obj) {
    if (obj instanceof String str || isOK()) {
        System.out.println(str.toLowerCase());
    } else {
        System.out.println(str.toLowerCase());
    }
}

В обеих ветвях теперь используется поле str, чего может не ожидать невнимательный программист. Чтобы как можно раньше обнаруживать подобные ошибки, используйте инспекции в IDE и разную подсветку синтаксиса для полей и переменных. А ещё я рекомендую всегда использовать квалификатор this для полей. Это добавит ещё больше надёжности.

Что ещё интересного? Как и «старый» instanceof, новый никогда не матчит null. Это значит, что можно всегда полагаться на то, что биндинги паттернов никогда не могут быть null:

if (obj instanceof String str) {
    System.out.println(str.toLowerCase()); // Никогда не выбросит NullPointerException
}

Кстати, используя это свойство, можно укоротить подобные цепочки:

if (a != null) {
    B b = a.getB();
    if (b != null) {
        C c = b.getC();
        if (c != null) {
            System.out.println(c.getSize());
        }
    }
}

Если использовать instanceof, то код выше можно переписать так:

if (a != null && a.getB() instanceof B b && b.getC() instanceof C c) {
    System.out.println(c.getSize());
}

Напишите в комментариях, что вы думаете по поводу такого стиля. Стали ли бы вы использовать такую идиому?

Что насчёт дженериков?

import java.util.List;

public class A {
    public static void main(String[] args) {
        new A().f(List.of(1, 2, 3));
    }

    public void f(Object obj) {
        if (obj instanceof List<Integer> list) {
            System.out.println(list.size());
        }
    }
}

> java --enable-preview --source 14 A.java
Note: A.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
3

Очень интересно. Если «старый» instanceof поддерживает только instanceof List или instanceof List<?>, то новый работает с любым конкретным типом. Ждём первого человека, который попадётся вот в такую ловушку:

if (obj instanceof List<Integer> list) {
    System.out.println("Int list of size " + list.size());
} else if (obj instanceof List<String> list) {
    System.out.println("String list of size " + list.size());
}

ИМХО, это довольно серьёзная проблема. С другой стороны, я не знаю, как можно было бы её исправить. Похоже, опять придётся полагаться на инспекции в IDE.

Выводы

В целом, новый паттерн-матчинг по типу работает очень круто. Улучшенный оператор instanceof позволяет делать не только тест на тип, но ещё и объявлять готовый биндинг этого типа, избавляя от необходимости ручного приведения. Это означает, что в коде будет меньше шума, и читателю будет гораздо проще разглядеть полезную логику. Например, большинство реализаций equals() можно будет писать в одну строчку:

public class Point {
    private final int x, y;
    …

    @Override
    public int hashCode() {
        return Objects.hash(x, y);
    }

    @Override
    public boolean equals(Object obj) {
        return obj instanceof Point p && p.x == this.x && p.y == this.y;
    }
}

С другой стороны, вызывают небольшие вопросы несколько спорных моментов:

• Не полностью прозрачные правила области видимости (пример с instanceof || false).
• Перекрытие полей.
• instanceof и дженерики.

Однако это скорее мелкие придирки, нежели серьёзные претензии. В целом, огромные преимущества нового оператора instanceof определённо стоят его добавления язык. А если он ещё выйдет из состояния preview и станет стабильной синтаксической конструкцией, то это будет большой мотивацией наконец-то уйти с Java 8 на новую версию Java.

P.S. У меня есть канал в Telegram ^[9], где я пишу о новостях Java. Призываю вас на него подписаться.

Автор: Zheka Kozlov

Источник ^[10]