Oracle annonce la sortie officielle de Java 11

Version imprimable

28/03/2018, 08h14
Victor Vincent

1 pièce(s) jointe(s)

Oracle annonce la sortie officielle de Java 11
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

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.
Pièce jointe 365177

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 ?

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

Voir aussi

:fleche: 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

:fleche: Java 8 ne va plus recevoir de mises à jour et correctifs de sécurité à partir de septembre à moins de passer à un support commercial
28/03/2018, 09h38
Pill_S

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?
28/03/2018, 09h42
robertledoux

Citation:

Envoyé par Pill_S

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.
28/03/2018, 11h40
BugFactory

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.
28/03/2018, 15h10
oallouch

ce que Jasper Potts en pense

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
28/03/2018, 18h46
marc.collin

Citation:

Envoyé par robertledoux

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
29/03/2018, 00h20
bouye

Ahah des mots chocs pour un effet choc :aie:.

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.
29/03/2018, 07h42
la.lune

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.
29/03/2018, 10h40
professeur shadoko

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 :aie:!
- 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 :roll:) 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 :ptdr: mais il faudra aussi hurler bien fort pour que les techniques de déploiement soient remises à jour.
29/03/2018, 13h26
adiGuba
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 ! :aie:
29/03/2018, 14h02
Pill_S

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:

Citation:

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:

Citation:

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:

Citation:

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...
29/03/2018, 22h17
adiGuba

Citation:

Envoyé par Pill_S

donc avantage limité

Ça peut rester malgré tout plus "long" puisqu'il faut se caler sur le planning du JRE... Et si c'est pas prêt ou validé ça reporte de 6 mois...

Citation:

Envoyé par Pill_S

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...

Pourtant beaucoup de librairie se sont développées en dehors de Java SE/EE, parfois avant d'être intégrées plus tard.

Le fait de pouvoir proposer des versions incompatibles permet aussi de passer outre les erreurs du passé...

IMHO c'est très important pour la couche UI afin de pouvoir évoluer avec son époque...
20/06/2018, 13h48
Jitou

C'est une bonne chose que l'on extirpe ces libs du framework Java, bien sûr cela restera des libs indépendantes disponibles dans le repository Maven.

> Java Web start est sur siège éjectable (mais pas encore éjecté) ... probablement au vu des problèmes des jars "exécutables"

Il serait effectivement aussi temps de virer la pire invention du monde Java, je connais des clients qui l'utilisent encore à fond cela et cela ne va pas les arranger mais dans le même temps ils sont à des années lumières d'arriver à Java 11 ...
21/06/2018, 23h36
bouye

Je sais que JWS fonctionne pour beaucoup de gens mais je sais aussi qu'il ne fonctionne pas pour beaucoup d'autres. Lors de la session de la JavaOne tournant autour en 2011 ou 12 (je sais pu ça date déjà) on était quand même 4 personnes dans la salle en train de se plaindre de manière assez virulente que ça ne fonctionnait pas du tout du tout, super pénible a mettre en place, impossible a diagnostiquer... M'enfin il me fallait passer par un outil externe (JaNeLa) pour valider les JNLP et corriger ceux pas vraiment optimises que me pondaient NetBeans ou ceux non-fonctionnels que je pouvais écrire a mano en suivant les références du format et autres didacticiels officiels :aie:
De plus les commentaires laisses sur Twitter laissent a penser que le fait que ce n'est pas open source pour des raisons de copyright dans doute (la techno etait licenciée a un tiers ou repompée d'ailleurs ?) ou encore que le code est de trop mauvaise qualité pour être publié.
25/08/2018, 13h42
nfouka

Migration Applet / JNLP sous Java 11

Bonjour ,
J'ai une application qui tourne en Applet et qui s'exescute avec un JNLP sur le navigateur , comme vous le savez les applets et le jnlp vont être supprimer à partir de la version 11 ( janvier 2019 )
J'envisage de faire une migration en Java 11 , et je me pose la question : est ce que je dois garder mon ancien code ( qui tourne depuis des années ) ou passer sur une nouvelles technologies basé sur java jee ou java fx
D'après vous c'est quoi qui est mieux et moins violent pour cette migration : garder le code et maigrir vers les Swing ( ou FX ) ou bien changer la stratégie est passer au java fmk( spring boot / jsf ... )
Merci d'avance pour vos conseils
Cordialement .
11/09/2018, 15h43
grunt2000

