Discussion :

[Stéphane le calme]

JDK 20 : la prochaine version de Java standard embarque six fonctionnalités phares parmi lesquelles Scoped Values,
une API qui permet de partager des données immuables au sein d'un même thread ou entre plusieurs threads

Java 20, ou Java Development Kit (JDK) 20, la prochaine version prévue de Java standard, a atteint le stade de la Release Candidate, après avoir achevé les phases Rampdown. Au total, ce sont six fonctionnalités qui sont prévues pour cette itération, notamment Scoped Values, Record Patterns, Pattern Matching for switch, Foreign Function & Memory API, Virtual Threads, Structured Concurrency. Pour l'instant, elles sont soit au stade d'incubation, soit au stade d'aperçu.

Java 20 est passé à la phase de release candidate le 9 février, selon un bulletin de Mark Reinhold d'Oracle, architecte en chef du Java Platform Group. Une deuxième version candidate est prévue pour le 23 février. La disponibilité générale du JDK est prévue pour le 21 mars 2023, dans le cadre de la cadence de publication de six mois d'Oracle pour les éditions Java standard. Pour JDK 20, les développeurs sont encouragés à signaler les bogues via la base dédiée. La période qui s’ouvre doit permettre aux contributeurs de tester, identifier et corriger de nouvelles failles, dans le cadre d’un processus strict et ce avant publication de la version de production.

Les principales fonctionnalités attendues dans JDK 20 :

Scoped values

Cette API en phase d'incubation permet de partager des données immuables au sein d'un même thread ou entre plusieurs threads. Ces valeurs sont préférables aux variables locales aux threads, en particulier quand on utilise un grand nombre de threads virtuels. Scope Value permet de partager des données de manière sûre et efficace entre les composants d'un grand programme sans recourir aux arguments de méthode.

Les objectifs :

• Facilité d'utilisation : fournissez un modèle de programmation pour partager des données à la fois au sein d'un thread et avec des threads enfants, afin de simplifier le raisonnement sur le flux de données.
• Compréhensibilité : rendre visible la durée de vie des données partagées à partir de la structure syntaxique du code.
• Robustesse : assurez-vous que les données partagées par un appelant ne peuvent être récupérées que par des appelés légitimes.
• Performances : traitez les données partagées comme immuables afin de permettre le partage par un grand nombre de threads et d'activer les optimisations d'exécution.

Non-objectifs :

• Ce n'est pas un objectif de changer le langage de programmation Java.
• L'objectif n'est pas d'exiger une migration à partir des variables locales de thread ou de déprécier l'API ThreadLocal existante.

Pour en expliquer la motivation, l'équipe rapporte que les grands programmes Java sont généralement constitués de composants distincts et complémentaires qui doivent partager des données entre eux. Par exemple, une infrastructure Web peut inclure un composant serveur, implémenté dans le style thread par demande, et un composant d'accès aux données, qui gère la persistance. Dans tout le framework, l'authentification et l'autorisation des utilisateurs reposent sur un objet Principal partagé entre les composants. Le composant serveur crée un principal pour chaque thread qui gère une demande, et le composant d'accès aux données fait référence au principal d'un thread pour contrôler l'accès à la base de données.

Normalement, les données sont partagées entre l'appelant et l'appelé en les transmettant comme arguments de méthode, mais cela n'est pas viable pour un principal partagé entre le composant serveur et le composant d'accès aux données car le composant serveur appelle d'abord le code utilisateur non approuvé. Nous avons besoin d'un meilleur moyen de partager les données du composant serveur vers le composant d'accès aux données plutôt que de les connecter à une cascade d'invocations de méthodes non fiables.

Record Patterns

Disponibles en seconde preview, les Record Patterns améliorent le langage de programmation Java avec des motifs pour déconstruire les valeurs d'enregistrement Record Values. Les motifs d'enregistrement (record patterns) et les motifs de type (type patterns) peuvent être imbriqués pour permettre une forme déclarative, puissante et composable de navigation et de traitement des données.

Pour être plus précis, les Record Patterns ont été proposés en tant que fonction en preview par JEP 405 et livrés dans JDK 19. Ce JEP propose une deuxième preview avec d'autres améliorations basées sur l'expérience et les commentaires continus.

Les principaux changements depuis la première preview sont les suivants*:

