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

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

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

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

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

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

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

Je m'inscris !

Java : 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

Le , par Bill Fassinou
28 commentaires

831PARTAGES

12  0 
Oracle a rendu disponible une version expérimentale du JDK 12 sur les plateformes Linux, Windows et MacOS pour tester les nouvelles fonctionnalités apportées et les améliorer en cas de besoin avant la date de sortie générale qui est prévue pour le 19 mars 2019. En septembre 2017, Oracle annonçait 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. La firme a tenu parole puisque après avoir lancé, il y a quelques mois environ, la version 11 de sa plateforme Java SE, le JDK 12 vient d’être présenté en bêta test.

Rappelons que la plateforme Java SE est composée de JSR (définissant les spécifications de Java), JDK (comprenant les bibliothèques logicielles de Java), JRE (l’environnement d’exécution de Java également inclus dans JDK) et intègre des améliorations techniques avec les nouvelles fonctionnalités telles que la prise en charge d’une nouvelle forme de pool de constante CONSTANT_Dynamic, le mot clé var pour la déclaration des paramètres formels d’une expression typée implicitement et un “gabage collector” ou ramasse-miettes Epsilon pour générer l’allocation de mémoire sans implémenter de mécanismes de récupération de mémoire.


Le JDK 12 est présenté comme une implémentation de référence de la version 12 de la plateforme Java SE. Il est caractérisé par neuf nouveautés et de nouvelles fonctionnalités telles que la prise en charge de Unicode 11 donc plus amélioré que le JDK 11 (qui prend en charge Unicode 10), l’annulation de la valeur par défaut keytool-keyalg, un nouveau format de clé privée codé x25519 et x448 compatible avec la norme RFC 8410. On compte en tout neuf caractéristiques essentiels du JDK 12 :

  • 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 micro-critè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 : permet aux développeurs de créer leurs propres littéraux et de les ajouter au langage ;
  • 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.

Il intègre également des nouveaux apports et des modifications majeures comme un nouvel indicateur de ligne de commande pour un rapport d’erreur plus étendu dans les journaux d’incidents, la propriété système user.timezone a été modifiée et peut maintenant renvoyer une valeur null selon sa configuration ou encore de nouvelles options d’interdiction et d’autorisation pour la propriété système java.security.manager et bien d’autres.

Oracle a pris la peine de décrire chaque fonctionnalité pris en compte par le JDK 12 et notifie cependant que ce dernier ne prend pas encore en compte le formatage de nombre compact. Il faut savoir que le formatage de nombre compact fait référence à la représentation d’un nombre sous une forme courte ou lisible par l’homme.
Il encourage les développeurs à tester le l’outil et à faire part de leurs commentaires et suggestions par rapport à d’éventuels problèmes ou bugs rencontrés afin d’aider à le peaufiner et a mis à la disposition de la communauté une page dédiée qui présente les résultats des tests toutes les semaines.

Source : JDK 12, Note de version

Et vous ?

Êtes-vous un développeur Java ? Que pensez-vous de ces fonctionnalités de la version bêta du JDK 12 ?
L'avez-vous déjà testé ? Partagez avec nous vos impressions

Voir aussi

Andrew Haley de Red Hat donne son avis sur l'avenir d'OpenJDK, l'implémentation libre de Java SE, après la sortie de JDK 11 sous licence commerciale

JDK 11 : trois nouveautés sont prévues ainsi que la suppression de JAVA EE, JavaFX et CORBA, dans le cadre des mises à jour semestrielles

JDK 10 : les fonctionnalités de la prochaine version de Java sont désormais gelées, la sortie est attendue pour le 20 mars 2018

Java 8 ne va plus recevoir de mises à jour et correctifs de sécurité à partir de septembre à moins de passer à un support commercial

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

28 commentaires
Commenter Signaler un problème
Uther
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 14/12/2018 à 6:05
Citation Envoyé par tomlev  Voir le message
Ils se prennent bien la tête pour pas grand chose. La syntaxe C# est très simple (un préfixe @ avant le début de la chaine) et ne pose pas de souci majeur. Après je ne connais pas les spécificités de la feature qui était prévue pour Java, donc il est possible que quelque chose m'ait échappé...