Sincèrement, je n'en peux plus.

J'ai passé un week-end à essayer de migrer une application Java 8 en Java 10 et à la mettre en modules.
Arrivé à un sous-projet utilisant Apache Spark, j'avais du mal : un module spark.core_2.11 m'était proposé, mais le placer dans module-info.java le faisait râler : il n'aime pas les chiffres ; j'étais étonné qu'un module puisse avoir ce nom-là, s'il ne convenait pas.
J'ai cherché trop longtemps : il ne fallait pas. Spark 2.3.1, la dernière version, ne soutient pas Java 10. Pas la 9 non plus. Seulement la 8. J'étais grognon.

C'en est ainsi de quasiment tout.
Java 9+ ça peut être le 10 ou le 11, ça reste un fiasco. Un an après la sortie de Java 9, je n'ai pas vu d'entreprises et je ne aucun projet autour de moi qui ait migré dessus.
Et surtout : aucune qui en ait l'intention. Et elles ont raison : il faudrait déjà que les projets open source, qui sont partie de nos logiciels, fonctionnent eux-mêmes avec du Java 9+ : c'est loin d'être le cas.

En Janvier prochain, nous serons tous sur une version obsolète : Java 8. On aura jamais vu ça. Personne n'est capable de migrer.
Qu'Oracle continue donc avec du Java 11, 12, 13 ! Ça ne sert à rien. Il fait du forcing à coup d'injonctions, mais nous sommes tous bloqués, tous coincés derrière.

Comme il dit mon maître à penser : "J'voudrais trouver les mots, mais y a pas de mots."
11/09/2018, 18h16
adiGuba

Citation:

Envoyé par grunt2000

Personne n'est capable de migrer.

Il y a pourtant une solution simple : ne pas utiliser le système de module !

Tant que les modules ne seront pas largement adoptés par les librairies tierces, ce sera inutilisable (ou difficilement).

C'est pas vraiment anormal, on avait eu un peu les mêmes problèmes avec les Generics...
13/09/2018, 15h45
Mickael Baron

Je suis du même avis que AdiGuba, pour l'instant les modules je n'en occupe pas. Il y a des warnings quand certaines API souhaitent accéder à des éléments natifs du JDK, je ferme les yeux ;-)

Mickael
26/09/2018, 15h57
Michael Guilloux

Oracle annonce la sortie officielle de Java 11

Oracle annonce la sortie officielle de Java 11
tour d'horizon des principales nouveautés de cette version LTS

Oracle a annoncé mardi la disponibilité générale de Java 11, conformément à sa nouvelle cadence de publication de six mois adoptée il y a un an avec Java 9. Avec sa nouvelle cadence, quand une nouvelle version de Java est disponible, la version précédente va immédiatement cesser de recevoir des mises à jour publiques. C'est ce qui fait d'ailleurs que Java 11 est une mise à jour importante, car il s'agit de la première version LTS (bénéficiant d'un support à long terme) depuis qu'Oracle a décidé de sortir deux versions de Java par an. Elle est donc destinée aux utilisateurs qui privilégient la stabilité à un accès rapide aux nouvelles fonctionnalités.

Pour en venir aux nouveautés, Java 11 ne fait pas moins que les versions précédentes. Cette version vient en effet avec un bon lot de nouveautés et de nombreux changements que les développeurs ne doivent pas ignorer.

Dans Java 11, une nouvelle API HTTP fait son apparition. En fait, elle n'est pas tout à fait nouvelle, puisqu'elle a été introduite dans le JDK 9 (en incubation) et mise à jour dans le JDK 10. L'API HTTP a été standardisée dans Java 11. Dans le cadre de ce travail, l'API précédemment incubée, qui se trouvait dans le package jdk.incubator.http, a été supprimée. Les codes qui utilisent les types du package jdk.incubator.http devraient donc être mis à jour pour importer les types HTTP à partir de java.net.http.

Java 11 met également à jour les API de plateforme existantes pour prendre en charge la version 10.0.0 du standard Unicode. Après le JDK 10, qui supportait Unicode 8.0.0, le JDK 11 combine en effet les versions 9.0.0 et 10.0.0 d'Unicode qui incluent 16 018 nouveaux caractères, 18 nouveaux blocs et 10 nouveaux scripts.

