Respuesta.

Historia del tema:

Las clases record (record) aparecieron en Java 14 como una vista previa, desde el lanzamiento de Java 16 es una funcionalidad estable. Implementan el concepto de contenedores inmutables (immutable) para el almacenamiento de datos, similares a los value-objects. Esta es una respuesta a la verbosidad de los clásicos DTO y POJO en Java.

Problema:

Para objetos simples con datos, era necesario implementar manualmente constructores, equals(), hashCode(), toString(). Este es un trabajo rutinario, propenso a errores, que consume muchas líneas de código.

Solución:

Una clase record se declara en una línea y obtiene automáticamente un constructor, getters, equals(), hashCode(), toString(). Los campos de un record son inmutables (final), y los records son especialmente útiles para transmitir información entre las capas de la aplicación.

Ejemplo de código:

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]

Características clave:

Inmutabilidad: los campos son final, los valores se establecen solo a través del constructor.
Generación automática de métodos estándar.
No pueden heredar de otras clases (excepto Object); pueden implementar interfaces.

Preguntas capciosas.

¿Se puede cambiar el estado de un objeto record después de su creación?

No, todos los campos son final, no se puede cambiar el valor de ninguna manera.

¿Se pueden crear records con lógica no estándar en el constructor?

Sí, se puede definir un constructor compacto o regular y agregar verificaciones:

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

¿Puede un record ser abstracto o heredar campos/lógica de otras clases?

No, un record siempre es final. Puede implementar interfaces, pero no heredar clases, excepto Object.

Errores comunes y anti-patrones

Intentar hacer campos mutables — la sintaxis no lo permitirá.
Crear lógica compleja dentro de un record, violando la idea de "contenedores de datos" simples.
Usar records donde se necesita una clase normal con comportamiento.

Ejemplo de la vida real

Caso negativo

Uso de POJOs largos para cada solicitud/respuesta, con implementación manual de equals, hashCode, toString, constructores y getters.

Ventajas:

Flexibilidad total en la implementación.

Desventajas:

Mucho código.
Alto riesgo de cometer errores.

Caso positivo

Convertir todos los DTO en clases record:

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