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 !

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

Le , par Stan Adkens

141PARTAGES

8  0 
Alors que la dernière version définitive du kit de développement Java (JDK) d’Oracle est sortie il y a moins d’un mois, les travaux pour la mise en œuvre de son successeur, Java 15, prévu pour le remplacer en septembre 2020, sont déjà lancés. Et jusqu'à présent, deux changements officiels - l'ajout de blocs de texte et la suppression du moteur JavaScript Nashorn - ciblent la version 15 de JDK. Tandis que trois autres propositions de changements - l'ajout de la fonctionnalité Hidden Classes, des Garbage Collectors Z et Shenandoah - sont encore en examen afin de cibler également la dernière version du JDK.


Même si la page officielle de l'OpenJDK n’en parle pas encore, la page de proposition de l'OpenJDK indique que le JDK 15 est la version cible de ces propositions de changements. Les cinq propositions (si celles qui sont en examen sont validées) devraient être des fonctionnalités officielles pour le kit de développement Java (JDK) 15, qui est la base de la prochaine version de Java SE (édition standard). Voici, ci-dessous, les spécificités de ces propositions d’amélioration :

Des blocs de texte pour une meilleure lisibilité de chaînes de caractères

Les blocs de texte sont destinés à simplifier la tâche d'écriture des programmes Java en facilitant l'expression de chaînes de caractères couvrant plusieurs lignes de code source, tout en évitant les séquences d'échappement dans les cas courants. Un bloc de texte est une chaîne littérale de plusieurs lignes qui évite la plupart des séquences d'échappement, formate automatiquement la chaîne de manière prévisible et offre au développeur le contrôle du format lorsqu'il le souhaite.

Les blocs de texte ont été proposés par le JEP 355 au début de 2019 et ont été ajoutés en prévisualisation au JDK 13 en juin 2019. Les réactions au JDK 13 ont suggéré qu’ils devaient demeurer en prévisualisation, avec des mises à jour, sur le JDK 14 en novembre 2019. Les commentaires sur le JDK 14 suggèrent que la fonction Text Blocks est maintenant prête à être rendue définitive et permanente, selon la page de proposition de l’OpenJDK.

L'un des objectifs de la proposition de blocs de texte est d'améliorer la lisibilité des chaînes dans les programmes Java qui indiquent du code écrit dans des langages autres que Java. Un autre objectif est de soutenir la migration à partir de chaînes de caractères littérales en stipulant que toute nouvelle construction peut exprimer le même ensemble de chaînes de caractères qu'une chaîne littérale, interpréter les mêmes séquences d'échappement et être manipulée de la même manière qu'une chaîne littérale. Les développeurs d'OpenJDK espèrent ajouter des séquences d'échappement pour gérer les espaces blancs explicites et le contrôle des nouvelles lignes.

La suppression du moteur JavaScript Nashorn

Le retrait de Nashorn, qui a fait ses débuts dans le JDK 8 en mars 2014, a depuis été rendu obsolète par des technologies telles que GraalVM. La proposition de l'OpenJDK 15 prévoit la suppression des API de Nashorn et de l'outil de ligne de commande jjs utilisé pour invoquer Nashorn. Selon la page de proposition de l’OpenJDK, le moteur, les API et l'outil avaient été dépréciés dans Java 11 avec l'intention expresse de les supprimer dans une prochaine version. Comme déjà indiqué plus haut, certaines propositions de changements sont toujours en examen, telles que :

L’ajout de Z Garbage Collector (ZGC)

Son intégration dans JDK 15 la ferait passer d'une fonctionnalité expérimentale à un produit définitif dans le cadre de cette proposition. Arrivé par le JEP 333 et intégré dans le JDK 11, qui est arrivé en septembre 2018, le ZGC est un Collector évolutif et à faible latence, d’après la page de proposition. Le ZGC a été introduit à titre expérimental à l’époque parce que les développeurs de Java ont décidé qu'une fonctionnalité de cette taille et de cette complexité devait être introduite avec précaution et de manière progressive.