Le fonctionnement de C# a en effet l'avantage d'être simple, mais il n'est pas parfait, loin de là. La syntaxe des chaines préfixées par @ de C# n'est d'ailleurs pas un "raw string" dans le sens ou on l'entend en général, vu que le guillemet doit-être échappé.
Ce qu'on appelle habituellement, une "raw string", c'est une séquence de caractère sans aucune séquence d’échappement. C'est les délimiteurs de la séquence qui varient suivant le besoin du contenu.

Par exemple en Rust les chaines brutes sont préfixées par "r" et autant de "#" qu'il doit y en avoir après le guillemet fermant.
Code Rust : Sélectionner tout 
1
2
3
4
let chaine_brute1 = r"Chaine pouvant contenir des \  sans échappement"; 
let chaine_brute2 = r#"Chaine pouvant aussi contenir des " sans échappement "#; 
let chaine_brute3 = r##" Chaine pouvant aussi contenir un "# sans échappement "##; 
...

De ce que j'ai compris du message de Brian Goetz, Java avait prévu d'utiliser le même nombre de backquote en début et fin de chaine, ce qui aurait donné:
Code text : Sélectionner tout 
1
2
3
4
 
var chaine_brute1 = `Chaine pouvant contenir des \ et " sans échapement`; 
var chaine_brute2 = ``Chaine pouvant aussi contenir des ` sans échappement``; 
var chaine_brute3 = ```Chaine pouvant aussi contenir des `` sans échappement```;

Pour moi, certains des argument de Brian Goetz sont convaincants :
  • il n’y pas de voie directe pour démarrer ou de terminer un littéral de chaîne brute avec un backquote
  • il n’y plus beaucoup de caractères de ponctuation non utilisés en Java et il faudrait peut être garder la backquote pour d'autres futur usages. (l'argument est présent dans le message originel mais pas repris dans l'article developpez.com)


Pour les autres points, je suis moins d'accord, notamment parce que la coloration syntaxique résout la plupart des problèmes évoqués
4  0 
adiGuba
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 13/12/2018 à 20:22
@tomlev : le problème c'est justement le préfixe. Et c'est leurs boulots de se prendre la tête 😉

La solution de C# impose de doubler toutes les double-quotes de la chaîne, et l'objectif étant justement d'éviter cela...

Le ` a l'avantage d'être un peu moins utilisé (quoique).
Mais j'aime pas trop la syntaxe...
3  0 
Gugelhupf
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 13/12/2018 à 21:48
Le JDK12 offre une feature assez intéressante avec le Switch Expressions (JEP 325)

Avant :
Code : Sélectionner tout 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
int numLetters;
switch (day) {
    case MONDAY:
    case FRIDAY:
    case SUNDAY:
        numLetters = 6;
        break;
    case TUESDAY:
        numLetters = 7;
        break;
    case THURSDAY:
    case SATURDAY:
        numLetters = 8;
        break;
    case WEDNESDAY:
        numLetters = 9;
}
Avec Java 12:
Code : Sélectionner tout 
1
2
3
4
5
6
int numLetters = switch (day) {
    case MONDAY, FRIDAY, SUNDAY -> 6;
    case TUESDAY                -> 7;
    case THURSDAY, SATURDAY     -> 8;
    case WEDNESDAY              -> 9;
};
3  0 
adiGuba
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 15/12/2018 à 6:56
Citation Envoyé par ijk-ref Voir le message
Ceci casserait l'habitude de pouvoir travailler notre code avec un simple éditeur de texte mais serait-ce si mal ?
Perso je ne souhaite pas cela du tout.
Qu'un EDI fassent une coloration syntaxique c'est une chose, mais il faut rester sur un format texte !

Déjà cela aurait un impact énorme sur l'écosystème, puisqu'il faudrait adapter tous les EDI et tous les outils manipulant le source, et ça fait beaucoup de monde !

