Ответ.

История вопроса:

Record-классы (record) появились в Java 14 как preview, с релиза Java 16 это стабильная функциональность. Они реализуют концепцию неизменяемых (immutable) контейнеров для хранения данных, похожих на value-objects. Это реакция на многословность классических DTO и POJO в Java.

Проблема:

Для простых объектов с данными приходилось вручную реализовывать конструкторы, equals(), hashCode(), toString(). Это рутинная, подверженная ошибкам работа, занимающая множество строк кода.

Решение:

Record-класс объявляется одной строкой и автоматически получает конструктор, геттеры, equals(), hashCode(), toString(). Поля record неизменяемы (final), рекорды особенно полезны для передачи информации между слоями приложения.

Пример кода:

public record Point(int x, int y) {}

Point p = new Point(3, 5);
System.out.println(p.x()); // 3
System.out.println(p); // Point[x=3, y=5]

Ключевые особенности:

Неизменяемость: поля final, значения задаются только через конструктор.
Автоматическая генерация стандартных методов.
Не могут наследоваться от других классов (кроме Object); могут реализовывать интерфейсы.

Вопросы с подвохом.

Можно ли изменить состояние объекта record после его создания?

Нет — все поля final, нельзя изменить значение ни одним способом.

Можно ли создавать record с нестандартной логикой в конструкторе?

Да, можно определить компактный или обычный конструктор и добавить проверки:

public record Point(int x, int y) {
    public Point {
        if (x < 0 || y < 0) throw new IllegalArgumentException();
    }
}

Может ли record быть абстрактным, или наследовать поля/логику других классов?

Нет — record всегда final. Может реализовывать интерфейсы, но не наследовать классы, кроме Object.

Типовые ошибки и анти-паттерны

Попытка сделать поля изменяемыми — синтаксис не позволит.
Создание сложной логики внутри record, нарушая идею простых «контейнеров данных».
Использование рекордов там, где нужен обычный класс с поведением.

Пример из жизни

Негативный кейс

Использование длинных POJO для каждого запроса/ответа, с ручным написанием equals, hashCode, toString, конструкторов и геттеров.

Плюсы:

Полная гибкость реализации.

Минусы:

Много кода.
Высокий риск допустить ошибку.

Позитивный кейс

Перевод всех DTO в record-классы:

public record UserDTO(String login, String email) {}