IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Michael Guilloux

275PARTAGES

12  0 
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de thelvin
Modérateur https://www.developpez.com
Le 18/03/2021 à 16:02
Ç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.
1  1 
Avatar de thelvin
Modérateur https://www.developpez.com
Le 18/03/2021 à 18:20
Citation Envoyé par walfrat Voir le message
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.
1  1 
Avatar de lvr
Membre extrêmement actif https://www.developpez.com
Le 18/03/2021 à 21:39
Citation Envoyé par thelvin Voir le message
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...
0  0 
Avatar de lvr
Membre extrêmement actif https://www.developpez.com
Le 21/03/2021 à 22:13
Citation Envoyé par thelvin Voir le message
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" ?
0  0 
Avatar de walfrat
Membre expérimenté https://www.developpez.com
Le 19/04/2021 à 15:47
Citation Envoyé par thelvin Voir le message
? 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.
0  0 
Avatar de bouye
Rédacteur/Modérateur https://www.developpez.com
Le 21/04/2021 à 0:51
Citation Envoyé par lvr Voir le message
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...
0  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 24/04/2021 à 7:03
Citation Envoyé par bouye Voir le message
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.
0  0 
Avatar de lvr
Membre extrêmement actif https://www.developpez.com
Le 17/03/2021 à 11:27
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 ?
0  1 
Avatar de Jonathan muswil
Membre à l'essai https://www.developpez.com
Le 17/03/2021 à 18:47
Quand je pense a sun vraiment 🤔🤔🤔
1  2 
Avatar de lvr
Membre extrêmement actif https://www.developpez.com
Le 18/03/2021 à 15:41
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 ?
0  1