JDK 11 : trois nouveautés sont prévues ainsi que la suppression de JAVA EE, JavaFX et CORBA,
Dans le cadre des mises à jour semestrielles

Le , par Victor Vincent, Chroniqueur Actualités
Dans le cadre de la nouvelle cadence de lancement de chaque six mois, adoptée pour l’édition standard de Java, Oracle est en train de peaufiner les dernières fonctionnalités de prochaine la version du JDK, la version 11, dont la sortie est prévue en septembre 2018. Cette version contrairement à JDK 10, est une version LTS pour « Long Term Support » ou version avec un support à long terme. Elle devrait avoir un support Oracle de premier niveau jusqu’en septembre 2023 et un support étendu incluant des correctifs et des alertes de sécurité jusqu’en 2026.

Succédant au JDK 10 lancé le 20 mars, seules trois nouvelles fonctionnalités sont annoncées à ce jour bien que d’autres puissent s’y greffer avant la date de sortie prévue.

  • Le format de fichier de classe Java qui sera étendu pour prendre en charge une nouvelle forme de pool de constante, CONSTANT_Dynamic.
  • Le mot clé « var » sera désormais utilisable lors de la déclaration des paramètres formels d'une expression lambda typée implicitement. En d’autres termes, une syntaxe à variable locale pour les paramètres lambda doit suivre la syntaxe d'une déclaration de paramètre formelle dans une expression implicitement typée avec la syntaxe d'une déclaration de variable locale.
  • Le « garbage collector » ou ramasse-miette Epsilon, annoncé en tant que collecteur "no-op", gérera l'allocation de mémoire sans implémenter de mécanismes de récupération de mémoire. Les cas d'utilisation d'Epsilon comprennent les tests de performance, la pression de la mémoire et l'interface de la machine virtuelle. Il pourrait également être utilisé pour des utilisations de courtes durées.



Parallèlement à ces ajouts, certaines fonctionnalités ne seront plus présentes. En effet dans la version Java 11, Java FX ainsi que les modules CORBA et Java JEE seront supprimés. La suppression de JavaFX étant en cours se prolongera dans cette version puisque n’étant pas liée au programme de mise à jour semestrielle de Java JDK. Déprécié depuis Java SE9, le retrait des modules Java EE et CORBA était une mesure prévue et sera effectif avec JDK11.
La suppression de CORBA peut être justifiée par deux facteurs. Premièrement, elle date des années 1990 et ne recèle plus aucun intérêt pour le développement d’applications Java modernes d’après Oracle. Enfin, les coûts de maintenance sont élevés comparés aux bénéfices rapportés. Cependant, cette suppression risque d’entrainer des dysfonctionnements sur des implémentations existantes. En effet, ces dernières risquent de ne pas fonctionner si elles n’incluent qu’une partie de l’API CORBA. Elles s’attendront à ce que le JDK leur fournisse le reste. De plus, il n’existe pas de versions tierces pour CORBA et il est peu probable qu’un tiers se décide à en prendre la charge.

