Discussion :

[Hinault Romaric]

Oracle présente de nouvelles fonctionnalités de Java 9
et fixe les bases pour implémenter la modularité

Oracle a dévoilé de nouvelles fonctionnalités qui seront intégrées à Java 9, la prochaine version majeure de la plateforme de développement, qui sera disponible en 2016.

Java 9 introduira via la JEP 158 (Unified JVM Logging), un système d’enregistrement commun pour tous les composants de la JVM. Cela permettra une refonte complète de la façon dont Java signale les événements dans les sous-systèmes.

Plus de contrôle au niveau de la compilation sera offert par cette version (JEP 165 - More compiler controls). Cette amélioration permettra aux développeurs de changer les options de compilation du compilateur JIT Hotspot afin de pouvoir effectuer des optimisations spécifiques.

Avec la JEP 214 (Remove GC Combinations Deprecated in JDK 8), trois fonctionnalités du garbage collection (ramasse-miettes) seront supprimées. Il s’agit de DefNew + CMS, ParNew + SerialOld et Incremental CMS. Ces fonctionnalités étaient déjà obsolètes dans Java 8.

Quelques petits changements seront apportés au projet Coin (JEP 213), qui avait été introduit dans Java 7. Pour rappel, le projet Coin apporte quelques changements linguistiques à Java.

En plus de ces fonctionnalités, Oracle a l’intention de finaliser avec le projet « Resolve Lint and Doclint Warnings » pour le nettoyage des avertissements, qui avait débuté il y a plusieurs années. Java 9 offrira également un support de Datagram Transport Layer Security, et des sorties HTML5 pour Javadoc. De nombreuses corrections seront également apportées pour améliorer la gestion des importations, et les classes dépréciées ne vont plus générer des alertes.

À ces spécifications, s’ajoutent d’autres JEP qui ont été présentées en aout dernier, qui permettent de doter le langage de programmation d’une nouvelle « API lightweight JSON » pour la production et la consommation de documents JSON, de « HTTP2 Client » pour le support du HTTP 2.0 et des web sockets et de « Process API Updates » qui permet d’améliorer le contrôle, la gestion et l’interaction avec les processus non Java.

Bien que le projet Jigsaw ne soit pas encore intégré au projet, Oracle a réaffirmé son engagement d’offrir la modularité dans Java 9. Les ingénieurs d’Oracle ont fixé les bases pour une mise en œuvre structurée du projet Jigsaw à travers la JEP 152, JEP 201 et JEP 220. Jigsaw représente une nouveauté très attendue. Mais, son développement fait face à plusieurs défis qui doivent être relevés avant son intégration.

Jigsaw apportera des gros changements au JDK. Il permettra de découper la bibliothèque d’exécution de base de Java en différents modules. Ainsi, une machine virtuelle Java (JVM) pourra fonctionner sans le support de certains packages de base.

Mark Reinhold, architecte en chef du groupe de la plateforme Java chez Oracle, a fait savoir qu’avec Jigsaw, le format JAR n’avait plus sa place dans le système d’exécution de Java. « Le format JAR a fait son temps, c'est le moment de passer à autre chose », avait affirmé celui-ci.

Une annonce qui n’a pas manqué de créer une certaine frayeur chez les développeurs. Mais, Oracle rassure. Bien que le système d’exécution de Java reposera sur les modules et non les fichiers jar, la plateforme continuera à prendre en charge et à exécuter les applications empaquetées dans les fichiers Jar. Avec le temps, les développeurs devront, cependant, migrer vers les nouveaux formats modulaires.

Le passage à un système de module aura également un impact important sur les outils de développement et les Framework.

À titre de rappel, les JEP sont les nouveaux processus permettant le développement et le test de fonctionnalités relatives au langage Java ou à sa machine virtuelle, sans recourir au processus complet de spécification (JSR). Par la suite, toute JEP qui a été implémentée avec succès sera intégrée à Java sous la forme de mise à jour ou de nouvelle version.


Source : Oracle


Et vous ?

Quelle fonctionnalité attendez-vous le plus dans Java 9 ?

[Traroth2]

