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 : Oracle publie la première release candidate du JDK 12
Avec toutes les fonctionnalités majeures annoncées sauf les littéraux de chaînes bruts

Le , par Bill Fassinou

313PARTAGES

13  2 
L’annonce a été faite le 15 février par Oracle que la première version Release Candidate du JDK 12 est disponible en téléchargement pour les plateformes Linux, Mac OS et Windows. Cette version RC1 a été lancée, dit la JEP (proposition d’amélioration du JDK), dans le but de recenser les bogues qu’il pourrait y avoir ainsi que les différentes suggestions de la communauté avant sa date de disponibilité générale prévue pour le 19 mars prochain. Passons en revue sa feuille de route depuis l’annonce de sa version bêta en décembre à ce jour.

La publication de la version bêta du JDK 12 remonte à décembre dernier. À ce moment, plusieurs fonctionnalités sont apparues dans le kit de développement et plusieurs autres ont été annoncées pour la suite de sa mise au point. Cette version bêta alignait neuf nouveautés principales et quelques fonctionnalités telles que la prise en charge d'Unicode 11, un nouveau format de clé privée codée x25519 et x448 compatible avec la norme RFC 8410. Les neuf caractéristiques qui ont été présentées sont les suivantes :

  • Shenandoah : c’est un ramasse-miettes à faible temps de pause en effectuant le travail d’évacuation simultanée entre les threads java en cours d’exécution. Les temps de pause sont indépendants de la taille du tas ;
  • suite Microbenchmark : c’est un outil pour aider les développeurs à utiliser les microcritères existant déjà dans le code source du JDK ou en créer de nouveaux ;
  • expression de commutation : apporte quelques modifications à l’instruction switch pour la rendre plus flexible ;
  • littéraux de chaînes bruts : permettent aux développeurs de pouvoir utiliser des chaînes littérales brutes sans échappement ;
  • API de constantes JVM : permet d’ajouter une API pour les descriptions nominales des principaux artéfacts de classes et de fichiers de classe, en particulier les constantes pouvant être chargées à partir du pool de constantes ;

  • un apport AArch64, pas deux : sert à supprimer toutes les sources liées aux arm64port pour permettre à tous les contributeurs de concentrer leurs efforts sur une implémentation ARM 64 bits unique et d’éliminer le travail en double requis par la maintenance de deux ports ;
  • archives CDS par défaut : sert à améliorer le processus de génération JDK afin de générer une archive CDS (Class Data Sharing) à l’aide de la liste de classe par défaut sur des plateformes 64 bits ;
  • collections mélangées abandonnées pour G1 : permet d’annuler les collections d’éléments lorsqu’elles peuvent dépasser la cible de pause ;
  • retournez rapidement la mémoire validée non utilisée de G1 : améliore le récupérateur G1 pour qu’il puisse renvoyer automatiquement la mémoire heap de Java au système d’exploitation lorsqu’il est inactif.


Seulement quelques jours après cette publication, la JEP annonçait qu’une des fonctionnalités mises en avant dans la version bêta ne sera probablement plus prise en charge ou ne sera plus intégrée dans le JDK 12. Il s’agissait des littéraux de chaînes bruts pour lesquels la JEP a indiqué n’avoir pas encore trouvé le bon moyen d’implémenter cette fonctionnalité au sein du JDK 12.

« En examinant les commentaires que nous avons reçus, je ne suis plus convaincue que nous ayons encore trouvé le bon compromis entre complexité et expressivité, ou que nous en avons suffisamment exploré l’espace de conception pour être sûr que la conception actuelle est la meilleure que nous puissions faire. En le retirant, nous pouvons continuer à affiner la conception, explorer plus d'options et viser un aperçu répondant réellement aux exigences du processus de fonction de prévisualisation (JEP 12) », avait écrit dans un mail, Brian Goetz, architecte du langage Java chez Oracle.

La JEP a mis en exécution cette annonce plus tard, vers la fin du mois de décembre, en supprimant définitivement cette fonctionnalité de la préversion du JDK 12. Pour se justifier, la JEP avait listé plusieurs raisons à cette suppression. On pourrait citer par exemple le fait que les littéraux de chaîne peuvent s’étendre sur plusieurs lignes et n'interprète pas les séquences d'échappement telles que les \n correspondant aux échappements Unicode de la forme \uXXXX ou le fait que les littéraux de chaînes bruts en général ne prennent pas directement en charge l'interpolation de chaîne. De nombreux autres problèmes (par exemple les délimiteurs) liés aux littéraux de chaînes bruts avaient été cités par la JEP sur le site du OpenJDK.

Par comparaison à ses pairs, la JEP indiquait que les langages de programmation tels que C++, Groovy, JavaScript, Python pour ne citer que ceux-là utilisent des littéraux de chaîne bruts et donc, qu'elle étudie ces langages pour les délimiteurs qu’ils utilisent ou pour rechercher des représentations de chaînes. Un groupe d’internautes avaient conseillé à la JEP de regarder dans Python 3.7 pour en tricher l’implémentation des littéraux de chaînes bruts qu’ils jugent être une réussite. « En fait, je craignais que Java ne soit trop influencé par C# en ce qui concerne les chaînes. Les développeurs Java devraient regarder dans Python 3.7 et non pas C# pour de belles syntaxes de chaînes », avait-il écrit en commentaire.

