[Actualité] En attendant la version officielle de Java 9, premier test avec Netbeans, c'est pas gagné !!!
par
, 02/08/2017 à 07h05 (22279 Affichages)
Houlà ça fait longtemps que je n'ai pas posté quelque chose moi ^^. Allons donc discuter un peu du JDK 9 :
Au début du mois de juillet, étant donné qu'on approchait de la date de sortie d'avant le débâcle "validation de Jigsaw" et à 2 mois de la date finale, je me suis dit que ça devait être suffisamment stable pour au moins tester une version préliminaire (à cette même époque pour les JDK 5 à 8, cela faisait déjà bien longtemps que je faisait du dev à plein temps sur les dernières bêta / RC). J'ai donc récupéré la 9+178 EA ainsi que la dernière nightly build du moment de NetBeans (20170705) histoire de faire quelques tests.
L’expérience ne s'est cependant pas révélée totalement concluante... Vu que plusieurs semaines (et un crash d'ordinateur) sont passées depuis, je viens de récupérer la v9-180 EA et NetBeans 20170801 pour retenter le coup. Hum.. bon ce n'est pas encore tout à fait ça
sans doute en partie la faute aux outils (ici NetBeans) qui sont encore plutôt instables.
Lors des mes premiers tests NetBeans me faisait une boite d'erreur à chaque fois que je tente de bidouiller le descriptif du module (fichier module-info.java), ce souci semble avoir été corrigé dans la version la plus récente. Malgré tout, même une simple app qui fait "hello world" se compile mais refuse de se lancer : même en exportant (exports) le package qui contient la classe principale depuis le descriptif du module, l'IDE n'arrive toujours pas a trouver cette dernière et donc le lancement échoue. Sans doute la faute de NetBeans ici (ou alors je m'y prends très mal).
Pour un package/projet existant, j'arrive bien à créer un module-info et à importer (requires) les modules Java. Il va falloir un certain temps pour comprendre où se trouve quoi : java.base = cœur (automatiquement importé) , java.logging = logging, java.desktop = AWT/Java2D/Swing/ImageIO ; comme prévu JavaFX découpé en plusieurs modules : javafx.base, javafx.controls, javafx.fxml, etc. J'ai plus de mal pour importer des "legacy" JAR qui ne sont pas des modules :
- Mis sur le CLASSPATH NetBeans ne trouve pas les classes contenues dedans donc rien ne compile, tout est souligné en rouge.
- Mis sur le MODULEPATH déjà il faut trouver le nom implicite du module pour l’écrire dans le module-info du projet (dans mon cas XXX_yyyy2.jar devient par exemple un module nommé XXX.yyyy), ensuite l'IDE trouve sans soucis les classes mais le projet ne compile pas pour autant car le compilateur indique... que ce JAR ne contient pas de module-info (dans NetBeans 20170705) ou ne trouve pas le module approprié (NetBeans 20170801).
Donc ça coince encore un peu aux entournures. Il faudrait que je teste ce que ça donne dans Eclipse et Intellij IDEA.
À l'usage, je trouve assez pénible de devoir modifier a mano le module-info pour inclure les requis et les exports donc j’espère bien que d'ici peu les principaux IDE feront ça de manière semi-automatique dès l'import d'une nouvelle classe de l'API qui n'est pas dans les modules pré-importées ou par simple clic droit sur un package/classe -> export to outside world yes/no. Idem j’espère que le refactoring d'un package modifiera automatiquement la ligne de l'export (peux pas trop tester là, vu les plantages récurrents de l'IDE).
Pour le reste, divers trucs mineurs ici et là qui sont passés deprecated tels que des constructeurs (ex : pour une raison inconnue j'avais 2-3 endroits avec new Double(String) ou new Double(double) à remplacer respectivement par Double.parseDouble(String) et Double.valueOf(double) qui étaient utilisés partout ailleurs dans le code). Pas trop pu tester les perfs vu que pour le moment même les quelques projets standalone que j'ai pu compiler ne se lancent pas.