Comme autre nouveauté, notons l'ajout du Z Garbage Collector, également appelé ZGC, un ramasse-miettes scalable à faible latence (en phase expérimentale). Il est conçu pour répondre à un certain nombre d'objectifs comme : des temps de pause qui ne dépassent pas les 10 ms ; et gérer des tas allant de quelques centaines de mégaoctets à plusieurs téraoctets. Précisons en passant que le tas est l'un des deux segments de mémoire utilisés lors de l'allocation dynamique de mémoire durant l'exécution d'un programme informatique. ZGC n'est pour le moment disponible que sous Linux/x64.

Au nombre des nouveautés, soulignons aussi que le nom de type réservé var peut maintenant être utilisé lors de la déclaration des paramètres formels d'une expression lambda. Cette nouveauté s'appuie sur la capacité de Java SE 10 à utiliser var pour la déclaration de variables locales. Entre autres nouvelles fonctionnalités, avec Java 11, il sera possible de lancer des programmes fournis sous la forme d’un fichier unique de code source Java.

https://www.developpez.com/public/images/news/jdk10.png

Côté sécurité, Java 11 implémente les algorithmes de chiffrement ChaCha20 et Poly1305, mais aussi TLS 1.3, la dernière version du protocole de sécurisation des échanges sur Internet. On notera du côté des fonctionnalités obsolètes la suppression des modules Java EE et CORBA de la plateforme Java SE et du JDK. Ces modules étaient déclarés obsolètes depuis Java SE 9. Le moteur JavaScript Nashorn a été également déprécié dans Java 11. Comme lui, les outils pack200, unpack200 et l'API Pack200 dans java.util.jar sont désormais obsolètes.

Si nous sommes loin de la liste exhaustive des changements introduits dans Java 11, on peut terminer sur des informations que les développeurs devraient savoir en utilisant Java 11. D'abord, les Applets et la plateforme de déploiement Web Start, obsolètes depuis Java 9, ont été supprimées dans cette nouvelle version. Il est aussi utile de rappeler que JavaFX n'est plus inclus dans le JDK. Il est maintenant disponible en téléchargement séparé depuis openjfx.io.

Stephen Colebourne met en garde contre le téléchargement du JDK Oracle

Si Java 11 est maintenant disponible, Stephen Colebourne, architecte et célèbre contributeur Java, estime qu'Oracle l’a délibérément ou accidentellement configuré pour être un piège pour les utilisateurs : le JDK Oracle vient avec une nouvelle licence. « Depuis 23 ans, les développeurs ont téléchargé le JDK d’Oracle et l’ont utilisé gratuitement. Tapez "JDK" dans votre moteur de recherche préféré, et le premier lien sera vers une page de téléchargement Oracle Java SE », explique Stephen Colebourne. « Mais cette recherche et ce lien sont désormais un piège : Oracle JDK, celui auquel toutes les recherches sur le Web vous amènent, est maintenant commercialisé ».