Depuis lors, un certain nombre d'améliorations ont été ajoutées, allant du déchargement simultané des classes, du désengagement de la mémoire inutilisée et de la prise en charge du partage des classes de données à une meilleure sensibilisation à NUMA et au pré-touchement de tas multi-thread. De plus, la taille maximale du tas a été augmentée de quatre téraoctets à 16 téraoctets. Les plateformes prises en charge par ce changement, selon la page de proposition, sont Linux, Windows et MacOS.

L’ajout du Garbage Collector Shenandoah

L’ajout du Garbage Collector Shenandoah à faible temps de pause dans le cadre de cette proposition ferait de cette fonctionnalité un élément de production et sortirait du stade expérimental. Le GC Shenandoah a été intégré au JDK 12 par le JEP 189. Il a été marqué comme expérimental afin de correspondre au statut d'autres nouveaux GC, notamment les GC Epsilon et ZGC. Aujourd'hui, Shenandoah est prête à abandonner son statut expérimental dans les principaux JDK.

L’ajout des Hidden Classes

Les Hidden Classes sont des classes qui ne peuvent pas être utilisées directement par le bytecode d'autres classes. Ces fonctionnalités, qui seront introduites dans Java 15, sont destinées à être utilisées par des frameworks qui génèrent des classes à l'exécution et les utilisent indirectement. Une Hidden Class peut être définie comme un membre d'une niche de contrôle d'accès et peut être déchargée indépendamment des autres classes.

L’ajout de cette fonctionnalité a été motivé, entre autres, par le fait que de nombreuses implémentations de langage construites sur la JVM reposent sur la génération dynamique de classes pour plus de flexibilité et d'efficacité, d’après la page de proposition. « Par exemple, dans le cas du langage Java, javac ne traduit pas une expression lambda dans un fichier de classe dédié au moment de la compilation mais, au contraire, émet un bytecode qui génère et instancie dynamiquement une classe pour produire un objet correspondant à l'expression lambda lorsque cela est nécessaire », lit-on sur la page.

Les premières versions builds du JDK 15 sont disponibles à l'adresse java.jdk.net. Le JDK 15 aura le statut de version de fonctionnalité à court terme, elle sera donc supportée pendant six mois, soit jusqu’en mars 2021, selon la cadence de livraison dite « non-LTS » d'Oracle. La prochaine version de support à long terme (LTS), qui bénéficiera de plusieurs années de support, sera la version JDK 17, prévue pour septembre 2021.

Source : OpenJDK

Et vous ?

Que pensez-vous de ces propositions de fonctionnalités officielles pour Java 15 ?

Lire aussi

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

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

Avatar de Levure
Membre du Club https://www.developpez.com
Le 17/09/2020 à 10:41
Citation Envoyé par bouye Voir le message
Hum, du coup c'est pas bien clair, mais suite au retrait de Nashorn, il n'est plus possible de faire tourner du JavaScript sur la JVM en standard ? Il faut utiliser une lib tierce implémentant le scripting engine (JSR-223) pour JavaScript ?
En réalité, la fonctionnalité est toujours là : le moteur Nashorn est simplement remplacé par GraalVM.
L'avantage est qu'on ne sera plus limité à utiliser de l'ECMAScript 5.1 car GraalVM supporte déjà ECMAScript 2019 et une bonne partie d'ECMAScript 2020.

Sinon, il y a très peu de changement à prévoir dans le code, ça se limitera à remplacer le nom du moteur dans la méthode
Code : Sélectionner tout
getEngineByName()
.
2  0 
Avatar de bouye
Rédacteur/Modérateur https://www.developpez.com
Le 17/09/2020 à 0:49
Les contributeurs de Tencent ? Ils ont pas peur des retours de la Maison Blanche ?

Hum, du coup c'est pas bien clair, mais suite au retrait de Nashorn, il n'est plus possible de faire tourner du JavaScript sur la JVM en standard ? Il faut utiliser une lib tierce implémentant le scripting engine (JSR-223) pour JavaScript ?

Quels sont les changements de syntaxe apporte sur instanceof et Record par rapport au JDK 14 ?

Ça fait longtemps que je ne suis plus l’actualité des UNIX mais dois-je en déduire que Solaris c'est définitivement fini, Oracle l'a jeté a la poubelle ?

A noter que JavaFX 15 est sorti il y a 2 jours pour accompagner le lancement de ce nouveau JDK.
0  0