Discussion :

[Bill Fassinou]

Le JDK 16 est déjà en cours de développement, bien que les travaux sur le JDK 15 continuent,
et devrait arriver avec la prise en charge des fonctionnalités du C++ 14

Bien que les travaux sur le JDK 15 continuent, avec une disponibilité générale prévue pour le 15 septembre, le JDK 16, son successeur, est déjà en cours de développement. Le site Web de l’OpenJDK dédié à cet exercice recense désormais 3 JEP (JDK Enhancement Proposals). Prévu pour mars 2021, le JDK 16 devrait arriver avec la prise en charge des fonctionnalités du C++ 14 dans le code source C++ du JDK. La communauté de l’OpenJDK prévoit également de migrer les référentiels de code source OpenJDK de Mercurial vers Git (GitHub) pour diverses raisons.

Activation des fonctionnalités du langage C++ 14

Selon la description donnée par le JEP 347, ce changement vise l'utilisation des fonctionnalités du C++ 14 dans le code source C++ du JDK et à donner des indications spécifiques sur les fonctionnalités qui peuvent être utilisées dans le code de la VM HotSpot. Par le biais du JDK 15, les caractéristiques du langage utilisées par le code C++ dans le JDK ont été limitées aux normes du langage C++ 98/03. Avec le JDK 11, le code source a été mis à jour pour permettre la construction avec des versions plus récentes du standard C++.

Cela inclut la possibilité de construire avec des versions récentes de compilateurs qui prennent en charge les caractéristiques du langage C++ 11/14. La présente proposition ne propose aucun changement de style ou d'usage pour le code C++ utilisé en dehors du HotSpot. Les règles sont déjà différentes pour le code du HotSpot et pour le code non HotSpot. À titre d’exemple, les exceptions C++ sont utilisées dans certains codes non HotSpot. Par contre, elles sont interdites dans HotSpot par les options de compilation.

Cependant, les exigences de cohérence de la construction rendront les nouvelles fonctionnalités du langage disponibles pour une utilisation dans tout le code C++ du JDK. Ensuite, pour tirer profit des fonctionnalités du langage C++, certaines modifications doivent être apportées au fil du temps, les détails dépendant du compilateur de la plateforme. Les versions minimales acceptables des différents compilateurs de plateforme doivent également être spécifiées. Le standard de langage souhaité doit être spécifié explicitement.

Migration des dépôts de code source OpenJDK de Mercurial vers Git

Le développement du JDK 16 se fera en même temps que la migration des référentiels de code source de la communauté OpenJDK de Mercurial (hg) vers Git. Le JEP 357 donne plusieurs raisons à cela. L’une d’entre elles est que les premiers prototypes de dépôts convertis montrent une réduction significative de la taille des métadonnées de contrôle de version. Par exemple, le répertoire .git du dépôt jdk/jdk est d'environ 300 Mo avec Git et le répertoire .hg est d'environ 1,2 Go avec Mercurial, selon la version de Mercurial utilisée, ce qui présente plusieurs avantages.

Le JEP 357 indique que cette réduction des métadonnées préserve l'espace disque local et réduit les temps de clonage, car moins de bits doivent passer par le fil. Git comporte également des clones peu profonds qui ne clonent que des parties de l'historique, ce qui permet de réduire encore les métadonnées pour les utilisateurs qui n'ont pas besoin de l'historique complet. Ainsi, l’objectif de cette action est de migrer tous les projets OpenJDK à dépôt unique de Mercurial vers Git, conserver l'historique du contrôle des versions, y compris les balises, reformater les messages d'engagement selon les meilleures pratiques de Git, porter les outils jcheck, webrev et defpath vers Git et créer un outil de traduction entre les hachages Mercurial et Git.

La migration vers GitHub

La migration vers GitHub est liée à la migration de Mercurial vers Git, avec des dépôts de code source JDK 16 qui seront sur le populaire site de partage de code. Mais pourquoi GitHub ? Le JEP 369 indique que la motivation pour choisir GitHub est qu'il excelle dans les trois principales raisons de choisir un fournisseur externe. Les performances de GitHub sont aussi bonnes, voire supérieures à celles des autres fournisseurs, c'est le plus grand service d'hébergement de code source au monde (50 millions d'utilisateurs en mai 2020), et il possède l'une des API les plus complètes.