Java au niveau des clients lourds comme mobiles étant en voie de disparition rapide, je ne suis pas sûr que Jigsaw soit toujours aussi attendu, en fait. Parce qu'au niveau serveur, les bénéfices concrets sont quand même minces. Démarrage plus rapide du serveur et occupation mémoire plus réduite, en gros. Au prix de la barrette de RAM...

[Blaspheme]

Salut Traroth2,
je lis ton commentaire "Java au niveau des clients lourds comme mobiles étant en voie de disparition rapide" et du coup m'interroge sur ce qui te fait dire ça?
As-tu senti un changement de ce coté là?

[Nico02]

Java au niveau des clients lourds comme mobiles étant en voie de disparition rapide, je ne suis pas sûr que Jigsaw soit toujours aussi attendu, en fait. Parce qu'au niveau serveur, les bénéfices concrets sont quand même minces. Démarrage plus rapide du serveur et occupation mémoire plus réduite, en gros. Au prix de la barrette de RAM...

Mouai m'enfin bon il faut pas non plus oublier tout ce qui est système embarqué qui eux seront ravis de ne pas avoir à charger toutes ces bibliothèques inutiles.

Et puis dire que Java est en voie de disparition des clients lourds/mobile

Autant les projets Web on effectivement le vent en poupe par rapport au client lourd (et pas que pour Java) autant le mobile je suis pas du tout convaincu..

[Traroth2]

Salut Traroth2,
je lis ton commentaire "Java au niveau des clients lourds comme mobiles étant en voie de disparition rapide" et du coup m'interroge sur ce qui te fait dire ça?
As-tu senti un changement de ce coté là?

Concernant le mobile, il y a 10 ans, un truc comme 95% des téléphones mobiles étaient compatibles avec Java ME. Et aujourd'hui, on est bien plus proche de 0%, surtout depuis la fin des Blackberry pré-10 (ni iOS, ni Android, ni WP ne proposent d'environnement Java ME). Pour les clients lourds, le principe même de client lourd est en perte de vitesse par rapport aux clients légers type HTML5+Javascript, mais de toutes manières, ça a toujours été la partie faible de Java. Et certains signes ne trompent pas : la plupart des navigateurs bloquent désormais les applets par défaut, et JavaFX n'a clairement pas le succès escompté. Ca laisse quoi ? Les liseuses (pas les tablettes) Kindle et les lecteurs de Blu-Ray ?

[akecoocoo]

Euh, les apps sous Android, c'est pas en Java ?!?

[Washmid]

Java, oui, Java ME, non

Plus précisément sous android c'est du Java SE :
- avec une machine virtuelle et un bytecode différents
- une grosse partie des API Java SE, sans tout ce qui est AWT / Swing en gros

[Traroth2]

Euh, les apps sous Android, c'est pas en Java ?!?

Ca dépend ce que tu entends par Java. On développe en langage Java avec des API ressemblant à 80% à celles de Java SE (pas la partie IHM, ni sécurité, ni multithreading, en particulier), mais la plateforme d'exécution n'a que peu de rapport avec une JVM. Je pense qu'Android n'est pas du tout concerné par Jigsaw...

Quant à la relation avec Java ME, la seule chose qu'Android en a reprise, c'est les API OpenGL ES.

[23JFK]

...
Mark Reinhold, architecte en chef du groupe de la plateforme Java chez Oracle, a fait savoir qu’avec Jigsaw, le format JAR n’avait plus sa place dans le système d’exécution de Java. « Le format JAR a fait son temps, il est temps de passer à autre », avait affirmé celui-ci.
...

Avec des affirmations comme celle-ci, il ne va pas rester architecte en chef bien longtemps celui-là.

[adiGuba]

Euh, les apps sous Android, c'est pas en Java ?!?

Le code source est écrit en Java, mais ce n'est pas compilé en bytecode Java ni exécuté par un JVM.

Google a créé son propre bytecode et sa propre machine virtuelle (Dalvik).

Avec des affirmations comme celle-ci, il ne va pas rester architecte en chef bien longtemps celui-là.

Pourquoi ?



a++

[tchize_]

