Похоже, что в Java 22 безымянные переменные и паттерны выйдут из preview. Это будет первый случай, когда языковая конструкция пробыла в preview всего один релиз.
Ранее все языковые конструкции в preview были как минимум два релиза:
• switch expressions: два релиза (Java 12 и 13)
• text blocks: два релиза (Java 13 и 14)
• records: два релиза (Java 14 и 15)
• pattern matching for instanceof: два релиза (Java 14 и 15)
• sealed: два релиза (Java 15 и 16)
• pattern matching for switch: 4 релиза (Java 17, 18, 19 и 20)
• records patterns: два релиза (Java 19 и 20)
Ну и теперь unnamed variables and patterns: только 1 релиз (Java 21)

#java22

Шкала депрессии бэка 😂

Вышел Lombok 1.18.30, поддержавший Java 21
#lombok

Вышла сразу пачка новых JEP'ов.

JEP 456: Unnamed Variables and Patterns
Безымянные переменные и паттерны станут стабильными в Java 22 после всего одного раунда превью.

JEP: String Templates (Final)
Шаблонные строки, похоже, тоже станут стабильными в Java 22.

JEP: Implicitly Declared Classes and Instance Main Method (2nd Preview)
Безымянные классы хотят переименовать в implicitly declared классы.

JEP 455: Primitive types in Patterns, instanceof, and switch (Preview)
Можно будет писать if (obj instanceof int). Вангую, что тоже попадёт в Java 22.

JEP 457: Class-File API (Preview)
API для чтения, записи и трансформации Java class-файлов. Кстати, оно уже есть в Java 21, но в internal пакете jdk.internal.classfile. В Java 22 станет preview.

#java22

Дно пробито

Предложение в итоге вылилось в JEP 461: Stream Gatherers (Preview)

Вышел Spring 6.1 GA 🥳

Вместе с ним выходит Spring Boot 3.2, но это произойдёт 23 ноября, так что надо чуть-чуть подождать.

В релизе Spring 6.1 тонна всего нового, но главная фишка – это, конечно же, поддержка виртуальных потоков. Включаются они флагом spring.threads.virtual.enabled=true (требуется JDK 21+). С виртуальными потоками можно спокойно вызывать блокирующее API и ни о чём не беспокоиться.

Ещё из интересного:

Новый интерфейс RestClient. Он синхронный, как и старый RestTemplate, но имеет современное удобное fluent API, похожее на WebClient, появившийся в Spring 5. Он не использует WebFlux, а значит не требует зависимости spring-webflux. Т.к. теперь есть виртуальные потоки, то синхронность уже не является проблемой и не вредит масштабируемости. RestClient, как и WebClient, разумеется, поддерживает декларативные HTTP-клиенты, созданные из интерфейсов с аннотациями @HttpExchange.

Новый интерфейс JdbcClient. Это современная альтернатива JdbcTemplate с fluent API:
Optional<Integer> value = client.sql("SELECT AGE FROM CUSTOMER WHERE ID = :id")
.param("id", 3)
.query(Integer.class)
.optional();

Ещё появилась поддержка CRaC, поддержка @HttpExchange аннотаций в MVC-контроллерах и многое другое. Подробный список можно посмотреть тут.

#spring

Что там по Java 22? Список JEP'ов на текущий момент такой (и я думаю, окончательный):

JEP 456: Unnamed Variables & Patterns
JEP 459: String Templates (Second Preview)
JEP 447: Statements before super(...) (Preview)
JEP 455: Primitive types in Patterns, instanceof, and switch (Preview)
JEP 463: Implicitly Declared Classes and Instance Main Methods (Second Preview)
JEP 458: Launch Multi-File Source-Code Programs
JEP 457: Class-File API (Preview)
JEP 461: Stream Gatherers (Preview)
JEP 454: Foreign Function & Memory API
JEP 460: Vector API (Seventh Incubator)
JEP 462: Structured Concurrency (Second Preview)
JEP 423: Region Pinning for G1
JEP 464: Scoped Values (Second Preview)

Список довольно внушительный, но если отбросить превью/инкубаторы, то остаётся только Unnamed Variables & Patterns, Foreign Function & Memory API, Launch Multi-File Source-Code Programs и Region Pinning for G1. В принципе, безымянные переменные/паттерны – неплохая фича, я бы попробовал.

А что вы думаете? Будете переходить на Java 22 с 21, когда выйдет? 😆 Ну а если серьёзно, то всё это станет стабильным в следующем LTS (Java 25), и это будет действительно мощный релиз (может, там даже и Valhalla будет).
#java22

Вышел Spring Boot 3.2.0.
Подробные Release Notes можно посмотреть здесь.

#spring

Время старта Spring-приложения на Java 17 и Java 21. То есть не трогая код и просто обновив версию Java, можно получить заметное сокращение времени старта.
Не сидите на старых версиях Java, обновляйтесь.

JetBrains запустил JetBrains AI. Это AI ассистент в IDE, который умеет многое, например, может объяснить код, предложить рефакторинг, предложить мультистроковое автодополнение, сконвертировать код в другой язык, сгенерировать коммит-сообщение, документацию, юнит-тесты и т.д. и т.п. Всё это он может, потому что глубоко анализирует окружающий контекст (текущий файл, проект, зависимости, язык...)
Также есть AI чат с ассистентом.
Ассистент работает через JetBrains AI Service, который в свою очередь использует OpenAI.
Подписка, разумеется, платная: 100$ в год или 10$ в месяц, если помесячно. Есть free trial. При этом сама IDE должна быть с лицензией (IDEA Community не подойдёт).