Ce choix est aussi motivé par l'API étendue de GitHub qui permet la prise en charge de nombreux outils, notamment des éditeurs de texte, des EDI, des outils de ligne de commande et des clients de bureau graphique. Les versions préliminaires du JDK 16 pour Linux, Windows et macOS sont disponibles à l'adresse jdk.java.net. Comme le JDK 15, le JDK 16 sera une version à court terme, supportée pendant six mois. Le JDK 17, prévu pour septembre 2021, sera une version de support à long terme (LTS) qui bénéficiera d'un support pendant plusieurs années. La version actuelle du LTS, le JDK 11, est sortie en septembre 2018.

Source : Site de l’OpenJDK

Et vous ?

Qu'en pensez-vous ?

Voir aussi

Java 15 est déjà sur les rails : la prochaine version standard ajoutera des blocs de texte et des Garbage Collectors et supprimera le moteur JavaScript Nashorn

Java 14 est disponible en version définitive avec de nouvelles fonctionnalités de productivité des développeurs, dont Switch Expressions, Records et autres

JDK 14 va apporter plus de fonctionnalités que les deux versions précédentes combinées. Petit tour d'horizon sur celles qui sont susceptibles d'intéresser le plus les développeurs

Le JDK 9 va supporter la compilation anticipée (AOT) en commençant par les systèmes Linux 64-bit exécutant Java 64-bit

[Michael Guilloux]

Oracle annonce la disponibilité de Java 16
Tour d'horizon des nouvelles fonctionnalités et améliorations du JDK

Oracle annonce la disponibilité de Java 16 avec 17 nouveautés (JEP) visant à améliorer la productivité des développeurs. La dernière version du Java Development Kit (JDK) intègre la finalisation des enregistrements et du filtrage par motif (Pattern Matching) pour l'opérateur instanceof, ainsi que des améliorations du langage présentées en préversion dans Java 14. Les développeurs pourront également utiliser le nouvel outil de packaging pour livrer des applications Java autocontenues, mais aussi découvrir trois interfaces de programmation en incubation : l'API Vecteur, l'API d'édition de liens étrangers et l'API d'accès à la mémoire étrangère. Il y a en outre une fonctionnalité qui est disponible en préversion : les classes scellées.

Oracle publie tous les six mois des mises à jour de Java afin que les développeurs puissent s'appuyer sur un calendrier de sorties prévisible. Les innovations sortent à un rythme soutenu pour améliorer constamment la performance, la stabilité et la sécurité, et contribuer à la diffusion de Java dans toutes les entreprises de tous les secteurs d'activité, quelle que soit leur taille.

Ainsi, après un semestre de collaboration intense entre les ingénieurs Oracle et les membres de la communauté Java, le JDK 16 est disponible avec son lot de nouveautés : ont été intégrées 17 propositions d'améliorations (JEP) relatives au langage, aux outils, à la gestion de la mémoire, avec de nouvelles fonctionnalités en statut incubation ou préversion.

Améliorations du langage présentées dans JDK 14 et finalisées dans JDK 16

• JEP 394 : le filtrage par motif (Pattern Matching) pour l'opérateur instanceof.
  
  
• JEP 395 : les enregistrements (Records)[/B], qui peuvent être vus comme des tuples nominaux.

Un nouvel outil pour améliorer la productivité des développeurs

• JEP 392 : un outil de packaging, jpackage, pour packager des applications Java autocontenues.

Améliorations de la gestion de la mémoire pour augmenter encore les performances

• JEP 387 : métaespace élastique. Cela permet de restituer plus rapidement au système d'exploitation la mémoire classe-métadonnées HotSpot inutilisée (c'est-à-dire le métaespace, ou metaspace), diminuer l'empreinte du métaespace et simplifier le code du métaespace pour réduire les coûts de maintenance.
  
  
• JEP 376 : traitement simultané de la pile de threads de ZGC. Il s'agissait ici de déplacer le traitement de la pile de threads de ZGC des points de sécurité (safepoints) vers une phase concurrente.