D’autres par contre, étaient un peu catégoriques sur le sujet. Un parmi eux avait écrit ceci : « En termes simples, je ne vois que très peu de cas d’utilisation où les chaînes brutes pourraient être utiles, qui permettent ou encouragent de nombreuses mauvaises pratiques. Dans mon esprit, les chaînes multilignes sont encore moins utiles et ajoutent une complexité inutile (voir la section sur la gestion des marges). Je ne pense pas que ça vaille le coup ».

De nombreux tests étant faits depuis décembre passé, la RC1 vient donc d’être publiée. Elle est publiée avec les 8 fonctionnalités majeures restantes depuis la suppression des littéraux de chaînes bruts. Ce sont : Shenandoah (le ramasse-miettes à temps de pause réduit), l’API de constantes JVM, la suite Microbenchmark, l’annulation des collections mixtes pour G1, le retour rapide de la mémoire non utilisée de G1, les archives CDS par défaut, un apport AArch64 et les expressions de commutation. Toutes les fonctionnalités sont donc au rendez-vous à part bien sûr les littéraux de chaînes bruts. Vous pouvez accéder au site de l’OpenJDK pour en apprendre davantage sur cette release candidate du JDK 12 et en savoir plus sur les fonctionnalités précitées.

En septembre 2017, Oracle avait annoncé qu’il y aura à l’avenir deux versions du JDK par an du fait que Java soit en concurrence directe avec d’autres plateformes qui sont mises à jour plus souvent. Après la sortie du JDK 12 le 19 mars prochain, il y aura donc très probablement une autre version du JDK courant cette année. Ceci étant dit, il semble qu’aucune fonctionnalité n’est en vue d’être ajoutée à cette version du JDK. Beaucoup d’internautes sur Reddit se disent impatients de pouvoir tester cette version du JDK et sont curieux de savoir ce que les prochaines versions de ce dernier réservent à la communauté.

Source : OpenJDK

Et vous ?

Que pensez-vous de la RC1 de JDK 12 ?
Cette version admissible comble-t-elle vos attentes ? Pourquoi ?
Quelles autres fonctionnalités souhaiteriez-vous avoir dans le JDK 12 ?

Voir aussi

Java : le JDK 12 est disponible en version bêta, il prend en charge Unicode 11 et dispose d'un nouveau format de clé privée codé x25519 et x448

Java 12 ne prendra probablement pas en charge les littéraux de chaîne bruts, la proposition d'amélioration JDK (JEP) suggère qu'on les supprime

Les littéraux de chaîne bruts ont été supprimés de Java 12 comme l'a suggéré la proposition d'amélioration JDK (JEP)

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

Avatar de Mickael_Istria
Membre émérite https://www.developpez.com
Le 21/03/2019 à 11:05
C'est justement l'occasion ou jamais d'apprendre a utiliser un IDE open-source et durable
3  0 
Avatar de bouye
Rédacteur/Modérateur https://www.developpez.com
Le 20/03/2019 à 23:32
A noter que l'expression switch supporte également les blocs multi-lignes entre {} et qu'il faut alors utiliser l'instruction break pour faire un retour de la valeur.

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
    public void assignValue(Size size) {
        int height = 0;
        height = switch(size) {
            case S -> 18;
            case M -> {
                    int weight = 19;
                    break (weight > 10 ? 15 : 20); 
                } 
            case L, XL -> 25;
        };
    }
A noter de plus qu'il ne s'agit pas la d'une fonctionnalité définitive mais d'une fonctionnalité en aperçu (Preview Language and VM Features), ce qui veut dire que oui elle est bien complète et fonctionnelle mais peut être modifiée ou retirée d'un prochain JDK si jamais il s’avère qu'elle cause trop de soucis.

Citation Envoyé par http://openjdk.java.net/jeps/12
A preview language or VM feature is a new feature of the Java SE Platform that is fully specified, fully implemented, and yet impermanent. It is available in a JDK feature release to provoke developer feedback based on real world use; this may lead to it becoming permanent in a future Java SE Platform.
Source : blog de intellij sur le support des switch expression dans Intellij 2019.1 disponible en Early Access (la version 2018.3 fonctionne avec le JDK 12 mais ne supporte pas cette syntaxe)

