Nouveauté Java 25 (7/18) - JEP 507 : Quand les primitifs rattrapent leur retard Depuis Java 1.0, une bizarrerie persiste : les types primitifs sont traités comme des citoyens de seconde zone. Cette troisième preview de la JEP 507 corrige enfin cette asymétrie historique. Partons d'un exemple concret. Vous développez une API de traitement JSON et définissez une structure avec double parce que JSON ne distingue pas entiers et décimaux. Mais quand vous voulez extraire un âge, forcément entier, le pattern matching vous abandonne. Cette incohérence révèle un problème plus profond : instanceof protège les conversions d'objets mais abandonne les primitifs à leur sort. Résultat ? Des décennies de casts dangereux et de vérifications manuelles laborieuses. La JEP 507 introduit la notion de "conversion exacte". Une conversion est exacte si aucune information n'est perdue. Pour certaines paires de types, c'est garanti comme byte vers int. Pour d'autres, il faut vérifier à l'exécution comme int vers byte. Concrètement, instanceof devient le gardien universel. Un entier de 1000 ne peut pas tenir dans un byte, mais peut se convertir en float sans perte. Le test échoue ou réussit selon la sécurité de la conversion. Le pattern matching gagne en puissance. Au lieu de subir les types exacts, vous exprimez votre intention. Un âge JSON peut être traité différemment selon qu'il tient dans un byte, un int, ou nécessite un double pour les valeurs aberrantes. L'extension du switch parachève cette uniformisation. Boolean rejoint enfin ses cousins primitifs, éliminant cette exception arbitraire vieille de 30 ans. Les long constants deviennent utilisables directement dans les case. Cette évolution dépasse la simple commodité syntaxique. Elle réconcilie sécurité et expressivité, deux qualités trop souvent antagonistes dans la gestion des primitifs Java. #Java25 #JEP507 #Java #PatternMatching #PrimitiveTypes #Switch #Instanceof #Oracle #OpenJDK #DéveloppeurJava #ProjectAmber #Langage