Чтобы включить ассистента, нужно обновиться до IDEA 2023.3.
#idea

Брайн Гетц предложил идею расширить возможности оператора switch ещё больше, добавив в него возможность обрабатывать исключения в ветках case. Напомню, что с Java 21 switch поддерживает паттерны, записи и case null. По его мнению этого недостаточно, т.к. с помощью них можно обработать только успешные результаты, но для ошибок приходится прибегать к классическому оператору try-catch. Было бы классно, если бы исключения можно было обрабатывать в той же манере, что и успешные результаты, т.е. прямо в ветках switch.

Примеры:

String allLines = switch (Files.readAllLines(path)) {
    case List<String> lines -> lines.stream().collect(Collectors.joining("\n"));
    case throws IOException _ -> "";
}

var opt = switch (Integer.parseInt(s)) {
    case int i -> Optional.of(i);
    case throws NumberFormatException _ -> Optional.empty();
};

#switch

Давайте поговорим про валидацию входных аргументов. На первый взгляд тема кажется совсем банальной, но есть в ней несколько нюансов, которым, на мой взгляд, уделяют недостаточно внимания.

Есть, к примеру, следующая запись:

public record Employee(String firstName, String lastName) {}

Чего здесь не хватает? Правильно, проверок на null для firstName и lastName. Ну так давайте добавим:

public record Employee(String firstName, String lastName) {
    public Employee {
        if (firstName == null) {
            throw new NullPointerException("firstName must not be null");
        }
        if (lastName == null) {
            throw new NullPointerException("lastName must not be null");
        }
    }
}

Как-то слишком длинно. Если у нас в проекте сотни подобных проверок (все ж пишут проверки, так ведь?🙂), то код сильно раздувается. Хочется покомпактнее. Вспоминаем, что в Java 8 появился метод Objects.requireNonNull(). Заменяем:

public Employee {
    Objects.requireNonNull(firstName, "firstName must not be null");
    Objects.requireNonNull(lastName, "lastName must not be null");
}

Гораздо лучше. Но теперь вспоминаем, что firstName и lastName также не могут быть пустыми. Objects.requireNonNull() тут уже не поможет. Придётся опять писать трёхстрочные if’ы? Не хочется. Можно создать какой-нибудь утилитный метод типа checkCondition(). Но наверняка в какой-нибудь библиотеке такое уже есть? Я в течение своей многолетней практики сталкивался с разными вариантами и в конце концов понял, что всё-таки лучшим образом эту проблему решили в Guava. В классе Preconditions:

public Employee {
    ...
    Preconditions.checkArgument(!firstName.isEmpty(), "firstName must not be empty");
    Preconditions.checkArgument(!lastName.isEmpty(), "lastName must not be empty");
}

Есть там и другие проверки: checkNotNull(), checkElementIndex(), checkPositionIndex(), checkState(). При этом checkArgument() из них самый универсальный, и с его помощью можно проверить любое boolean выражение:

Preconditions.checkArgument(firstName != null && !firstName.isEmpty(), "firstName must not be null or empty");
Preconditions.checkArgument(lastName != null && !lastName.isEmpty(), "lastName must not be null or empty");

В итоге мы смогли уложиться в две строчки, что очень хорошо: проверки не должны занимать много места.

В Гуаве при этом решено ещё несколько проблем.

Представим, что нам ещё надо добавить проверку на максимальную длину строки. Мы пишем в обычном if-стиле и случайно допускаем ошибку в шаблоне:

if (firstName.length() > MAX_LENGTH) {
    throw new IllegalArgumentException(String.format("firstName is too long, max length is %s, got %s", MAX_LENGTH));
}

Если в рантайме firstName оказался слишком длинным, то выбросится исключение, но совсем не IllegalArgumentException с красивым сообщением, а что-то совсем другое (MissingFormatArgumentException). Обидно. Гуава в этом плане более снисходительна. Вариант с Preconditions будет в любом случае бросать llegalArgumentException:

Preconditions.checkArgument(firstName.length() <= MAX_LENGTH, "firstName is too long, max length is %s, got %s", MAX_LENGTH);

Конечно, тут сообщение будет неполное. Но это лучше, чем совершенное левое исключение, не связанное с исходной ошибкой.

Другая фишка – это стремление Гуавы не генерировать мусора. Все помнят, что в Java есть боксинг, а это значит, что простая сигнатура checkArgument() с Object… создавала бы обёртки над примитивными значениями каждый раз. Мелочь, но всё равно не очень приятно. Но в Гуаве у checkArgument() есть множество перегрузок для большинства простых случаев.

Например, в этом случае мусора не будет вообще, так как есть перегрузка checkArgument(boolean, String, int, int):

Preconditions.checkArgument(firstName.length() <= MAX_LENGTH, "firstName is too long, max length is %s, got %s", MAX_LENGTH, firstName.length());

Таким образом, Preconditions в Гуаве – это:
1. Компактно
2. Безопасно
3. Эффективно

В общем, рекомендую. Валидировать аргументы надо, и надо делать это с хорошими сообщениями.

#guava