• Ajout de la prise en charge de l'inférence des arguments de type des modèles d'enregistrement génériques,
• Ajout de la prise en charge des modèles d'enregistrement pour qu'ils apparaissent dans l'en-tête d'une instruction for améliorée, et
• Suppression de la prise en charge des modèles d'enregistrement nommés.

Les objectifs sont d'étendre le filtrage de motifs pour exprimer des requêtes de données plus sophistiquées et composables, sans modifier la syntaxe ou la sémantique des motifs de type. Parmi les principales modifications apportées depuis le premier aperçu livré avec le JDK 19, on peut citer le support de l’inférence du type paramétré pour les patterns de record generic, le support des record patterns dans les boucles for (enhanced for statements) et la suppression du support des patterns de record nommés.

Pour en expliquer les motivations, l'équipe explique que dans JDK 16, JEP 394 a étendu l'opérateur instanceof pour prendre un modèle de type et effectuer une correspondance de modèle. Cette extension modeste permet de simplifier l'idiome familier instanceof-and-cast*:

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
// Old code
if (obj instanceof String) {
    String s = (String)obj;
    ... use s ...
}
 
// New code
if (obj instanceof String s) {
    ... use s ...
}

Dans le nouveau code, obj correspond au modèle de type String s si, au moment de l'exécution, la valeur de obj est une instance de String. Si le modèle correspond, l'expression instanceof est true et la variable de modèle s est initialisée à la valeur de obj convertie en chaîne, qui peut ensuite être utilisée dans le bloc contenu.

Dans JDK 17, JDK 18 et JDK 19, l'équipe a étendu l'utilisation des modèles de type pour changer également les étiquettes de casse, via JEP 406, JEP 420 et JEP 427.

Les modèles de type suppriment de nombreuses occurrences de casting (une méthode ou un processus qui convertit un type de données en un autre type de données dans les deux sens manuellement et automatiquement) d'un coup. Cependant, ils ne sont que la première étape vers un style de programmation plus déclaratif et axé sur les données. Comme Java prend en charge de nouvelles façons plus expressives de modéliser les données, la correspondance de modèles peut rationaliser l'utilisation de ces données en permettant aux développeurs d'exprimer l'intention sémantique de leurs modèles.

Foreign function and memory API

En seconde preview également, cette API permet aux programmes Java d’interagir avec du code et des données en dehors du runtime Java, notamment aux applications Java d'appeler des bibliothèques natives et de traiter des données natives sans la fragilité et les risques de la JNI (Java Native Interface).

L'API Foreign Function & Memory (FFM) combine deux API d'incubation antérieures*: l'API Foreign-Memory Access (JEP 370, 383 et 393) et l'API Foreign Linker (JEP 389). L'API FFM a été incubée dans JDK 17 via JEP 412, elle a été ré-incubée dans JDK 18 via JEP 419, et elle a été proposée en préversion pour la première fois dans JDK 19 via JEP 424. Cette JEP propose d'incorporer des améliorations basées sur les commentaires et de proposer en seconde preview l'API dans JDK 20. Dans cette version*:

• Les abstractions MemorySegment et MemoryAddress sont unifiées (les adresses mémoire sont désormais modélisées par des segments mémoire de longueur nulle) ;
• La hiérarchie scellée MemoryLayout est améliorée pour faciliter l'utilisation avec la correspondance de modèles dans les expressions et instructions switch (JEP 433), et
• MemorySession a été divisé en Arena et SegmentScope pour faciliter le partage de segments au-delà des limites de maintenance.

Les objectifs :

• Facilité d'utilisation : remplacer l'interface native Java (JNI) par un modèle de développement Java pur supérieur.
• Performances : fournit des performances comparables, voire supérieures, aux API existantes telles que JNI et sun.misc.Unsafe.
• Généralité : fournit des moyens d'opérer sur différents types de mémoire étrangère (par exemple, la mémoire native, la mémoire persistante et la mémoire de tas gérée) et, au fil du temps, de prendre en charge d'autres plates-formes (par exemple, 32 bits x86) et des fonctions étrangères écrites dans d'autres langages que C (par exemple, C++, Fortran).
• Sécurité : autoriser les programmes à effectuer des opérations non sécurisées sur la mémoire étrangère, mais avertir les utilisateurs de ces opérations par défaut.

Cette API n'a pas pour objectif de :

