Afin de préparer l’arrivée de Java 9, dont la sortie est prévue en juillet prochain, Oracle a décidé de délivrer aux développeurs quelques conseils sur la manière d’adapter les applications, à la modularisation en particulier, grande nouveauté de la future mise à jour. Le guide de migration JDK (Java Development Kit) 9 précise que chaque opération peut induire des incompatibilités dans les binaires, les sources et les comportements par rapport aux versions précédentes. « La modularisation de la plate-forme Java SE apporte de nombreux avantages, mais également de nombreux changements », a déclaré Oracle. « Le code qui utilise uniquement les API officielles de la plate-forme Java SE et les API JDK spécifiques prises en charge devraient continuer à fonctionner sans modification. Mais le code qui utilise certaines fonctionnalités ou des API avec un JDK interne pourrait ne pas s'exécuter ou donner des résultats différents », a mis en garde l’éditeur.

Pour préparer la migration, Oracle suggère aux développeurs de se procurer la toute première build, de faire tourner leur programme avant de recompiler, de mettre à jour leurs bibliothèques tierces, de compiler leur application et d'exécuter l'analyse statique jdeps sur le code. Lors de l'exécution de leurs applications, Oracle met en garde les développeurs sur les options de VM non reconnues par la JVM. Oracle leur recommande également d'examiner de près leurs tests pour vérifier que le comportement des applications ne change pas par rapport au JDK 8. Oracle indique différentes raisons pour lesquelles la compilation avec le compilateur JDK 9 peut échouer.

De nombreuses API internes du JDK encore inaccessibles

Par défaut, la plupart des API internes du JDK sont inaccessibles, de sorte que les développeurs peuvent obtenir des erreurs IllegalAccessErrors au moment de l'exécution, indiquant que l'application ou les bibliothèques dépendent des API internes. L'outil d’analyse des dépendances de Java, le Java Dependency Analysis Tool, permet d’identifier les dépendances. « Les développeurs auront sans doute plus d’alertes de dépréciation qu’auparavant pour les informer qu’une fonction est obsolète au regard des modifications apportées au JDK », a déclaré Oracle. « S’ils reçoivent des alertes avec des demandes de suppression, ils devront résoudre ces questions rapidement ».

Concernant l’opération de récupération de mémoire, le Garbage Collector G1 est désigné comme collecteur par défaut sur les configurations de serveurs 32 et 64 bits. « L'utilisation d'un collecteur à faible latence comme le G1 devrait apporter à la plupart des utilisateurs une meilleure expérience globale qu'un collecteur orienté débit, ce qui était le cas de Parallel GC, le collecteur par défaut précédent », a encore déclaré Oracle. L’éditeur recommande aux développeurs de « vérifier leurs paramètres VM pour voir si des ajustements sont nécessaires ».

Le client Windows 32 VM abandonné

Le JDK 9 supprime JavaDB, une autre appellation de la base de données Derby Apache, et l'agent hprof de la JVM Tool Interface (JVM TI). Cet agent était écrit en code de démonstration pour JVM TI et n’était pas destiné à devenir un outil de production. « Les fonctions utiles de l'agent ont été remplacées par de meilleurs outils dans le JDK », a déclaré Oracle. Jhat, un outil expérimental de visualisation d’arborescence, non supporté, a également été supprimé. Le client Windows 32 VM est abandonné, remplacé par un seul serveur VM. « Le JDK 8 et les versions antérieures proposaient une JVM client et une JVM serveur pour les systèmes Windows 32 bits, la JVM client étant fixée par défaut », a déclaré Oracle. « JDK 9 comporte uniquement la JVM serveur. Ses performances sont meilleures, même s’il faut éventuellement des ressources supplémentaires ». Oracle a également supprimé certaines fonctionnalités spécifiques à Mac OS, comme le moteur AppleScript.