Parce qu'au niveau serveur, les bénéfices concrets sont quand même minces. Démarrage plus rapide du serveur et occupation mémoire plus réduite, en gros. Au prix de la barrette de RAM...

Démarrage plus rapide des serveurs => Extrèmement intéressant si tu travail avec des noeuds à la demande. Quand ta charge augmente, entre attendre 30 secondes le démarrage de la jvm et attendre 15 secondes, c'est la différence entre un engorgement temporaire et un effet de cascade qui va tuer tes clients.

Modulariser java pour réduire son emprunte mémoire est important aussi sur un serveur lancant beaucoup de jvm. Ca permettra, en ce qui me concerne, d'utiliser plus souvent java pour du scripting là où pour le moment on lance du python ou du php parce qu'on ne peut pas se permette de de lancer simultanément 20 ou 40 jvm qui consomment chacune 64Mb ou d'attendre 5 secondes d'initialisation pour calculer 2 secondes. Et réduire le nombre de langages à maitriser dans une équipe, c'est aussi augmenter son expertise...

La barette de RAM est pas chère, c'est vrai. Mais sur un serveur, la différence entre 8 16 ou 32 slots pour mettre ta mémoire, c'est très coûteux.

[23JFK]

Avec des affirmations comme celle-ci, il ne va pas rester architecte en chef bien longtemps celui-là.

Pourquoi ?

C'est la partie proclamant la "fin" du format JAR qui me fait tiquer. D'ailleurs, depuis sa primodéclaration, il semble avoir un peu fait machine arrière.

Puis, tous les projets n'ont pas besoin de pousser à l'extrême le concept de modularité. Côté serveur, cela permettra sans doute d'optimiser le fonctionnement, mais pour des déploiements d'applications, une requête sur un fichier JAR sera toujours plus performante que 20 requêtes sur des fichiers JMOD.

[yahiko]

Java au niveau des clients lourds comme mobiles étant en voie de disparition rapide

J'aurai dit en voie de disparition lente, mais au final, ça revient au même

Sinon, je pense que Java ne disparaîtra pas totalement, mais il me paraît évident que ses belles années sont derrières.

[adiGuba]

C'est la partie proclamant la "fin" du format JAR qui me fait tiquer. D'ailleurs, depuis sa primodéclaration, il semble avoir un peu fait machine arrière.

Puis, tous les projets n'ont pas besoin de pousser à l'extrême le concept de modularité. Côté serveur, cela permettra sans doute d'optimiser le fonctionnement, mais pour des déploiements d'applications, une requête sur un fichier JAR sera toujours plus performante que 20 requêtes sur des fichiers JMOD.

Pourquoi il y aurait 1 seule requête pour un JAR, mais 20 pour un JMOD ?


C'est juste un nouveau format va juste permettre de gérer les lacunes des jars, comme la gestion des dépendances et des versions...
Une fois la transition faite il y aura peut d'intérêt à revenir au JAR, sauf à vouloir conserver une rétrocompatibilité avec une ancienne version de Java...


a++

[Traroth2]

Démarrage plus rapide des serveurs => Extrèmement intéressant si tu travail avec des noeuds à la demande. Quand ta charge augmente, entre attendre 30 secondes le démarrage de la jvm et attendre 15 secondes, c'est la différence entre un engorgement temporaire et un effet de cascade qui va tuer tes clients.

Modulariser java pour réduire son emprunte mémoire est important aussi sur un serveur lancant beaucoup de jvm. Ca permettra, en ce qui me concerne, d'utiliser plus souvent java pour du scripting là où pour le moment on lance du python ou du php parce qu'on ne peut pas se permette de de lancer simultanément 20 ou 40 jvm qui consomment chacune 64Mb ou d'attendre 5 secondes d'initialisation pour calculer 2 secondes. Et réduire le nombre de langages à maitriser dans une équipe, c'est aussi augmenter son expertise...

La barette de RAM est pas chère, c'est vrai. Mais sur un serveur, la différence entre 8 16 ou 32 slots pour mettre ta mémoire, c'est très coûteux.