• réimplémenter JNI en plus de cette API, ou modifier JNI de quelque manière que ce soit*;
• réimplémenter les anciennes API Java, telles que sun.misc.Unsafe, en plus de cette API*;
• fournir des outils qui génèrent mécaniquement du code Java à partir de fichiers d'en-tête de code natif*; ou
• modifier la manière dont les applications Java qui interagissent avec les bibliothèques natives sont empaquetées et déployées (par exemple, via des fichiers JAR multiplateformes).

Qu'est-ce qui a motivé son développement ? La plate-forme Java a toujours offert une base riche aux développeurs de bibliothèques et d'applications qui souhaitent aller au-delà de la JVM et interagir avec d'autres plates-formes. Les API Java exposent des ressources non Java de manière pratique et fiable, que ce soit pour accéder à des données distantes (JDBC), appeler des services Web (client HTTP), servir des clients distants (canaux NIO) ou communiquer avec des processus locaux (sockets de domaine Unix). Malheureusement, les développeurs Java sont toujours confrontés à des obstacles importants pour accéder à un type important de ressources non Java*: le code et les données sur la même machine que la JVM, mais en dehors de l'environnement d'exécution Java.

Virtual threads

En seconde preview, les Virtual threads sont des threads légers qui demandent moins d'effort d'écriture, de maintenance et d'observation des applications concurrentes à haut débit. Depuis le premier aperçu livré avec le JDK 19, l'API a connu des changements mineurs (quelques modifications rendues dans l’API permanentes dans le JDK 19) et des dégradations de ThreadGroup (également rendues permanentes dans le JDK 19).

Les objectifs :

• activer les applications serveur écrites dans le style simple thread par demande pour évoluer avec une utilisation matérielle quasi optimale.
• activer le code existant qui utilise l'API java.lang.Thread pour adopter des threads virtuels avec un minimum de modifications.
• faciliter le dépannage, le débogage et le profilage des threads virtuels avec les outils JDK existants.

Les développeurs Java se sont appuyés sur les threads comme élément de base des applications serveur simultanées pendant près de trois décennies. Chaque instruction de chaque méthode est exécutée à l'intérieur d'un thread et, puisque Java est multithread, plusieurs threads d'exécution se produisent en même temps. Le thread est l'unité de simultanéité de Java : un morceau de code séquentiel qui s'exécute en même temps que — et largement indépendamment — d'autres unités de ce type. Chaque thread fournit une pile pour stocker les variables locales et coordonner les appels de méthode, ainsi que le contexte lorsque les choses tournent mal*: les exceptions sont levées et interceptées par les méthodes du même thread, de sorte que les développeurs peuvent utiliser la trace de la pile d'un thread pour découvrir ce qui s'est passé. Les threads sont également un concept central pour les outils*: les débogueurs parcourent les instructions dans les méthodes d'un thread et les profileurs visualisent le comportement de plusieurs threads pour aider à comprendre leurs performances.

Structured Concurrency

Cette API vient simplifier la programmation multithread et traite plusieurs tâches exécutées dans différents threads comme une seule unité de travail. La gestion et l'annulation des erreurs sont rationalisées, ce qui améliore la fiabilité et l'observabilité. Le seul changement depuis son incubation dans le JDK 19 est que StructuredTaskScope a été mis à jour pour prendre en charge l'héritage des Scoped Values par les threads créés dans la portée d'une tâche. Cette fonctionnalité est en cours de réincubation.