Amélioration du réseau pour renforcer la souplesse et la productivité des développeurs

• JEP 380 : les canaux des sockets de domaine UNIX. L'amélioration consiste à ajouter le support de toutes les fonctionnalités des sockets de domaine Unix (communes à Windows et aux plus grandes plateformes Unix) aux API de canaux de socket et de canaux de socket serveur dans le package java.nio.channels. Les sockets de domaine Unix sont utilisées pour les communications interprocessus (IPC) sur le même hôte. Elles sont en de nombreux points comparables aux sockets TCP/IP, sauf qu'elles sont adressées par des noms de chemin du système de fichiers plutôt que par des adresses et des numéros de port Internet Protocol (IP).

Traitement du code incompatible avec les évolutions futures

• JEP 396 : encapsulage fort des internes du JDK par défaut. Dans le JDK 9, Oracle avait encapsulé fortement les nouveaux éléments de l'API interne, afin d'en limiter l'accès. Cependant, pour faciliter la migration, JDK 9 avait délibérément choisi de ne pas encapsuler fortement à l'exécution le contenu des packages qui existaient dans JDK 8. JDK 16 restreint cette contrainte en encapsulant par défaut la plupart des éléments internes du JDK, sauf pour des API internes critiques telles que sun.misc.Unsafe. Les utilisateurs finaux peuvent toujours choisir l'encapsulation forte plus légère qui était le comportement par défaut depuis JDK 9. Cette solution encourage les développeurs à migrer de l'utilisation d'éléments internes à l'utilisation des API standards, afin qu'eux-mêmes et leurs utilisateurs puissent passer sans problème aux futures versions de Java.
  
  
• JEP 390 : avertissements pour les classes basées sur des valeurs. La proposition ici était de désigner les classes enveloppantes primitives comme étant basées sur des valeurs et déprécier leurs constructeurs pour encourager leur suppression, en générant de nouveaux avertissements de dépréciation. Cette version génère des avertissements de tentatives inappropriées de synchronisation sur des instances de toute classe basée sur des valeurs dans la plateforme Java.

Fonctionnalités en statut d'incubation ou en préversion

• JEP 338 : API Vecteur. Cette fonctionnalité fournit une itération initiale d'un module en incubation, jdk.incubator.vector, pour exprimer des calculs de vecteurs se compilant de façon fiable à l'exécution vers des instructions matérielles optimales de vecteurs sur les architectures CPU supportées.
  
  
• JEP 389 : API d'édition de liens étrangers (Foreign Linker API). Cette fonctionnalité en statut d'incubation introduit une API offrant un accès au code natif pur Java typé statiquement.
  
  
• JEP 393 : API d'accès à la mémoire étrangère (Foreign-Memory Access API). Cette fonctionnalité également en statut d'incubation introduit une API permettant aux programmes Java d'accéder de façon sure et efficace à la mémoire étrangère à l'extérieur du heap Java.
  
  
• JEP 397 : Classes scellées (préversion). Cette nouveauté enrichit le langage de programmation Java avec des classes et interfaces scellées. Les classes et interfaces scellées restreignent les autres classes ou interfaces qui pourront les étendre ou les implémenter.

Améliorations pour les contributeurs d'OpenJDK

• JEP 347 : activation des fonctionnalités du langage C++14 (dans le code source du JDK). Cette amélioration vise à permettre l'utilisation des fonctionnalités du langage C++14 dans le code source C++ du JDK, et formuler des recommandations précises sur les fonctionnalités qui peuvent être utilisées dans le code HotSpot.
  
  
• JEP 357 : migration de Mercurial vers Git. Il s'agissait ici de migrer les référentiels de codes sources de la communauté OpenJDK depuis Mercurial (hg) vers Git.
  
  
• JEP 369 : migration vers GitHub (hébergement des référentiels Git de la communauté OpenJDK sur GitHub).

De nouveaux portages pour le support de Java sur encore plus de plateformes

• JEP 386 : portage du JDK sur Alpine Linux et sur d'autres distributions Linux utilisant musl comme bibliothèque C primaire, sur les deux architectures x64 et AArch64.
  
  
• JEP 388 : portage du JDK sur Windows/Aarch64