Pour ce qui est de la plateforme JAVA EE, la suppression est due à des difficultés de maintenance qu’elle a entrainées dans JAVA SE au fil de ses évolutions. Sortie en décembre 2011, JAVA SE 6 était accompagnée d’une large panoplie des services web utiles au développeur. Parmi ceux-ci, on peut en citer quatre qui étaient dédiés à JAVA JEE : JAX-WS (Java API for XML-based Web Services,**JAXB (Java Architecture for XML Binding), JAF (JavaBeans Activation Framework) et Common Annotations for Java. Ces ajouts de fonctionnalités pour JAVA EE ont entrainé des complications pour JAVA SE notamment parce qu’ils incluaient des fonctionnalités sans rapport avec cette dernière. Ainsi Oracle affirme qu’avec des versions « standalone » disponibles sur des sites tiers, il n’est plus nécessaire de l’inclure dans JAVA SE ou dans le JDK. Cependant, certaines applications pourraient ne pas compiler si elles s’appuient sur un support prêt à l’emploi du JDK pour les API et outils Java EE. Des incompatibilités binaires et de source se produiraient lors de la migration de JDK 6,7 et 8 vers une version ultérieure. Oracle recommande aux développeurs concernés par ces risques de déployer sur des versions alternatives des technologies Java EE à la place.

Source : Mail List Open JDK, Open JDK

Et vous ?

Que pensez-vous de la suppression annoncée des trois modules cités plus haut de JDK 11 ?

Voir aussi

JDK 10 : les fonctionnalités de la prochaine version de Java sont désormais gelées, la sortie est attendue pour le 20 mars 2018

Java 8 ne va plus recevoir de mises à jour et correctifs de sécurité à partir de septembre à moins de passer à un support commercial


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de Pill_S Pill_S - Membre expert https://www.developpez.com
le 28/03/2018 à 9:38
Suppression de... JavaFX? J'ai bien lu? C'est une blague??!

N'ayant jamais vraiment utilisé, je ne vais pas trop m'en plaindre, mais par contre ça me semblait un framework moderne pour développer du standalone... le successeur de swing... mis en avant par Oracle (au moins durant un temps...) comme LA solution à tous nos problèmes

ça devient un package séparé? ou c'est vraiment end of life?
Avatar de robertledoux robertledoux - Membre habitué https://www.developpez.com
le 28/03/2018 à 9:42
Citation Envoyé par Pill_S Voir le message
Suppression de... JavaFX? J'ai bien lu? C'est une blague??!

N'ayant jamais vraiment utilisé, je ne vais pas trop m'en plaindre, mais par contre ça me semblait un framework moderne pour développer du standalone... le successeur de swing... mis en avant par Oracle (au moins durant un temps...) comme LA solution à tous nos problèmes

ça devient un package séparé? ou c'est vraiment end of life?
J'avoue ne pas comprendre, JavaFX permet la création d'application d'une manière super simple et de séparer la vue du reste, c'est le top. J'espère que c'est juste séparer JavaFX (et pk pas le laisser à la communauté); car bon, SWING et consorts, c'est quand même le meilleur moyen d'avoir des interfaces dégueulasses d'un autre age; en claire c'est la mort de Java pour les apps desktop.
Avatar de BugFactory BugFactory - Membre expérimenté https://www.developpez.com
le 28/03/2018 à 11:40
D'après
https://blogs.oracle.com/java-platfo...oadmap-updates
JavaFx sera disponible comme module séparé.

J'ai un projet JavaFx en production et ça ne me plait pas. JavaFx a besoin de davantage d'engagement de la part d'Oracle, pas moins.
Avatar de oallouch oallouch - Futur Membre du Club https://www.developpez.com
le 28/03/2018 à 15:10
Jasper Potts, un des lead dev de JavaFX a retweeté 2 tweets:
un tweet pessimiste : https://twitter.com/skovatch/status/971495384206880768
un tweet de consolation : https://twitter.com/johanvos/status/971447653144899586

Ca sent pas bon de toute manière
Avatar de marc.collin marc.collin - Membre éclairé https://www.developpez.com
le 28/03/2018 à 18:46
Citation Envoyé par robertledoux Voir le message
J'avoue ne pas comprendre, JavaFX permet la création d'application d'une manière super simple et de séparer la vue du reste, c'est le top. J'espère que c'est juste séparer JavaFX (et pk pas le laisser à la communauté); car bon, SWING et consorts, c'est quand même le meilleur moyen d'avoir des interfaces dégueulasses d'un autre age; en claire c'est la mort de Java pour les apps desktop.
le développement de nouvelle app desktop se fait quand même rare
je vois presque peu d'offre d'emploi
Avatar de bouye bouye - Rédacteur/Modérateur https://www.developpez.com
le 29/03/2018 à 0:20
Ahah des mots chocs pour un effet choc .

Le principe est le même que pour Java EE (ou plutôt je devrais dire désormais Jakarta EE) : Oracle s'en désolidarise et le renvoie a son niveau de module séparé du JDK tel que c’était le cas lors de JavaFX 1.x, 2.0 et 2.1 (JavaFX a fait uniquement parti du JDK dans ses version 2.2, 8, 9 et 10). Comme le projet est OpenSource, il sera géré par l'OpenJFX qui est en train de s'organiser autour de Johan Vos et de Gluon pour manager la chose. Pour le moment il sont en train de simplifier la maniere de contribuer (mise en place d'un GitHub forkable) et de build, ensuite le plan c'est de fournir des binaires precompiles sous Maven et une distro ZIP.