Mais en plus on perdrait toute la simplicité du format texte, simplement pour "cacher" un séparateur.
Impossible de manipuler ou de générer du code à la volé de manière simple, car outre la structure du code il faudrait respecter ce nouveau format...
3  0 
Mickael_Istria
Avatar de Mickael_Istria
Membre expert 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 
kbadache
Avatar de kbadache
Membre confirmé https://www.developpez.com
Le 13/12/2018 à 21:54
Citation Envoyé par redcurve Voir le message
On parle de java la moindre fonctionnalité est un immense bordel infâme bref rien de nouveau sous la tasse de café
Juste que ceux qui développent Java essaient de voir un peu plus loin que "Cette feature est trop génial, on l'a rajoute".
Rétrocompatibilité, utilisabilité, évolution futur...
2  0 
adiGuba
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 16/12/2018 à 17:55
Mais on en revient au même point :
  • Le code affiché dans l'EDI ne correspond pas au code contenu dans le fichier source (et c'est pas forcément souhaitable)
  • C'est une fonctionnalité d'un EDI, alors qu'on parle d'une fonctionnalité du langage indépendante d'un quelconque éditeur...
2  0 
adiGuba
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 16/12/2018 à 8:57
Citation Envoyé par ijk-ref Voir le message
Qu'est ce qui définit un format texte ? Rien n'empêcherait d'en avoir un avec des "flags" sur les caractères.
Ben un format texte c'est un fichier constitué de caractères, donc ces flags seraient des caractères et c'est exactement de quoi il est question : comment choisir ces caractères en gardant une bonne lisibilité et sans avoir à utiliser de caractères d'échappement (ou le moins possible).

Citation Envoyé par ijk-ref Voir le message
Sinon on peut aussi rester sur un format de texte classique mais l'EDI nous cachant la complexité des caractères d'échappements.

A l'instar de la touche "Verr Maj" un double clique sur la touche ["] pourrait nous mettre en mode "entrée de texte" et on pourrait écrire vraiment n'importe quoi même faire des retours à la lignes tant qu'on ne re double clique pas sur la touche ["] pour revenir en mode "code". En interne ça écrirait du code normal.
Sauf que ça c'est une fonctionnalité de l'EDI, et non pas du langage.
Rien n'empêche un EDI de proposer cela dès maintenant... Mais on n'aurait plus une correspondance exact entre le code visible dans l'EDI et le fichier source...

Citation Envoyé par ijk-ref Voir le message
Si vous avez déjà écrit des expressions régulières, déjà que c'est assez dur de les relire, alors entre les caractères d'échappements du format texte... et ceux des expressions cela devient vite le bordel. Si il y avait un moyen (comme je viens de présenter) de les supprimer rendant le code plus lisible ce serait bien mieux.
Ben c'est exactement l'objectif de la proposition.
`a\. "hello" ` serait l'équivalent de "a\\. \"hello\"" .

Et le problème relevé, c'est que si ça marche super bien pour les expressions régulières, ça peut poser problème pour d'autres types de codes utilisant le caractère ` comme des scripts shell ou du SQL...

Le rythme des 6 mois entre chaque version permet de décaler ça pour y réfléchir encore un peu...
1  0 
Uther
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 16/12/2018 à 10:18
Citation Envoyé par ijk-ref Voir le message
Quelqu'un a-t-il déjà suggéré une approche différente : la mise en forme de texte ?

Habituellement utilisé (dans les traitements de textes) pour souligner, mettre en gras ou en italique. Elle pourrait servir pour désigner (au compilateur) ce qui est du texte. Il n'y aurait donc plus besoin naturellement de séquences d'échappement.

Ceci casserait l'habitude de pouvoir travailler notre code avec un simple éditeur de texte mais serait-ce si mal ?
Les IDE font déjà ça en partie : c'est la coloration syntaxique.

Ils peuvent théoriquement aller plus loin et faire ce que vous préconisez. Il convertiraient le texte formaté en Java classique, ainsi, il n'y aurait même pas besoin de modifier le langage Java lui même. Mais ils ne le font pas car au final, ça n'est pas plus pratique pour les développeurs.

Gérer de la mise en forme de texte au clavier, ça n'est pas pratique et avec la souris, c'est moins productif. Personnellement, j'ai assez d'ennuis avec le formatage de textes Word, j'ai pas envie d'avoir les même soucis en programmant. D'ailleurs, sous Word je finis souvent par faire afficher les caractères cachés.
1  0 
bouye
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 
Commenter Signaler un problème