Selon Georges Saab, Vice-Président d'Oracle en charge du développement de la plateforme Java, cette dernière version démontre toute la puissance de ce rythme semestriel. « Le filtrage par motif et les enregistrements étaient apparus pour la première fois il y a un an avec le JDK 14, ils ont, depuis, intégré plusieurs cycles de commentaires de la communauté basés sur leur utilisation dans des applications opérationnelles. Ce processus a permis aux développeurs Java d'expérimenter ces fonctionnalités avant leur finalisation, mais il a aussi permis de tenir compte de ces retours essentiels pour aboutir à deux JEP solides comme le roc, qui répondent vraiment aux besoins de la communauté », dit-il. Java 16 est disponible en téléchargement pour les différentes plateformes prises en charge.

Source : Oracle, Nouveautés du JDK 16

Et vous ?

Que pensez-vous de ces nouvelles fonctionnalités et améliorations ?
Lesquelles appréciez-vous le plus ? Pourquoi ?
Quelles fonctionnalités disponibles dans les autres langages aimeriez-vous voir dans Java ?

Voir aussi :

Marquée obsolète depuis 2016, l'API Applet sera bientôt définitivement supprimée de Java, y a-t-il des raisons de regretter les applets Java ?
Alors que Java fête ses 25 ans, Oracle annonce l'arrivée de JDK 15. Cette version modernise le code existant et s'accompagne de la suppression du moteur JavaScript Nashorn
Le JDK 16 est déjà en cours de développement, bien que les travaux sur le JDK 15 continuent, et devrait arriver avec la prise en charge des fonctionnalités du C++ 14

[lvr]

Je suis un peu confus entre les version du JRE et celles du JDK.
Peut-on écrire du code avec le JDK 16 (pour par exemple profiter de fonctionnalités comme les blocs de textes) et l'exécuter avec une JRE 1.8 ?

[thelvin]

Je suis un peu confus entre les version du JRE et celles du JDK.
Peut-on écrire du code avec le JDK 16 (pour par exemple profiter de fonctionnalités comme les blocs de textes) et l'exécuter avec une JRE 1.8 ?

Non. L'inverse est possible mais c'est déjà moins étonnant. Ça veut dire qu'on peut utiliser les programmes et libs existants, sans être obligé de garder les versions de Java qui les ont faites à l'époque (et sans être obligé de se caler sur une version unique de Java pour les différentes bibliothèques.)

[walfrat]

Je suis un peu confus entre les version du JRE et celles du JDK.
Peut-on écrire du code avec le JDK 16 (pour par exemple profiter de fonctionnalités comme les blocs de textes) et l'exécuter avec une JRE 1.8 ?

Le JRE contient ce qu'il faut pour éxécuter du Java.

Je JDK contient le JRE plus ce qu'il faut pour développer en Java (le compilateur Javac par exemple). A noter que certaines technos peuvent avoir besoin du JDK pour être exécuté car elles génèrent du code automatiquement (JSP/SOAP sont des exemples de mémoire).

Il est impossible d'écrire du code incompatible avec une version précédente et de l’exécuter dessus. En revanche tu peux prendre un JDK 16, régler ton environnement en Java 8 et écrire le code en conséquence.

[esperanto]

Non. L'inverse est possible mais c'est déjà moins étonnant. Ça veut dire qu'on peut utiliser les programmes et libs existants, sans être obligé de garder les versions de Java qui les ont faites à l'époque (et sans être obligé de se caler sur une version unique de Java pour les différentes bibliothèques.)

L'inverse est possible, mais attention, pas toujours: il faut aussi que tu n'aies pas utilisé une des nombreuses librairies qu'Oracle a considéré comme obsolètes depuis la version 9, ou alors tu dois les télécharger séparément. J'ai notamment le cas pour un projet que je maintiens mais qui a une vieille dépendance à JAXB dont on peine à se débarasser parce que nous avons des dépendances à d'autres librairies qui elles ont conservé l'usage de JAXB.

[Jonathan muswil]

Quand je pense a sun vraiment 🤔🤔🤔

