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

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

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

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

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

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

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

Je m'inscris !

Oracle Technologie annonce la sortie de JDK 19 avec des nouvelles propriétés système,
Pour System.out et System.err et la prise en charge d'Unicode 14.0

Le , par Bruno

6PARTAGES

5  0 
Oracle Technologiea annoncé que le JDK 19 était désormais complet, car il a atteint la phase initiale de lancement. Sept fonctionnalités pour cette version, notamment la concurrence structurée, les modèles d'enregistrement, un aperçu d'une fonction étrangère et d'une API de mémoire, ainsi que la prise en charge de l'architecture de jeu d'instructions (ISA) Linux/RISC-V. Java 19 sera disponible en septembre 2022.


Conformément au calendrier de sortie du JDK 19, Mark Reinhold, architecte en chef du groupe Java Platform d'Oracle, a annoncé que les ajouts à la prochaine version du kit de développement sont terminés. Pour rappel, une nouvelle version standard de Java est publiée tous les six mois. Avec cette dernière étape dans le processus de publication de la version standard de Java, les autres fonctionnalités prévues, telles que les génériques universels et les objets de valeur, devront attendre une version ultérieure de la plateforme. Les nouvelles fonctionnalités du JDK 19 comprennent :

Schémas de signature

security-libs/javax.net.ssl

De nouvelles API Java SE, javax.net.ssl.getSignatureSchemes() et javax.net.ssl.setSignatureSchemes(), ont été ajoutées pour permettre aux applications de personnaliser les schémas de signature utilisés dans les connexions TLS ou DTLS individuelles. Le fournisseur sous-jacent peut définir les schémas de signature par défaut pour chaque connexion TLS ou DTLS.


Les applications peuvent également utiliser les propriétés système existantes jdk.tls.client.SignatureSchemes et/ou jdk.tls.server.SignatureSchemes pour personnaliser les schémas de signature par défaut spécifiques au fournisseur. S'ils ne sont pas nuls, les schémas de signature transmis à la méthode setSignatureSchemes() remplaceront les schémas de signature par défaut pour les connexions TLS ou DTLS spécifiées.

Un fournisseur peut ne pas avoir été mis à jour pour prendre en charge les nouvelles API et dans ce cas, il peut ignorer les schémas de signature définis. Le fournisseur JDK SunJSSE prend en charge cette méthode. Il est recommandé aux fournisseurs tiers d'ajouter la prise en charge de ces méthodes lorsqu'ils ajoutent la prise en charge du JDK 19 ou des versions ultérieures.

Nouvelles propriétés système pour System.out et System.err

core-libs/java.lang

Deux nouvelles propriétés système, stdout.encoding et stderr.encoding, ont été ajoutées. La valeur de ces propriétés système est l'encodage utilisé par les flux de sortie standard et d'erreur standard (System.out et System.err). Les valeurs par défaut de ces propriétés système dépendent de la plateforme. Les valeurs prennent la valeur de la propriété native.encoding lorsque la plate-forme ne fournit pas de flux pour la console. Les propriétés peuvent être remplacées par l'option de ligne de commande du lanceur (avec -D) pour les définir en UTF-8 lorsque cela est nécessaire.

Prise en charge d'Unicode 14.0

core-libs/java.lang

Cette version met à jour la prise en charge d'Unicode à 14.0, ce qui inclut les éléments suivants : la classe java.lang.Character prend en charge la base de données de caractères Unicode du niveau 14.0, ce qui ajoute 838 caractères, pour un total de 144 697 caractères. Ces ajouts incluent 5 nouveaux scripts, pour un total de 159 scripts, ainsi que 37 nouveaux caractères emoji. Les classes java.text.Bidi et java.text.Normalizer prennent en charge le niveau 14.0 des annexes standard Unicode, respectivement #9 et #15. Le paquet java.util.regex prend en charge les grappes de graphèmes étendues basées sur le niveau 14.0 de l'annexe standard Unicode #29. Pour plus de détails sur Unicode 14.0, reportez-vous à la note de publication du Consortium Unicode.

Prise en charge de la liaison de canal HTTPS pour Java GSS/Kerberos

core-libs/java.net

La prise en charge des jetons de liaison de canal TLS pour l'authentification Negotiate/Kerberos sur HTTPS a été ajoutée via javax.net.HttpsURLConnection. Les jetons de liaison de canal sont de plus en plus nécessaires comme forme de sécurité renforcée. Ils fonctionnent en communiquant d'un client à un serveur la compréhension par le client de la liaison entre la sécurité de la connexion, représentée par un certificat de serveur TLS, et les informations d'authentification de niveau supérieur, telles qu'un nom d'utilisateur et un mot de passe. Le serveur peut alors détecter si le client a été trompé par un MITM et interrompre la session ou la connexion. Cette fonctionnalité est contrôlée par une nouvelle propriété système jdk.https.negotiate.cbt qui est décrite en détail dans Propriétés de mise en réseau.

