Oracle prépare les développeurs à la migration vers Java 9
La documentation Early Access pour le JDK 9 est disponible en ligne

Le , par Michael Guilloux

61PARTAGES

8  0 
La sortie de Java 9 est prévue pour le mois de juillet 2017 et depuis le mois dernier, les fonctionnalités ont été gelées pour entamer la phase de Rampdown. Au cours de cette étape, les équipes qui travaillent sur le développement du JDK 9 vont se concentrer sur la correction des bogues, en particulier les bogues de priorité P1-P3 qui sont nouveaux dans cette version, et d’autres bogues de priorité P1-P3 si le temps le permet.

Ce nouveau virage annonce donc de manière imminente la sortie de la prochaine version du JDK repoussée plusieurs fois. De son côté, Oracle veut préparer les développeurs à la migration vers Java 9. Pour cela, la firme de Redwood City a récemment publié la documentation Early Access pour le JDK 9. En plus de fournir un guide de migration de Java 8 vers Java 9, cette documentation présente les nouveautés dans la nouvelle version de la plateforme Java.

« Chaque nouvelle version de Java SE introduit des incompatibilités dans les binaires, les sources et les comportements avec les versions précédentes », explique Oracle. Le but de ce guide de migration est donc d’aider les développeurs à identifier les problèmes potentiels et de leur faire des suggestions sur la façon de procéder pour migrer une application Java existante vers JDK 9.

Les changements les plus importants dans le JDK 9 viennent du projet Jigsaw pour la modularisation de la plateforme Java SE. Cette fonctionnalité « apporte de nombreux avantages, mais aussi de nombreux changements », indique Oracle. « Tout code qui utilise uniquement les API officielles de la plateforme Java SE et les API JDK spécifiques prises en charge doit continuer à fonctionner sans modification. » Par contre, « un code qui utilise certaines fonctionnalités ou des API internes au JDK peut ne pas s'exécuter ou peut donner des résultats différents. » Pour préparer la migration, Oracle suggère de télécharger la dernière build Early Access du JDK 9. Il faut noter que ces builds sont destinées à être utilisées dans des environnements de test, pas en production.

Avec la build Early Access, Oracle recommande d’exécuter l’application que vous souhaitez migrer avant de recompiler, et de voir ce qui se passe. Si votre programme utilise uniquement des API Java SE standard, il devrait pouvoir s'exécuter sans aucune modification. Si l’application est lancée avec succès, il est conseillé d’examiner attentivement vos tests et vous assurer que le comportement est le même qu’avec le JDK 8. Certains utilisateurs ont en effet remarqué que leurs dates et devises sont formatées différemment.

Les étapes suivantes dans le guide de migration vers Java 9 consistent à mettre à jour les bibliothèques tierces, compiler l'application et exécuter l'analyse statique jdeps sur le code.

En ce qui concerne les outils et bibliothèques tiers, il est indiqué dans la documentation qu’il devrait exister des versions mises à jour qui prennent en charge le JDK 9. Il faudra donc consulter les sites web des fournisseurs d’outils et bibliothèques tiers pour obtenir une version de chaque bibliothèque ou outil conçue pour fonctionner sur Java 9. Si des mises à jour existent, il est conseillé de les télécharger et les installer. « Si vous utilisez un IDE pour développer vos applications, il peut vous aider à migrer le code existant », ajoute Oracle. « Les EDI NetBeans, Eclipse et IntelliJ ont tous des versions early access disponibles qui incluent le support de JDK 9. »

Pour un certain nombre de raisons spécifiques, des erreurs peuvent se produire lors de la compilation à l'aide du compilateur JDK 9. Oracle explique par exemple que la plupart des API internes au JDK sont inaccessibles par défaut, de sorte que les développeurs soient susceptibles d’obtenir des erreurs au moment de l'exécution indiquant que l'application ou ses bibliothèques dépendent d'API internes.

Pour identifier les dépendances, vous pouvez utiliser l’outil d'analyse de dépendance de Java. Oracle suggère enfin d’exécuter l'outil jdeps sur votre application. Jdeps est un outil d'analyse statique qui vous aide à savoir de quels paquets et classes dépendent vos applications et vos bibliothèques.

Outre le guide de migration, la documentation Early Access pour le JDK 9 présente les nouveautés dans la nouvelle version de la plateforme Java.

Téléchargez les builds JDK 9 Early Access

Sources : Oracle, Guide de migration vers le JDK 9, Nouveautés dans JDK 9

Et vous ?

Qu'en pensez-vous ?
Avez-vous déjà testé la build JDK 9 ? Si oui, partagez votre expérience.

