Discussion :

[Songbird]

Un des intérêts de Java est effectivement Write once run everywhere. Effectivement, avec cette fonctionnalité ce ne sera plus le cas (mais bon personne nous oblige à faire de la compilation anticipée...). A terme, ils visent certainement le Write once compile everywhere ?! Le write once run everywhere n'est pas du tout le seul intérêt de Java.

Je suis bien d'accord sur le fait qu'il n'y a pas que la portabilité aisée comme intérêt à utiliser Java, toutefois cette portabilité est quand même bien ancrée dans le coeur du langage.
Après oui effectivement, on ne nous oblige pas d'utiliser la compilation anticipée, mais, comme tu l'as dit toi-même, je ne vois pas d'intérêt à utiliser cette fonctionnalité.

En revanche, dans le domaine du jeu vidéo, ça pourrait peut-être permettre à Java de commencer à faire ses premiers pas concrets dans ce milieu.

[adiGuba]

Je ne me sens pas vraiment excité par la news, le but est d'éliminer le coût d'évaluation des instructions interprétées mais c'est déjà ce que fait le JIT (ok c'est au runtime mais, ça coûte si cher que ça ? Un serveur, une fois démarré, on n'est pas censé le redémarrer toutes les 20 minutes). En fait, j'ai du mal à voir un use case intéressant pour cette techno (je n'ai pas lu la source) ou alors peut être pour une application pour laquelle on veut des performances aux petits oignons ?!

Je pense que l'intérêt se situe plutôt coté client pour accélérer le démarrage des applications, en conservant le code natif au lieu de le recompiler à chaque fois...
Ou alors pour déployer des applications sur des devices spécifiques (TV, etc.)

En revanche, dans le domaine du jeu vidéo, ça pourrait peut-être permettre à Java de commencer à faire ses premiers pas concrets dans ce milieu.

Je pense que le plus gros problème vient plus de l'absence de type "value", qui rend le partage de données difficile entre Java et les appels systèmes natifs...


a++

[yann2]

Je pense que l'intérêt se situe plutôt coté client pour accélérer le démarrage des applications, en conservant le code natif au lieu de le recompiler à chaque fois...
Ou alors pour déployer des applications sur des devices spécifiques (TV, etc.)

a++

Ok pour le côté device spécifique mais pour un client lourd j'ai vraiment du mal à voir l'intérêt. Il me semble que le JIT est capable d'optimiser la génération de code machine en analysant la manière dont est utilisée l'application (inline d'une opération souvent appelée par exemple). En générant le code machine au moment de la compilation on perd ces optimisations, non ?


Bon du coup je suis allé voir la source :

Motivations

JIT compilers are fast, but Java programs can become so large that it takes a long time for the JIT to warm up completely. Infrequently-used Java methods might never be compiled at all, potentially incurring a performance penalty due to repeated interpreted invocations.

Ok, ça aurait été sympa d'avoir des exemples ou chiffres. Parce que, chez moi, Java est déjà super rapide, les seules fois où j'ai des problèmes de performance c'est parce que j'ai fait de la merde

Ils ont l'air perplexes sur reddit aussi : https://www.reddit.com/r/java/commen...e_compilation/. J'ai beaucoup aimé ce commentaire :

This is a monster truck feature. Occasionally useful but will be mostly used by jackasses who don't really need it.

[adiGuba]

Ok pour le côté device spécifique mais pour un client lourd j'ai vraiment du mal à voir l'intérêt. Il me semble que le JIT est capable d'optimiser la génération de code machine en analysant la manière dont est utilisée l'application (inline d'une opération souvent appelée par exemple). En générant le code machine au moment de la compilation on perd ces optimisations, non ?

Oui en effet on perdrait certaines optimisations liés au contexte d’exécution.
Mais apparemment le code AOT peut être recompilé par le compilateur JIT.

Donc grosso-modo cela pourrait aussi permettre d'exécuter du code natif au lieu du code interprété, tout en bénéficiant d'une compilation JIT si besoin.

Ok, ça aurait été sympa d'avoir des exemples ou chiffres. Parce que, chez moi, Java est déjà super rapide, les seules fois où j'ai des problèmes de performance c'est parce que j'ai fait de la merde

Je pense que l'intérêt c'est d'améliorer le temps de démarrage.
Java est très performant pour de "grosses" tâches, mais moins pour un programme qui retourne une valeur immédiatement...

Le fait d'avoir un java.base précompilé devrait aider de ce coté là.



a++

[bouye]

Coté client et encore plus sur mobile ou le JIT n'est pas forcément autorisé (hum iOS). Donc à la longue ça sera forcément utile pour le port mobile de l'OpenJDK.
Et puis en chipotant, cela ne change rien au "Write Once, run anywhere". C'est juste, et uniquement pour ceux utilisant cette fonctionnalité, qu'il faudra faire des compilations spécifiques pour les plateformes ciblées, le code Java lui ne changeant pas.

Par contre, je m'étonne que cette fonctionnalité soit annoncée si tardivement. Plusieurs propositions pour JavaFX pour le JDK9 (telles que le support de WebGL ou encore le remplacement du moteur de rendu Pisces par Marlin un moteur beaucoup plus performant) sont actuellement, après discussions sur la mailing liste de l'OpenJFX, repoussées au calendes grecques (post release JDK 9 ou même JDK 10) sous le prétexte que le JDK9 est déjà "feature complete" et donc qu'il est trop tard pour rajouter des fonctionnalités totalement nouvelles, trop drastiquement différentes ou demandant de trop longues phases de test ou de stabilisation.

[l'art souille]

Une excellente étude (IBM) en plusieurs parties sur la compilation real-time Java (notamment Part 2 : JIT et AOT) : http://www.ibm.com/developerworks/vi...time+Java+Part

[Stéphane le calme]

JDK 9 atteint le milestone Feature Extension Complete,
les JEP qui ont reçu un délai supplémentaire sont désormais implémentés et intégrés dans le master forest

La sortie initiale de JDK 9 avait été annoncée pour le 22 septembre 2016. Mais Mark Reinhold, architecte en chef du JDK chez Oracle, a demandé un délai supplémentaire de six mois pour la finalisation de Jigsaw, un projet dont l’objectif est de concevoir et de mettre en œuvre un système de modules standards pour Java SE. Après validation de sa proposition, la date de sortie de Java 9 a donc été repoussée au 23 mars 2017, avec donc un décalage dans le reste du calendrier.

« Nous avons fait beaucoup de progrès sur le projet Jigsaw, l’élément clé de cette version, au cours des huit derniers mois. [...] Malgré ces progrès, à ce stade, il est clair que Jigsaw a besoin de plus de temps. Nous avons récemment reçu des commentaires critiques qui ont motivé une refonte de la fonctionnalité package-export du système de module, sans laquelle nous ne pourrions pas atteindre l'un de nos principaux objectifs. Il existe, en plus de cela, de nombreux problèmes de conception non encore résolus, qui nécessitent du temps pour y travailler », a expliqué Reinhold en septembre dernier, précisant que le nombre de bogues ouverts qui sont nouveaux dans le JDK 9 est également plus important que celui dans le JDK 8. Aussi, il a pu obtenir une rallonge dans le délai de livraison de la version finale de JDK 9 qui est prévue pour le 27 juillet de l’année en cours.

Selon la feuille de route communiquée par Reinhold, en décembre dernier, JDK 9 a atteint l’étape Feature Extension Complete (les JEP et petites améliorations qui ont reçu un délai supplémentaire ont été implémentés et intégrés dans le master forest). Reinhold l’a d’ailleurs confirmé dans un message sur la liste de diffusion du projet.

Le 19 janvier, Reinhold a annoncé que le projet est entré dans la première phase du processus Rampdown, des étapes qui permettent d’appliquer « des niveaux de contrôles croissants » aux changements entrant dans la nouvelle version du JDK. Cette première phase de Rampdown vise à corriger les bogues de priorité P1-P3 : il l’a décrit comme un processus durant lequel « nous visons à corriger les bogues qui doivent être corrigés et à comprendre pourquoi nous n'allons pas corriger certains bogues qui devraient peut-être être corrigés ».

À ce stade du projet, l'ensemble des fonctionnalités est gelé, a expliqué Reinhold, et il est « hautement improbable » que d'autres JEP soient ciblés pour la version JDK 9. Bien que de petites améliorations aux nouvelles fonctionnalités seront prises en considération, « la barre est désormais beaucoup plus élevée ». Les membres de la communauté peuvent demander l'approbation de ce type d'améliorations par le biais du processus FC-extension existant. Ces améliorations peuvent être incluses si elles représentent un faible risque à condition qu’elles ajoutent de petites quantités de fonctionnalités manquantes ou améliorent l'ergonomie, « en particulier lorsqu’elles sont justifiées par un feedback de développeurs ».

En outre, il a expliqué que les améliorations qui ajoutent de nouvelles fonctionnalités importantes nécessiteront des justifications beaucoup plus importantes. Quant aux améliorations des tests ou de la documentation, elles ne vont pas nécessiter de telles justifications.

Source : message de Mark Reinhold

[Askeridos]

JDK 9 atteint le milestone Feature Extension Complete,
les JEP qui ont reçu un délai supplémentaire sont désormais implémentés et intégrés dans le master forest

Yeah, tous ces termes me mettent de bonne humeur ce matin. Ve masteuw fowest, le maïlessetaune genre les mecs ça fait plus pro , ça m'donne envie de revoir la saison 1 de Stargate SG-1.

[Pill_S]

ça m'donne envie de revoir la saison 1 de Stargate SG-1.

Eclate-toi, Teal'c...

Ch'ai pas mais c'est des termes tellement esotériques? J'ai l'impression qu'on en pond à la chaîne des biens pires...

Moi je salue quand même l'arrivée (bien que tardive ^^) d'une release majeure de Java et de quelques fonctionnalités qui vont être bien pratiques (byebye OSGi)

[GordonFreeman]

On l'aura notre JDK9

Pas mal de changement intéressant dans cette nouvelle mouture.
Pour ceux qui seraient intéressé à connaître l'ensemble des changements/évolutions : http://openjdk.java.net/projects/jdk9/

@Pill_s : je suis pas sûr Qu'OSGI disparaisse de si tôt,
Je sait que le JDK9 apporte le projet Jigsaw qui est censé apportée de la modularité mais concrètement je n'ai toujours pas compris si cela remplacera réellement OSGI.
Perso je n'en ai pas l'impression mais à voir plus en détails.

Si quelqu'un à plus d'info sur la question je suis preneur .

[Mickael_Istria]

(byebye OSGi)

C'est a peu pres impossible car:
1. Les applis modulaires qui veulent etre backward-compatible ne pourront pas utiliser Jigsaw et devront utiliser OSGi
2. Jigsaw ne gere pas vraiment de "lifecycle" des modules, ou en tout cas ne laisse pas le developpeur s'appuyer dessus pour gerer son appli (c'est un point tres important en IoT)
3. Jigsaw ne dispose pas d'une couche service comme OSGi
4. OSGi a deja beaucoup d'utilisateurs, notamment des tres difficiles -politiquement parlant- a migrer (comme les use-cases embarques)
5. J'attends de voir si les developpeurs Java "finaux" vont vraiment avoir quelque chose a faire de Jigsaw pour leurs apps. Au final, les applis sont deja quasiment toutes dans des conteneurs modulaires genre OSGi ou Java EE, donc ajouter la modularite a la couche de la JVM ne devrait pas leur changer grand chose.

Les raisons techniques (1,2,3) rendent par exemple entre impossible et inutile la migration d'applis existantes comme Eclipse ou Karaf

Au final, j'imagine que seule les applis neuves visant vraiment les perfs optimales (donc l'embarque) vont rapidement adopter Jigsaw, et encore, il faudra attendre que Java 9 soit considere comme robuste avant qu'ils y passent. Pour le dev Java workstation ou serveur, la valeur de Jigsaw est tres faible et inferieure a OSGi.

[Michael Guilloux]

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

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 ?

[GordonFreeman]

C'est a peu pres impossible car:
1. Les applis modulaires qui veulent etre backward-compatible ne pourront pas utiliser Jigsaw et devront utiliser OSGi
2. Jigsaw ne gere pas vraiment de "lifecycle" des modules, ou en tout cas ne laisse pas le developpeur s'appuyer dessus pour gerer son appli (c'est un point tres important en IoT)
3. Jigsaw ne dispose pas d'une couche service comme OSGi
4. OSGi a deja beaucoup d'utilisateurs, notamment des tres difficiles -politiquement parlant- a migrer (comme les use-cases embarques)
5. J'attends de voir si les developpeurs Java "finaux" vont vraiment avoir quelque chose a faire de Jigsaw pour leurs apps. Au final, les applis sont deja quasiment toutes dans des conteneurs modulaires genre OSGi ou Java EE, donc ajouter la modularite a la couche de la JVM ne devrait pas leur changer grand chose.

Les raisons techniques (1,2,3) rendent par exemple entre impossible et inutile la migration d'applis existantes comme Eclipse ou Karaf

Au final, j'imagine que seule les applis neuves visant vraiment les perfs optimales (donc l'embarque) vont rapidement adopter Jigsaw, et encore, il faudra attendre que Java 9 soit considere comme robuste avant qu'ils y passent. Pour le dev Java workstation ou serveur, la valeur de Jigsaw est tres faible et inferieure a OSGi.