Ainsi, le piège, selon lui, est que les développeurs vont télécharger le JDK Oracle (parce que c'est ce qu'ils ont toujours fait, et c'est suggèrent les recherches sur le Web) ; l'utiliser en production (car ils ne vont pas réaliser que la licence a changé) ; et recevoir plus tard un appel désagréable des équipes Licences d'Oracle exigeant de payer beaucoup d'argent.

« En d'autres termes, Oracle peut amener [les développeurs] à télécharger la mauvaise version (commerciale) de Java. Si vous ne lisez pas attentivement les [termes], vous ne réaliserez peut-être même pas qu'Oracle JDK est maintenant commercial et que vous êtes donc tenu de payer Oracle pour Java », dit-il.

Maintenant, est-ce un piège de la part d'Oracle ? L'architecte Java laisse les lecteurs se faire leurs propres opinions. Mais en attendant d’avoir une réponse, il y a une solution simple : utiliser une build OpenJDK. En plus de son JDK commercial, Oracle propose une build OpenJDK qui est gratuite et sous licence GPL, disponible sur le site jdk.java.net. Et il y aussi d'autres builds OpenJDK qui devraient bientôt être disponibles, comme celles d'AdoptOpenJDK ou de groupes autres qu'Oracle.

:fleche: Télécharger l'OpenJDK

Sources : Annonce Oracle, OpenJDK, Stephen Colebourne

Et vous ?

:fleche: Aviez-vous l'habitude de télécharger le JDK Oracle ? Que pensez-vous de ce changement licence ?
:fleche: Croyez-vous qu'Oracle voulait piéger les développeurs Java ?
:fleche: A part cela, que pensez-vous de cette nouvelle version de Java ?
:fleche: Quelles nouveautés appréciez-vous le plus ? Quels changements trouvez-vous décevants ? Pourquoi ?
:fleche: Qu'attendez-vous des prochaines versions ?

Voir aussi :

:fleche: JavaFX 11 est enfin disponible en tant que module open source distinct du JDK : tour d'horizon des améliorations et des nouveautés
:fleche: 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
:fleche: Java 11 : migrer ou changer de langage, qu'envisagez-vous de faire suite aux derniers changements annoncés par Oracle ?
:fleche: Oracle annonce la sortie officielle de Java 10, ce qui signifie la fin des mises à jour et correctifs de sécurité gratuits pour Java 9
27/09/2018, 13h19
grunt2000
Pardonnez-moi d'être une freizh, mais je n'arrive pas à comprendre quelle est la différence entre la version open jdk et celle d'Oracle dans le code.

Deux équipes concurrentes font la course à chaque fois pour implémenter des fonctionnalités de chaque côté,
Code:

1 2 3 4 // Open JDK public void increase() { this.value = this.value + 1; }
Code:

1 2 3 4 // Oracle public void increase() { this.value = 1 + this.value; }
... en se tenant prêtes pour livrer toutes deux le 25 Septembre ?

ou bien : c'est le même code mais on fait un package payant pour Oracle, et un gratuit pour open-jdk, ou qu'est-ce qui change ?

Concrètement, c'est quoi les différences binaires entre les deux versions ?
27/09/2018, 13h49
darklinux

Il n ' y en a aucune , mais OpenJDK est la version de référence à Java
27/09/2018, 14h58
grunt2000

Citation:

Envoyé par darklinux

Il n ' y en a aucune , mais OpenJDK est la version de référence à Java

Du coup, comment une version OpenJDK se transforme en version Oracle ?
Parce qu'à ce compte, je vous fais aussi une version grunt2000 si vous voulez : s'il suffit de copier le binaire sur son site web.

D'où vient que c'est Oracle qui semble décider de ce qui sera implémenté dans Java, alors que ça devrait être du coup, si c'est OpenJDK le chef de file, et pourquoi les gens iraient chez Oracle acheter un JDK du coup, s'il est à l'exact identique de l'autre ?
27/09/2018, 15h14
Invité

Citation:

Envoyé par grunt2000

Du coup, comment une version OpenJDK se transforme en version Oracle ?
Parce qu'à ce compte, je vous fais aussi une version grunt2000 si vous voulez : s'il suffit de copier le binaire sur son site web.

D'où vient que c'est Oracle qui semble décider de ce qui sera implémenté dans Java, alors que ça devrait être du coup, si c'est OpenJDK le chef de file, et pourquoi les gens iraient chez Oracle acheter un JDK du coup, s'il est à l'exact identique de l'autre ?

L'Open JDK est maintenu par Oracle, la version "Oracle" du JDK contient des modifications de licence, des ajustements de performances ou des implémentations spécifiques à certains environnements. Les notions de support ne sont pas les mêmes non plus.
27/09/2018, 20h46
adiGuba

L'OpenJDK c'est la version de référence (depuis je ne sais plus quelle version).
La version d'Oracle n'est juste qu'une des implémentations parmi d'autre (comme IBM).

Rien n'a vraiment changé de ce côté là. C'était déjà comme cela avant.

Ce qui a changé c'est que desormais le JDK d'Oracle est soumis à un accord commercial.
En clair il n'est plus gratuit... Contrairement à l'OpenJDK.

Bref pour continuer à l'utiliser gratuitement c'est par ici :
https://jdk.java.net/11/

Juste pour que je comprenne bien, parce que ça ne m'est pas clair : pareil mais implémentation différente ?

Est-ce que la situation est celle-ci :

Oracle OpenJDK

Classes Mêmes CRC que OpenJDK Mêmes CRC que Oracle

Exécutables java.exe et javac.exe même taille et CRC/SHA-1/MD5... que OpenJDK java.exe et javac.exe même taille et CRC/SHA-1/MD5... que Oracle

Ou bien :
Les classes distribuées et les exécutables distribués peuvent différer binairement
et alors : comment précisément ?

28/09/2018, 16h29
Olivier Famien

3 pièce(s) jointe(s)

Andrew Haley de Red Hat donne son avis sur l’avenir d’OpenJDK, l’implémentation libre de Java SE

Andrew Haley de Red Hat donne son avis sur l’avenir d’OpenJDK, l’implémentation libre de Java SE,
après la décision d’Oracle de livrer JDK 11 sous licence commerciale

Oracle a annoncé, depuis quelques jours, la sortie de la version 11 de sa plateforme Java SE composée de JSR (définissant les spécifications de Java), JDK (comprenant les bibliothèques logicielles de Java) et JRE (l’environnement d’exécution de Java également inclus dans JDK). Au-delà des améliorations techniques et autres nouvelles fonctionnalités introduites dans cette version de Java 11, la nouvelle version de la plateforme Java SE, annoncée avec un support LTS (un support à long terme), sera livrée avec une version commerciale de JDK 11.

Pièce jointe 415771

Cette résultante est la conséquence des décisions d’Oracle annoncées en juin dernier et introduisant un modèle d’abonnement à la plateforme Java SE afin que les utilisateurs puissent bénéficier d’un support des ingénieurs d’Oracle pour cette plateforme. Selon les termes de licence d’Oracle, cet abonnement fournit aux entreprises des fonctionnalités et des outils commerciaux tels que Java Advanced Management Console pour identifier, gérer et ajuster l’utilisation du bureau Java SE en entreprise. Il inclut également le support Oracle Premier pour les versions actuelles et versions précédentes de Java SE.

Pour résumer, l’argument présenté par Oracle pour soutenir cette décision est que « les entreprises veulent une totale flexibilité quant au moment et à la manière dont elles mettent à jour leurs applications de production ». Cet abonnement serait donc un support complémentaire aux options gratuites utilisées par les entreprises pour gérer leurs outils Java. À ce sujet, l’entreprise explique que « l’abonnement Java SE complète les versions gratuites et continues de Java SE et la gestion de l’écosystème OpenJDK dans lequel Oracle produit maintenant des binaires Open Source OpenJDK, permettant ainsi aux développeurs et aux entreprises de ne pas avoir besoin d’un support commercial ou d’outils de gestion d’entreprise ».

Pièce jointe 415774

Malgré ces propos qui se veulent rassurants, Andrew Haley, ingénieur en chef de la plateforme Java chez Red Hat, a tenu à préciser de manière claire et nette qu’Oracle ne fournirait plus de binaires gratuits de JDK après une période de six mois. Et les ingénieurs de l’entreprise n’écriront plus de correctifs pour les bogues OpenJDK après cette période.

Voyant des craintes s’élever au sein de la communauté Java à la suite de ces changements, Andrew Haley encourage la communauté à être optimiste et explique dans un billet de blog comment OpenJDK pourrait toujours évoluer sans le concours des ingénieurs d’oracle. À noter qu’OpenJDK est l’implémentation libre (sous licence GPL) de la plateforme Java SE d’Oracle. Elle se compose de plusieurs contributeurs dont Oracle, Red Hat, Azul Systems, SAP SE, IBM, Apple pour ne citer que ceux-là.

Pièce jointe 415778

Selon le modèle de fonctionnement établi autour d’OpenJDK, les organisations collaborent pour résoudre les bogues critiques et les vulnérabilités de sécurité et publient les correctifs à intervalles réguliers. Pour Andrew Haley, qui assure actuellement la direction des projets de mise à jour de JDK 8 et 11, ce mode de fonctionnement ne devrait pas changer pour OpenJDK 8 et OpenJDK 11, même sans le concours des ingénieurs d’Oracle. Cela sous-entend qu’OpenJDK 8 qui bénéficie d’un support LTS jusqu’en 2023 et OpenJDK 11 au-delà de cette date recevront leurs mises à jour régulières comme prévu. Et pour encore rassurer la communauté sur le fait qu’OpenJDK survivra sans Oracle, Haley annonce, qu’en plus des personnes et organisations qui aident actuellement à la sortie des mises à jour d’OpenJDK, de nouvelles organisations, y compris Amazon Web Services, sont prêtes à apporter leur soutien au projet.

Avec le retrait du support d’Oracle dans l’implémentation des mises à jour d’OpenJDK, une question qui se pose fréquemment est celle de savoir comment les utilisateurs obtiendront des téléchargements gratuits de binaires OpenJDK compilés, par opposition au code source fourni par OpenJDK. Selon Haley, le projet de mises à jour OpenJDK lui-même devrait s’engager à fournir des fichiers binaires lors de la publication des versions. Mais si vous utilisez des distributions Linux, l’ingénieur en chef de Red Hat suggère d’utiliser les paquets OpenJDK fournis par le système et son gestionnaire de packages.

Pour les binaires OpenJDK de Windows et Mac OS, il incombera aux projets de mises à jour OpenJDK de décider comment et où construire les fichiers binaires. Cela dit, Haley déclare que son « équipe Red Hat est heureuse de s’engager à fournir des téléchargements Windows et Linux régulièrement mis à jour, testés (et en particulier par TCK'd) ». Mais Haley souligne qu’ils auront probablement besoin d’aide pour la construction et les tests sur Macintosh.

Enfin, Haley termine son propos en reconnaissant que l’absence du soutien des ingénieurs d’Oracle constituera un défi pour la communauté Java. Mais pour lui, ce défi devrait permettre à la communauté de prouver qu’elle peut toujours tenir sans cette entreprise. Un appel est donc lancé aux contributeurs pour assurer la pérennité d’OpenJDK.

Source : Java SE Roadmap, Red Hat

Et vous ?

:fleche: Quel est votre avis sur le retrait du support d’Oracle pour OpenJDK ?

:fleche: Êtes-vous rassuré par les déclarations de Haley quant à l’avenir du projet OpenJDK ?

:fleche: Pensez-vous qu’OpenJDK pourra tenir sans le soutien des ingénieurs Oracle ?

Voir aussi

:fleche: Java SE : Oracle soumet l’utilisation des fonctionnalités commerciales à une souscription mensuelle, la licence permanente n’est plus d’actualité
:fleche: Oracle annonce des changements pour Java SE : deux versions par an, licence GPL, des fonctionnalités commerciales du JDK d’Oracle en open source
:fleche: Oracle envisage de transférer le développement de Java EE à une fondation open source, une preuve de l’abandon de la plateforme
:fleche: Java SE 8 : les mises à jour publiques seront disponibles jusqu’à décembre 2020 minimum pour les fonctionnalités non commerciales
:fleche: Oracle annonce la disponibilité générale de Java EE 8, le développement de la plateforme sera désormais géré par la Fondation Eclipse
28/09/2018, 16h41
GLDavid

Bonjour

Citation:

Enfin, Haley termine son propos en reconnaissant que l’absence du soutien des ingénieurs d’Oracle constituera un défi pour la communauté Java. Mais pour lui, ce défi devrait permettre à la communauté de prouver qu’elle peut toujours tenir sans cette entreprise. Un appel est donc lancé aux contributeurs pour assurer la pérennité d’OpenJDK.

J'appelle cela une liberation. Pour être franc et avoir été pendant longtemps un codeur Java, la nouvelle de l'acquisition de Java par Oracle m'a été désagréable et les évènements consequents ne m'ont pas rassurés. On savait qu'Oracle essaierait de tirer le maximum de bénéfices.
Là, je vois une prise de conscience et un appel à ce que Java soit clairement du domaine libre. En gros, OpenJDK serait la base et norme, Oracle peut faire ce qu'il veut autour de cette base.

@++
28/09/2018, 16h48
deltree

On supprime on supprime... mais est-ce qu'au moins ça baisse en taille?

Je reviens sur le problème des modules.

Citation:

Envoyé par adiGuba

Il y a pourtant une solution simple : ne pas utiliser le système de module !

Je suis passé sur le JDK 10 il y a quelques mois. Et je lance Geoserver sur mon poste.

Code:

1
2
3
4
5
6
SEVEN@SEVEN-PC MINGW64 /c/Outils/Programmation/geoserver-2.13.2/bin
$ sh startup.sh
GEOSERVER DATA DIR is F:\data\dev-compte-france\geoserver_data_dir
[...]
29 sept. 06:05:48 ERROR [context.ContextLoader] - Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'KMLEncoder': Failed to introspect bean class [org.geoserver.kml.KMLEncoder] for lookup method metadata: could not find class that it depends on; nested exception is java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException

D'après les solutions que l'on trouve sur Internet sur ce sujet, il faut rajouter à la ligne de commande la directive :
--add-modules java.xml.bind

Alors, je force le trait exprès pour exagérer mais j'ai fait l'essai et bien sûr ceci ne fonctionne pas :

Code:

1
2
sh startup.sh --add-modules java.xml.bind
sh startup.sh -D--add-modules java.xml.bind

Il faut lire le contenu du script startup.sh livré par Geotools :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
#!/bin/sh
# -----------------------------------------------------------------------------
# Start Script for GEOSERVER
#
# $Id$
# -----------------------------------------------------------------------------
 
# Guard against misconfigured JAVA_HOME
if [ ! -z "$JAVA_HOME" -a ! -x "$JAVA_HOME"/bin/java ]; then
  echo "The JAVA_HOME environment variable is set but JAVA_HOME/bin/java"
  echo "is missing or not executable:"
  echo "    JAVA_HOME=$JAVA_HOME"
  echo "Please either set JAVA_HOME so that the Java runtime is JAVA_HOME/bin/java"
  echo "or unset JAVA_HOME to use the Java runtime on the PATH."
  exit 1
fi
 
# Find java from JAVA_HOME or PATH
if [ ! -z "$JAVA_HOME" ]; then
  _RUNJAVA="$JAVA_HOME"/bin/java
elif [ ! -z "$(which java)" ]; then
  _RUNJAVA=java
else
  echo "A Java runtime (java) was not found in JAVA_HOME/bin or on the PATH."
  echo "Please either set the JAVA_HOME environment variable so that the Java runtime"
  echo "is JAVA_HOME/bin/java or add the Java runtime to the PATH."
  exit 1
fi
 
if [ -z $GEOSERVER_HOME ]; then
  #If GEOSERVER_HOME not set then guess a few locations before giving
  # up and demanding user set it.
  if [ -r start.jar ]; then
     echo "GEOSERVER_HOME environment variable not found, using current "
     echo "directory.  If not set then running this script from other "
     echo "directories will not work in the future."
     export GEOSERVER_HOME=`pwd`
  else 
    if [ -r ../start.jar ]; then
      echo "GEOSERVER_HOME environment variable not found, using current "
      echo "location.  If not set then running this script from other "
      echo "directories will not work in the future."
      export GEOSERVER_HOME=`pwd`/..
    fi
  fi 
 
  if [ -z "$GEOSERVER_HOME" ]; then
    echo "The GEOSERVER_HOME environment variable is not defined"
    echo "This environment variable is needed to run this program"
    echo "Please set it to the directory where geoserver was installed"
    exit 1
  fi
 
fi
 
if [ ! -r "$GEOSERVER_HOME"/bin/startup.sh ]; then
  echo "The GEOSERVER_HOME environment variable is not defined correctly"
  echo "This environment variable is needed to run this program"
  exit 1
fi
 
#Find the configuration directory: GEOSERVER_DATA_DIR
if [ -z $GEOSERVER_DATA_DIR ]; then
    if [ -r "$GEOSERVER_HOME"/data_dir ]; then
        export GEOSERVER_DATA_DIR="$GEOSERVER_HOME"/data_dir
    else
        echo "No GEOSERVER_DATA_DIR found, using application defaults"
	      GEOSERVER_DATA_DIR=""
    fi
fi
 
cd "$GEOSERVER_HOME"
 
if [ -z $MARLIN_JAR]; then
    export MARLIN_JAR=`find \`pwd\`/webapps -name "marlin*.jar" | head -1`
fi
export MARLIN_ENABLER="-Xbootclasspath/a:$MARLIN_JAR -Dsun.java2d.renderer=org.marlin.pisces.MarlinRenderingEngine"
 
echo "GEOSERVER DATA DIR is $GEOSERVER_DATA_DIR"
#added headless to true by default, if this messes anyone up let the list
#know and we can change it back, but it seems like it won't hurt -ch
exec "$_RUNJAVA" $JAVA_OPTS $MARLIN_ENABLER -DGEOSERVER_DATA_DIR="$GEOSERVER_DATA_DIR" -Djava.awt.headless=true -DSTOP.PORT=8079 -DSTOP.KEY=geoserver -jar start.jar

Là, on peut observer qu'en définissant à l'extérieur la variable d'environnement :

Code:

export JAVA_OPTS='--add-modules java.xml.bind'

Il démarre correctement.

Donc, c'est résolu pour lui. Mais tous les autres programmes Java démarrant par des scripts se pose le même problème, s'ils ne démarrent pas directement avec un JDK 9+.
Le .sh, ici, il est bien fait. Mais pour les autres que je rencontrerai, s'ils n'ont pas un JAVA_OPTS aussi bien placé : il faudra faire un cycle de lancement et examen des classes manquantes, édition à la main du sh pour rajouter un module, jusqu'à ce que ça marche.

C'est pas si instantané que ça.

29/09/2018, 20h27
adiGuba

C'est toutefois un cas un peu particulier, car il utilise une librairie de Java EE, et donc qui ne fait pas partie de l'API standard de Java SE...

La vrai solution serait de fournir une implémentation avec le programme.

Pour la grande majorité des programmes le fonctionnement reste identique qu'en Java 8 ou inférieur tant qu'on n'utilise pas les modules.
30/09/2018, 10h09
yildiz-online

Petit retour d'expérience,

je suis passé de l'oracle JDK 10.2 à openJDK 18.9 sur l'image docker utilisée dans ma chaine de build, pas de soucis pour la compilation, signature, packaging et l'upload sur maven central sur bitbucket pipeline

Ces mêmes projets, par contre échouent lors des tests unitaires (Exception in thread "main" java.lang.reflect.InvocationTargetException durant la phase test maven, invoquant surefire) sur travis CI, alors que c'est la même image docker utilisée pour les 2 CIs (mais un build sensiblement différent, jacoco:prepare-agent par exemple).

L'ensemble des répos ayant un build automatique quotidien, demain je serais fixé sur la totalité, mais à priori, tout n'est pas si simple.

Edit, un upgrade vers Jacoco 8.2 semble régler le problème, mais ça reste bancal (change log jacoco: 0.8.2 -> Experimental support for Java 11 and Java 12 class files, including JEP 12 "preview features" (GitHub #719, #738, #743)
01/10/2018, 16h21
esperanto

Inverse

Citation:

Envoyé par GLDavid

En gros, OpenJDK serait la base et norme, Oracle peut faire ce qu'il veut autour de cette base.

ça risque plutôt d'être l'inverse: tant qu'Oracle restera seul dépositaire de la spécification, c'est leur version qui sera considérée comme la base.
De plus les entreprises ont souvent tendance à installer la version d'Oracle plutôt que la version libre.
Ensuite Oracle peut très bien décider de ne plus diffuser gratuitement certaines évolutions de la spécification, de sorte que l'OpenJDK ne pourra plus suivre.

AJOUT
Et ce n'est pas que pure spéculation, il y a déjà un précédent. Quand Oracle a repris Java, une de leur premières mesures fut de ne plus fournir les protocoles de test de certification aux concurrents libres, notamment la machine virtuelle proposée par Apache.
Plus qu'à attendre que Red hat se fâche avec eux, et bientôt l'Open JDK sera considéré comme un concurrent.
01/10/2018, 18h51
Mickael_Istria

Citation:

Envoyé par esperanto

ça risque plutôt d'être l'inverse: tant qu'Oracle restera seul dépositaire de la spécification, c'est leur version qui sera considérée comme la base.
De plus les entreprises ont souvent tendance à installer la version d'Oracle plutôt que la version libre.
Ensuite Oracle peut très bien décider de ne plus diffuser gratuitement certaines évolutions de la spécification, de sorte que l'OpenJDK ne pourra plus suivre.

Des gens disaient exactement la meme chose pour Java EE il y a 7-8 ans, et en plus pretendaient que c'etait une raison de choisir Spring!
En 2018, si quqleu'un redit ca, on repond "LOL".
On peut esperer qu'en 2023, en lisant ce message, on se dira "LOL" aussi.

	Oracle	OpenJDK
Classes	Mêmes CRC que OpenJDK	Mêmes CRC que Oracle
Exécutables	java.exe et javac.exe même taille et CRC/SHA-1/MD5... que OpenJDK	java.exe et javac.exe même taille et CRC/SHA-1/MD5... que Oracle