EDIT - Avis perso : je pense que syntaxiquement c’était une erreur de choisir break et que return aurait été plus le bienvenu a cet endroit. Même si le mécanisme sous-jacent est probablement différent de celui des méthode, lambda et autres classe anonyme et qu'il ont fait ce choix pour des raisons d’analyse syntaxique ou de compilateur, il semble plus logique pour le programmeur moyen que la valeur renvoyée par un bloc, quel qu'il soit, se fasse de manière unifiée par une instruction return. D'un autre cote il s'agit aussi d'un bloc d'expression comme pour similaire a un for ou un while et donc ça pourrait poser le soucis que ça laisserait penser a ce que cette instruction sorte de la méthode englobant le switch.
1  0 
Avatar de bouye
Rédacteur/Modérateur https://www.developpez.com
Le 21/03/2019 à 12:51
J'ai la version 2018.3 Community de Intellij IDEA et il fonctionne très bien avec les JDK 9, 10, 11 et 12 juste qu'il ne supporte le switch expression. La version 2019.1 qui est dispo sur le canal early access est sensé le supporter. Intellij IDEA ne supporte pas JLink par contre. Le supporte des modules fonctionne plutôt bien dans Intellij.

Apache NetBeans 10 supporte les JDK 8, 9 et 10 mais pas trop 11 il me semble (à vérifier) et encore moins le 12 (il me semble que c'est prévu pour NetBeans 11 d'après la roadmap chez Apache). Apache NetBeans supporte JLink et couplé avec le JDK 8 supporte très bien javapackager. Le support des modules est défaillant dans Apache NetBbeans lorsqu'on utilise des legacy jar avec noms de modules auto-générés, pour une raison que je ne m'explique pas Apache NetBeans n'utilise pas la même règle de génération de nom de module que le JDK.
1  0 
Avatar de atha2
Membre éprouvé https://www.developpez.com
Le 21/03/2019 à 0:55
Citation Envoyé par bouye Voir le message
A noter que l'expression switch supporte également les blocs multi-lignes entre {} et qu'il faut alors utiliser l'instruction break pour faire un retour de la valeur.

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
    public void assignValue(Size size) {
        int height = 0;
        height = switch(size) {
            case S -> 18;
            case M -> {
                    int weight = 19;
                    break (weight > 10 ? 15 : 20); 
                } 
        };
    }
EDIT - Avis perso : je pense que syntaxiquement c’était une erreur de choisir break et que return aurait été plus le bienvenu a cet endroit. Même si le mécanisme sous-jacent est probablement différent de celui des méthode, lambda et autres classe anonyme et qu'il ont fait ce choix pour des raisons d’analyse syntaxique ou de compilateur, il semble plus logique pour le programmeur moyen que la valeur renvoyée par un bloc, quel qu'il soit, se fasse de manière unifiée par une instruction return. D'un autre cote il s'agit aussi d'un bloc d'expression comme pour similaire a un for ou un while et donc ça pourrait poser le soucis que ça laisserait penser a ce que cette instruction sorte de la méthode englobant le switch.
J'imagine que les parenthèse sont optionnelles et qu'on peut écrire :
Code : Sélectionner tout
1
2
break weight > 10 ? 15 : 20;
?
Perso sans parler de l'aspect technique qui ne me parait pas pertinent dans le choix du mot clé, le choix du mot clé "break" me parait plus pertinent que "return". Pour interrompre le file d’exécution d'une méthode, on utilise le mot clé "return". Pour interrompe le file d’exécution d'une structure de contrôle (while, for switch), on utilise "for" (voir "continue".

Sinon plutôt (ou en complément) que break une autre syntaxe pourrait être pertinente :
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
    public void assignValue(Size size) {
        int height = 0;
        height = switch(size) {
            case S -> 18;
            case M -> {
                    int weight = 19;
                    weight > 10 ? 15 : 20; 
                } 
        };
    }
Comme dans pas mal de langage fonctionnel, l'évaluation d'un bloc d'instruction correspond à l’évaluation de la dernière instruction de ce bloc. Mais j'imagine qu'autoriser ça dans ce contexte forcerai à modifier le comportement des lambdas et du "return" classique afin d'uniformiser le langage.
0  0 
Avatar de DaTheWolf
Membre du Club https://www.developpez.com
Le 21/03/2019 à 7:35
Voilà,

Pour les nouveautés ça a l'air chouette. Surtout l'amélioration du GC, qui me laisse espérer pour certains de mes projets.
Mon problème est que j'utilise un IDE payant, et je ne peux pas renouveler ma licence pour l'instant. L'IDE JetBrains ne reconnaît la string de version "10" "11" "12" parce que ... raison commerciale certainement en 2019.

Connaissez-vous un patch? Parce que Eclipse et Netbeans je ne sais pas les utiliser.

PS il y a bien une version gratuite des produits JetBrains pour une utilisation libre (ce qui est mon cas) mais apparemment quand on a payé une licence on ne sait pas rétrograder.
0  0 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 25/03/2019 à 12:51
Les expressions switch ressemblent comme deux gouttes d'eau à celles qui arrivent en C# 8 (juste les flèches qui sont différentes : "->" en Java, "=>" en C#). Quant à savoir qui a copié l'autre, je ne m'avancerai pas... de toute façon Java et C# se sont toujours piqué des idées
0  0 
Avatar de Mickael_Istria
Membre émérite https://www.developpez.com
Le 25/03/2019 à 13:11
Eclipse IDE 2019-03 supporte bien Java 12 (et les switch expressions) en lui ajoutant cette extension: https://marketplace.eclipse.org/cont...se-2019-03-411
0  0