[walfrat]

L'inverse est possible, mais attention, pas toujours: il faut aussi que tu n'aies pas utilisé une des nombreuses librairies qu'Oracle a considéré comme obsolètes depuis la version 9, ou alors tu dois les télécharger séparément. J'ai notamment le cas pour un projet que je maintiens mais qui a une vieille dépendance à JAXB dont on peine à se débarasser parce que nous avons des dépendances à d'autres librairies qui elles ont conservé l'usage de JAXB.

Sur les cas que j'ai eu ce n'est pas vraiment difficile, j'ai passé un code Java 8 JAXB / Corba en Java 11 sans trop de soucis.

Maintenant si on tombe sur des cas ou des personnes ont utilisées des vieilles classes internes au JRE, ce sera un autre problème.

[Mister Nono]

Par expérience je me rends compte que bon nombre de professionnels migrent ou ont migré vers d'autres langages.

En effet, la réactivité de Oracle semble venir trop tard pour éviter une "hémorragie" vers d'autres horizons.

Dommage car JAVA était un bon produit du temps de Sun qui avait un dynamisme et une politique permettant de pallier aux évolutions qu'il aurait fallut faire il y a bien des années.

A+

[lvr]

Comment gérer l'hétérogénéité de la distribution du JRE pour des app grand public ?
Je constate que sous Windows c'est encore souvent la 1.8 (sans toujours une possibilité de mettre à jour (ex des PC corporate)).
Sous ma VM Xubuntu, openJdk 8 et 11 sont présents, ...
Donc j'aurais tendance à tout garder sour Java 8, tant qu'elle est supportée, et quand elle ne l'est plus, alors passer à Java 11.
C'est quoi votre approche ?

[Mister Nono]

Donc j'aurais tendance à tout garder sour Java 8, tant qu'elle est supportée, et quand elle ne l'est plus, alors passer à Java 11.
C'est quoi votre approche ?

Après près de 20 ans de bons et loyaux services, cela fait 2 ans que je ne réalise plus d'applications en JAVA et la vie est belle.

[thelvin]

Ça tombe bien, ça fait un sacré bail que Java 8 n'est plus supporté. En tout cas pas sa version canonique, fournie par Oracle. D'autres comme Coretto fournissent leur propre mouture du JDK 8 et le maintiennent encore, jurant à qui veut l'entendre que ça continuera pendant un bon moment.

