Les classes Record déclarent implicitement les champs de composant comme final, interdisant toute mutation après la création. En utilisant un constructeur compact — en omettant la liste des paramètres formels — le compilateur Java interdit l'assignation explicite de champ via this.component = ... car il injecte automatiquement le bytecode d'assignation immédiatement après l'exécution du corps du constructeur. Ce design oblige les développeurs à réassigner eux-mêmes les variables de paramètre (par exemple, component = Objects.requireNonNull(component)) plutôt que d'assigner directement les champs. Par conséquent, la copie défensive devient essentielle pour les composants mutables ; puisque le record stocke des références, le fait de ne pas cloner les arguments mutables dans le constructeur compact permet des modifications externes qui compromettent la garantie d'immuabilité du record.
Lors du développement d'une plateforme de trading haute fréquence, l'équipe d'architecture a adopté des classes Record pour représenter des ticks de données de marché immuables contenant un prix BigDecimal et un horodatage java.util.Date. La mutabilité de Date représentait une vulnérabilité critique, car une condition de concurrence pouvait permettre à un thread producteur de modifier l'objet d'horodatage après l'instanciation du record, corrompant la piste d'audit.
Trois approches ont été envisagées pour atténuer cette exposition. La première stratégie consistait à migrer vers java.time.Instant, un type temporel immuable. Bien que cela ait éliminé la surcharge de copie défensive et soit aligné avec les API temporelles modernes de Java, cela nécessitait un refactoring extensif des composants middleware légacy qui sérialisaient des objets Date, introduisant un risque de livraison inacceptable.
La seconde option a utilisé une méthode de fabrique statique pour effectuer une copie défensive avant de déléguer au constructeur canonique. Cette approche a maintenu l'encapsulation mais a renoncé à la syntaxe concise et aux bénéfices de l'égalité structurelle automatique intrinsèques aux records, compliquant également les frameworks de désérialisation qui s'attendaient à des modèles de constructeurs canoniques.
La solution finale employait un constructeur compact pour valider les entrées et créer des clones défensifs : timestamp = (Date) timestamp.clone();. Cela tirait parti de l'assignation de champ implicite du compilateur pour stocker la copie plutôt que la référence originale, assurant la sécurité des threads sans sacrifier la sémantique du record.
L'implémentation a réussi à prévenir les attaques de manipulation temporelle, atteignant zéro incident de corruption de données lors de tests de résistance ultérieurs impliquant des millions de transactions concurrentes.
Pourquoi le compilateur rejette-t-il l'assignation explicite this.field dans un constructeur compact malgré sa permission dans les constructeurs réguliers ?
La Spécification du langage Java définit les constructeurs compacts comme étant élargis en constructeurs canoniques où le compilateur synthétise la liste des paramètres et ajoute des assignations de champ. Puisque les composants de record sont implicitement final, le corps du constructeur compact s'exécute dans un état pré-assignation où les champs sont considérés comme "définitivement non assignés". Toute assignation explicite this.field constituerait une seconde affectation à une variable final, violant les règles d'assignation définitive, tandis que la réassignation de la variable de paramètre est permise car elle masque simplement l'assignation implicite qui suit.
Comment la copie défensive dans le constructeur compact d'un record protège-t-elle contre les attaques de désérialisation lors de l'utilisation d'ObjectInputStream ?
Contrairement aux classes Serializable traditionnelles, que la JVM instaure par allocation Unsafe et remplit par réflexion ou méthodes readObject, les records désérialisés sont toujours reconstruits en invoquant le constructeur canonique avec des arguments fournis par le flux. Par conséquent, la logique de copie défensive exécutée dans le constructeur compact nettoie automatiquement les flux d'entrée malveillants ou corrompus tentant d'injecter des objets mutables pour des modifications ultérieures. Les développeurs négligent souvent ce mécanisme, mettant à tort en œuvre des méthodes readObject ou readResolve dans des records où elles ne sont ni nécessaires ni invoquées lors de la désérialisation standard.
Quelle distinction de bytecode existe-t-il entre un constructeur compact et un constructeur canonique explicitement déclaré dans des records ?
Un constructeur compact se compile en bytecode où invokespecial (appelant le constructeur de Object) est suivi de la logique du constructeur, puis des instructions putfield générées par le compilateur pour chaque composant. En revanche, un constructeur canonique explicite intègre des opérations putfield écrites par le développeur. Cette distinction empêche les constructeurs compacts d'effectuer des validations ou de la logique après l'initialisation des champs dans la même méthode, contraignant fondamentalement la séquence d'initialisation et nécessitant que toutes les transformations défensives se produisent sur les variables de paramètre avant que les assignations implicites ne s'exécutent.