EDIT - et même si l'info est déjà passée dans une autre news, coté client les vraies suppressions dans le JDK 11 sont celles des Applets et de Java Web Start qui vont eux tomber aux oubliettes (pas de passage en OpenSource pour JWS). La roadmap indique que Oracle cherche même un repreneur pour Swing sur le long terme, c'est dire a quel point le desktop ne les intéresser plus (ça se voyait quand même depuis 2013), sans doute faute de reel plan ou de rentrées financières suffisantes. Le fait de larguer JEE me fait juste dire que Java ne rapporte sans doute pas assez d'argent pour Oracle, ce qui rejoint les rumeurs qu'on avait eut il y a 2 ans.
Avatar de la.lune la.lune - Membre chevronné https://www.developpez.com
le 29/03/2018 à 7:42
Pour JavaFX, c'est juste une question de suivi des mises à jours du JDK, que JavaFX ne pourra suivre le cycle de 6 mois, pas mais la plate-forme JavaFX restera encore là a évoluer et être utilisé. Et avec la modularité introduite dans JDK9, JavaFX est un module à part entière mais cela ne veut pas dire qu'il sera supprimé de la plate-forme Java, non mais il sera distribué séparément. Celui qui veut faire le JavaFX va télécharger le module JavaFX pour l'intégrer au projet.

Mais ces informations sont déjà publiées ici par des gens qui connaissent les choses mais celui qui a publié cette actualité, on voit qu'il ne maîtrise pas bien ce qu'il dit, ce qui fait de la polémique.
Avatar de professeur shadoko professeur shadoko - Membre expérimenté https://www.developpez.com
le 29/03/2018 à 10:40
Ce qui me semble beaucoup plus inquiétant c'est que ça boite au niveau des techniques de déploiement (ça grince sur jigsaw-dev à ce sujet).

- Java Web start est sur siège éjectable (mais pas encore éjecté) ... probablement au vu des problèmes des jars "exécutables"
- justement les jars "exécutables" (on clique dessus) ne sont plus là avec les jars modulaires ... et donc par quoi les remplacer? pour l'instant par des scripts !
- Les images jlink c'est chou ... mais c'est 1) spécifique à une plate-forme 2) délicat à mettre à jour dès qu'une nouvelle version de java apparait 3) troublant (doux euphémisme ) lorsqu'on veut mettre en place des plug-ins ou des données de configuration in situ

Les migrations des bibliothèques et des apps. vers Java modulaire génèrent certes quelques souffrances mais il faudra aussi hurler bien fort pour que les techniques de déploiement soient remises à jour.
Avatar de adiGuba adiGuba - Expert éminent sénior https://www.developpez.com
le 29/03/2018 à 13:26
Personnellement je vois plutôt d'un très bon œil le fait que certains modules puissent être détaché du JRE.
Le JRE devrait vraiment se concentrer sur l'essentiel.

Et ce n'est pas forcément une mise à mort.
Au contraire le fait de séparer ces modules apporte même des avantages :
  • Ils pourront évoluer indépendamment de Java et avoir des cycles de release différent sans avoir à attendre la prochaine version de Java.
    Et ce même si avec le passage aux releases tous les 6 mois le problème est moins flagrant qu'avant...
  • Ils auront la possibilité de proposer des évolutions "incompatibles", ce qui est quasi-impossible dans le standard sans tout casser.
    Avec des modules distincts on peut tout à fait envisager cela sans trop de problème.


Reste juste les problèmes de déploiements soulevé par professeur shadoko... mais je ne saurais en dire plus vu que je n'ai pas encore touché à Java 9 !
Avatar de Pill_S Pill_S - Membre expert https://www.developpez.com
le 29/03/2018 à 14:02
Tout dépend toujours du point de vue sous lequel on observe un événement...

Personnellement, je vois ça plutôt comme quelque chose de mauvais, quand tu dis:

Ils pourront évoluer indépendamment de Java et avoir des cycles de release différent sans avoir à attendre la prochaine version de Java.
... moi je retiens plutôt:
Et ce même si avec le passage aux releases tous les 6 mois le problème est moins flagrant qu'avant...
donc avantage limité, mais surtout:
Ils auront la possibilité de proposer des évolutions "incompatibles"
... et ça ça peut être plutôt méchant. Bien que n'ayant pas trop codé en C/C++, j'ai entendu tellement de fois les légendaires citations du genre "ouaaaaais quand tu prends la version 1.2 du compilateur avec la version 3.4 de telle librairie, ça fait que la version 5.6 de la dépendance truc a un bug alors faut upgrader machintruc en version 7.8 mais si tu fais ça tu pourras plus utiliser la syntaxe bidule-machin"...

On était plutôt épargné avec Java, étant donné que tout beaucoup était géré par Sun/Oracle, on utilisait un runtime cohérent. J'ai peur que cela soit en train de disparaitre et que tout devienne très bordelique avec un JRE explosé en de multiples dépendences, plus vraiment sous contrôle...

PS: souvenez-vous de Flex. ça lui a pas trop réussi d'être désolidarisé d'Adobe...
Contacter le responsable de la rubrique Accueil