Discussion :

[Bruno]

Java 21 devrait inclure des collections séquencées et des modèles de chaînes de caractères,
le framework des collections de Java manque d'un type de collection qui représente une séquence

L'équipe de développement du JDK devrait inclure des collections séquencées et des modèles de chaînes de caractères avec Java 21. Parmi les autres caractéristiques possibles du JDK 21 figurent toutes les fonctions d'incubation et de prévisualisation du JDK 20, telles que les scoped values, les records patterns et les virtual threads. Les génériques universels et l'API VM asynchrone de suivi de pile pourraient également être inclus.

Même un développeur Java de longue date peut ne pas avoir une bonne compréhension de la manière dont la plateforme est développée et maintenue. La principale leçon à retenir est qu'il s'agit vraiment d'un processus ouvert.

À la base du développement de Java, se trouve le Java Community Process (JCP). Il s'agit d'une sorte de document de base auto-conscient qui définit la manière d'introduire des modifications dans la plateforme et qui permet ainsi de modifier le processus lui-même. La dernière version du JCP est la 2.11, qui a été adoptée en 2019.

Le JCP formalise la manière dont les nouvelles fonctionnalités et les modifications apportées à Java (c'est-à-dire les spécifications techniques) sont proposées, examinées et approuvées, y compris la définition de divers rôles que les gens peuvent occuper. Ces rôles permettent d'offrir un lieu où la communauté des utilisateurs de Java peut participer à la gouvernance de la plateforme.

Lorsqu'un effort est suffisamment large, il est considéré comme un projet JDK. Ce terme recouvre un large éventail d'artefacts, de la documentation au code, incluant souvent une ou plusieurs propositions d'amélioration du JDK (JEP). Les projets impliquent un ou plusieurs groupes de travail. Les groupes sont dédiés à divers domaines de la plateforme Java. Un projet compte généralement plusieurs personnes actives dans le rôle d'auteur.

Pour proposer de nouvelles fonctionnalités et des changements, le JCP permet la création ("initiation") de Java Specification Requests (JSR). Cela se fait via un formulaire standardisé. Pour accéder au formulaire, vous devez vous inscrire pour obtenir un compte JCP gratuit.

De nouvelles versions de l'implémentation Java standard d'Oracle sont disponibles tous les six mois. Comme dit précédemment, parmi les autres caractéristiques possibles du JDK 21 figurent toutes les fonctions d'incubation et de prévisualisation du JDK 20, telles que les scoped values, les records patterns et les virtual threads. Les génériques universels et l'API VM asynchrone de suivi de pile pourraient également être inclus.

Bien que la page de publication du JDK 21 ne mentionne encore aucune fonctionnalité au 9 mars 2023, deux propositions d'amélioration de Java couvrant ces deux fonctionnalités ont déjà été désignées pour le JDK 21. Les propositions spécifiques sont les suivantes

Collections séquencées

Introduire de nouvelles interfaces pour représenter les collections avec un ordre de rencontre défini. Chacune de ces collections possède un premier élément bien défini, un deuxième élément, et ainsi de suite jusqu'au dernier élément. Elle fournit aussi des API uniformes pour accéder à ses premiers et derniers éléments, et pour traiter ses éléments dans l'ordre inverse.

Motivation

Le framework des collections de Java manque d'un type de collection qui représente une séquence d'éléments avec un ordre de rencontre défini. Il manque par ailleurs un ensemble uniforme d'opérations qui s'appliquent à ces collections. Ces lacunes ont été une source répétée de problèmes et de plaintes.

Par exemple, List et Deque définissent tous deux un ordre de rencontre, mais leur supertype commun est Collection, qui ne le définit pas. De même, Set ne définit pas d'ordre de rencontre et les sous-types tels que HashSet n'en définissent pas, alors que les sous-types SortedSet et LinkedHashSet en définissent un. La prise en charge de l'ordre de rencontre est donc dispersée dans la hiérarchie des types, ce qui rend difficile l'expression de certains concepts utiles dans les API.

Ni Collection ni List ne peuvent décrire un paramètre ou une valeur de retour ayant un ordre de rencontre. Collection est trop général, reléguant de telles contraintes à la spécification de la prose, ce qui peut conduire à des erreurs difficiles à déboguer. List est trop spécifique, excluant SortedSet et LinkedHashSet.

Un problème connexe est que les collections de vues sont souvent obligées d'adopter une sémantique plus faible. En enveloppant un LinkedHashSet avec Collections::unmodifiableSet, on obtient un Set, sans tenir compte de l'information sur l'ordre de rencontre.

Sans interfaces pour les définir, les opérations liées à l'ordre de rencontre sont soit incohérentes, soit absentes. Bien que de nombreuses implémentations permettent d'obtenir le premier ou le dernier élément, chaque collection définit sa propre méthode, et certaines ne sont pas évidentes ou sont totalement absentes.

Certaines d'entre elles sont inutilement lourdes, comme l'obtention du dernier élément d'une liste. D'autres ne sont même pas possibles sans faire preuve d'héroïsme : Le seul moyen d'obtenir le dernier élément d'un LinkedHashSet est d'itérer l'ensemble.

De même, l'itération des éléments d'une collection du premier au dernier est simple et cohérente, mais l'itération dans l'ordre inverse ne l'est pas non plus. Toutes ces collections peuvent être itérées vers l'avant à l'aide d'un Iterator, de la boucle for améliorée, de stream() ou de toArray(). L'itération en sens inverse est différente dans chaque cas. NavigableSet fournit la vue descendingSet() pour l'itération inverse :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
for (var e : navSet.descendingSet())
    process(e);
Deque does so with a reverse Iterator:
for (var it = deque.descendingIterator(); it.hasNext();) {
    var e = it.next();
    process(e);
}
List does so but with ListIterator:
for (var it = list.listIterator(list.size()); it.hasPrevious();) {
    var e = it.previous();
    process(e);
}

Enfin, [C=Java]LinkedHashSet[C/] ne prend pas en charge l'itération inverse. Le seul moyen pratique de traiter les éléments d'un LinkedHashSet dans l'ordre inverse est de copier ses éléments dans une autre collection.

De même, le traitement des éléments d'une collection à l'aide de flux est une alternative puissante et efficace au traitement des éléments à l'aide de boucles, mais il peut être difficile d'obtenir un flux dans l'ordre inverse. Parmi les différentes collections qui définissent l'ordre de rencontre, la seule qui prenne en charge cette fonctionnalité est NavigableSet :

navSet.descendingSet().stream()
Les autres collections nécessitent soit de copier les éléments dans une autre collection, soit de créer un flux à partir d'un Spliterator personnalisé qui inverse l'itération.
Cette situation est regrettable. Le concept de collection avec un ordre de rencontre défini existe à plusieurs endroits dans le cadre des collections, mais il n'y a pas de type unique qui le représente. En conséquence, certaines opérations sur de telles collections sont incohérentes ou manquantes, et le traitement d'éléments dans l'ordre inverse va de l'inconfortable à l'impossible. Nous devons combler ces lacunes.

Description

L'équipe définit de nouvelles interfaces pour les collections séquencées, les ensembles séquencés et les cartes séquencées, puis nous les intégrons dans la hiérarchie des types de collections existants. Toutes les nouvelles méthodes déclarées dans ces interfaces sont implémentées par défaut.

Une collection séquencée est une collection dont les éléments ont un ordre de rencontre défini. (Le mot "séquencé" tel qu'il est utilisé ici est le participe passé du verbe séquencer, qui signifie « arranger les éléments dans un ordre particulier »). Une collection séquencée a un premier et un dernier élément, et les éléments entre eux ont des successeurs et des prédécesseurs. Une collection séquencée permet d'effectuer des opérations communes à chaque extrémité et de traiter les éléments du premier au dernier et du dernier au premier (c'est-à-dire en avant et en arrière).

Code :

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

1
2
3
4
5
6
7
8
9
10
11
interface SequencedCollection<E> extends Collection<E> {
    // new method
    SequencedCollection<E> reversed();
    // methods promoted from Deque
    void addFirst(E);
    void addLast(E);
    E getFirst();
    E getLast();
    E removeFirst();
    E removeLast();
}

La nouvelle méthode reversed() permet d'obtenir une vue inversée de la collection d'origine. Toute modification apportée à la collection d'origine est visible dans la vue. Si cela est autorisé, les modifications apportées à la vue s'inscrivent dans la collection d'origine.

La vue inversée permet à tous les différents types séquencés de traiter les éléments dans les deux sens, en utilisant tous les mécanismes d'itération habituels : Enhanced for loops, explicit iterator() loops, forEach(), stream(), parallelStream(), and toArray().

Par exemple, il était auparavant assez difficile d'obtenir un flux ordonné à l'envers à partir d'un LinkedHashSet.

Code :

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

linkedHashSet.reversed().stream()

(La methode reversed() est essentiele pour renomer NavigableSet::descendingSet, estpromu en SequencedCollection.)

Les méthodes suivantes de SequencedCollection sont issues de Deque. Elles permettent d'ajouter, d'obtenir et de supprimer des éléments aux deux extrémités :

• void addFirst(E)
• void addLast(E)
• E getFirst()
• E getLast()
• E removeFirst()
• E removeLast()

Les méthodes add*(E) et remove*() sont facultatives, principalement pour prendre en charge le cas des collections non modifiables. Les méthodes get*() et remove*() lèvent l'exception NoSuchElementException si la collection est vide.

Les méthodes equals() et hashCode() ne sont pas définies dans SequencedCollection car ses sous-interfaces ont des définitions contradictoires.

Ensembles ordonnés

Un ensemble séquencé est un ensemble qui est une SequencedCollection ne contenant pas d'éléments dupliqués.

Code :

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

1
2
3
interface SequencedSet<E> extends Set<E>, SequencedCollection<E> {
    SequencedSet<E> reversed();    // covariant override
}

Les collections telles que SortedSet, qui positionnent les éléments par comparaison relative, ne peuvent pas prendre en charge les opérations de positionnement explicite telles que les méthodes addFirst(E) et addLast(E) déclarées dans la superinterface SequencedCollection. Ces méthodes peuvent donc provoquer une exception de type UnsupportedOperationException.

Les méthodes addFirst(E) et addLast(E) de SequencedSet ont une sémantique particulière pour les collections telles que LinkedHashSet : Si l'élément est déjà présent dans l'ensemble, il est déplacé à la position appropriée. Cela permet de remédier à une lacune de longue date de [C=Java]LinkedHashSet, à savoir l'impossibilité de repositionner des éléments.

Schémas séquencés

Un schéma séquencé est une carte dont les entrées ont un ordre de rencontre défini.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
interface SequencedMap<K,V> extends Map<K,V> {
    // new methods
    SequencedMap<K,V> reversed();
    SequencedSet<K> sequencedKeySet();
    SequencedCollection<V> sequencedValues();
    SequencedSet<Entry<K,V>> sequencedEntrySet();
    V putFirst(K, V);
    V putLast(K, V);
    // methods promoted from NavigableMap
    Entry<K, V> firstEntry();
    Entry<K, V> lastEntry();
    Entry<K, V> pollFirstEntry();
    Entry<K, V> pollLastEntry();
}

Les nouvelles méthodes put*(K, V) ont une sémantique particulière, similaire aux méthodes add*(E) correspondantes de SequencedSet : pour les shemas telles que LinkedHashMap, elles ont pour effet supplémentaire de repositionner l'entrée si elle est déjà présente dans la carte. Pour les cartes telles que SortedMap, ces méthodes provoquent une exception de type UnsupportedOperationException.

Les méthodes suivantes de SequencedMap sont issues de NavigableMap. Elles permettent d'obtenir et de supprimer des entrées aux deux extrémités :

• Entry<K, V> firstEntry()
• Entry<K, V> lastEntry()
• Entry<K, V> pollFirstEntry()
• Entry<K, V> pollLastEntry()

Adaptation

Les trois nouvelles interfaces définies ci-dessus s'intègrent parfaitement dans la hiérarchie des types de collections existants :

En détail, l'équipe Java procède aux ajustements suivants pour adapter les classes et les interfaces existantes :

• List a pour superinterface immédiate SequencedCollection,
• Deque a SequencedCollection comme superinterface immédiate,
• LinkedHashSet implémente SequencedSet,
• SortedSet a pour superinterface immédiate SequencedSet,
• LinkedHashMap implémente SequencedMap, et
• SortedMap a SequencedMap comme superinterface immédiate.

Nous définissons des surcharges covariantes pour la méthode reversed() aux endroits appropriés. Par exemple, List::reversed est surchargée pour renvoyer une valeur de type List plutôt qu'une valeur de type SequencedCollection.

L'équipe a également ajouté de nouvelles méthodes à la classe utilitaire Collections afin de créer des wrappers non modifiables pour les trois nouveaux types :

• (Collections.unmodifiableSequencedCollection(collection)
• Collections.unmodifiableSequencedSet(sequencedSet)
• Collections.unmodifiableSequencedMap(sequencedMap)

Alternatives

Types

Une alternative à l'ajout de nouveaux types consisterait à réutiliser l'interface List en tant que type de collection séquencée générale. En effet, List est séquencée, mais elle supporte également l'accès aux éléments par index entier. De nombreuses structures de données séquencées ne supportent pas naturellement l'indexation et devraient donc la supporter de manière itérative. L'accès indexé aurait alors une performance de O(n) au lieu de O(1), perpétuant ainsi l'erreur de LinkedList.

Deque semble prometteur en tant que type de séquence général, puisqu'il prend déjà en charge le bon ensemble d'opérations. Cependant, il est encombré par d'autres opérations, notamment une famille d'opérations à retour nul (offer, peek et poll), des opérations sur la pile (push et pop) et des opérations héritées de Queue. Ces opérations sont judicieuses pour une file d'attente, mais le sont moins pour d'autres collections. Si Deque était transformé en type de séquence général, List serait également une file d'attente et prendrait en charge les opérations de pile, ce qui entraînerait une API encombrée et confuse.

Nommage

Le terme sequence choisi ici, implique des éléments disposés dans l'ordre. Il est couramment utilisé sur diverses plateformes pour représenter des collections dont la sémantique est similaire à celle décrite ci-dessus.

Le terme ordered n'est pas assez spécifique. Nous avons besoin d'itération dans les deux sens et d'opérations aux deux extrémités. Une collection ordonnée telle qu'une file d'attente est une exception notable : Elle est ordonnée, mais elle est aussi résolument asymétrique.

Le terme réversible, utilisé dans une version antérieure de cette proposition, n'évoque pas immédiatement le concept de deux extrémités. Le fait que la variante Map soit nommée ReversibleMap, qui implique de manière trompeuse qu'elle supporte la consultation par clé et par valeur (parfois appelée BiMap ou BidiMap), constitue peut-être un problème plus important.

Modèles de chaînes de caractères ("Preview")

Améliorez le langage de programmation Java avec des modèles de chaînes de caractères. Les modèles de chaînes complètent les chaînes littérales et les blocs de texte existants de Java en couplant le texte littéral avec des expressions et des processeurs intégrés pour produire des résultats spécialisés. Il s'agit d'une fonctionnalité de langage et d'une API de prévisualisation.

Motivation

Les développeurs élaborent régulièrement des chaînes de caractères à partir d'une combinaison de texte littéral et d'expressions. Java propose plusieurs mécanismes d’élaboration de chaînes de caractères, qui présentent malheureusement tous des inconvénients.

La concaténation de chaînes avec l'opérateur + produit un code difficile à lire :

Code :

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

String s = x + " plus " + y + " equals " + (x + y);

StringBuilder est trop verbeux :

Code :

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

1
2
3
4
5
6
7
8
 
String s = new StringBuilder()
               .append(x)
               .append(" plus ")
               .append(y)
               .append(" equals ")
               .append(x + y)
               .toString();

java.text.MessageFormat nécessite trop de spécifications et utilise une syntaxe peu familière dans la chaîne de format :

Code :

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

1
2
MessageFormat mf = new MessageFormat("{0} plus {1} equals {2}");
  String s = mf.format(x, y, x + y);

Les modèles de chaînes, qui apparaîtront en version Preview, complètent les chaînes littérales et les blocs de texte existants de Java en couplant le texte littéral avec des expressions et des processeurs intégrés pour produire des résultats spécialisés. Cette API est destinée à simplifier l'écriture de programmes Java en facilitant l'expression de chaînes de caractères comprenant des valeurs calculées au moment de l'exécution. Elle promet d'améliorer la lisibilité des expressions, la sécurité des programmes, la flexibilité et de simplifier l'utilisation des API qui acceptent les chaînes de caractères écrites dans des langages autres que Java. L'objectif est également de permettre le développement d'expressions autres que des chaînes, dérivées de la combinaison de texte littéral et d'expressions intégrées.

Interpolation de chaînes de caractères

De nombreux langages de programmation proposent l'interpolation de chaînes comme alternative à la concaténation de chaînes. Typiquement, cela prend la forme d'une chaîne littérale qui contient des expressions intégrées ainsi que du texte littéral. L'intégration d'expressions in situ permet aux lecteurs de discerner facilement le résultat escompté. Au moment de l'exécution, les expressions intégrées sont remplacées par leurs valeurs (stringifiées) - on dit que les valeurs sont interpolées dans la chaîne. Voici quelques exemples d'interpolation dans d'autres langues :

JavaScript `${x} plus ${y} equals ${x + y}`
C# $"{x} plus {y} equals {x + y}"
Visual Basic $"{x} plus {y} equals {x + y}"
Scala f"$x%d plus $y%d equals ${x + y}%d"
Python f"{x} plus {y} equals {x + y}"
Ruby "#{x} plus #{y} equals #{x + y}"
Groovy "$x plus $y equals ${x + y}"
Kotlin "$x plus $y equals ${x + y}"
Swift "\(x) plus \(y) equals \(x + y)"

Certains de ces langages permettent l'interpolation pour toutes les chaînes de caractères littérales, tandis que d'autres exigent que l'interpolation soit activée lorsque cela est souhaité, par exemple en préfixant le délimiteur d'ouverture de la chaîne littérale par $ ou f. La syntaxe des expressions intégrées varie également, mais elle implique souvent des caractères tels que $ ou { }, ce qui signifie que ces caractères ne peuvent pas apparaître littéralement à moins qu'ils ne soient échappés.

L'interpolation est non seulement plus pratique que la concaténation lors de l'écriture du code, mais elle offre également une plus grande clarté lors de la lecture du code. Cette clarté est particulièrement frappante avec les chaînes de caractères de grande taille. Par exemple, en JavaScript :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
const title = "My Web Page";
const text  = "Hello, world";
 
var html = `<html>
              <head>
                <title>${title}</title>
              </head>
              <body>
                <p>${text}</p>
              </body>
            </html>`;

L'interpolation de chaînes de caractères est dangereuse

Malheureusement, la commodité de l'interpolation présente un inconvénient : il est facile de construire des chaînes qui seront interprétées par d'autres systèmes, mais qui sont dangereusement incorrectes dans ces systèmes.

Les chaînes qui contiennent des instructions SQL, des documents HTML/XML, des extraits JSON, des scripts shell et du texte en langage naturel doivent toutes être validées et assainies selon des règles spécifiques au domaine. Comme le langage de programmation Java ne peut pas appliquer toutes ces règles, c'est aux développeurs utilisant l'interpolation qu'il incombe de valider et d'assainir.

En règle générale, cela signifie qu'il faut se souvenir d'envelopper les expressions intégrées dans des appels à des méthodes d'échappement ou de validation, et s'appuyer sur des IDE ou des outils d'analyse statique pour aider à valider le texte littéral.
L'interpolation est particulièrement dangereuse pour les instructions SQL car elle peut conduire à des attaques par injection. Prenons l'exemple d'un code Java hypothétique contenant l'expression intégrée ${nom} :

Code :

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

1
2
String query = "SELECT * FROM Person p WHERE p.last_name = '${name}'";
ResultSet rs = connection.createStatement().executeQuery(query);

Peut-on faire mieux ?

Pour Java, nous aimerions disposer d'une fonction de composition de chaînes de caractères qui soit aussi claire que l'interpolation, mais qui permette d'obtenir un résultat plus sûr dès le départ, en échangeant peut-être un peu de commodité pour gagner beaucoup de sécurité.

Par exemple, lors de la composition d'instructions SQL, tous les guillemets dans les valeurs des expressions intégrées doivent être échappés, et la chaîne dans son ensemble doit avoir des guillemets équilibrés. Compte tenu de la valeur problématique de nom montrée ci-dessus, la requête qui devrait être composée est une requête sûre :

SELECT * FROM Person p WHERE p.last_name = '\'Smith\' OR p.last_name <> \'Smith\''

Il est préférable que le modèle de processeur apparaisse en premier, car le résultat de l'évaluation de l'expression du modèle dépend entièrement du fonctionnement du processeur de modèle.

Sources : Java (1, 2, 3)

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

Java 19 : nouvelles fonctionnalités avec exemples, elle apporte des méthodes pour créer des HashMaps préalloués

JDK 19 : les nouvelles fonctionnalités de Java 19 incluent la concurrence structurée, les modèles d'enregistrement et l'aperçu d'une API de fonction et de mémoire étrangères

[Anthony]

L'OpenJDK formule une proposition visant à rendre Java plus facile à apprendre pour les débutants, à travers une fonctionnalité du JDK 21 qui est actuellement désactivée par défaut

Le langage Java pourrait être plus facile à apprendre pour les étudiants grâce à une proposition visant à introduire des méthodes main flexibles et des classes principales anonymes dans le langage.

Les détails du plan comprennent l'amélioration du protocole par lequel les programmes Java sont lancés pour être flexibles, en particulier pour permettre l'omission du paramètre String[] des méthodes principales et pour permettre à ces dernières de n'être ni publiques ni statiques ; le programme "Hello World" serait simplifié. Des classes principales anonymes pourraient être introduites pour rendre la déclaration de classe implicite.

Il s'agit actuellement d'une fonctionnalité du langage désactivée par défaut dans le JDK 21 (dont la disponibilité générale est prévue pour septembre), incluse pour provoquer un retour d'information de la part des développeurs sur la base d'une utilisation réelle (ce qui pourrait conduire à la rendre permanente à l'avenir). Il ne s'agit pas d'introduire un dialecte ou une chaîne d'outils Java distincts pour les débutants, souligne la proposition d'amélioration de Java (JEP) 445. "Les programmes des étudiants devraient être compilés et exécutés avec les mêmes outils que ceux qui compilent et exécutent n'importe quel programme Java."

Mais elle affirme qu'un simple programme "Hello World" a aujourd'hui "trop d'encombrement... trop de code, trop de concepts, trop de constructions - pour ce que fait le programme".

Code :

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

1
2
3
4
5
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, World !") ;
}
}

Les classes main anonymes rendraient la déclaration de la classe publique implicite (tout en épargnant aux néophytes le "mystérieux" modificateur static et le paramètre args String[] ). Le programme est simplifié comme suit :

Code :

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

1
2
3
void main() {
System.out.println("Hello, World !") ;
}

La proposition soutient que ce changement réduit "la cérémonie d'écriture de programmes simples tels que les scripts et les utilitaires de ligne de commande". Et puisque Java est destiné à être un premier langage de programmation, ce changement signifierait que les étudiants "peuvent écrire leurs premiers programmes sans avoir besoin de comprendre les caractéristiques du langage conçues pour les grands programmes", en utilisant à la place "des déclarations simplifiées pour les programmes à classe unique". (Cela permet aux étudiants et aux éducateurs d'explorer plus progressivement les fonctionnalités du langage).

Un programme Hello, World ! écrit sous la forme d'une classe principale anonyme se concentre beaucoup plus sur ce que le programme fait réellement, en omettant les concepts et les constructions dont il n'a pas besoin. Malgré cela, tous les membres sont interprétés de la même manière que dans une classe ordinaire. Pour transformer une classe principale anonyme en classe ordinaire, il suffit d'envelopper sa déclaration, à l'exclusion des déclarations d'importation, dans une déclaration de classe explicite.

JEP 445 : Des méthodes main flexibles et des classes principales anonymes

Résumé

Faire évoluer le langage Java pour que les étudiants puissent écrire leurs premiers programmes sans avoir besoin de comprendre les caractéristiques du langage conçues pour les gros programmes. Loin d'utiliser un dialecte Java distinct, les étudiants peuvent écrire des déclarations simplifiées pour des programmes à classe unique, puis étendre leurs programmes de manière transparente pour utiliser des fonctionnalités plus avancées au fur et à mesure que leurs compétences augmentent. Il s'agit d'une fonctionnalité preview du langage.

Objectifs

• Offrir une rampe d'accès en douceur à Java afin que les enseignants puissent introduire les concepts de programmation de manière graduelle.
• Aider les étudiants à écrire des programmes de base de manière concise et à faire évoluer leur code au fur et à mesure que leurs compétences se développent.
• Réduire la cérémonie d'écriture de programmes simples tels que les scripts et les utilitaires de ligne de commande.
• Ne pas introduire de dialecte Java distinct pour les débutants.
• Ne pas introduire de chaîne d'outils distincte pour les débutants ; les programmes des étudiants devraient être compilés et exécutés avec les mêmes outils que ceux qui compilent et exécutent tout programme Java.

Motivation

Java est un langage multi-paradigme qui excelle dans les applications complexes et de grande envergure développées et maintenues pendant de nombreuses années par de grandes équipes. Il possède de riches caractéristiques pour le masquage des données, la réutilisation, le contrôle d'accès, la gestion des espaces de noms et la modularité qui permettent de composer proprement des composants tout en les développant et en les maintenant de manière indépendante. Grâce à ces caractéristiques, les composants peuvent exposer des interfaces bien définies pour leur interaction avec d'autres composants et masquer les détails de leur mise en œuvre interne afin de permettre l'évolution indépendante de chacun d'entre eux.

En effet, le paradigme orienté objet lui-même est conçu pour assembler des éléments qui interagissent par le biais de protocoles bien définis et qui font abstraction des détails de mise en œuvre. Cette composition de grands composants s'appelle la programmation en grand. Java offre également de nombreuses constructions utiles pour la programmation en petit, c'est-à-dire tout ce qui est interne à un composant. Ces dernières années, Java a amélioré à la fois ses capacités de programmation en grand avec les modules et ses capacités de programmation en petit avec la programmation orientée données.

Cependant, Java est également conçu pour être un premier langage de programmation. Lorsque les programmeurs débutent, ils n'écrivent pas de grands programmes, en équipe - ils écrivent de petits programmes, seuls. Ils n'ont pas besoin d'encapsulation et d'espaces de noms, utiles pour faire évoluer séparément des composants écrits par des personnes différentes. Lorsqu'ils enseignent la programmation, les instructeurs commencent par les concepts de base de la programmation en petit, à savoir les variables, le flux de contrôle et les sous-programmes. À ce stade, il n'est pas nécessaire d'utiliser les concepts de programmation en grand que sont les classes, les paquets et les modules. Rendre le langage plus accueillant pour les nouveaux venus est dans l'intérêt des vétérans de Java, mais eux aussi peuvent trouver agréable d'écrire des programmes simples de manière plus concise, sans aucun échafaudage de programmation dans les grandes dimensions.

Prenons le programme classique Hello, World ! qui est souvent utilisé comme premier programme pour les étudiants de Java :

Code :

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

1
2
3
4
5
public class HelloWorld { 
    public static void main(String[] args) { 
        System.out.println("Hello, World!");
    }
}

Il y a trop d'encombrement ici - trop de code, trop de concepts, trop de constructions - pour ce que fait le programme.

La déclaration de classe et le modificateur d'accès public obligatoire sont des constructions de programmation à grande échelle. Ils sont utiles pour encapsuler une unité de code avec une interface bien définie vers des composants externes, mais plutôt inutiles dans ce petit exemple.

Le paramètre String[] args existe également pour interfacer le code avec un composant externe, dans ce cas le shell du système d'exploitation. Il est mystérieux et inutile ici, d'autant plus qu'il n'est jamais utilisé.

Le modificateur static fait partie du modèle classe-objet de Java. Pour le novice, static n'est pas seulement mystérieux, il est aussi nuisible : Pour ajouter des méthodes ou des champs que main peut appeler et utiliser, l'étudiant doit soit les déclarer tous comme statiques - propageant ainsi un idiome qui n'est ni commun ni une bonne habitude - soit affronter la différence entre les membres statiques et les membres d'instance et apprendre à instancier un objet.

Le nouveau programmeur rencontre ces concepts au pire moment possible, avant d'avoir appris les variables et le flux de contrôle, et alors qu'il ne peut pas apprécier l'utilité des constructions de programmation en grand pour maintenir un programme de grande taille bien organisé. Les éducateurs leur disent souvent : "Ne t'inquiète pas pour ça, tu comprendras plus tard". Cela n'est satisfaisant ni pour eux, ni pour leurs étudiants, et laisse à ces derniers l'impression durable que Java est compliqué.

La motivation de ce JEP n'est pas seulement de réduire la cérémonie, mais d'aider les programmeurs qui sont nouveaux à Java, ou à la programmation en général, à apprendre Java d'une manière qui introduit les concepts dans le bon ordre : Commencer par les concepts fondamentaux de la programmation en petit, puis passer aux concepts avancés de la programmation en grand lorsqu'ils sont réellement bénéfiques et peuvent être plus facilement appréhendés.

Nous proposons de le faire non pas en changeant la structure du langage Java - le code est toujours enfermé dans des méthodes, qui sont enfermées dans des classes, qui sont enfermées dans des paquets, qui sont enfermés dans des modules - mais en cachant ces détails jusqu'à ce qu'ils soient utiles dans des programmes plus importants. Nous offrons une rampe d'accès, une pente graduelle qui s'insère gracieusement dans l'autoroute. Lorsque les étudiants passent à des programmes plus importants, ils n'ont pas besoin d'abandonner ce qu'ils ont appris au cours des premières étapes, mais ils voient plutôt comment tout cela s'inscrit dans un cadre plus large.

Les changements que nous proposons ici ne sont qu'une étape pour rendre Java plus facile à apprendre. Ils n'abordent même pas tous les problèmes de vitesse du programme Hello, World ! ci-dessus : Le débutant peut encore être déconcerté par la mystérieuse incantation System.out.println, et il a encore besoin d'importer des classes et des méthodes utilitaires de base pour des fonctionnalités essentielles, même dans les programmes des premières semaines. Nous nous pencherons peut-être sur ces problèmes dans un prochain JEP.

Source : OpenJDK

Et vous ?

Quel est votre avis sur le sujet ?

Pensez-vous que cette approche permettra aux néophytes de mieux maîtriser les particularités du langage Java ?

Voir aussi

Java 21 devrait inclure des collections séquencées et des modèles de chaînes de caractères, le framework des collections de Java manque d'un type de collection qui représente une séquence

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

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

[bouye]

Ok, pourquoi pas. D'autres langages ne le font-ils pas depuis quelques temps il me semble ? L’usage de jshell aussi a peut-être inspiré la chose.
Comme beaucoup de changements de syntaxe récents, si cela est validé, ça révolutionnera pas grand chose, puisqu’il juste une légère simplification de l’écriture du code ; le bytecode restant quand a lui inchangé.

Sauf grosse erreur d’interprétation de ma part, le mode ultra-précautionneux / arcbouté sur une syntaxe rigide du langage que les gens chargés de développer le JDK chez Sun / Oracle d'il y a 10+ ans exhibaient montrait bien que leur soucis semblait être qu'ils n'arrivaient pas a envisager des changements drastique de syntaxe sans avoir forcément avoir des modifications incompatibles du bytecode derrière. Or, visiblement, désormais, et avec tout ce qui a été introduit ou incubé depuis, ils ont un peu changé leur vision ; oui on peut vraiment faire évoluer et changer la syntaxe de Java mais derrière ça compile toujours dans la même chose.

Et puisque Java est destiné à être un premier langage de programmation

Compte tenu de la désertification du forum Java, je m'interroge sur la pertinence de cette remarque. Est-ce encore le cas aux US ? Car ça ne semble plus trop être le cas en France.
Certes on a encore parfois de temps a autres une question d'un gamin qui cherche a faire du dével sur Minecraft (et pas grand monde pour lui répondre).
Même si le faux jumeau C# a fait de beau effort de portabilité (je dois reconnaître que c'est du beau boulot de la part de Microsoft et aussi d'autres grand acteurs attractifs comme Unity), le monde de l'enseignement et universitaire semble avoir entièrement basculé sur Python et JavaScript, non ? Étant bien loin de la fac (a la fois physiquement et en nombre d’années) qu'en est-il de nos jours ?

[Uther]

Je suis pas sur que la désertification du forum Java soit due à une baisse de l'importance du Langage. J'ai l'impression que c'est le cas de la plupart des forums du site. J'ai plutôt l'impression que c'est plus lié a la montée en puissance d'alternatives qui offrent un format taillé sur mesure à la réponse de question techniques comme Stack Overflow.

Je pense que Java en temps que langage Objet statiquement typé a un réel intérêt pédagogique.

[walfrat]

Il y a trop d'encombrement ici - trop de code, trop de concepts, trop de constructions - pour ce que fait le programme.

Sérieusement ?

Les élèves peuvent juste commencer avec un "voici un template, mettez votre code ici, pour lancer le code, faite clic droit > executer en tant que > java console".

C'est comme ça que j'ai commencer, en C, sans savoir ce que c'était que ce foutu "char**argc, char**argv" et ça ne m'a pas posé de problème.

[plegat]

La proposition soutient que ce changement réduit "la cérémonie d'écriture de programmes simples tels que les scripts et les utilitaires de ligne de commande".

Ok ok... et un utilitaire en ligne de commande à qui on ne peut pas passer d'arguments, c'est tout de même vite limité en fonctionnalités...
Et normalement tous les EDI ont le template et le raccourci clavier qui va bien pour taper tout ça automatiquement (ah le "psvm" de Netbeans...)

Et puisque Java est destiné à être un premier langage de programmation, ce changement signifierait que les étudiants "peuvent écrire leurs premiers programmes sans avoir besoin de comprendre les caractéristiques du langage conçues pour les grands programmes", en utilisant à la place "des déclarations simplifiées pour les programmes à classe unique". (Cela permet aux étudiants et aux éducateurs d'explorer plus progressivement les fonctionnalités du langage).

... ou comment dire autrement "on veut pouvoir faire en Java la même chose qu'on peut faire en python"...
Je me souviens encore de certaines discussions sur le forum Java où on retrouvait 50 classes dans un seul fichier... ça sera peut-être plus clair avec cette proposition (ou pas!)

Bref, attention à une mauvaise utilisation, ça peut être bien pour mettre le pied à l'étrier, mais il faut vite bifurquer sur les constructions habituelles pour ne pas partir dans le plat de spaghetti.

Un programme Hello, World ! écrit sous la forme d'une classe principale anonyme se concentre beaucoup plus sur ce que le programme fait réellement, en omettant les concepts et les constructions dont il n'a pas besoin.

Oui, enfin bon, à part afficher "Hello, World !" à l'écran, ça ne fait pas grand chose à la base comme programme... on repassera pour le côté éducatif, surtout si on simplifie en virant tous les éléments éducatifs... un quart d'heure de cours et c'est bon, on passe au niveau suivant!

Faudrait surtout travailler à virer le "System.out." pour faire un "println"... c'est franchement super trop verbeux pour les débutants...

[smarties]

J'ai fait du JAVA il y a des années et j'ai basculé sur Python pour les raisons suivantes :
- trop verbeux (System.out.println, le respect des "bonne pratique" créait du code inutile à mon gout pour respecter les design patterns)
- trop de mémoire utilisée et ça explose quand on a fait de la sérialisation dé-sérialisation à mon goût... ou quand il fallait un serveur web --> ça utilisait trop de RAM sur mon NAS ARM à mon goût
- le marché de l'emploi était saturé ou j'étais et las salaires plutôt bas

[marc.collin]

le monde de l'enseignement et universitaire semble avoir entièrement basculé sur Python et JavaScript, non ?

si je me fie au cv de stagiaire qu'on recoit non... et il y a en de plus en plus qui sont francais... le java semble encore bien appris

[OButterlin]

Donc si je comprends bien, le fait de devoir encadrer une méthode dans une classe rend le langage trop verbeux, trop d'encombrement, trop de concept...

Que les "nouveaux" développeurs continuent à raisonner comme des fainéants, il n'y aura rien d'étonnant ensuite qu'on les remplace tous par une IA...

S'il y a une classe c'est que java est un langage objet, si ça dérange, ils n'ont qu'à faire du RPG, du côté compact, on fait difficilement mieux... encore que... même en java on peut faire du compact, illisible, pas maintenable, dans le genre

Code :

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

class A{public String c(String a, String b){return (a==null?"":a)+(b==null?"":b);}}

[walfrat]

J'ai fait du JAVA il y a des années et j'ai basculé sur Python pour les raisons suivantes :
- trop verbeux (System.out.println, le respect des "bonne pratique" créait du code inutile à mon gout pour respecter les design patterns)
- trop de mémoire utilisée et ça explose quand on a fait de la sérialisation dé-sérialisation à mon goût... ou quand il fallait un serveur web --> ça utilisait trop de RAM sur mon NAS ARM à mon goût
- le marché de l'emploi était saturé ou j'étais et las salaires plutôt bas

1- Tu peux faire un import static System.out et tu pourras juste faire "println".
2- Tu ne fais pas des bonnes pratiques pour faire des bonnes pratiques, tu les utilises quand elle réponde à un problème que tu dois résoudre, autrement dit quand tu en as besoin.
3- Avec la completion des IDE, ecrire du code un peu plus long ne me coute rien personnellement, ce qui compte pour moi c'est plutôt a quelle vitesse je le relis, et ça ça dépend surtout du dev qui a écris le code que du language.
4- J'ai pas fait de comparaison, mais oui avec la couche habituelle de framework (quand tu vise pas spécialement du cloud), il y a une empreinte RAM de base.

[marc.collin]

java est déjà simple à apprendre.... il y a même pas 30 ans... les gens apprennaient l'asm, le c... autrement plus complexe que java

java est encore enseigné dans bonne nombre d'école

verbeux mais très très lisible

[sylsau]

Il y a trop d'encombrement ici - trop de code, trop de concepts, trop de constructions - pour ce que fait le programme.

S'ils trouvent ça trop verbeux, autant arrêter le Java avant même d'avoir commencé.

C'est un classique de base de tout programme, je doute qu'enlever cela change grand chose ...

[Uther]

Le coté verbeux n'est pas un problème du langage en soit, quand on le connait bien, c'est tout a fait justifié. Et même pour un débutant, c'est pas tant la quantité de code a taper qui pose soucis, mais le fait qu'il le comprend pas. En Java un simple Hello World fait appel aux notions de classe, de visibilité, de type statique, de tableau, d'attribut et de méthode alors que c'est des choses que quelqu'un qui découvre la programmation est censé apprendre bien plus tard, une fois qu'il a intégré l’algorithmie.

[OButterlin]

...quelqu'un qui découvre la programmation est censé apprendre bien plus tard, une fois qu'il a intégré l’algorithmie.

Commencer un langage avant l'algorithmique est un non sens à mon avis... pourquoi ne pas changer un moteur avant de faire des cours de mécanique

Le problème est plutôt que les nouveaux développeurs veulent en faire toujours moins, ne pas réfléchir, tout doit venir tout cuit, sans effort.
Pour illustrer mon propos, je vois de plus en plus de discussion sur des forums dédiés au développement où à un problème la réponse est : demande à ChatGPT...
(et en l'occurrence, la réponse se trouvait sur la 10ème ligne de la stacktrace... )

[thelvin]

Commencer un langage avant l'algorithmique est un non sens à mon avis... pourquoi ne pas changer un moteur avant de faire des cours de mécanique

Euh... Autant je ne nie pas particulièrement que cet ordre semble plus élégant,

autant, du coup, tu la pratiques avec quoi, l'algorithmique ? Du papier ? Tu construis une machine de Turing ?

C'est le serpent et la poule, l’œuf qui se mord la queue, et il arrive un moment où il faut aussi décider de commencer quand même.

Il me semble que l'approche générale est

"Au début, en fait c'est pas tellement le langage qu'on apprend. On accepte juste les fioritures qu'il exige qu'on mette autour de nos programmes parce que c'est comme ça, en se disant qu'on pourra toujours y revenir plus tard.

On apprend les idées et quelles syntaxes sont nécessaires pour elles dans ce langage. Après seulement avoir pratiqué de l'algorithmique avec cet outil, on revient vers l'étude de comment ce langage fonctionne, et peut-être un autre aussi en même temps pour illustrer plus facilement la notion de ce qui fait partie du langage."

[OButterlin]

Euh... Autant je ne nie pas particulièrement que cet ordre semble plus élégant,

autant, du coup, tu la pratiques avec quoi, l'algorithmique ? Du papier ? Tu construis une machine de Turing ?

En ce qui me concerne, j'ai appris l'algorithmique sans langage, certes, c'était il y a très longtemps mais bon, c'est possible.
Nos profs nous apprenais à raisonner avec deux symboles :
- la répétitive (un bloc avant répétitive, la fonction répétitive, un bloc après répétitive)
- l'alternative (un bloc avant condition, la fonction "true", la fonction "false", un bloc après condition

rien d'autre... et nous avons tout conceptualisé comme ça (d'ailleurs au niveau d'un assembleur il y a même moins vu qu'en gros on n'a que des débranchements sous condition).

Mais je t'accorde que le langage permet de matérialiser l'algo, et c'est bien pratique

[Uther]

Commencer un langage avant l'algorithmique est un non sens à mon avis... pourquoi ne pas changer un moteur avant de faire des cours de mécanique

Oui enfin faire de l'algorithmie sans la mise en pratique, c'est plutôt compliqué. Faire de l'algo papier ça plaira peut-être a quelque matheux, mais sans un minimum d'application pratique, c'est plutôt décourageant. Il faut voir que quand on fait de l'apprentissage, avoir l'impression que ce que l'on fait a une application est un vrai plus. Et le fait d'avoir un retour immédiat aide vraiment à appréhender le fonctionnement.

Il me semble que l'approche générale est

"Au début, en fait c'est pas tellement le langage qu'on apprend. On accepte juste les fioritures qu'il exige qu'on mette autour de nos programmes parce que c'est comme ça, en se disant qu'on pourra toujours y revenir plus tard.

On apprend les idées et quelles syntaxes sont nécessaires pour elles dans ce langage. Après seulement avoir pratiqué de l'algorithmique avec cet outil, on revient vers l'étude de comment ce langage fonctionne, et peut-être un autre aussi en même temps pour illustrer plus facilement la notion de ce qui fait partie du langage."

Pour du Java en effet on est obligé d'apprendre a recopier un squelette de base sans le comprendre, avec le risque d'avoir des erreurs difficiles à comprendre. D'ailleurs cette façon de procéder en mode : "recopie et ne te pose pas de question pour le moment", ne doit pas aider les étudiants a considérer que l'informatique c'est autre chose que du copier coller de code tout prêt.

Le Basic avec lequel j'ai débuté, ou le Python et JavaScript que l'on utilise souvent de nos jours, sont quand même plus accueillants comme premier langage. Bien sur qu'on peut continuer a apprendre la programmation avec le Java en l'état, mais ça ne veut pas dire qu'il est idiot d'essayer d’améliorer la situation.

[OButterlin]

Faire de l'algo papier ça plaira peut-être a quelque matheux

Damned, je viens discrètement de me faire traiter de matheux... je ne sais pas si j'y survivrai

le Python et JavaScript que l'on utilise souvent de nos jours, sont quand même plus accueillants comme premier langage. Bien sur qu'on peut continuer a apprendre la programmation avec le Java en l'état, mais ça ne veut pas dire qu'il est idiot d'essayer d’améliorer la situation.

D'accord sur ce point. Javascript est non seulement simple à appréhender mais il interagit directement sur le contenu d'une page html, on voit très rapidement le résultat.
Ceci dit, apprendre la POO avec javascript, c'est un peu limité... même si on arrive à faire de l'objet en javascript (j'utilise ça pour mes bibliothèques d'outils).

Pour modérer mon propos initial, disons qu'il faut un minimum de connaissances algorithmiques pour bien commencer avec un langage.

Pour l'amélioration de java, il n'y a pas de sujet (de mon point de vue), d'ailleurs il n'arrête pas de progresser.
Là où je suis plus circonspect c'est quand le progrès consiste à taper le moins de code possible, pas sûr que ce soit une idée de génie.

Pour illustrer, l'exemple de Kotlin qui propose l'inférence de type.
Je ne vois pas comment un compilateur peut déterminer correctement le type d'une variable à l'initialisation.
Si on déclare une variable val somme = 0, de quel type sera somme ? int ? double ? Comment déterminer la capacité attendue ?

[Uther]

Damned, je viens discrètement de me faire traiter de matheux... je ne sais pas si j'y survivrai

C'est pas une insulte, ca me plaisait aussi. Mais clairement c'est pas facile d’accrocher un éleve avec juste un raisonnement sur papier.

Pour illustrer, l'exemple de Kotlin qui propose l'inférence de type.
Je ne vois pas comment un compilateur peut déterminer correctement le type d'une variable à l'initialisation.
Si on déclare une variable val somme = 0, de quel type sera somme ? int ? double ? Comment déterminer la capacité attendue ?

Le type est déterminée en fonction de l'utilisation qui est faite de la variable dans le reste de son scope. Si la variable est utilisée dans comme paramètre de fonction qui attendent un Int, elle sera de type Int. Et si c'est utilisé comme paramètres par plusieurs fonctions avec des types incompatibles, ça lèvera une erreur.

[Jade Emy]

JDK 21 : la First Release Candidate est disponible.

Cette version sera l'implémentation de référence de la version 21 de la plate-forme Java SE, comme spécifié par la JSR 396 dans le processus communautaire Java

Le JDK 21 se trouve dans la Rampdown Phase Two. L'ensemble des fonctionnalités est gelé. Aucun autre JEP ne sera ciblé sur cette version.

Le dépôt de stabilisation, jdk21, est ouvert à certaines corrections de bogues, avec approbation, conformément au processus de publication du JDK (JEP 3). Les améliorations tardives sont toujours possibles, avec approbation, mais la barre est maintenant extraordinairement haute. Intégrer la plupart des changements de stabilisation via des backports depuis le dépôt principal.

• RDP 2 candidate bugs
• Processus de demande de correction
• Processus de report de bugs
• Processus de demande d'amélioration tardive

Des binaires en accès anticipé sous GPL sont disponibles ici.

Calendrier

2023/06/08 Rampdown Phase One (fork de la ligne principale)
2023/07/20 Rampdown Phase Two
2023/08/10 Initial Release Candidate
2023/08/24 Final Release Candidate
2023/09/19 General Availability

Pour le détail des nouveautés, consulter : JDK 21 Release Notes

Source : OpenJDK

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

Java 21 devrait inclure des collections séquencées et des modèles de chaînes de caractères. Le framework des collections de Java manque d'un type de collection qui représente une séquence

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

Malgré OpenJDK, 70% des correctifs et fonctionnalités Java proviennent d'Oracle, selon des statistiques d'Oracle sur les problèmes résolus dans JDK 11 - JDK 20 par organisation