💿 Java Records: Конец эпохи Lombok?

Долгие годы Project Lombok был нашим единственным спасением от бесконечных геттеров, сеттеров, equals() и hashCode(). Но начиная с Java 14 (и официально в Java 16), в языке появилась нативная альтернатива - Records.

Многие поспешили удалить Lombok и переписать всё на рекорды. И... столкнулись с проблемами. Давайте разберем, почему record - это не просто "короткий класс".

🏎 Скорость написания

Lombok (@Value для неизменяемости):

@Value
public class User {
    String name;
    int age;
}

Record:

public record User(String name, int age) {}

Тут победа за рекордами. Синтаксис максимально лаконичен. Мы объявляем состояние, а не поля.

🔍 Что под капотом? (Главные отличия)

Вот здесь начинаются нюансы, из-за которых Records нельзя назвать полной заменой Lombok.

1. Жесткая неизменяемость (Immutability)
Record - это всегда final класс с final полями. Вы не можете сделать "сеттер" в рекорде. Если вам нужен изменяемый DTO (например, для заполнения формы по шагам) - Record не подойдет. Lombok @Data всё еще нужен.

2. Запрет на наследование
Рекорды не могут наследоваться от других классов (они уже неявно наследуются от java.lang.Record).

• Если у вас есть BaseEntity с полем ID - вы не сможете унаследовать рекорд от него.

3. Имена геттеров
Это ломает многие старые библиотеки.

• Lombok/JavaBean: getName(), getAge()
• Record: name(), age()
• Совет: Jackson и современные JSON-библиотеки уже умеют с этим работать, но легаси-фреймворки могут "не увидеть" ваши поля.

✨ Killer Feature: Компактные конструкторы

То, чего нет в Lombok. Валидация данных в рекордах выглядит потрясающе чисто. Вам не нужно дублировать аргументы:

public record User(String name, int age) {
    // Обратите внимание: нет скобок с аргументами!
    public User {
        if (age < 0) {
            throw new IllegalArgumentException("Age cannot be negative");
        }
        name = name.toUpperCase(); // Можно даже менять данные перед записью
    }
}

🏆 Вердикт: Кто победил?

Никто. Это инструменты для разных целей.

✅ Используйте record: Для DTO, ключей в Map, ответов API, записей в Event Log и промежуточных данных в Stream API. Это "именованные кортежи" данных.

✅ Используйте Lombok / POJO: Для JPA сущностей (Hibernate не очень любит рекорды из-за прокси и отсутствия сеттеров), для классов с наследованием и там, где нужна мутабельность.

#Java #Lombok #CleanCode #Java17

👉 @java_geek

🏗 Java: Структурная конкурентность. Прощайте, зомби-потоки!

Допустим, вы используете Виртуальные потоки (Project Loom), чтобы сделать два независимых запроса: получить данные пользователя (API 1) и его заказы (API 2).

Раньше мы использовали ExecutorService или CompletableFuture. Но у них есть огромная архитектурная дыра: они ничего не знают друг о друге.

🧟‍♂️ Проблема зомби-потоков (Unstructured Concurrency)

Если API 1 мгновенно падает с ошибкой 500, ваш метод все равно будет ждать, пока API 2 доработает (или упадет по таймауту). Поток, качающий заказы, становится "сиротой". Он делает бесполезную работу, тратит сеть и память, хотя результат уже никому не нужен.

А если ошибку выкинет родительский метод? Дочерние потоки продолжат жить своей жизнью в фоне. Это хаос.

🧩 Решение: StructuredTaskScope

В современной Java (начиная с 21 версии) потоки привязали к лексической области видимости - блоку кода. Если мы выходим из блока (из-за ошибки или успешного завершения), все запущенные внутри него дочерние потоки автоматически отменяются (получают interrupt).

Вот как выглядит "Запрос-Ответ", где должны выполниться оба действия (Стратегия *All or Nothing*):

// ShutdownOnFailure: если один упал, отменяем остальные
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    
    // Запускаем подзадачи (Subtasks)
    Subtask<User> user = scope.fork(() -> fetchUser(id));
    Subtask<List<Order>> orders = scope.fork(() -> fetchOrders(id));

    scope.join();          // Ждем завершения обеих задач...
    scope.throwIfFailed(); // ...или первой же ошибки!

    // Сюда дойдем, только если обе задачи успешны
    return new UserProfile(user.get(), orders.get());
} 
// При выходе из блока любые зависшие потоки будут убиты

🏎 Стратегия "Кто первый, тот и прав"

А что, если вам нужно получить курс валют, и у вас есть 3 разных провайдера? Вам нужен ответ от любого, кто ответит быстрее.

// ShutdownOnSuccess: первый успешный отменяет остальные
try (var scope = new StructuredTaskScope.ShutdownOnSuccess<Quote>()) {
    
    scope.fork(() -> getFromBankA());
    scope.fork(() -> getFromBankB());
    scope.fork(() -> getFromBankC());

    scope.join(); // Ждем первого успешного

    return scope.result(); // Возвращаем самый быстрый ответ
}

Как только Банк А ответит, запросы к Банкам B и C будут немедленно отменены. Никакого ручного управления Future.cancel(). Всё работает из коробки.

🧠 Почему это меняет всё?

1. Читаемость: Многопоточный код читается сверху вниз, как обычный синхронный.
2. Безопасность ресурсов: Утечки потоков физически невозможны. Структура гарантирует, что родитель не завершится, пока не разберется со всеми детьми.
3. Идеальные логи: Стек-трейс теперь показывает реальную иерархию (кто кого вызвал), а не обрывается на внутренностях пула потоков.

В связке с Виртуальными потоками это делает Java одним из самых удобных языков для написания высоконагруженных сетевых приложений.

#Concurrency #ProjectLoom #CleanCode #Backend

👉 @java_geek