Sinon, l'approche recommandée, c'est de fournir des exécutables natifs aux clients chez qui on installe pas Java nous-même. jpackager (pour faire des .exe, .msi ou équivalents MacOS et linux à partir d'un programme Java) est justement mis en avant dans cette nouvelle release. Il existait avant, et puis il y avait des alternatives tierces.

"Mais l'intérêt de Java n'est-il pas d'être indépendant des système et machine hôtes ?" Ça fait un sacré bail que Java n'est plus le seul, et les autres qui font pareil, ne distribuent que des exécutables natifs. Autrement dit, ça fait bien plus de 10 ans qu'on a compris que s'abstraire de l'hôte, ça donne de gros avantages d'architecture de conception, mais que le fait qu'à la fin le livrable binaire puisse tourner sur n'importe quelle machine ça n'a aucun intérêt. Il en existe trois, de toute façon, des machines différentes. L'abstraction précitée permet de partir du programme Java et de générer les trois binaires pour les trois machines clientes possibles, sans effort.

Quant aux cas où on a vraiment besoin d'être abstraits du système, c'est pour être capable de s'adapter aux changements d'écosystèmes qui ne préviennent pas. C'est pour les applications hébergées, pas les applications qui tournent sur un ordi de salon. Et même si c'est pas le fournisseur qui héberge, en 2019 (pardon, 2021,) les livrables de ce genre d'applis ce sont des images docker. Sur lesquelles Java entre autres est installé. Dont le fournisseur a bien évidemment lui-même choisi la version.

[walfrat]

Une autre raison pour fournir des exécutables est que cela permet de bloquer la ligne de commande aux utilisateurs lambda comme mesure de sécurité.

Car si tu livre avec un .bat, il faut autoriser la ligne de commande.

Quant aux bienfondé de bloqué la ligne de commande, je n'en sais rien

[thelvin]

Car si tu livre avec un .bat, il faut autoriser la ligne de commande.

? Curieuse idée... Il suffit de double-cliquer sur le .bat.

Et de fournir un raccourci avec icône qui se contente de lancer le .bat.

[Mister Nono]

Car si tu livre avec un .bat, il faut autoriser la ligne de commande.

On peut aussi fournir le programme sur disquette...

[lvr]

Sinon, l'approche recommandée, c'est de fournir des exécutables natifs aux clients chez qui on installe pas Java nous-même. jpackager (pour faire des .exe, .msi ou équivalents MacOS et linux à partir d'un programme Java) est justement mis en avant dans cette nouvelle release. Il existait avant, et puis il y avait des alternatives tierces.

Je crois que je vais me pencher vers .jarpackager. Mais, bon, comme mes apps sont des apps perso fait sur mon petit temps libre et que je mets à dispo de qui ça intéresse, cette hétérogénéité ne motive pas trop à partager son taf...

[lvr]

Sinon, l'approche recommandée, c'est de fournir des exécutables natifs aux clients chez qui on installe pas Java nous-même. jpackager (pour faire des .exe, .msi ou équivalents MacOS et linux à partir d'un programme Java) est justement mis en avant dans cette nouvelle release. Il existait avant, et puis il y avait des alternatives tierces.

Je suis parti vers le plugin Maven io.github.fvarrui.javapackager .
Je cale sur comment faire un exe Linux (e.g. un ".deb") sous Windows...De manière, avec javapackager, c'est possible où la seule option est de faire un ".tar.gz" ?

[walfrat]

? Curieuse idée... Il suffit de double-cliquer sur le .bat.

Et de fournir un raccourci avec icône qui se contente de lancer le .bat.

Ben d'après ce qu'on m'a rapporté, si tu interdit l'accès a cmd.exe au poste client, double clicquer sur un bat ne marche pas. Il faut donc livrer un EXE.

[bouye]

Je suis un peu confus entre les version du JRE et celles du JDK.
Peut-on écrire du code avec le JDK 16 (pour par exemple profiter de fonctionnalités comme les blocs de textes) et l'exécuter avec une JRE 1.8 ?

Le JRE n'existe plus depuis belle lurette, deal with it!

Il devrait etre possible d’écrire du code en JDK 16 pour l'executer sur du JDK/JRE (1.)8 si on se contente d'utiliser des anciennes API, aucun des ajouts apportes par les JDK 9-10-11-12-13-14-15 et 16 et avec le flag qu'il faut pour sortir du bytecode compatible JDK/JRE (1.)8. Qq chose dans le genre javac -source 1.8 -target 1.8 ... ou un truc du genre. Normalement les IDE permettent de configurer ce genre de choses.

Et sinon on vous fourni un outil pour créer des applications avec lanceur natif donc le fichier bat/script de lancement sur la ligne de commande il serait également temps de l'envoyer aux oubliettes. Bon après il va falloir aussi la signer numériquement votre app si vous voulez pas que Windows / votre antivirus envoie des alarmes a l'utilisateur...

[Uther]

Il devrait etre possible d’écrire du code en JDK 16 pour l'executer sur du JDK/JRE (1.)8 si on se contente d'utiliser des anciennes API, aucun des ajouts apportes par les JDK 9-10-11-12-13-14-15 et 16 et avec le flag qu'il faut pour sortir du bytecode compatible JDK/JRE (1.)8. Qq chose dans le genre javac -source 1.8 -target 1.8 ... ou un truc du genre. Normalement les IDE permettent de configurer ce genre de choses.

C'est possible, mais je le déconseille fortement. En faisant ça, on peut facilement utiliser sans s'en rendre compte une méthode/classe qui n'existe pas dans la version ciblée. Du coup, on se retrouve, avec un code qui compile et fonctionne bien sur l'environnement de développement, mais qui plantera à l'exécution sur l'environnement final, parfois de manière sournoise.

Il est généralement plus prudent d'utiliser le JDK qui correspond à la version minimale ciblée.