Formats de date et d'heure supplémentaires

core-libs/java.time

Des formats de date/heure supplémentaires sont maintenant introduits dans les classes java.time.format.DateTimeFormatter/DateTimeFormatterBuilder. Dans les versions précédentes, seuls 4 styles prédéfinis, à savoir FormatStyle.FULL/LONG/MEDIUM/SHORT, étaient disponibles.

Maintenant, les utilisateurs peuvent spécifier leur propre style flexible avec la nouvelle méthode DateTimeFormatter.ofLocalizedPattern(String requestedTemplate). Par exemple, DateTimeFormatter.ofLocalizedPattern("yMMM" produit un formateur capable de formater une date d'une manière localisée, comme "Feb 2022" dans la locale américaine ou "2022年2月" dans la locale japonaise. La méthode DateTimeFormatterBuilder.appendLocalized(String requestedTemplate) est également fournie.

Support de la protection PAC-RET sur Linux/AArch64

hotspot/compilateur

Le support de la protection PAC-RET sur la plateforme Linux/AArch64 a été introduit. Lorsqu'il est activé, OpenJDK utilisera les caractéristiques matérielles de l'extension PAC (Pointer Authentication Code) ARMv8.3 pour se protéger contre les attaques ROP (Return Orientated Programming). Pour plus d'informations sur l'extension PAC, voir "Providing protection for complex software" ou « la section Pointer authentication in AArch64 state » dans le ARM Arm.

Pour profiter de cette fonctionnalité, OpenJDK doit d'abord être construit avec l'option de configuration --enable-branch-protection en utilisant GCC 9.1.0+ ou LLVM 10+ . Ensuite, l'indicateur d'exécution -XX:UseBranchProtection=standard activera la protection PAC-RET si le système la prend en charge et si le binaire Java a été compilé avec la protection des branches activée ; sinon l'indicateur est ignoré en silence. Alternativement, -XX:UseBranchProtection=pac-ret activera également la protection PAC-RET, mais dans ce cas, si le système ne la prend pas en charge ou si le binaire java n'a pas été compilé avec la protection des branches activée, un avertissement sera imprimé.

Prise en charge de l'architecture de jeu d'instructions Linux/RISC-V

RISC-V est une architecture de jeu d'instructions (ISA) RISC libre et open source, conçue à l'origine à l'Université de Californie, Berkeley, et maintenant développée en collaboration sous le parrainage de RISC-V International. Elle est déjà prise en charge par un large éventail de chaînes d'outils de langage. Selon l'équipe du JDK, avec la disponibilité croissante du matériel RISC-V, un portage du JDK serait précieux. Avec le portage Linux/RISC-V, Java obtiendrait la prise en charge d'un jeu d'instructions matérielles qui est déjà pris en charge par un large éventail de chaînes d'outils de langage.

RISC-V est en fait une famille d'ISA connexes. Le portage Linux/RISC-V ne prendrait en charge que la configuration RV64GV de RISC-V, un ISA 64 bits à usage général qui inclut des instructions vectorielles. Les développeurs de Java pourraient envisager d'autres configurations RISC-V à l'avenir.

Génération automatique de l'archive CDS

hotspot/runtime

L'option JVM -XX:+AutoCreateSharedArchive peut être utilisée pour créer ou mettre à jour automatiquement une archive CDS pour une application. Par exemple : java -XX:+AutoCreateSharedArchive -XX:SharedArchiveFile=app.jsa -cp app.jar App L'archive spécifiée sera écrite si elle n'existe pas, ou si elle a été générée par une version différente du JDK. Dans une interview accordée à The Register, Georges Saab, SVP d'Oracle chargé du développement de la plate-forme Java et président du conseil d'administration d'OpenJDK, a déclaré qu'il s'agissait de la dixième version réalisée dans le cadre du cycle de publication de six mois.

« Toutes ces versions sont sorties à la date et à l'heure prévues », a déclaré Saab. « Il n'y a eu aucun retard depuis que nous sommes passés à ce modèle, ce qui, comme vous le savez probablement, n'était pas toujours le cas avec le modèle précédent que nous avions. » Saab a déclaré que le résultat est de pouvoir mettre l'innovation entre les mains des développeurs plus rapidement que ce qui était possible pendant les cycles de publication pluriannuels.

« Par le passé, ils devaient souvent attendre assez longtemps pour obtenir des nouveautés en Java, puis ils en recevaient trop, d'un seul coup », a-t-il expliqué. « Nous sommes conscients que tout le monde n'a pas envie de tout rebaser tous les six mois », a ajouté Saab. « C'est pourquoi nous avons proposé un abonnement à Java SE pour un support à long terme, afin de permettre aux entreprises qui le souhaitent de rester sur une seule version et de recevoir des mises à jour tous les trimestres, pour assurer leur sécurité.

Le cycle de publication accéléré de Java ne signifie pas nécessairement que les nouvelles fonctionnalités apparaissent soudainement. Elles font souvent surface en tant que technologies de prévisualisation, afin de susciter des réactions de la communauté et des ajustements dans les versions suivantes. « Nous n'avons pas trouvé un moyen magique de faire trois ou quatre ans de travail en six mois », a expliqué Saab. Ainsi, le processus de développement de Java est devenu itératif et participatif, même s'il permet aux membres de la communauté d'attendre la sortie des versions pour que les fonctionnalités mûrissent.

Les améliorations sur lesquelles se concentre la communauté Java ont été organisées autour de thèmes spécifiques. « À titre d'exemple », explique Saab, « le projet Amber vise à améliorer le langage et la syntaxe Java, afin de les rendre plus modernes, plus succincts, plus faciles à utiliser et, surtout, plus faciles à lire et à comprendre. Leyden vise à améliorer le temps de démarrage et le temps de chauffe. Loom porte sur l'évolutivité et fait passer l'évolutivité de Java au niveau supérieur. »

Dans Java 19, ces projets thématiques sont exprimés dans diverses propositions d'amélioration de Java, ou JEP.

Source : Java

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

JDK 18, l'implémentation de référence de Java 18, est désormais disponible, elle propose comme Python, Ruby, PHP ou encore Erlang, un mini serveur Web prêt à l'emploi

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

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

Avatar de thelvin
Modérateur https://www.developpez.com
Le 04/12/2022 à 17:06
Ben oui mais alors tu fais des reproches à Java que tu ne fais jamais à rien d'autre.

Tous les systèmes fonctionnent comme ça, avec ces effets, depuis que tu existes. Mais maintenant c'est Java ta tête de turc.

Tu reproches littéralement à Java de ne pas être resté à la version que tu t'es mis à utiliser à un moment, puisque par définition de nouvelles versions ça veut dire des changements, et que par définition un changement fait qu'un truc qui comptait sur le fait que ce soit pas comme ça, se met à ne plus marcher. Ça signifie qu'aucun effort de compatibilité ascendante n'est parfait, comme notamment ça n'a jamais été particulièrement bon dans aucune chose que tu aies jamais utilisée. Et pourtant ce n'est pas à tout le reste que tu fais des reproches.

Et sinon, si quelque chose ne marche pas en changeant la version "canonique" de Java installée sur un système, il suffit de ne pas la changer en installant d'autres versions. Rien de malsain là-dedans.
1  0 
Avatar de smillien62
Futur Membre du Club https://www.developpez.com
Le 15/11/2022 à 12:21
Pour basculer la console Windows en UTF-8 :
chcp 65001
0  0 
Avatar de grunt2000
Membre éclairé https://www.developpez.com
Le 01/12/2022 à 19:35
Les amis, mais connaissez-vous une entreprise qui utilise java 17 en production ?
Si c'est le cas, c'est à l'unité. Rien n'est compatible avec lui, et de loin :
chaque ligne commande pour lancer un traitement existant s'agrémente de

Code : Sélectionner tout
1
2
3
4
5
6
java --add-exports java.base/sun.nio.ch=ALL-UNNAMED \
   --add-opens java.base/java.util=ALL-UNNAMED \
   --add-opens java.base/java.nio=ALL-UNNAMED \
   --add-opens java.base/java.lang=ALL-UNNAMED \
   --add-opens java.base/java.lang.invoke=ALL-UNNAMED \
   -jar leProgramme.jar
Alors, Java 19, quand il y a zéro utilisateurs de Java 17... À quoi bon...
Depuis le flop des modules, les choix sont discutables.
0  0 
Avatar de thelvin
Modérateur https://www.developpez.com
Le 02/12/2022 à 5:52
Hello,

on est pas encore en prod mais on utilise Java 17 pour nos versions en cours de release, et on a pas détecté de problème de ce genre-là.
C'est pas en prod, mais c'est en dev, QA, staging et on attaque la pré-prod lundi.

On notera :

- que nous on n'utilise pas les modules, du coup oui c'est pas surprenant qu'on ait pas ce problème-là.
- que des bibliothèques populaires de l'écosystème Java qui comptent comme module sans nom, il en reste plus franchement des quantités. (Au boulot on utilise pas les modules, mais je le fais à titre perso et elles ont toutes un nom.)
- qu'on est pas censé utiliser les classes fournies par la JVM en dehors des packages java et javax. Et que ça fait plus de 15 ans que tout le monde s'en passe sans problème.
0  0 
Avatar de grunt2000
Membre éclairé https://www.developpez.com
Le 02/12/2022 à 22:22
Je vois ça avec les exécutables existants que j'ai à droite et à gauche dans l'entreprise.

Je ne peux pas dire chacun de quels dépendances ils sont faits qui amènent quels problèmes, parce qu'avec les dépendances, par Maven, l'une tire l'autre et une application peut rassembler souvent 20 à 50 jars.
Simplement, constater qu'ils ne se lancent pas du premier coup, sans réglages.

Il y a peu, j'essayais Spark et Zeppelin : eh bien, aucun ne passe en Java 17. Java 17 n'assure pas la compatibilité ascendante. En tous cas, pas instantanément : il faut faire des réglages pour avoir un fonctionnement correct, ce qui implique d'avoir la capacité d'intervenir sur toutes les applications : retrouver leurs .sh de lancement, pour les adapter. Faut avoir le temps et l'envie.

Le problème, c'est pas de passer un programme en Java 17.
Mais que tous les programmes qui sont sur son PC ou serveur le supportent : parce que c'est rare (et pas sain) les machines avec deux JDK ou Java de versions différentes qui fonctionnent conjointement. Donc on préfère migrer un bon coup.
Et là, c'est vraiment pas parti pour. Java 17 m'a l'air d'être un flop, ce qui m'interroge sur la suite de Java. Java 19 ? À quoi bon ? Si personne n'est sur le 17 ?
0  0 
Avatar de thelvin
Modérateur https://www.developpez.com
Le 03/12/2022 à 15:52
Oui ben dans les faits il y a beaucoup d'environnements d'accord avec toi et beaucoup qui ne le sont pas. Notamment parce qu'un certain nombre d'outils ne sont pas en Java, et que ceux qui le sont, c'est bien de dire "on a pas envie de toucher" mais il y a ce truc qui s'appelle "sécurité" et donc si tu touches pas à un truc pendant plus d'un an, c'est que tu te dis que quiconque s'en sert devrait se faire pirater plus souvent.

Au passage soyons précis : Java 17 assure très bien la compatibilité ascendante. C'est Java 9 qui ne l'assure pas top, et très très mal si on utilise les modules. Dans la mesure où Java 9 n'est pas à support longue durée, on peut dire alors que c'est Java 11. Aucune difficulté pour passer de Java 11 à une version plus tardive.

Au passage également, s'il y a mention de java.base/sun.nio.ch ce n'est pas Java qui n'a pas assuré la compatibilité, c'est l'auteur. Il savait très bien que les chances de compatibilité ascendantes seraient réduites et si elles marchent ce ne serait que par chance, et il a décidé que c'est ce qu'il voulait. A ce niveau-là, corriger les failles de sécurité c'est casser la compatibilité. Et si moi je voulais que ce vecteur d'attaque fonctionne sur mon environnement, hein ?

Mais que tous les programmes qui sont sur son PC ou serveur le supportent : parce que c'est rare (et pas sain) les machines avec deux JDK ou Java de versions différentes qui fonctionnent conjointement.
Ça m'a tout l'air d'un culte cargo. Qui dit ça et pourquoi ?
0  0 
Avatar de grunt2000
Membre éclairé https://www.developpez.com
Le 04/12/2022 à 7:43
Tout simplement parce que quand tu vas changer la version Java sur ton PC, c'est tous les logiciels tournant autour de Java qui vont l'utiliser, en particulier, ceux dont tu n'as pas conscience.

Et typiquement, je voulais passer à Java 17 pour un logiciel que je développais et qui était parfaitement compatible avec, mais quand j'ai dit à mon PC "maintenant c'est Java 17",
alors un certain nombre d'autres logiciels basés sur Java se sont mis à dysfonctionner.

Alors je peux dire : "Apache Zeppelin, c'est de votre faute !",
"Société xyz, qui m'avez remis le traitement de texte Schtroumpf, basé sur Java, vous êtes responsables !"
"Fournisseur du driver JDBC pour la base truc, vous auriez du prévoir !"
....

La chance que je leur écrive des courriers/mails est faible, qu'ils adaptent leurs logiciels/dépendances, existante, mais dans un avenir incertain.

Quand je mets tout en balance, je préfère considérer que le fautif est Java 17, qui n'assure pas la compatibilité ascendante parfaitement avec ses versions précédentes, les rendant immédiatement inutilisables, ce qui est problématique.

Ça, c'est incontestable et observable rapidement sur tout poste où l'on fait la substitution de JDK, pour changer le 11 en 17 ou plus => une part conséquente des applications présentes ne se lanceront plus, pour des problèmes sibyllins de dépendances qui ne le supportent pas.
Cela pousse forcément les détenteurs de postes de travail qui doivent rester opérationnels, à écarter Java 17, qui pour le moment ne permet pas de garantir le bon fonctionnement de toutes les applications.
0  1