Voir aussi :

JDK 10 : le projet pour l'implémentation de la plateforme Java 10 est ouvert, qu'attendez-vous de cette nouvelle version ?
Les futures fonctionnalités de JavaFX pour la version 10 de la plateforme Java déjà en discussion sur la liste de diffusion de l'OpenJFX
Gartner proclame l'obsolescence de Java EE sur le marché des plateformes d'applications, partagez-vous cet avis ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Mickael_Istria
Membre émérite https://www.developpez.com
Le 02/05/2017 à 12:18
Citation Envoyé par Vyrob Voir le message
Y a un truc qui m'échappe : pourquoi se manifestent-ils seulement maintenant, à 3 mois de la release ? Le projet Jigsaw ne date pourtant pas d'hier.
Il faut lire les posts detailles et les discussions en lien.
Les inquietudes vis-a-vis de Jigsaw et de son interet technique et pour la communaute ont ete manifestees par tous des le debut. La compatibilite avec OSGi ou Maven a ete identifiee comme critique tres tot. Maitenant que Jigsaw a atteint un "pallier", il a ete teste dans ces environnements (OSGi et Maven) et il apparait qu'en l'etat actuel, ca complique tout sans ajouter grand chose. En l'etat actuel, il ne delivre pas les promesses qui ont ete identifiees initialement comme des "requirements".
Si l'annonce n'est publiee que maintenant, c'est qu'avant, il y avait encore de l'espoir que ca tourne mieux; mais maintenant, Jigsaw est face a un constat d'echec programme, et il est donc temps d'etre plus explicite si on veut que les choses aillent dans le bon sens.

Le principal avantage sera la taille en mémoire de la JVM qui va considérablement baisser.
Si par memoire tu entends "espace disque du deliverable", OK. Pour la RAM ou le Heap ca ne devrait pas changer grand chose car les classloaders ne chargent deja que ce qui est utile.
5  0 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 10/05/2017 à 7:27
La prédiction n'a jamais été une science exacte, d'une part, et d'autre part la manie d'établir des dates de rendu même quand on n'en sait fichtrement rien n'aide pas à ce qu'elles soient respectées. Dans ces conditions, on a beau faire ce qu'on peut, il ne faut pas s'étonner que ça arrive.
2  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 07/09/2017 à 17:24
Citation Envoyé par Matthieu Vergne Voir le message
Et c'est où qu'il prend en compte ce qui est faisable en interne ? Parce que bon, copier les autres a ses avantages, mais si c'est pour avoir en pratique le même rythme et se contenter de sortir des versions qui sont juste de moins en moins boguées, les utilisateurs resteront au rythme habituel pour éviter de perdre leur temps, en se contentant d'ignorer les versions intermédiaires.
L'intérêt c'est que les versions intermédiaires pourront proposer de nouvelles fonctionnalités plus "simple", sans avoir à dépendre du temps de développement trop important d'une autre fonctionnalités.

Par exemple si cela aurait été le cas on aurait déjà pu avoir le REPL, HttpClient avec support d'HTTP2, l'évolution de la classe Process, etc.

Citation Envoyé par Matthieu Vergne Voir le message
Ce qui veut dire qu'à terme il n'en restera qu'un seul. L'objectif, si on lit entre les lignes, et de supprimer l'un des deux. La question est alors de savoir lequel. Je vous le laisse en mille. Reste à voir ensuite l'évolution que ça engendrera, style pas en arrière sur les licences avec celui qui reste. En surface, ça semble génial, mais où sont les garanties ?
Moi je vois plutôt çà dans le sens où çà leur permettra de proposer plus facilement leur JDK commerciale.

S'ils tuent l'OpenJDK ils se prendront un gros bad-buzz, se retrouveront éjecté des distributions, et risqueraient de voir un fork...

Citation Envoyé par ParseCoder Voir le message
Dommage qu'Oracle n'ai pas choisit une license aussi libérale que la license du .NET Compiler Platform (Roslyn).
C'est à dire ?
On est sur du GPLv2 là je ne vois pas où est le problème...