Oui, oui, je ne dis pas que ça ne sert à rien. Mais c'est sur le client que la différence aurait été vraiment déterminante, et là, les jeux sont faits. Jigsaw vient avec 10 ans de retard...

[Traroth2]

J'aurai dit en voie de disparition lente, mais au final, ça revient au même

Sinon, je pense que Java ne disparaîtra pas totalement, mais il me paraît évident que ses belles années sont derrières.

Ah mais je n'ai jamais dit que Java allait disparaitre, hein. Au niveau serveur, c'est loin d'être le cas, et vues la qualité et la vitesse d'adoption de Java 8, on peut s'attendre à un véritable renouveau, au contraire.

[adiGuba]

Oui, oui, je ne dis pas que ça ne sert à rien. Mais c'est sur le client que la différence aurait été vraiment déterminante, et là, les jeux sont faits. Jigsaw vient avec 10 ans de retard...

Bah les technos tournent. Rien ne dit que Java ne reviendra pas sur le devant de la scène coté desktop et/ou navigateur.
A la fin des années 90 c'était le DHTML qui était à la mode, avant d'être petit à petit remplacé par des langages cote-serveur... avant de revenir à la mode sous un autre nom (AJAX) un peu plus élaboré.

Et de nos jours on parle de plus en plus du JavaScript coté desktop !



Le gros problème de Java dans le navigateur, outre le plugin bien lourd, c'était surtout la guerre qu'il y a eu avec Microsoft et son "Java" non-standard qui a complètement cassé le "write-one run-everywhere".



Le JavaScript c'est certe bien mais cela a un paquet de défaut, surtout lorsqu'on gère des applications complexes.
Je ne serais pas étonné de voir des tentatives pour intégrer un nouveau langage en standard dans les navigateurs, et un langage comme Java (ou C#) pourrait très bien remplacer avantageusement le JavaScript.

Le gros problème c'est que ces langages sont étroitement liés à des API énormes contenant plein de chose pas forcément adapté (que faire de CORBA, AWT, Swing, JDBC ou encore javax.management), et qu'il devient difficile et "lourd" de les incorporer dans un navigateur.

Mais demain avec le projet Jigsaw on pourrait très bien imaginer un Java "light" : le même langage, mais associé à une API minimum.
Le module de base devrait contenir les principaux package (java.lang / java.util), et pourra être enrichi d'autres modules selon les besoins.

Il serait donc possible de voir des navigateurs inclurent un Java "minimum", le tout couplé à un module "browser" permettant une communication simple avec le browser, et des modules optionnelles représentant les fonctionnalités "html5"...
Et on pourrait se retrouver à codé des applications Java qui tourneraient directement dans le navigateur.



a++

[yahiko]

Je sens le troll involontaire, mais je pense surtout que le gros problème de Java, c'est le langage en lui-même.
Je ne vois pas un développeur Web habitué à la syntaxe fonctionnelle de JavaScript se mettre à faire du tout POO comme l'impose Java.

[tchize_]

Il est clair qui si on vois java remplaçant javascript, il va falloir passer par autoriser la programmation fonctionnelle. Ceci dit groovy, c'est du java et ça le permet, donc c'est loin d'être impossible :p

puis les javascriptien sont de plus en plus habitués à la poo avec jquery & co

[adiGuba]

Je sens le troll involontaire, mais je pense surtout que le gros problème de Java, c'est le langage en lui-même.
Je ne vois pas un développeur Web habitué à la syntaxe fonctionnelle de JavaScript se mettre à faire du tout POO comme l'impose Java.

Oui tout à fait.
JavaScript a de nombreux avantages vis à vis de la simplicité d'utilisation.


Mais je vois que je me suis mal exprimé: je voulais pas remplacer JavaScript ! Il n'y a aucun doute sur le fait qu'il restera utilisable dans les navigateurs encore bien longtemps.
Je parlais plutôt de lui offrir une alternative via un langage comme Java ou C# pour les applications plus complexes.



Quand tu vois que Google a pondu GWT pour développer en Java en compilant le tout vers du JavaScript, tu te dis que cela pourrait être pas ma de rester directement sur du Java...


a++