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

4PARTAGES

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-le nous !