a++
2  0 
Avatar de kilroyFR
Membre éclairé https://www.developpez.com
Le 07/09/2017 à 20:38
Oracle ne faisant rien sans arriere pensée (il faut bien payer l'ile de l'insatiable ellison), du business, rien que du business dans cette strategie.
2  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 11/09/2017 à 15:11
Citation Envoyé par Matthieu Vergne Voir le message
La position que je prend est plus celle du questionnement : qu'est-ce qui empêcherait Oracle de prendre de telles mesures aux dépends de la communauté ? À l'heure actuelle, je ne vois pas de garantie qui permette de se dire "ça c'est une bonne chose". J'ai l'impression qu'à l'heure actuelle, c'est plus une question de pari/confiance.
On peut toujours ce méfier, mais cette question n'a rien de particulier à la situation. On peut tout a fait la poser pour n'importe quel langage/société. Il n'y a pas plus de raison d'être sceptique qu'envers Microsoft, Google, Apple, Redhat, ...
2  0 
Avatar de Vyrob
Membre régulier https://www.developpez.com
Le 02/05/2017 à 11:29
Y a un truc qui m'échappe : pourquoi se manifestent-ils seulement maintenant, à 3 mois de la release ? Le projet Jigsaw ne date pourtant pas d'hier.
1  0 
Avatar de bouye
Rédacteur/Modérateur https://www.developpez.com
Le 09/05/2017 à 23:10
Erf, a deux mois de la sortie planifiée et déjà repoussée de nombreuses fois, c'est limite ridicule...
1  0 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 10/05/2017 à 14:29
Je viens d'ailleurs de terminer de lire un chapitre à ce sujet :
Dunning, David. «*Prediction: The Inside View*». In Social psychology: handbook of basic principles, édité par Arie W. Kruglanski et E. Tory Higgins, 2nd ed., 69‑90. New York: Guilford Press, 2007.

En résumé : l'homme est une machine à prédire de la merde, mais ça se soigne.
1  0 
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 04/06/2017 à 14:25
Bonjour,

Java9 semble s'approcher. J'utilise Karaf de longue date et après avoir relu le sujet, je pense que la notion de module de java9 et de module de OSGI sont suffisamment différentes pour ne pas être contradictoires.

J'ai vu que beaucoup de questions se posaient autour des deux notions de module.
De que j'ai conclus des mes essais avec le jdk9 et de mon expérience Karaf c'est que nous ne sommes pas du tout dans le même scope, bien qu'il y ait des usages qui se recouvre.

Je veux faire une application découpée en modules pour faciliter l'évolution la maintenance, etc. Mais que je lance comme un tout. Dans ce cas tant la notion de module de java9 que celle de OSGI peuvent faire l'affaire.

Je veux une application qui fonctionne comme un conteneur dans lequel je veux déployer des modules à la volée en arrêter les relancer les supprimer, etc. je veux qu'ils puissent interagir, se reconnaitre, etc. là le jdk9 ne le permet pas.

Pour moi l'apport de la modularité dans java9 permet essentiellement d'obtenir un runtime adapté au besoin de l'application. de définir des sous-ensembles réutilisables d'appli en appli. Alors que OSGI est plus un conteneur, et/ou un système de plug-in à chaud.

Je vais donc continuer à utiliser Karaf, aider à le faire fonctionner sur java 9. quant à l'usage que je fais du tout forcément se posera la question module java9 ou bundle OSGI. ce qui semble se dessiner c'est que les librairies de base vont probablement devenir des modules java9 alors que les composants de l'application resteront des bundles.

A+JYT
1  0 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 07/09/2017 à 14:47
Citation Envoyé par Michael Guilloux Voir le message
« En m’appuyant sur les modèles de publication utilisés par d'autres plateformes et par diverses distributions de système d'exploitation, je propose qu'après Java 9, nous adoptions un modèle strict et basé sur le temps avec une nouvelle version de fonctionnalités tous les six mois, des mises à jour chaque trimestre et une LTS tous les trois ans », peut-on lire dans son billet.
Et c'est où qu'il prend en compte ce qui est faisable en interne ? Parce que bon, copier les autres a ses avantages, mais si c'est pour avoir en pratique le même rythme et se contenter de sortir des versions qui sont juste de moins en moins boguées, les utilisateurs resteront au rythme habituel pour éviter de perdre leur temps, en se contentant d'ignorer les versions intermédiaires.

Citation Envoyé par Michael Guilloux Voir le message
L'objectif est de rendre l'OpenJDK et le JDK d'Oracle interchangeables. « Bien que nous sachions qu'il y aura d'abord des différences, notre intention est que, après quelques versions, il n'y ait plus de différences techniques entre les builds OpenJDK et les binaires Oracle JDK », a déclaré Smith.
Ce qui veut dire qu'à terme il n'en restera qu'un seul. L'objectif, si on lit entre les lignes, et de supprimer l'un des deux. La question est alors de savoir lequel. Je vous le laisse en mille. Reste à voir ensuite l'évolution que ça engendrera, style pas en arrière sur les licences avec celui qui reste. En surface, ça semble génial, mais où sont les garanties ?
2  1 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web