Ha ben merci, tu réponds à quelques questions que je me posait sur ce sujet.

Merci pour ces quelques éclaircissements.

Cordialement

[Vyrob]

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.

[Mickael_Istria]

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.

[Cafeinoman]

C'est sûr que si au final, ca fait un peu d'OSGI et un peu de Maven, mais en moins bien, tout en ne marchant pas ni avec l'un ni avec l'autre, ça n'a pas d'intérêt...

[Vyrob]

Il faut lire les posts detailles et les discussions en lien.

Je n'ai lu que cette news effectivement, je n'ai pas été voir les articles qui y sont liés. C'est juste que je pensais qu'avec leur processus de développement, ils se seraient rendu compte dès le début si ça n'allait pas, et de fait n'auraient pas eu besoin d'attendre d'en être à la dernière phase pour manifester leur refus. M'enfin il semblerait que je me sois trompé ! Merci pour l'explication en tout cas.

[Padget]

C'est vrai qu'à trois mois d'une release... c'est un peu court pour rebondir. Mais bon, si cela aboutis, cela sera une excellente amélioration pour Java. Le principal avantage sera la taille en mémoire de la JVM qui va considérablement baisser. On rejoint aussi le crédo du C++ : ne t'embarrasse que ce dont tu as la nécessité.
Par contre si, comme certains semblent le supposer, Oracle se détourne de Java, il risque (tant mieux ?) d'y avoir une reconversion de pas mal de développeur vers d'autres écosystèmes (.Net par exemple) : "Le malheur des uns, fait le bonheur des autres".

[steel-finger]

Quelqu'un sais comment va fonctionné ce système de module ?

Sinon ça ne m'étonne pas de RedHat & IBM, ils protègent leur intérêts et c'est normal n'importe quelle entreprise ferais de même

[Mickael_Istria]

Sinon ça ne m'étonne pas de RedHat & IBM, ils protègent leur intérêts et c'est normal n'importe quelle entreprise ferais de même

Les inquietudes sont purement techniques et en rien politiques, et les problemes mentionnes sont valables pour tout l'ecosysteme Java. Il ne faut pas voir la critique d'une specification comme un moyen de ralentir le monde, disons qu'il faut plutot le voir comme un coup de frein pour etre sur de ne pas louper le virage...