Les développeurs gèrent la complexité en décomposant les tâches en plusieurs sous-tâches. Dans le code monothread ordinaire, les sous-tâches s'exécutent séquentiellement. Cependant, si les sous-tâches sont suffisamment indépendantes les unes des autres et s'il y a suffisamment de ressources matérielles, la tâche globale peut être exécutée plus rapidement (c'est-à-dire avec une latence plus faible) en exécutant les sous-tâches simultanément. Par exemple, une tâche qui compose les résultats de plusieurs opérations d'E/S s'exécutera plus rapidement si chaque opération d'E/S s'exécute simultanément dans son propre thread. Les threads virtuels (JEP 425) rendent rentable le fait de dédier un thread à chacune de ces opérations d'E/S, mais la gestion du grand nombre de threads qui peuvent en résulter reste un défi.

Correspondance de modèles pour les expressions et déclarations switch

En quatrième préversion (elle était déjà présente dans les JDK 17, JDK 18 et JDK 19), la fonctionnalité permet l'expression concise et sûre de requêtes complexes orientées données. Elle pourra évoluer en continu avec les Record Patterns, ce qui permettra des améliorations continues basées sur l'expérience et le feedback. Parmi les principales modifications apportées au Pattern matching for switch depuis le troisième aperçu, on peut citer une grammaire simplifiée pour les étiquettes de switch et la prise en charge de l'inférence des arguments de type pour les generic patterns et les record patterns dans les déclarations et expressions de switch. De plus, un switch exhaustif sur une classe enum provoque désormais une MatchException plutôt qu'une IncompatibleClassChangeError si aucune étiquette de switch ne s'applique au moment de l'exécution.

Source : Inside Java

[Bill Fassinou]

Oracle publie Java 20 avec des fonctionnalités en incubation et en prévisualisation, dont les threads virtuels et la concurrence structurée
ainsi que des améliorations en matière de performances

Oracle a annoncé mardi la disponibilité générale de Java 20 (ou JDK 20) à l'occasion de la deuxième journée de son événement "DevLive Level Up" qui se déroule du 20 au 23 mars à Redwood Shores, en Californie, et en ligne. Le JDK 20 offre des milliers d'améliorations en matière de performances, de stabilité et de sécurité, y compris des améliorations de plateforme qui aideront les développeurs à améliorer leur productivité et à stimuler l'innovation. Cette nouvelle mouture du JDK 20 propose également des versions d'incubation ou de prévisualisation de sept nouvelles fonctionnalités, dont les threads virtuels et la concurrence structurée.

Le JDK 20, qui est une version à court terme soutenue pendant six mois, fait suite au lancement du JDK 19 le 20 septembre dernier. Le JDK 21, prévu pour septembre, sera une version de support à long terme (LTS), soutenue par plusieurs années de support. « Depuis plus de 25 ans, Java permet aux développeurs de concevoir et de réaliser la prochaine génération d'applications robustes, évolutives et sécurisées », a déclaré Georges Saab, vice-président senior du développement de la plateforme Java et président du conseil d'administration de l'OpenJDK, Oracle. Selon l'index TIOBE, Java est le troisième langage de programmation le plus utilisé au monde.

Java 20 a été développé grâce à un effort de collaboration entre les ingénieurs d'Oracle et les membres de la communauté mondiale des développeurs Java, facilité par OpenJDK et le Java Community Process (JCP). Selon Oracle, les fonctionnalités du JDK 20 sont en passe d'être normalisées. Parmi les fonctionnalités qui n'ont pas été intégrées au JDK 20, mais qui sont toujours à l'étude pour Java, citons les génériques universels, les modèles de chaînes, les collections séquencées et une API VM asynchrone de suivi de pile. Bien que Java lui-même soit open source, Oracle propose des versions commerciales à utiliser à la fois sur site et dans son cloud.

Le JDK 20 ajoute sept propositions d'amélioration qui promettent de révolutionner le langage. Selon l'équipe du JDK, ces elles sont issue du du projet OpenJDK Amber (Record Patterns et Pattern Matching for Switch) ; des améliorations issues du projet OpenJDK Panama pour interconnecter la machine virtuelle Java (JVM) et le code natif (Foreign Function & Memory API et Vector API). Les fonctionnalités de l'Irs sont liées au projet Loom (Scoped Values, Virtual Threads et Structured Concurrency), qui rationalisera considérablement le processus d'écriture, de maintenance et d'observation des applications concurrentes à haut débit. Voici de quoi il s'agit :

Mises à jour et améliorations du langage

JEP 432 : Record Patterns (deuxième préversion)

Record Patterns (motifs d'enregistrement) est une proposition qui améliore le langage Java en permettant aux utilisateurs d'imbriquer des modèles d'enregistrement et des modèles de type pour créer une forme puissante, déclarative et composable de navigation et de traitement des données. Cela permet d'augmenter la productivité des développeurs en leur permettant d'étendre la correspondance des motifs afin d'obtenir des requêtes de données plus sophistiquées et composables. Les objectifs sont d'étendre le filtrage pour exprimer des requêtes de données plus sophistiquées et composables, sans modifier la syntaxe ou la sémantique des motifs de type.

Les principales modifications apportées depuis le premier aperçu dans le JDK 19 sont les suivantes : ajout de la prise en charge de l'inférence des arguments de type des motifs d'enregistrement génériques, prise en charge des motifs d'enregistrement apparaissant dans l'en-tête d'une instruction for améliorée, et suppression de la prise en charge des motifs d'enregistrement nommés.

JEP 433 : correspondance de motifs pour Switch (quatrième aperçu)

En étendant la c de motifs à switch, une expression peut être testée par rapport à un certain nombre de motifs - chacun avec une action spécifique - de sorte que des requêtes complexes orientées données peuvent être exprimées de manière concise et sûre. L'extension de l'expressivité et de l'applicabilité des expressions et des instructions switch permet d'accroître la productivité des développeurs. Prévue dans le JDK 17, le JDK 18 et le JDK 19, cette quatrième prévisualisation permettra de poursuivre la coévolution avec les motifs d'enregistrement, ce qui permettra d'apporter des améliorations continues sur la base du retour d'information.

Les principaux changements apportés à la correspondance des motifs pour switch depuis la troisième préversion comprennent une grammaire simplifiée pour les étiquettes switch et la prise en charge de l'inférence des arguments de type pour les motifs génériques et les motifs d'enregistrement dans les déclarations et les expressions switch. De plus, un switch exhaustif sur une classe enum lève désormais MatchException au lieu de IncompatibleClassChangeError si aucune étiquette de switch ne s'applique au moment de l'exécution.

Fonctionnalités en incubation et en prévisualisation du projet Loom

JEP 429 : Scoped Values (incubation)

Selon l'équipe du projet Loom, cette proposition d'amélioration du langage est une API en phase d'incubation qui permet le partage de données immuables à l'intérieur et entre les threads, ce qui est préférable aux variables locales - en particulier lors de l'utilisation d'un grand nombre de threads virtuels. Une valeur scopée permet de partager des données de manière sûre et efficace entre les composants d'un grand programme sans avoir recours à des arguments de méthode. Les objectifs sont la facilité d'utilisation, la compréhensibilité, la robustesse et la performance.

JEP 436 : les threads virtuels (deuxième aperçu)

Cette proposition permet de rationaliser considérablement le processus d'écriture, de maintenance et d'observation des applications concurrentes à haut débit en introduisant des threads virtuels légers dans la plateforme Java. En permettant aux développeurs de dépanner, de déboguer et de profiler facilement les applications concurrentes avec les outils et techniques JDK existants, les threads virtuels contribuent à accélérer le développement d'applications.

Selon Oracle, cette capacité changera fondamentalement la façon dont les applications Java sont mises à l'échelle. Les modifications mineures apportées depuis le premier aperçu dans le JDK 19 comprennent un petit nombre de modifications de l'API (rendues permanentes dans le JDK 19) et des dégradations de ThreadGroup (également rendues permanentes dans le JDK 19).

JEP 437 : la concurrence structurée (deuxième incubation)

Cette proposition comporte une API qui simplifie la programmation multithread en traitant plusieurs tâches exécutées dans différents threads comme une seule unité de travail. La gestion et l'annulation des erreurs sont rationalisées, ce qui améliore la fiabilité et l'observabilité. Le seul changement depuis l'incubation dans le JDK 19 est que StructuredTaskScope a été mis à jour pour prendre en charge l'héritage des valeurs scopées par les threads créés dans une portée de tâche. Cette fonctionnalité est en cours de réincubation.

Aperçu des fonctionnalités du projet Panama

JEP 434 : la fonction étrangère et l'API de mémoire (deuxième aperçu)

La fonction étrangère et l'API de mémoire permettent aux programmes Java d'interagir avec le code et les données en dehors du temps d'exécution Java. En invoquant efficacement des fonctions étrangères (c'est-à-dire du code extérieur à la machine virtuelle Java [JVM]) et en accédant en toute sécurité à la mémoire étrangère (c'est-à-dire la mémoire non gérée par la JVM), cette fonctionnalité permet aux programmes Java d'appeler des bibliothèques natives et de traiter des données natives sans avoir recours à l'interface native Java. La facilité d'utilisation, les performances et la sécurité s'en trouvent accrues.

L'API permet aux programmes Java d'appeler des bibliothèques natives et de traiter des données natives sans la fragilité et le danger de JNI (Java Native Interface). L'API a été incubée dans les versions 17 et 18 du JDK et présentée en avant-première dans le JDK 19. Les améliorations apportées depuis le JDK 19 comprennent l'unification des abstractions MemorySegment et MemoryAddress, une hiérarchie MemoryLayout améliorée et la division de MemorySession en Arena et SegmentScope pour promouvoir le partage des segments à travers les limites de la maintenance.

JEP 438 : API vectorielle (cinquième incubation)

L'API vectorielle, une proposition qui n'a été officiellement ajoutée qu'il y a quelques semaines, introduirait une API pour exprimer les calculs vectoriels qui se compilent de manière fiable au moment de l'exécution en tant qu'instructions vectorielles optimales sur les architectures de CPU prises en charge. Cela permettrait d'obtenir des performances supérieures à celles des calculs scalaires équivalents. L'API vectorielle a été incubée dans les JDK 16, JDK 17, JDK 18 et JDK 19.

Sources : Java 20, Oracle

Et vous ?

Que pensez-vous des nouvelles fonctionnalités de Java 20 ?

Voir aussi

Le langage de programmation Rust gagne en popularité parmi les développeurs et fait son entrée dans le top 20, selon Tiobe. Python, Java, C et C++ s'accaparent à eux seuls de 55% de parts de marché

JDK 20 : la prochaine version de Java embarque six fonctionnalités phares parmi lesquelles Scoped Values, une API qui permet de partager des données immuables au sein d'un même thread

C++ est sacré langage de programmation de 2022 sur l'indice TIOBE. En termes de popularité, sur l'année écoulée, il est suivi respectivement par C et Python

Augmentation de la popularité de C#, selon l'indice Tiobe qui lui a observé une croissance de près de 2% au cours des 12 derniers mois, tandis que C a perdu pratiquement autant en popularité

[Padget]

Je trouve que sur ce genre d'annonces d'Oracle il manque toujours des exemples de code pour illustrer les propos. Parce que j'ai personnellement rien compris au blabla sur la preversion 2 des records...

[miaous]

Je trouve que sur ce genre d'articles il manque toujours des exemples de code pour illustrer les propos. Parce que j'ai personnellement rien compris au blabla sur la preversion 2 des records...

avec JEP 432 : Record Patterns (deuxième préversion) pour un record Point (int x, int y)
tu pourras ecrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
List<Point> points=....
for ( Point(int x, int y): points ){
System.out.println(" " +x ", " +y );
 
}

équivalent à:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
List<Point> points=....
for ( Point p: points ){
int x=p.x();
int y=p.y();
System.out.println(" " +x ", " +y );
 
}

[Stéphane le calme]

Malgré OpenJDK, 70% des correctifs et fonctionnalités Java proviennent d'Oracle,
selon des statistiques publiées par Oracle.

Oracle a publié Java 20 et affirme que depuis Java 11 en 2018, il a contribué à plus de 70 % des correctifs et des fonctionnalités, mesurés par les problèmes du système de suivi des problèmes JIRA.

« Sur les 21 604 problèmes JIRA marqués comme résolus dans Java 11 à Java 20 au moment de leur disponibilité générales, 15 420 ont été résolus par des personnes travaillant pour Oracle tandis que 6 184 ont été apportés par des développeurs individuels et des développeurs travaillant pour d'autres organisations », a déclaré la société. Dans le cas du JDK 20, 1 595 des 2 314 numéros ont été complétés par Oracle, ce qui approche les 69 %.

Plus tôt ce mois-ci, Oracle a annoncé la disponibilité générale de Java 20 (ou JDK 20). Parmi les principales fonctionnalités de JDK 20, nous pouvons citer :

• Scoped values : Cette API permet de partager des données immuables au sein d'un même thread ou entre plusieurs threads. Ces valeurs sont préférables aux variables locales aux threads, en particulier quand on utilise un grand nombre de threads virtuels. Scope Value permet de partager des données de manière sûre et efficace entre les composants d'un grand programme sans recourir aux arguments de méthode.
• Record Patterns : ils améliorent le langage de programmation Java avec des motifs pour déconstruire les valeurs d'enregistrement Record Values. Les motifs d'enregistrement (record patterns) et les motifs de type (type patterns) peuvent être imbriqués pour permettre une forme déclarative, puissante et composable de navigation et de traitement des données.
• Structured Concurrency : Cette API vient simplifier la programmation multithread et traite plusieurs tâches exécutées dans différents threads comme une seule unité de travail. La gestion et l'annulation des erreurs sont rationalisées, ce qui améliore la fiabilité et l'observabilité. Le seul changement depuis son incubation dans le JDK 19 est que StructuredTaskScope a été mis à jour pour prendre en charge l'héritage des Scoped Values par les threads créés dans la portée d'une tâche.
• Correspondance de modèles pour les expressions et déclarations switch : La fonctionnalité permet l'expression concise et sûre de requêtes complexes orientées données. Elle pourra évoluer en continu avec les Record Patterns, ce qui permettra des améliorations continues basées sur l'expérience et le feedback. Parmi les principales modifications apportées au Pattern matching for switch, on peut citer une grammaire simplifiée pour les étiquettes de switch et la prise en charge de l'inférence des arguments de type pour les generic patterns et les record patterns dans les déclarations et expressions de switch. De plus, un switch exhaustif sur une classe enum provoque désormais une MatchException plutôt qu'une IncompatibleClassChangeError si aucune étiquette de switch ne s'applique au moment de l'exécution.

Java 20, statistiques

Dans un billet de blog, Oracle a déclaré : « Comme nous l'avons fait avec les versions précédentes, avec Java 20, nous célébrons les contributions de nombreuses personnes et organisations de la communauté OpenJDK - nous construisons tous Java, ensemble ! »

Rapport de correction JDK 20

Le taux de changement au fil du temps dans les versions du JDK est resté largement constant pendant des années, mais sous la cadence de six mois, le rythme auquel les fonctionnalités et les améliorations prêtes pour la production sont livrées a fortement augmenté.

Au lieu de créer des dizaines de milliers de correctifs et de fournir près d'une centaine de JEP (propositions d'amélioration du JDK) toutes les quelques années, comme nous l'avons fait avec les versions majeures d'antan, les améliorations sont fournies dans des versions de fonctionnalités plus légères selon un calendrier de six mois plus gérable et prévisible. Les changements vont de nouvelles fonctionnalités importantes à de petites améliorations en passant par la maintenance de routine, les corrections de bogues et les améliorations de la documentation. Chaque modification est représentée dans un seul commit pour un seul problème dans le système de bogues JDK.

Sur les 21 604 problèmes JIRA marqués comme résolus dans Java 11 à Java 20 au moment de leur disponibilité générale, 15 420 ont été résolus par des personnes travaillant pour Oracle tandis que 6 184 ont été apportés par des développeurs individuels et des développeurs travaillant pour d'autres organisations. En parcourant les problèmes et en rassemblant les données d'organisation des cessionnaires, on obtient le tableau suivant des organisations parrainant le développement de contributions en Java*:

Problèmes résolus dans JDK 11 - JDK 20 par organisation

Dans Java 20, sur les 2 314 problèmes JIRA marqués comme corrigés, 1 595 ont été résolus par Oracle, tandis que 719 ont été apportés par d'autres membres de la communauté Java. Oracle tient à remercier les développeurs travaillant pour des organisations telles qu'Alibaba, Amazon, ARM, Google, Huawei, IBM, Intel, ISCAS, Red Hat, SAP et Tencent pour leurs contributions notables. Nous sommes également reconnaissants de voir les contributions de petites organisations telles que Bellsoft et Loongson, ainsi que de développeurs indépendants qui ont collectivement contribué à 7*% des correctifs de Java 20.

Nous sommes également reconnaissants aux nombreux développeurs expérimentés qui ont examiné les modifications proposées, aux premiers utilisateurs qui ont essayé les versions à accès anticipé et signalé des problèmes, et aux professionnels dévoués qui ont fourni des commentaires sur les listes de diffusion OpenJDK.

En clair

Le deuxième contributeur le plus important depuis 2018 est Red Hat, selon les statistiques, suivi des indépendants, puis de SAP. Dans les statistiques du JDK 20, les indépendants sont légèrement en avance sur Red Hat, avec SAP toujours à la quatrième place.

Il s'agit d'une mesure quelque peu grossière, car plusieurs personnes de différentes organisations peuvent contribuer à un problème ; mais cela ne montre rien d'autre qu'Oracle qui consacre beaucoup de ressources à Java, qu'il décrit comme le « langage de programmation n^°1 pour les tendances technologiques d'aujourd'hui ». C'est peut-être une exagération, puisque la plupart des enquêtes le placent derrière JavaScript et Python, mais si le contexte est celui des applications d'entreprise, cela reste extrêmement important.

L'une des raisons de l'accent mis sur les correctifs peut être qu'il n'y a pas grand-chose de nouveau dans JDK 20, à moins que vous ne comptiez les Preview mis à jour. Les grosses fonctionnalités qu'attendent les développeurs, comme les threads virtuels (Project Loom), ou le remplacement de JNI Java Native Interface (Project Panama), ne sont pas encore définitives. La correspondance de modèles (Project Amber) a également un aperçu mis à jour. Scoped Values, qui fait partie du projet Loom, apparaît pour la première fois dans le JDK en tant « qu'incubateur », la première étape d'une nouvelle fonctionnalité majeure.

Peu importe qu'il s'agisse d'une version légère pour les fonctionnalités, car il ne s'agit pas d'une version de support à long terme (LTS), d'ailleurs elle sera remplacée dans six mois par JDK 21, qui sera une version LTS. La cadence des versions LTS est maintenant de deux ans.

La sortie du JDK 20 s'accompagne de nouvelles versions d'autres implémentations d'OpenJDK. Amazon a publié Corretto 20 et a déclaré que « les points forts d'OpenJDK 20 incluent une deuxième Preivew des Record Patterns, qui sont utilisés pour travailler plus facilement avec des objets basés sur des enregistrements ».

Source : Inside Java

Et vous ?

Quelle lecture faites-vous de ces statistiques ?
Comment pouvez-vous les interpréter ?
Que pensez-vous du fait que ça soit Oracle qui les publient ?
Ces statistiques gagneraient-elles à être plus étayées ?
Ce format favorise-t-il Oracle ? Dans quelle mesure ?

[professeur shadoko]

avec JEP 432 : Record Patterns (deuxième préversion) pour un record Point (int x, int y)
tu pourras ecrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
List<Point> points=....
for ( Point(int x, int y): points ){
System.out.println(" " +x ", " +y );
 
}

équivalent à:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
List<Point> points=....
for ( Point p: points ){
int x=p.x();
int y=p.y();
System.out.println(" " +x ", " +y );
 
}

Si mes souvenirs sont bons parmi les principes avancés à l'intérieur de l'équipe initiale Java il y avait: méfions nous des "facilités d'écriture"! au risque d'être bavards pas d'implicites, pas de raccourcis! ça fait déjà un bout de temps que ces principes sont partis à la poubelle.

[foxzoolm]

List<Point> points=....
for ( Point(int x, int y): points ){
...
}

la question est : le sucre syntaxique fit-il grossir ?

perso je trouve se genre d'annotation extrêmement dangereuse...
le principe de la POO (selon moi) etant de garder les methodes et les datas le plus proche possible (syntaxiquement)...

voir des x, y se balander dans le code sans lien avec l'objet... SIC!!!

[thelvin]

Si mes souvenirs sont bons parmi les principes avancés à l'intérieur de l'équipe initiale Java il y avait: méfions nous des "facilités d'écriture"! au risque d'être bavards pas d'implicites, pas de raccourcis! ça fait déjà un bout de temps que ces principes sont partis à la poubelle.

Oui ben ça nous a filé les lambdas et le instanceof pattern.
Le moins que l'on puisse dire est que mettre ces principes à la poubelle a été, jusqu'à maintenant, très bénéfique.

[professeur shadoko]

Oui ben ça nous a filé les lambdas et le instanceof pattern.
Le moins que l'on puisse dire est que mettre ces principes à la poubelle a été, jusqu'à maintenant, très bénéfique.

pas de pb pour le instanceof mais pour le cas de lambda mes sentiments sont très partagés: c'est pratique mais une source d'effets de bord pas très explicites. Je rêve d'une forme syntaxique dans laquelle ce qui est modifiable dans le contexte soit bien spécifié (au risque d'être horriblement bavard).

[bouye]

C'est une question d'habitude a prendre, on a le même soucis avec les accesseurs des champs des record qui laissent tomber le prefix get (is pour les boolean) et se contentent de reprendre le nom de la variable a l'identique.

[floyer]

Les lambda peuvent être très utile dans une approche fonctionnelle. On a une collection, et on déduit une autre collection avec map ou filter. Une approche «*purement fonctionnelle*» évite justement des effets de bord. Évidemment la fonction lambda peut avoir un effet de bord en interagissant avec les objets qui lui sont proposés, mais pas plus qu’un bloc équivalent dans une boucle for.