Créée au début février et mise à jour le 31 mars par OpenJDK, la JEP (Java Enhancement Proposal) vise à rendre la signification « final » définitive dans Java. L’idée est d’émettre des alertes sur l'utilisation de la réflexion profonde pour muter les champs finaux. Ces avertissements prépareraient les développeurs Java à une future version qui garantirait l'intégrité par défaut en limitant la mutation des champs finaux, ce qui rendrait Java plus sûr et potentiellement plus rapide. L'un des principaux objectifs de la proposition est de préparer l'écosystème Java à une future version qui interdira par défaut la mutation des champs finaux par deep reflection.

À partir de cette version, les développeurs devront explicitement activer la possibilité de changer les champs finaux au démarrage. La JEP comprend aussi d’autres objectifs, comme l'alignement des champs finaux des classes normales sur les composants des classes record, qui ne peuvent pas être modifiés par deep reflection et la possibilité pour les bibliothèques de sérialisation de continuer à travailler avec les classes serializable, même celles qui comportent des champs finaux. Il n'est pas prévu de déprécier ou de supprimer une partie de l'API de la plateforme Java, ni d'empêcher la mutation des champs finaux par les bibliothèques de sérialisation lors de la désérialisation.

La réaffectation des champs finaux au cœur du débat

Actuellement, la JEP ne mentionne aucune version de Java ayant la capacité « final-means-final ». La proposition explique que les développeurs Java s'appuient sur les champs finaux pour représenter un état immuable. L'attente qu'un champ final ne puisse pas être réaffecté, que ce soit délibérément ou accidentellement, est souvent cruciale lorsque les développeurs raisonnent sur l'exactitude des données. Mais il est faux de penser qu'un champ final ne peut pas être réaffecté. La plateforme Java fournit des API qui facilitent la réaffectation des champs finaux à tout moment par n'importe quel code du programme, ce qui sape le raisonnement sur la correction et invalide d'importantes optimisations. Ainsi, un champ final est aussi transformable qu'un champ non final.

Même si relativement peu de code modifie les champs finaux, l'existence d'API ayant cette capacité implique que les développeurs ou la JVM ne peuvent absolument pas faire confiance à la valeur d'un champ final, quel qu'il soit. Selon la proposition, cela compromet la sécurité et les performances de tous les programmes. Les projets prévoient d'imposer l'immuabilité des champs finaux afin que le code ne puisse pas utiliser deep reflection pour les réaffecter à volonté. Le cas particulier des bibliothèques de sérialisation, qui ont besoin de muter les champs finaux pendant la désérialisation, sera pris en charge par le biais d'une API à usage limité.