Réponse.

Historique de la question :

Les classes Record (record) sont apparues dans Java 14 en tant que preview, et depuis la version Java 16, elles sont une fonctionnalité stable. Elles mettent en œuvre le concept de conteneurs immuables (immutable) pour stocker des données, semblables aux value-objects. C'est une réponse à la verbosité des DTO et POJO classiques en Java.

Problème :

Pour les objets simples contenant des données, il était nécessaire d'implémenter manuellement les constructeurs, equals(), hashCode(), toString(). C'était un travail répétitif, sujet à erreurs, prenant beaucoup de lignes de code.

Solution :

Une classe record est déclarée en une seule ligne et obtient automatiquement un constructeur, des accesseurs, equals(), hashCode(), toString(). Les champs d'un record sont immuables (final), et les records sont particulièrement utiles pour transmettre des informations entre les couches de l'application.

Exemple de code :

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]

Caractéristiques clés :

Immutabilité : champs final, valeurs définies uniquement par le constructeur.
Génération automatique de méthodes standard.
Ne peut pas hériter d'autres classes (excepté Object) ; peut implémenter des interfaces.

Questions pièges.

Peut-on modifier l'état d'un objet record après sa création ?

Non — tous les champs sont final, il n'est pas possible de modifier la valeur de quelque manière que ce soit.

Peut-on créer un record avec une logique non standard dans le constructeur ?

Oui, il est possible de définir un constructeur compact ou ordinaire et d'ajouter des vérifications :

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

Un record peut-il être abstrait, ou hériter des champs/de la logique d'autres classes ?

Non — un record est toujours final. Il peut implémenter des interfaces, mais ne peut pas hériter de classes, excepté Object.

Erreurs courantes et anti-patterns

Tenter de rendre les champs mutables — la syntaxe ne le permettra pas.
Création d'une logique complexe à l'intérieur d'un record, en violation de l'idée de « conteneurs de données » simples.
Utilisation de records là où une classe ordinaire avec comportement est nécessaire.

Exemples de la vie réelle

Cas négatif

Utilisation de longs POJO pour chaque requête/réponse, avec écriture manuelle de equals, hashCode, toString, constructeurs et accesseurs.

Avantages :

Flexibilité totale de mise en œuvre.

Inconvénients :

Beaucoup de code.
Risque élevé d'erreurs.

Cas positif

Conversion de tous les DTO en classes record :

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