Modifications de la version Java 8

Principales nouveautés de la version Java 8

Cet article s'applique aux éléments suivants:

Plate(s)-forme(s): Aucune
Navigateur(s): Aucune
Version(s) de Java: 8.0

Cette page présente les principales modifications influant sur l'expérience utilisateur dans toutes les versions de Java. Pour plus d'informations sur les modifications, reportez-vous aux notes sur la version.
» Dates de publication des versions de Java

Java 8 Update 441 (8u441)

Principales nouveautés de cette version

JDK 8u441 contient des données de fuseau horaire IANA 2024b.
Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
JavaFX ne sera plus inclus dans JDK/JRE 8
Cette version, JDK et JRE 8 Update 441, est la dernière à intégrer JavaFX. Comme annoncé en 2020, la prise en charge de JavaFX sur JDK 8, la dernière version de JavaFX commercialement prise en charge d'Oracle, prendra fin en mars 2025. Par conséquent, JDK 8 Update 441 est la dernière mise à niveau de JDK/JRE 8 avec JavaFX. Oracle continue de développer et de publier des versions (release) de JavaFX sous forme de modules autonomes via le projet OpenJFX pour les dernières versions de Java uniquement. Pour plus de détails, reportez-vous à Mise à jour du plan d'informations relatif à Java SE (printemps 2024).
Autres notes : prise en charge de la base de données de fuseaux horaires 2024b
La base de données de fuseaux horaires IANA a été mise à niveau vers 2024b. Cette version comprend principalement des modifications visant à améliorer les données historiques pour le Mexique, la Mongolie et le Portugal. Elle modifie également l'abréviation d'un horodatage, pour le fuseau horaire 'MET'. Par ailleurs, Asie/Choybalsan est désormais un alias pour Asie/Oulan-Bator.
Reportez-vous à JDK-8339637

Maintien à jour du JDK

Oracle recommande de mettre à jour le JDK à chaque mise à jour de patches critiques. Pour déterminer si une version donnée est la dernière, vous pouvez utiliser la page Niveau de sécurité nécessaire afin d'identifier la dernière version de chaque famille de versions.

Les mises à jour des patches critiques, qui contiennent des corrections de vulnérabilité de sécurité, sont annoncées un an à l'avance sur Mises à jour des patches critiques, alertes de sécurité et bulletins. Il n'est pas recommandé d'utiliser ce JDK (version 8u441) après la prochaine mise à jour de patches critiques prévue pour le 15 avril 2025.

Java Management Service, disponible pour tous les utilisateurs, peut vous aider à rechercher les versions de Java vulnérables dans les systèmes. Les abonnés à Java SE et les clients qui utilisent Oracle Cloud peuvent se servir de Java Management Service pour mettre à jour les exécutions Java et effectuer des vérifications de sécurité supplémentaires, comme identifier les bibliothèques tierces potentiellement vulnérables utilisées par les programmes Java. Utilisateur existant de Java Management Service, cliquez ici pour vous connecter à votre tableau de bord. La documentation Java Management Service fournit la liste des fonctionnalités disponibles pour tous les utilisateurs et de celles disponibles uniquement pour les clients. Apprenez-en davantage sur l'utilisation de Java Management Service pour surveiller et sécuriser les installations de Java.

Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u441) le 15 mai 2025. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente. Pour plus d'informations, reportez-vous à Date d'expiration du JRE 23.1.2 dans le guide de déploiement de la plate-forme Java, Standard Edition.

Corrections de bug

Cette version corrige également les vulnérabilités de sécurité décrites dans la mise à jour de patches critiques Oracle. Pour consulter une liste plus exhaustive des corrections de bug incluses dans cette version, reportez-vous à Notes sur la version 8u441.

Java 8 Update 431 (8u431)

Principales nouveautés de cette version

JDK 8u431 contient des données de fuseau horaire IANA 2024a.
Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Problèmes importants résolus : la mise à niveau du RPM du JDK laisse des entrées alternatives orphelines
Résolution du problème relatif à la mauvaise gestion des entrées dans les groupes "java" et "javac" lors d'une mise à niveau du RPM.
Lors de la mise à niveau du RPM Java d'une ancienne version installée sur un répertoire partagé (/usr/lib/jvm/jdk-${FEATURE}-oracle-${ARCH}) vers une version installée sur un répertoire propre à la version (/usr/lib/jvm/jdk-${VERSION}-oracle-${ARCH}), les anciennes entrées Java dans les groupes "java" et "javac" ne sont pas supprimées.
JDK-8336107 (non public)
Autres notes : nouvelles limites par défaut dans les implémentations HTTP du JDK
De nouvelles limites par défaut ont été ajoutées à HTTP dans le JDK.
L'implémentation intégrée au JDK du gestionnaire de protocoles d'URL pour HTTP (HttpURLConnection) dispose désormais d'une limite par défaut sur la taille maximale des en-têtes de réponse qui sera acceptée par une partie distante. Par défaut, la limite est définie sur 384 ko (393 216 octets), et correspond à la taille cumulative de l'ensemble des noms et valeurs d'en-tête, plus une surcharge de 32 octets par paire nom-valeur d'en-tête.
JDK-8328286 (non public)
Autres notes : ajout des certificats d'autorité de certification racine TLS SSL.com émis en 2022
Les certificats racine suivants ont été ajoutés au truststore de certificats d'autorité de certification :
+ SSL.com
+ ssltlsrootecc2022
DN: CN=SSL.com TLS ECC Root CA 2022, O=SSL Corporation, C=US
+ SSL.com
+ ssltlsrootrsa2022
DN: CN=SSL.com TLS RSA Root CA 2022, O=SSL Corporation, C=US
Reportez-vous à JDK-8341057
Autres notes : fin de l'acceptation des certificats de serveur TLS ancrés par les certificats racine Entrust et émis après le 11 novembre 2024
Le JDK n'acceptera plus les certificats de serveur TLS émis après le 11 novembre 2024 et ancrés par les certificats racine Entrust, faisant écho à des stratégies similaires récemment annoncées par Google et Mozilla. La liste des certificats concernés inclut les certificats AffirmTrust, qui sont gérés par Entrust.
Reportez-vous à JDK-8337664

Maintien à jour du JDK

Les mises à jour des patches critiques, qui contiennent des corrections de vulnérabilité de sécurité, sont annoncées un an à l'avance sur Mises à jour des patches critiques, alertes de sécurité et bulletins. Il n'est pas recommandé d'utiliser ce JDK (version 8u431) après la prochaine mise à jour de patches critiques prévue pour le 21 janvier 2025.

Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u431) le 21 février 2025. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente. Pour plus d'informations, reportez-vous à Date d'expiration du JRE 23.1.2 dans le guide de déploiement de la plate-forme Java, Standard Edition.

Corrections de bug

Java 8 Update 421 (8u421)

Principales nouveautés de cette version

JDK 8u421 contient des données de fuseau horaire IANA 2024a.
Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Problème connu : utilisation du fichier de clés du navigateur sous Windows
Sous Windows, une fois la fonctionnalité Utiliser les certificats et les clés du fichier de clés du navigateur activée (qui l'est par défaut), Java Web Start et le plug-in Java peuvent accéder aux certificats qui sont actuellement considérés comme sécurisés par l'ordinateur local. Les certificats étant chargés de façon dynamique, il n'est pas garanti que la liste complète des certificats sécurisés soit disponible. Par conséquent, les applets Java et les applications Java Web Start peuvent rencontrer des problèmes de validation de signature et de connexion sécurisée provoqués par un manque de certificats pertinents car la structure de développement ne peut accéder qu'aux certificats qui sont actifs lors du lancement d'une application.
JDK-8330728 (non public)
Autres notes : ajout de l'argument STATIC=1 au programme d'installation du JRE
Cette correction ajoutera l'argument de programme d'installation STATIC=1 et fera passer l'argument de programme d'installation RETAIN_ALL_VERSIONS=1 en phase d'abandon. La transmission de STATIC=1 empêchera la désinstallation des anciennes versions de JRE 8 lors d'une mise à niveau manuelle ou d'une mise à jour automatique.
JDK-8313223 (non public)
Autres notes : ajout des certificats d'autorité de certification racine GlobalSign R46 et E46
Les certificats racine suivants ont été ajoutés au truststore de certificats d'autorité de certification :
+ GlobalSign + globalsignr46 DN: CN=GlobalSign Root R46, O=GlobalSign nv-sa, C=BE + GlobalSign + globalsigne46 DN: CN=GlobalSign Root E46, O=GlobalSign nv-sa, C=BE
Reportez-vous à JDK-8316138
Autres notes : création par le programme d'installation d'un répertoire de jonction dans un nouvel emplacement
Le JRE sera installé à l'emplacement C:\Program Files\Java\latest\jre-$fullversion, où $fullversion est la version technique du JRE. Par exemple, 8u421 sera installé dans C:\Program Files\Java\latest\jre-1.8.0_421.

"C:\Program Files" sera ajusté afin de devenir "C:\Program Files (x86)" pour Java 32 bits.

Une jonction sera créée à l'emplacement C:\Program Files\Java\latest\jre-1.8. Elle pointera vers la version la plus récente du JRE de la famille 8.
JDK-8329700 (non public)

Maintien à jour du JDK

Les mises à jour des patches critiques, qui contiennent des corrections de vulnérabilité de sécurité, sont annoncées un an à l'avance sur Mises à jour des patches critiques, alertes de sécurité et bulletins. Il n'est pas recommandé d'utiliser ce JDK (version 8u421) après la prochaine mise à jour de patches critiques prévue pour le 15 octobre 2024.

Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer ce JRE (version 8u421) le 15 novembre 2024. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente. Pour plus d'informations, reportez-vous à Date d'expiration du JRE 23.1.2 dans le guide de déploiement de la plate-forme Java, Standard Edition.

Corrections de bug

Java 8 Update 411 (8u411)

Principales nouveautés de cette version

JDK 8u411 contient des données de fuseau horaire IANA 2024a.
Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Nouvelle fonctionnalité : ajout des certificats Certainly Root R1 et E1
Les certificats racine suivants ont été ajoutés au truststore de certificats de l'autorité de certification :+ Certainly + certainlyrootr1 DN: CN=Certainly Root R1, O=Certainly, C=US + Certainly + certainlyroote1 DN: CN=Certainly Root E1, O=Certainly, C=US
Reportez-vous à JDK-8321408
Nouvelle fonctionnalité : activation par défaut du mode de validation sécurisé de signature XML
Le mode de validation sécurisé de signature XML a été activé par défaut (auparavant, il ne l'était pas sauf en cas d'exécution avec un gestionnaire de sécurité). Lorsque cette fonctionnalité est activée, la validation des signatures XML est soumise à une vérification plus stricte des algorithmes et d'autres contraintes, comme indiqué par la propriété de sécurité jdk.xml.dsig.secureValidationPolicy.
Si nécessaire, et à leurs risques et périls, les applications peuvent désactiver le mode en définissant la propriété org.jcp.xml.dsig.secureValidation sur Boolean.FALSE avec l'API DOMValidateContext.setProperty().
Reportez-vous à JDK-8259801

Maintien à jour du JDK

Les mises à jour des patches critiques, qui contiennent des corrections de vulnérabilité de sécurité, sont annoncées un an à l'avance sur Mises à jour des patches critiques, alertes de sécurité et bulletins. Il n'est pas recommandé d'utiliser ce JDK (version 8u411) après la prochaine mise à jour de patches critiques prévue pour le 16 juillet 2024.

Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u411) le 16 août 2024. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente. Pour plus d'informations, reportez-vous à Date d'expiration du JRE 23.1.2 dans le guide de déploiement de la plate-forme Java, Standard Edition.

Corrections de bug

Java 8 Update 401 (8u401)

Principales nouveautés de cette version

JDK 8u401 contient des données de fuseau horaire IANA 2023c.
Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Nouvelle fonctionnalité : nouvelle propriété système permettant d'activer/de désactiver le mode de validation sécurisé de signature XML
Une nouvelle propriété système nommée org.jcp.xml.dsig.secureValidation a été ajoutée. Elle peut être utilisée pour activer ou désactiver le mode de validation sécurisé de signature XML. La propriété système doit être définie sur "true" pour l'activation ou sur "false" pour la désactivation. Toute autre valeur de la propriété système est traitée comme "false". Si la propriété système est définie, elle remplace la valeur de la propriété XMLCryptoContext. Le mode de validation sécurisé est activé par défaut si vous exécutez le code avec SecurityManager. Sinon, il est désactivé par défaut.
Reportez-vous à JDK-8301260
Nouvelle fonctionnalité : événement JDK Flight Recorder pour la désérialisation
Un nouvel événement JDK Flight Recorder (JFR) a été ajouté pour surveiller la désérialisation des objets. Lorsque JFR est activé et que la configuration JFR inclut des événements de désérialisation, JFR émet un événement chaque fois que le programme en cours d'exécution tente de désérialiser un objet. L'événement de désérialisation est nommé java/deserialization et est désactivé par défaut. L'événement de désérialisation contient des informations utilisées par le mécanisme de filtre de sérialisation. De plus, si un filtre est activé, l'événement JFR indique si le filtre a accepté ou rejeté la désérialisation de l'objet.
Reportez-vous à JDK-8261160

Maintien à jour du JDK

Les mises à jour des patches critiques, qui contiennent des corrections de vulnérabilité de sécurité, sont annoncées un an à l'avance sur Mises à jour des patches critiques, alertes de sécurité et bulletins. Il n'est pas recommandé d'utiliser ce JDK (version 8u401) après la prochaine mise à jour de patches critiques prévue pour le 16 avril 2024.

Les clients disposant de produits sous abonnement à Java SE qui gèrent les mises à jour/installations JRE pour un grand nombre de bureaux doivent envisager d'utiliser Java Management Service (JMS).

Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u401) le 16 mai 2024. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente. Pour plus d'informations, reportez-vous à Date d'expiration du JRE 23.1.2 dans le guide de déploiement de la plate-forme Java, Standard Edition.

Corrections de bug

Java 8 Update 391 (8u391)

Principales nouveautés de cette version

JDK 8u391 contient des données de fuseau horaire IANA 2023c.
Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Nouvelle fonctionnalité : nouvel événement JFR : jdk.SecurityProviderService
Un nouvel événement JFR (Java Flight Recorder) a été ajouté aux détails d'enregistrement des appels java.security.Provider.getService(String type, String algorithm).
Reportez-vous à JDK-8254711
Fonctionnalité enlevée : suppression du certificat racine RootCA1 de SECOM Trust System
Le certificat racine suivant de SECOM Trust System a été enlevé du fichier de clés d'accès cacerts :
+ alias name "secomscrootca1 [jdk]" Nom distinctif : OU=Security Communication RootCA1, O=SECOM Trust.net, C=JP
Reportez-vous à JDK-8295894
Fonctionnalité enlevée : suppression de la prise en charge de Linux ARM 32 pour JDK 8
La prise en charge de la plate-forme pour Linux ARM 32 dans JDK 8 a été enlevée. Par conséquent, le téléchargement ARM 32 Hard Float ABI ne sera pas disponibe. Les systèmes d'exploitation qui prenaient en charge ARM 32 sont arrivés en fin de vie. Il n'existe donc plus de prise en charge de système d'exploitation connue.
JDK-8305927 (non public)
Autres notes : ajout du certificat de l'autorité de certification racine Certigna
Le certificat racine suivant a été ajouté au truststore de certificats de l'autorité de certification :
+ Certigna (Dhimyotis) + certignarootca Nom distinctif : CN=Certigna Root CA, OU=0002 48146308100036, O=Dhimyotis, C=FR
Reportez-vous à JDK-8314960

Maintien à jour du JDK

Les mises à jour des patches critiques, qui contiennent des corrections de vulnérabilité de sécurité, sont annoncées un an à l'avance sur Mises à jour des patches critiques, alertes de sécurité et bulletins. Il n'est pas recommandé d'utiliser ce JDK (version 8u391) après la prochaine mise à jour de patches critiques prévue pour le 16 janvier 2024.

Les clients disposant d'un abonnement à Java SE qui gèrent les mises à jour/installations JRE pour un grand nombre de bureaux doivent envisager d'utiliser Java Advanced Management Console (AMC).

Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u391) le 16 février 2024. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente. Pour plus d'informations, reportez-vous à Date d'expiration du JRE 23.1.2 dans le guide de déploiement de la plate-forme Java, Standard Edition.

Corrections de bug

Java 8 Update 381 (8u381)

Principales nouveautés de cette version

JDK 8u381 contient des données de fuseau horaire IANA2023c.
Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Nouvelle fonctionnalité : autorisation de caractères supplémentaires pour la prise en charge de GB18030-2022
L'organisme national chinois des normes (CESI) a récemment publié la norme GB18030-2022 (version mise à jour de la norme GB18030) et synchronise GB18030 avec la version 11.0 de la norme Unicode. L'implémentation du jeu de caractères pour cette nouvelle norme remplace désormais la précédente norme 2000. Toutefois, cette nouvelle norme comporte des modifications incompatibles avec l'implémentation précédente. Pour les utilisateurs devant employer les anciens mappings, la nouvelle propriété système jdk.charset.GB18030 est introduite. En définissant sa valeur sur 2000, les mappings des précédentes versions de JDK pour le jeu de caractères GB18030, qui reposent sur la norme 2000, sont utilisés.
Reportez-vous à JDK-8307229
JDK accepte désormais les clés RSA au format PKCS#1
Les fournisseurs de JDK peuvent désormais accepter les clés privées et publiques RSA au format PKCS#1, comme la clé RSA KeyFactory.impl du fournisseur SunRsaSign. L'objet de clé privée ou publique RSA doit être au format PKCS#1 et disposer d'un encodage correspondant à la syntaxe ASN.1 pour une clé privée et une clé publique RSA PKCS#1.
Reportez-vous à JDK-8023980
Autres notes : améliorations et prise en charge de cgroup version 2 dans 8u381
JDK 8u381 inclut plusieurs améliorations et corrections visant à améliorer la prise en charge de cgroup versions 1 et 2 pour les conteneurs. Ces améliorations incluent la détection précise des limites de ressource des conteneurs, la génération de rapports corrects sur les mesures de conteneur collectées, l'impression des informations supplémentaires sur les conteneurs et l'amélioration de la stabilité des applications dans les environnements en conteneur.
Reportez-vous à JDK-8307634
Autres notes : ajout du certificat de l'autorité de certification racine TWCA
Le certificat racine suivant a été ajouté au truststore de certificats de l'autorité de certification :
+ TWCA + twcaglobalrootca DN: CN=TWCA Global Root CA, OU=Root CA, O=TAIWAN-CA, C=TW
Reportez-vous à JDK-8305975
Autres notes : ajout de 4 certificats de l'autorité de certification racine GTS
Les certificats racine suivants ont été ajoutés au truststore de certificats de l'autorité de certification :
+ Google Trust Services LLC + gtsrootcar1 DN: CN=GTS Root R1, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootcar2 DN: CN=GTS Root R2, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootecccar3 DN: CN=GTS Root R3, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootecccar4 DN: CN=GTS Root R4, O=Google Trust Services LLC, C=US
Reportez-vous à JDK-8307134
Autres notes : ajout de 2 certificats de l'autorité de certification racine TLS de Microsoft Corporation
Les certificats racine suivants ont été ajoutés au truststore de certificats de l'autorité de certification :
+ Microsoft Corporation + microsoftecc2017 DN: CN=Microsoft ECC Root Certificate Authority 2017, O=Microsoft Corporation, C=US + Microsoft Corporation + microsoftrsa2017 DN: CN=Microsoft RSA Root Certificate Authority 2017, O=Microsoft Corporation, C=US
Reportez-vous à JDK-8304760

Maintien à jour du JDK

Les mises à jour des patches critiques, qui contiennent des corrections de vulnérabilité de sécurité, sont annoncées un an à l'avance sur Mises à jour des patches critiques, alertes de sécurité et bulletins. Il n'est pas recommandé d'utiliser ce JDK (version 8u381) après la prochaine mise à jour de patches critiques prévue pour le 17 octobre 2023.

Les clients disposant d'un abonnement à Java SE qui gèrent les mises à jour/installations JRE pour un grand nombre de bureaux doivent envisager d'utiliser Java Advanced Management Console (AMC).

Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u381) le 17 novembre 2023. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente. Pour plus d'informations, reportez-vous à Date d'expiration du JRE 23.1.2 dans le guide de déploiement de la plate-forme Java, Standard Edition.

Corrections de bug

Java 8 Update 371 (8u371)

Principales nouveautés de cette version

JDK 8u371 contient des données de fuseau horaire IANA2022g.
Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Nouvelle fonctionnalité : ajout d'une bibliothèque GSS-API native par défaut sous Windows
Une bibliothèque GSS-API native a été ajoutée à JDK sur la plate-forme Windows. La bibliothèque est côté client et utilise les informations d'identification par défaut. Elle est chargée si la propriété système sun.security.jgss.native est définie sur "true". Les utilisateurs peuvent tout de même charger une bibliothèque GSS-API native tierce en définissant la propriété système sun.security.jgss.lib sur son chemin.
Reportez-vous à JDK-6722928
Suppression d'options et de fonctionnalités : l'implémentation de moteur javax.script et com.apple.concurrent.Dispatch sont enlevés pour macOS AArch64
Le moteur AppleScript implémentant l'API de moteur javax.script a été enlevé sans être remplacé. Le fonctionnement du moteur AppleScript n'était pas cohérent. Le fichier de configuration des services (META-INF/services) était manquant et fonctionnait uniquement par inadvertance lors de l'installation de JDK 7 ou de JDK 8 sur les systèmes qui avaient déjà la version d'Apple du fichier AppleScriptEngine.jar.
L'API com.apple.concurrent.Dispatch était destinée à Mac uniquement. Elle a été transférée vers JDK 7u4 avec le port du code JDK 6 d'Apple. Les développeurs sont encouragés à utiliser les API standard java.util.concurrent.Executor et java.util.concurrent.ExecutorService à la place.
Reportez-vous à JDK-8297475
Autres notes : ajout du certificat de l'autorité de certification racine Certigna (Dhimyotis)
Le certificat racine suivant a été ajouté au truststore de certificats de l'autorité de certification :
+ Certigna (Dhimyotis) + certignarootca DN: CN=Certigna, O=Dhimyotis, C=FR
Reportez-vous à JDK-8245654
Autres notes : suppression de SSLv2Hello et de SSLv3 des protocoles TLS activés par défaut
SSLv2Hello et SSLv3 ont été enlevés des protocoles TLS activés par défaut.

Après cette mise à jour, si SSLv3 est enlevé de la propriété de sécurité jdk.tls.disabledAlgorithms, les API SSLSocket.getEnabledProtocols(), SSLServerSocket.getEnabledProtocols(), SSLEngine.getEnabledProtocols() et SSLParameters.getProtocols() renverront "TLSv1.3, TLSv1.2, TLSv1.1, TLSv1". "SSLv3" ne sera pas renvoyé dans cette liste.
Si un client ou un serveur a toujours besoin d'utiliser le protocole SSLv3, il peut l'activer via les propriétés système jdk.tls.client.protocols ou jdk.tls.server.protocols, ou à l'aide des API SSLSocket.setEnabledProtocols(), SSLServerSocket.setEnabledProtocols() et SSLEngine.setEnabledProtocols().
Reportez-vous à JDK-8190492

Maintien à jour du JDK

Oracle recommande de mettre à jour le JDK à chaque mise à jour de patches critiques. Utilisez la page de référence de sécurité afin d'identifier la dernière version de chaque famille de versions.

Les mises à jour des patches critiques, qui contiennent des corrections de vulnérabilité de sécurité, sont annoncées un an à l'avance sur Mises à jour des patches critiques, alertes de sécurité et bulletins. Il n'est pas recommandé d'utiliser ce JDK (version 8u371) après la publication de la prochaine mise à jour de patches critiques prévue pour le 18 juillet 2023.

Les clients disposant d'un abonnement à Java SE qui gèrent les mises à jour/installations JRE pour un grand nombre de bureaux doivent envisager d'utiliser Java Advanced Management Console (AMC).

Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u371) le 18 août 2023. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente. Pour plus d'informations, reportez-vous à Date d'expiration du JRE 23.1.2 dans le guide de déploiement de la plate-forme Java, Standard Edition.

Corrections de bug

Java 8 Update 361 (8u361)

Principales nouveautés de cette version

JDK 8u361 contient des données de fuseau horaire IANA 2022d, 2022e, 2022f.
Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Nouvelle fonctionnalité : prise en charge de RSASSA-PSS dans les réponses OCSP
Les réponses OCSP signées avec l'algorithme RSASSA-PSS sont désormais prises en charge.
Reportez-vous à JDK-8274471
Autres notes : désactivation par défaut du moteur JavaScript FXML
Le "moteur de script JavaScript" pour FXML est désormais désactivé par défaut. Tout fichier .fxml disposant d'une instruction de traitement (PI) "javascript" ne sera plus chargé par défaut et une exception sera générée.
L'option peut être activée en définissant la propriété système -Djavafx.allowjs=true
JDK-8294779 (non public)
Autres notes : gestion incorrecte des arguments entre guillemets dans ProcessBuilder
ProcessBuilder sous Windows est restauré pour résoudre une régression causée par JDK-8250568. Auparavant, un argument pour ProcessBuilder qui commençait par un guillemet double et se terminait par une barre oblique inverse suivie d'un guillemet double était transmis à une commande de façon incorrecte et pouvait entraîner l'échec de la commande. Par exemple, la commande aurait considéré que l'argument "C:\\Program Files\" avait des guillemets doubles en trop. Cette mise à jour restaure le comportement de longue date qui ne traite pas spécialement la barre oblique inverse avant le guillemet double final.
Reportez-vous à JDK-8282008
Autres notes : configurabilité du délai de maintien de connexion par défaut de HttpURLConnection
Deux propriétés système ont été ajoutées pour contrôler le comportement de maintien de connexion de HttpURLConnection dans le cas où le serveur n'indique pas de délai de maintien de connexion. Deux propriétés sont définies pour contrôler séparément les connexions aux serveurs et les connexions aux proxies. Il s'agit de http.keepAlive.time.server et de http.keepAlive.time.proxy, respectivement. Vous trouverez plus d'informations sur elles dans Propriétés de réseau.
Reportez-vous à JDK-8278067
Autres notes : fin de la mise à disposition de l'outil VisualVM
Cette version du JDK n'inclut plus de copie de Java VisualVM. VisualVM est désormais disponible en téléchargement distinct sur la page https://visualvm.github.io.
Reportez-vous à JDK-8294184

Maintien à jour du JDK

Les mises à jour des patches critiques, qui contiennent des corrections de vulnérabilité de sécurité, sont annoncées un an à l'avance sur Mises à jour des patches critiques, alertes de sécurité et bulletins. Il n'est pas recommandé d'utiliser ce JDK (version 8u361) après la prochaine mise à jour de patches critiques prévue pour le 18 avril 2023.

Les clients disposant d'un abonnement à Java SE qui gèrent les mises à jour/installations JRE pour un grand nombre de bureaux doivent envisager d'utiliser Java Advanced Management Console (AMC).

Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u361) le 18 mai 2023. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente. Pour plus d'informations, reportez-vous à Date d'expiration du JRE 23.1.2 dans le guide de déploiement de la plate-forme Java, Standard Edition.

Corrections de bug

Java 8 Update 351 (8u351)

Principales nouveautés de cette version

Données IANA TZ 2022b, 2022c.
Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Autres notes : mise à niveau de l'algorithme MAC PKCS12 par défaut
L'algorithme MAC par défaut utilisé dans un fichier de clés PKCS #12 a été mis à jour. Ce nouvel algorithme repose sur SHA-256 et est plus sécurisé que l'ancien qui reposait sur SHA-1. Pour obtenir des informations détaillées, reportez-vous aux propriétés de sécurité commençant par keystore.pkcs12 dans le fichier java.security.
Reportez-vous à JDK-8267880
Autres notes : désactivation des fichiers JAR signés avec des algorithmes SHA-1
Les fichiers JAR signés avec des algorithmes SHA-1 sont désormais restreints par défaut et traités comme s'ils n'étaient pas signés. Cela s'applique aux algorithmes utilisés pour condenser, signer et éventuellement horodater les fichiers JAR. Cela s'applique également aux algorithmes de signature et de condensation des certificats dans la chaîne de certificats du signataire de code et de l'autorité d'horodatage, ainsi qu'à toute réponse OCSP ou liste de certificats révoqués utilisée pour vérifier si ces certificats ont été révoqués. Ces restrictions s'appliquent également aux fournisseurs JCE signés.
Reportez-vous à JDK-8269039
Autres notes : 3DES et RC4 en phase d'abandon dans Kerberos
Les types de cryptage Kerberos des3-hmac-sha1 et rc4-hmac sont désormais en phase d'abandon et désactivés par défaut. Les utilisateurs peuvent définir allow_weak_crypto = true dans le fichier de configuration krb5.conf pour les réactiver (avec d'autres types de cryptage faible, y compris des-cbc-crc et des-cbc-md5) à leurs risques et périls. Pour désactiver un sous-ensemble de types de cryptage faible, les utilisateurs peuvent répertorier explicitement les types de cryptage préférés dans l'un des paramètres default_tkt_enctypes, default_tgs_enctypes ou permitted_enctypes.
Reportez-vous à JDK-8139348

Maintien à jour du JDK

Les mises à jour des patches critiques, qui contiennent des corrections de vulnérabilité de sécurité, sont annoncées un an à l'avance sur Mises à jour des patches critiques, alertes de sécurité et bulletins. Il n'est pas recommandé d'utiliser ce JDK (version 8u351) après la prochaine mise à jour de patches critiques prévue pour le 17 janvier 2023.

Les clients disposant d'un abonnement à Java SE qui gèrent les mises à jour/installations JRE pour un grand nombre de bureaux doivent envisager d'utiliser Java Advanced Management Console (AMC).

Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u351) le 17 février 2023. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente. Pour plus d'informations, reportez-vous à Date d'expiration du JRE 23.1.2 dans le guide de déploiement de la plate-forme Java, Standard Edition.

Corrections de bug

» Notes sur la version 8u351

Java 8 Update 341 (8u341)

Principales nouveautés de cette version

Données de fuseau horaire IANA 2022a.
Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Nouvelle fonctionnalité : prise en charge de la liaison de canal HTTPS pour Java GSS/Kerberos
Les jetons de liaison de canal TLS sont désormais pris en charge pour l'authentification Negotiate/Kerberos sur HTTPS via javax.net.HttpsURLConnection.

Les jetons de liaison de canal sont de plus en plus nécessaires car ils constituent une forme de sécurité améliorée. Ils communiquent à un serveur la compréhension d'un client de la liaison entre la sécurité de la connexion (telle que représentée par le certificat de serveur TLS) et les informations d'identification d'authentification de niveau supérieur (comme un nom utilisateur et un mot de passe). Le serveur peut ensuite détecter si le client a été victime d'une attaque de type MITM et arrêter la session/connexion.
Reportez-vous à JDK-8279842
Nouvelle fonctionnalité : activation de TLS version 1.3 par défaut sur JDK 8u pour les rôles de client
L'implémentation TLS version 1.3 est disponible dans JDK 8u à compter de la version 8u261 et est activée par défaut pour les rôles de serveur, mais désactivée par défaut pour les rôles de client. A partir de cette version, TLS version 1.3 est désormais également activé par défaut pour les rôles de client. Pour plus de détails, reportez-vous à la section Informations supplémentaires du plan d'informations Oracle JRE and JDK Cryptographic Roadmap.
Reportez-vous à JDK-8245263
Autres notes : mise à jour de java.net.InetAddress pour détecter des valeurs littérales d'adresse IPv4 ambiguës
La classe java.net.InetAddress a été mise à jour de sorte à accepter strictement les valeurs littérales d'adresse IPv4 dans la notation décimale à point. Les méthodes de la classe InetAddress sont mises à jour afin de générer une exception java.net.UnknownHostException pour les valeurs littérales d'adresse IPv4 non valides. Pour désactiver cette vérification, la nouvelle propriété système "jdk.net.allowAmbiguousIPAddressLiterals" peut être définie sur "true".
Reportez-vous à JDK-8277608 (non public)
Autres notes : troncature des extensions de groupe JDK lors du téléchargement via Firefox 102
Sur oracle.com et java.com, certaines extensions de groupe JDK sont tronquées lors du téléchargement via Firefox version 102. Les groupes téléchargés n'ont pas d'extension de fichier telle que ".exe", ".rpm", ".deb". Si vous ne pouvez pas effectuer une mise à niveau vers la version Firefox ESR 102.0.1 ou Firefox 103 lorsqu'elle est publiée, vous pouvez essayer les solutions de contournement suivantes :
-Ajouter manuellement une extension de fichier au nom du fichier après le téléchargement.
‐Utiliser un autre navigateur
Reportez-vous à JDK-8277093

Maintien à jour du JDK

Les mises à jour des patches critiques, qui contiennent des corrections de vulnérabilité de sécurité, sont annoncées un an à l'avance sur Mises à jour des patches critiques, alertes de sécurité et bulletins. Il n'est pas recommandé d'utiliser ce JDK (version 8u341) après la prochaine mise à jour de patches critiques prévue pour le 18 octobre 2022.

Les clients disposant d'un abonnement à Java SE qui gèrent les mises à jour/installations JRE pour un grand nombre de bureaux doivent envisager d'utiliser Java Advanced Management Console (AMC).

Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u341) le 18 novembre 2022. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente. Pour plus d'informations, reportez-vous à Date d'expiration du JRE 23.1.2 dans le guide de déploiement de la plate-forme Java, Standard Edition.

Corrections de bug

» Notes sur la version 8u341

Java 8 Update 333 (8u333)

Principales nouveautés de cette version

Données de fuseau horaire IANA 2021a.
Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Modification : activation des autres flux de données Windows par défaut
L'implémentation Windows de java.io.File a été modifiée de sorte que des vérifications de validité strictes ne soient pas effectuées par défaut sur les chemins de fichier. Ainsi, les deux points (":") sont autorisés dans le chemin ailleurs qu'immédiatement après une lettre de lecteur unique. Les chemins qui représentent d'autres flux de données NTFS sont également autorisés, par exemple "nomfichier:nomflux". Le comportement par défaut de java.io.File redevient celui d'avant la mise à jour de patches critiques d'avril 2022 dans lequel des vérifications de validité strictes n'étaient pas effectuées par défaut sur les chemins de fichier sous Windows. Pour réactiver la vérification stricte des chemins dans java.io.File, la propriété système jdk.io.File.enableADS doit être définie sur false (pas de distinction majuscules/minuscules). Ce peut être préférable, par exemple, si des chemins d'appareil spéciaux Windows tels que NUL: ne sont pas utilisés.
Reportez-vous à JDK-8285445

Maintien à jour du JDK

Les mises à jour des patches critiques, qui contiennent des corrections de vulnérabilité de sécurité, sont annoncées un an à l'avance sur Mises à jour des patches critiques, alertes de sécurité et bulletins. Il n'est pas recommandé d'utiliser ce JDK (version 8u333) après la prochaine mise à jour de patches critiques prévue pour le 19 juillet 2022.

Les clients disposant d'un abonnement à Java SE qui gèrent les mises à jour/installations JRE pour un grand nombre de bureaux doivent envisager d'utiliser Java Advanced Management Console (AMC).

Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u333) le 19 août 2022. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente. Pour plus d'informations, reportez-vous à Date d'expiration du JRE 23.1.2 dans le guide de déploiement de la plate-forme Java, Standard Edition.

Corrections de bug

Cette version repose sur la mise à jour de patches critiques précédente et ne contient aucune correction de sécurité supplémentaire. Pour consulter une liste plus exhaustive des corrections de bug incluses dans cette version, reportez-vous à la page Notes sur la version de JDK 8u333.

» Notes sur la version 8u333

Java 8 Update 331 (8u331)

Principales nouveautés de cette version

Données de fuseau horaire IANA 2021e.
Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Nouvelle fonctionnalité : nouvelles limites de traitement XML
Trois limites de traitement ont été ajoutées. Il s'agit des suivantes :
- jdk.xml.xpathExprGrpLimit
  Description : limite le nombre de groupes qu'une expression XPath peut contenir.
  Type : entier
  Valeur : un entier positif. Une valeur inférieure ou égale à 0 indique l'absence de limite. Si la valeur n'est pas un entier, une exception NumberFormatException est générée. La valeur par défaut est 10.
- jdk.xml.xpathExprOpLimit
  Description : limite le nombre d'opérateurs qu'une expression XPath peut contenir.
  Type : entier
  Valeur : un entier positif. Une valeur inférieure ou égale à 0 indique l'absence de limite. Si la valeur n'est pas un entier, une exception NumberFormatException est générée. La valeur par défaut est 100.
- jdk.xml.xpathTotalOpLimit
  Description : limite le nombre total d'opérateurs XPath dans une feuille de style XSL.
  Type : entier
  Valeur : un entier positif. Une valeur inférieure ou égale à 0 indique l'absence de limite. Si la valeur n'est pas un entier, une exception NumberFormatException est générée. La valeur par défaut est 10 000.
Processeurs pris en charge
- jdk.xml.xpathExprGrpLimit et jdk.xml.xpathExprOpLimit sont pris en charge par le processeur XPath.
- Les trois limites sont prises en charge par le processeur XSLT.
Définition des propriétés
Pour le processeur XSLT, les propriétés peuvent être modifiées via TransformerFactory. Par exemple :
```
<code>        TransformerFactory factory = TransformerFactory.newInstance();

        factory.setAttribute("jdk.xml.xpathTotalOpLimit", "1000");
```
Pour les deux processeurs XPath et XSLT, les propriétés peuvent être définies via la propriété système et le fichier de configuration jaxp.properties situé dans le répertoire conf de l'installation Java. Par exemple :
```
<code>        System.setProperty("jdk.xml.xpathExprGrpLimit", "20");
```
ou dans le fichier jaxp.properties,
```
<code>        jdk.xml.xpathExprGrpLimit=20
```
JDK-8270504 (non public)
Autres notes : exposition des certificats avec des paramètres de sécurité appropriés uniquement en tant qu'entrées de certificat sécurisé dans macOS KeychainStore
Sous macOS, seuls les certificats avec des paramètres de sécurité appropriés dans le porte-clés de l'utilisateur seront exposés en tant qu'entrées de certificat sécurisé dans le fichier de clés de type KeychainStore. De plus, l'appel de la méthode KeyStore::setCertificateEntry ou de la commande keytool -importcert sur un fichier de clés KeychainStore échoue désormais avec une exception KeyStoreException. Appelez à la place la commande "security add-trusted-cert" de macOS pour ajouter un certificat sécurisé au porte-clés de l'utilisateur.
JDK-8278449 (non public)
Autres notes : l'analyse des URL dans les fournisseurs JNDI intégrés LDAP, DNS, RMI et CORBA est plus stricte. La puissance de l'analyse peut être contrôlée par les propriétés système :
L'analyse des URL dans les fournisseurs JNDI intégrés LDAP, DNS et RMI est plus stricte. La puissance de l'analyse peut être contrôlée par les propriétés système :
```
<code>  -Dcom.sun.jndi.ldapURLParsing="legacy" | "compat" | "strict" (to control "ldap:" URLs)


  -Dcom.sun.jndi.dnsURLParsing="legacy" | "compat" | "strict" (to control "dns:" URLs)

  -Dcom.sun.jndi.rmiURLParsing="legacy" | "compat" | "strict" (to control "rmi:" URLs)

  -Dcom.sun.jndi.corbaURLParsing="legacy" | "compat" | "strict" (to control "iiop:" and "iiopname:" URLs)
```
La valeur par défaut est "compat" pour l'ensemble des propriétés.
- Le mode "legacy" désactive la nouvelle validation.
- Le mode "compat" limite les incompatibilités.
- Le mode "strict" est plus strict et peut entraîner une régression en rejetant les URL qu'une application peut considérer valides.
Si une chaîne d'URL non autorisée est trouvée, une exception javax.naming.NamingException (ou une sous-classe) est générée.
JDK-8278972 (non public)

Maintien à jour du JDK

Les mises à jour des patches critiques, qui contiennent des corrections de vulnérabilité de sécurité, sont annoncées un an à l'avance sur Mises à jour des patches critiques, alertes de sécurité et bulletins. Il n'est pas recommandé d'utiliser ce JDK (version 8u331) après la prochaine mise à jour de patches critiques prévue pour le 19 juillet 2022.

Les clients disposant d'un abonnement à Java SE qui gèrent les mises à jour/installations JRE pour un grand nombre de bureaux doivent envisager d'utiliser Java Advanced Management Console (AMC).

Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u331) le 19 août 2022. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente. Pour plus d'informations, reportez-vous à Date d'expiration du JRE 23.1.2 dans le guide de déploiement de la plate-forme Java, Standard Edition.

Corrections de bug

Cette version corrige également les vulnérabilités de sécurité décrites dans la mise à jour de patches critiques Oracle. Pour obtenir la liste complète des corrections de bug incluses dans cette version, reportez-vous à la page Corrections de bug de JDK 8u331.

» Notes sur la version 8u331

Java 8 Update 321 (8u321)

Principales nouveautés de cette version

IANA TZ Data 2021b, 2021c, 2021d, 2021e.
JDK 8u321 contient des données de fuseau horaire IANA 2021b, 2021c, 2021d, 2021e. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Nouvelle fonctionnalité : nouvelles propriétés de configuration SunPKCS11
Le fournisseur SunPKCS11 ajoute de nouveaux attributs de configuration de fournisseur pour mieux contrôler l'utilisation de ressources natives. Le fournisseur SunPKCS11 utilise des ressources natives afin de travailler avec des bibliothèques PKCS11 natives. Pour gérer et mieux contrôler les ressources natives, des attributs de configuration supplémentaires sont ajoutés afin de contrôler la fréquence d'effacement des références natives ainsi que de déterminer si le jeton PKCS11 sous-jacent doit être détruit après la déconnexion.
Reportez-vous à JDK-8240256
Suppression de fonctionnalités et d'options : suppression du certificat racine GlobalSign de Google
Le certificat racine suivant de Google a été enlevé du fichier de clés cacerts :
+ alias name "globalsignr2ca [jdk]" Distinguished Name: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
Reportez-vous à JDK-8225083
Autres notes : mise à jour des données de fuseau horaire vers 2021c
La base de données de fuseau horaire IANA, sur laquelle reposent les bibliothèques de date/d'heure de JDK, a apporté une modification mineure à certaines règles de fuseau horaire depuis 2021c. Depuis cette mise à jour, certaines des règles de fuseau horaire antérieures à 1970 ont été modifiées en fonction des modifications introduites dans la version 2021b. Pour plus de détails, reportez-vous à l'annonce de 2021b
Reportez-vous à JDK-8274407

Maintien à jour du JDK

Oracle recommande de mettre à jour le JDK à chaque mise à jour des patches critiques. Pour déterminer si une version donnée est la dernière, vous pouvez utiliser la page de référence de sécurité afin d'identifier la dernière version de chaque famille de versions.

Les mises à jour des patches critiques, qui contiennent des corrections de vulnérabilité de sécurité, sont annoncées un an à l'avance sur Mises à jour des patches critiques, alertes de sécurité et bulletins. Il n'est pas recommandé d'utiliser ce JDK (version 8u291) après la prochaine mise à jour de patches critiques prévue pour le 20 juillet 2021.

Les clients disposant d'un abonnement à Java SE qui gèrent les mises à jour/installations JRE pour un grand nombre de bureaux doivent envisager d'utiliser Java Advanced Management Console (AMC).

Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u291) le 20 août 2021. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente. Pour plus d'informations, reportez-vous à Date d'expiration du JRE 23.1.2 dans le guide de déploiement de la plate-forme Java, Standard Edition.

Corrections de bug

» Notes sur la version 8u321

Java 8 Update 311 (8u311)

Principales nouveautés de cette version

Données IANA TZ 2021a.
Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Nouvelle fonctionnalité : programme d'affichage Marlin dans JDK 8u
A compter de la version 8u311, le programme de rastérisation graphique de Marlin et ses artefacts seront conçus et distribués dans les groupes JDK/JRE. Il ne s'agit pas du moteur d'affichage par défaut. Toutefois, il est possible de l'activer en configurant la propriété système suivante :
sun.java2d.renderer=sun.java2d.marlin.MarlinRenderingEngine
Reportez-vous à JDK-8143849
Nouvelle fonctionnalité : sous-ensemble de filtres de désérialisation propres au contexte
Permet aux applications de configurer des filtres de désérialisation propres au contexte et sélectionnés de manière dynamique à l'aide d'une fabrique de filtres à l'échelle de la JVM, appelée afin de sélectionner un filtre pour chaque flux de désérialisation. Le comportement est un sous-ensemble strict de JEP 415 : Filtres de désérialisation propres au contexte qui permet de configurer une fabrique de filtres à l'aide d'une propriété configurée sur la ligne de commande ou dans le fichier de propriétés de sécurité.
Reportez-vous aux filtres de désérialisation propres au contexte et au guide de filtrage de sérialisation pour plus de détails.
JDK-8268680 (non public)
Suppression de fonctionnalités et d'options : suppression du certificat racine IdenTrust
Le certificat racine d'IdenTrust suivant a été enlevé du fichier de clés cacerts :
+ alias name "identrustdstx3 [jdk]"
Distinguished Name: CN=DST Root CA X3, O=Digital Signature Trust Co.
Reportez-vous à JDK-8225082
Autres notes : la version ne prend pas en charge Windows 11correctement
Cette version n'identifie pas Windows 11 correctement. La propriété os.name est définie sur Windows 10 sous Windows 11. Dans les journaux d'erreurs HotSpot, le système d'exploitation est identifié comme Windows 10 ; toutefois, le journal d'erreurs HotSpot affiche le numéro de build. Windows 11 a le build 22000.194 ou supérieur.
Reportez-vous à JDK-8274840
Autres notes : mise à jour des préférences au niveau des mécanismes de cryptage activés par défaut
L'ordre de priorité par défaut des mécanismes de cryptage pour les protocoles TLS 1.0 à TLS 1.3 a été mis à jour.
Pour TLS 1.3, TLS_AES_256_GCM_SHA384 a désormais la priorité par rapport à TLS_AES_128_GCM_SHA256.
Pour les protocoles TLS 1.0 à TLS 1.2, la priorité de certains des mécanismes intermédiaires a diminué, tel que décrit ci-dessous :
- La priorité des mécanismes de cryptage qui ne conservent pas la confidentialité persistante a été diminuée par rapport à ceux qui la conservent.
- La priorité des mécanismes de cryptage qui utilisent SHA-1 a diminué.
Reportez-vous à JDK-8163326
Autres notes : modification du comportement de l'élément HttpURLConnection lorsqu'aucun serveur proxy satisfaisant n'est trouvé
Le comportement de l'élément HttpURLConnection lorsque ProxySelector est utilisé a été modifié dans cette version JDK. HttpURLConnection basculait sur une tentative de connexion directe si le ou les serveurs proxy configurés ne parvenaient pas à établir une connexion. A compter de cette version, le comportement par défaut a été modifié : une connexion directe ne sera plus utilisée lorsque la première tentative de connexion du serveur proxy échoue.
Reportez-vous à JDK-8161016

Maintien à jour du JDK

Les mises à jour des patches critiques, qui contiennent des corrections de vulnérabilité de sécurité, sont annoncées un an à l'avance sur Mises à jour des patches critiques, alertes de sécurité et bulletins. Il n'est pas recommandé d'utiliser ce JDK (version 8u311) après la prochaine mise à jour de patches critiques prévue pour le 18 janvier 2022.

Les clients disposant d'un abonnement à Java SE qui gèrent les mises à jour/installations JRE pour un grand nombre de bureaux doivent envisager d'utiliser Java Advanced Management Console (AMC).

Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u311) le 18 février 2022. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente. Pour plus d'informations, reportez-vous à Date d'expiration du JRE 23.1.2 dans le guide de déploiement de la plate-forme Java, Standard Edition.

Corrections de bug

» Notes sur la version 8u311

Java 8 Update 301 (8u301)

Principales nouveautés de cette version

Données IANA TZ 2021a.
JDK 8u301 contient les données de fuseau horaire IANA version 2021a. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Nouvelle fonctionnalité : personnalisation de la génération de fichiers de clés PKCS12
Ajout de nouvelles propriétés système et de sécurité pour permettre aux utilisateurs de personnaliser la génération des fichiers de clés PKCS #12. Inclut des algorithmes et des paramètres pour la protection des clés, la protection des certificats et MacData. L'explication détaillée et les valeurs possibles de ces propriétés sont disponibles dans la section "PKCS12 KeyStore properties" du fichier java.security.
Reportez-vous à JDK-8076190
Suppression de fonctionnalités et d'options : suppression des certificats racine avec des clés 1 024 bits
Les certificats racine avec des clés publiques RSA 1 024 bits faibles ont été enlevés du fichier de clés cacerts.
Reportez-vous à JDK-8243559
Suppression de fonctionnalités et d'options : suppression du certificat de l'autorité de certification Sonera Class2 de Telia Company
Le certificat racine suivant a été enlevé du truststore des certificats CA :
+ Telia Company + soneraclass2ca DN: CN=Sonera Class2 CA, O=Sonera, C=FI
Reportez-vous à JDK-8225081
Autres notes : mise à niveau des algorithmes de cryptage PKCS12 par défaut
Les algorithmes de cryptage par défaut utilisés dans un fichier de clés PKCS #12 ont été mis à jour. Les nouveaux algorithmes reposent sur AES-256 et SHA-256, et sont plus puissants que les anciens qui reposaient sur RC2, DESede et SHA-1. Pour obtenir des informations détaillées, reportez-vous aux propriétés de sécurité commençant par keystore.pkcs12 dans le fichier java.security.
Pour assurer la compatibilité, une nouvelle propriété système nommée keystore.pkcs12.legacy est définie. Elle rétablit les anciens algorithmes moins puissants. Aucune valeur n'est définie pour cette propriété.
Reportez-vous à JDK-8153005

Maintien à jour du JDK

Les mises à jour des patches critiques, qui contiennent des corrections de vulnérabilité de sécurité, sont annoncées un an à l'avance sur Mises à jour des patches critiques, alertes de sécurité et bulletins. Il n'est pas recommandé d'utiliser ce JDK (version 8u301) après la prochaine mise à jour de patches critiques prévue pour le 19 octobre 2021.

Les clients disposant d'un abonnement à Java SE qui gèrent les mises à jour/installations JRE pour un grand nombre de bureaux doivent envisager d'utiliser Java Advanced Management Console (AMC).

Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u301) le 19 novembre 2021. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente. Pour plus d'informations, reportez-vous à Date d'expiration du JRE 23.1.2 dans le guide de déploiement de la plate-forme Java, Standard Edition.

Corrections de bug

» Notes sur la version 8u301

Java 8 Update 291 (8u291)

Principales nouveautés de cette version

Données IANA TZ 2020e, 2020f, 2021a.
JDK 8u291 contient des données de fuseau horaire IANA 2020e, 2020f, 2021a. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Autres notes : nouvelles propriétés système et de sécurité permettant de contrôler la reconstruction des objets distants par les implémentations intégrées JNDI RMI et LDAP du JDK
jdk.jndi.object.factoriesFilter : cette propriété système et de sécurité permet d'indiquer un filtre en série qui contrôle l'ensemble de classes de fabrique d'objets autorisées à instancier les objets à partir des références d'objet renvoyées par les systèmes de dénomination/d'annuaire. La classe de fabrique nommée par l'instance de référence est mise en correspondance avec ce filtre lors de la reconstruction de référence distante. La propriété de filtre prend en charge la syntaxe de filtre reposant sur un modèle avec le format indiqué par JEP 290. Cette propriété s'applique aux implémentations de fournisseur intégrées JNDI/RMI et JNDI/LDAP. La valeur par défaut permet à toute classe de fabrique d'objets indiquée dans la référence de recréer l'objet référencé.
JDK-8244473 (non public)
Autres notes : la version de Java par défaut n'est pas mise à jour pour l'exécution du fichier .jar par double-clic
Si la variable d'environnement PATH contient un enregistrement configuré par les programmes d'installation d'Oracle JDK de versions plus récentes, le programme d'installation d'Oracle JRE insère le chemin d'accès au répertoire contenant les commandes Java (java.exe, javaw.exe et javaws.exe) dans la variable d'environnement PATH après cet enregistrement. Auparavant, le programme d'installation d'Oracle JRE ignorait les modifications apportées à la variable d'environnement PATH par les programmes d'installation d'Oracle JDK de versions plus récentes et mettait à jour la valeur de la variable d'environnement PATH de façon incorrecte. Pour obtenir plus d'informations techniques, reportez-vous à la demande de service client : https://bugs.openjdk.java.net/browse/JDK-8259858
Reportez-vous à JDK-8259215
Autres notes : désactivation de TLS 1.0 et 1.1
Les versions TLS 1.0 et 1.1 du protocole TLS ne sont plus considérées comme sécurisées et ont été remplacées par des versions plus modernes et sécurisées (TLS 1.2 et 1.3).
Elles sont désormais désactivées par défaut. Si vous rencontrez des problèmes, vous pouvez, à vos risques et périls, réactiver les versions en enlevant "TLSv1" et/ou "TLSv1.1" de la propriété de sécurité jdk.tls.disabledAlgorithms dans le fichier de configuration java.security.
Reportez-vous à JDK-8202343
Autres notes : désactivation de TLS 1.0 et 1.1 pour les applets du plug-in Java et les applications Java Web Start
Les versions TLS 1.0 et 1.1 ont été désactivées. Ces protocoles ne sont pas utilisés par les applets du plug-in Java et les applications Java Web Start par défaut. En cas de problèmes, une option permet de réactiver les protocoles dans le panneau de configuration Java.
JDK-8255892 (non public)

Maintien à jour du JDK

Les mises à jour des patches critiques, qui contiennent des corrections de vulnérabilité de sécurité, sont annoncées un an à l'avance sur Mises à jour des patches critiques, alertes de sécurité et bulletins. Il n'est pas recommandé d'utiliser ce JDK (version 8u291) après la prochaine mise à jour de patches critiques prévue pour le 20 juillet 2021.

Les clients disposant d'un abonnement à Java SE qui gèrent les mises à jour/installations JRE pour un grand nombre de bureaux doivent envisager d'utiliser Java Advanced Management Console (AMC).

Corrections de bug

» Notes sur la version 8u291

Java 8 Update 281 (8u281)

Principales nouveautés de cette version

Données IANA 2020d
Le JDK 8u281 contient des données de fuseau horaire IANA version 2020d. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Nouvelle fonctionnalité : ajout de l'option groupname à la génération de paires de clés keytool
Une nouvelle option -groupname a été ajoutée à keytool -genkeypair pour que l'utilisateur puisse indiquer un groupe nommé lors de la génération d'une paire de clés. Par exemple, keytool -genkeypair -keyalg EC -groupname secp384r1 générera une paire de clés EC en utilisant la courbe secp384r1. Dans la mesure où plusieurs courbes de même taille peuvent exister, il est préférable d'utiliser l'option -groupname plutôt que l'option -keysize.
Reportez-vous à JDK-8213400
Nouvelle fonctionnalité : mise à jour de la bibliothèque Apache Santuario vers la version 2.1.4
La bibliothèque Apache Santuario a été mise à niveau vers la version 2.1.4. Par conséquent, une nouvelle propriété système com.sun.org.apache.xml.internal.security.parser.pool-size a été introduite.
Cette nouvelle propriété système définit la taille du pool du cache interne DocumentBuilder utilisé lors du traitement des signatures XML. La fonction équivaut à la propriété système org.apache.xml.security.parser.pool-size utilisée dans Apache Santuario et a la même valeur par défaut de 20.
Reportez-vous à JDK-8231507
Nouvelle fonctionnalité : prise en charge de l'extension certificate_authorities
L'extension "certificate_authorities" est une extension facultative introduite dans TLS 1.3. Elle permet d'indiquer les autorités de certification prises en charge par une adresse et devant être utilisées par l'adresse réceptrice pour orienter la sélection de certificat.
Reportez-vous à JDK-8206925
Autres notes : modification de Properties.loadFromXML à des fins de conformité avec la spécification
L'implémentation de la méthode java.util.Properties loadFromXML a été modifiée à des fins de conformité avec sa spécification. Plus particulièrement, l'implémentation de l'analyseur XML sous-jacent rejette désormais les documents XML non conformes en générant une exception InvalidPropertiesFormatException, comme indiqué par la méthode loadFromXML.
Reportez-vous à JDK-8213325
Autres notes : suppression du nom de zone Etats-Unis/Nouveau Pacifique dans le cadre de tzdata2020b
Suite à la mise à jour du JDK vers tzdata2020b, les fichiers obsolètes nommés pacificnew et systemv ont été enlevés. Par conséquent, le nom de zone Etats-Unis/Nouveau Pacifique déclaré dans le fichier de données pacificnew n'est peut plus être utilisé.
Reportez-vous à JDK-8254177

Maintien à jour du JDK

Les mises à jour des patches critiques, qui contiennent des corrections de vulnérabilité de sécurité, sont annoncées un an à l'avance sur Mises à jour des patches critiques, alertes de sécurité et bulletins. Il n'est pas recommandé d'utiliser ce JDK (version 8u281) après la prochaine mise à jour de patches critiques prévue pour le 20 avril 2021.

Les clients disposant d'un abonnement à Java SE qui gèrent les mises à jour/installations JRE pour un grand nombre de bureaux doivent envisager d'utiliser Java Advanced Management Console (AMC).

Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u281) le 15 mai 2021. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente. Pour plus d'informations, reportez-vous à Date d'expiration du JRE 23.1.2 dans le guide de déploiement de la plate-forme Java, Standard Edition.

Corrections de bug

» Notes sur la version 8u281

Java 8 Update 271 (8u271)

Principales nouveautés de cette version

Données IANA 2020a
JDK 8u271 contient les données de fuseau horaire IANA version 2020a. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Nouvelle fonctionnalité : désactivation par défaut des courbes nommées faibles dans TLS, CertPath et les fichiers JAR signés
Les courbes nommées faibles sont désactivées par défaut en les ajoutant aux propriétés de sécurité disabledAlgorithms suivantes : jdk.tls.disabledAlgorithms, jdk.certpath.disabledAlgorithms et jdk.jar.disabledAlgorithms. Avec 47 courbes nommées faibles à désactiver, l'ajout des différentes courbes nommées à chaque propriété disabledAlgorithms serait un processus chronophage. Pour éviter cela, une nouvelle propriété de sécurité, jdk.disabled.namedCurves, est implémentée. Elle peut répertorier les courbes nommées communes à toutes les propriétés disabledAlgorithms. Pour utiliser la nouvelle propriété dans les propriétés disabledAlgorithms, ajoutez le mot-clé include au début du nom de propriété complet. Les utilisateurs peuvent toujours ajouter des courbes nommées aux propriétés disabledAlgorithms distinctes de cette nouvelle propriété. Aucune autre propriété ne peut être incluse dans les propriétés disabledAlgorithms.
Reportez-vous à JDK-8233228
Nouvelle fonctionnalité : prise en charge des recommandations inter-domaines Kerberos (RFC 6806)
Le client Kerberos a été amélioré avec la prise en charge des recommandations inter-domaines et de la canonisation de nom de principal, telles que définies par l'extension de protocole RFC 6806.
Grâce à cette nouvelle fonctionnalité, le client Kerberos bénéficie de configurations d'environnement plus dynamiques et n'a pas forcément besoin de savoir (en avance) comment atteindre le domaine d'un principal cible (utilisateur ou service).
Reportez-vous à JDK-8223172
Fonctionnalité enlevée : suppression du plug-in Java de JDK 8u pour les plates-formes Linux, Solaris et MacOS
NPAPI est considéré comme étant un plug-in vulnérable et a été désactivé dans de nombreux navigateurs. Actuellement, aucun navigateur ne prend en charge le plug-in Java (qui repose sur NPAPI) sur les plates-formes Linux, Solaris et MacOS.
A compter de la version 8u271, la partie du plug-in Java responsable de l'intégration et de l'interaction avec un navigateur (en particulier la bibliothèque libnpjp2) et un artefact associé ne sera pas créée, et ne fait pas partie de la distribution de l'environnement JRE sur les plates-formes Linux, Solaris et MacOS.
JDK-8240210 (non public)
Autres notes : ajout d'une propriété pour contrôler les mécanismes d'authentification LDAP autorisés à effectuer une authentification sur des connexions clear
Une nouvelle propriété d'environnement, jdk.jndi.ldap.mechsAllowedToSendCredentials, a été ajoutée pour contrôler les mécanismes d'authentification LDAP autorisés à envoyer des informations d'identification sur des connexions LDAP clear (connexions non sécurisées avec TLS). Une connexion LDAP encrypted est une connexion ouverte à l'aide du modèle ldaps, ou une connexion ouverte à l'aide du modèle ldap, puis mise à niveau vers TLS avec une opération étendue STARTTLS.
JDK-8237990 (non public)

Maintien à jour du JDK

Oracle recommande de mettre à jour le JDK à chaque mise à jour des patches critiques. Pour déterminer si une version donnée est la dernière, vous pouvez utiliser la page de référence de sécurité suivante afin d'identifier la dernière version de chaque famille de versions.

Les mises à jour des patches critiques, qui contiennent des corrections de vulnérabilité de sécurité, sont annoncées un an à l'avance sur Mises à jour des patches critiques, alertes de sécurité et bulletins. Il n'est pas recommandé d'utiliser ce JDK (version 8u271) après la prochaine mise à jour de patches critiques prévue pour le 19 janvier 2021.

Les clients disposant d'un abonnement à Java SE qui gèrent les mises à jour/installations JRE pour un grand nombre de bureaux doivent envisager d'utiliser Java Advanced Management Console (AMC).

Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u271) le 20 février 2021. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente. Pour plus d'informations, reportez-vous à Date d'expiration du JRE 23.1.2 dans le guide de déploiement de la plate-forme Java, Standard Edition.

Corrections de bug

» Notes sur la version 8u271

Java 8 Update 261 (8u261)

Principales nouveautés de cette version

Données IANA 2020a
JDK 8u261 contient les données de fuseau horaire IANA version 2020a. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Nouvelle fonctionnalité : modification de la bibliothèque runtime (DLL) Windows Visual Studio dont dépendent JDK/JRE
Dans le cadre de la maintenance en cours, la chaîne d'outils Microsoft Visual Studio 2017 sera utilisée afin de concevoir JDK 7 et JDK 8 pour Windows. JDK 8u261, dans la mise à jour de patches critiques de juillet 2020, a été conçu avec Visual Studio 2017. Avec la publication de la mise à jour de patches critiques d'octobre 2020, JDK 7u281 passera à Visual Studio 2017.
JDK-8246783 (non public)
Nouvelle fonctionnalité : JEP 332 : protocole TLS (Transport Layer Security) 1.3
JDK 8u261 inclut une implémentation de la spécification TLS 1.3 (RFC 8446). Pour obtenir plus d'informations, y compris la liste des fonctionnalités prises en charge, reportez-vous au guide de référence Java Secure Socket Extension (JSSE) et à JEP 332.
Reportez-vous à JDK-814252
Nouvelle fonctionnalité : nouvelles propriétés système pour configurer les modèles de signature TLS
Deux nouvelles propriétés système ont été ajoutées pour personnaliser les modèles de signature TLS dans JDK.
jdk.tls.client.SignatureSchemes a été ajouté pour le côté client TLS et jdk.tls.server.SignatureSchemes pour le côté serveur.
Reportez-vous à JDK-8242141
Nouvelle fonctionnalité : négociation de paramètres Finite Field Diffie-Hellman Ephemeral pour TLS
L'implémentation de JDK SunJSSE prend maintenant en charge les mécanismes TLS FFDHE définis dans la RFC 7919. Si un serveur ne peut pas traiter l'extension TLS supported_groups ou les groupes nommés dans l'extension, les applications peuvent soit personnaliser les noms de groupe pris en charge avec jdk.tls.namedGroups, soit désactiver les mécanismes FFDHE en définissant la propriété système jsse.enableFFDHE sur False.
Reportez-vous à JDK-8140436

Maintien à jour du JDK

Oracle recommande de mettre à jour le JDK à chaque mise à jour des patches critiques. Pour déterminer si une version donnée est la dernière, vous pouvez utiliser la page de référence de sécurité suivante afin d'identifier la dernière version de chaque famille de versions.

Les mises à jour des patches critiques, qui contiennent des corrections de vulnérabilité de sécurité, sont annoncées un an à l'avance sur Mises à jour des patches critiques, alertes de sécurité et bulletins. Il n'est pas recommandé d'utiliser ce JDK (version 8u261) après la prochaine mise à jour de patches critiques prévue pour le 13 octobre 2020.

Les clients disposant d'un abonnement à Java SE qui gèrent les mises à jour/installations JRE pour un grand nombre de bureaux doivent envisager d'utiliser Java Advanced Management Console (AMC).

Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u261) le 13 novembre 2020. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente. Pour plus d'informations, reportez-vous à Date d'expiration du JRE 23.1.2 dans le guide de déploiement de la plate-forme Java, Standard Edition.

Corrections de bug

» Notes sur la version 8u261

Java 8 Update 251 (8u251)

Principales nouveautés de cette version

Données IANA 2019c
JDK 8u251 contient les données de fuseau horaire IANA version 2019c. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Nouvelle fonctionnalité : prise en charge étendue des algorithmes PKCS#1 v2.2, notamment de la signature RSASSA-PSS
Les fournisseurs SunRsaSign et SunJCE ont été améliorés avec la prise en charge de plus d'algorithmes définis dans PKCS#1 v2.2, tels que la signature RSASSA-PSS et OAEP utilisant des algorithmes Digest FIPS 180-4. De nouveaux constructeurs et de nouvelles méthodes ont été ajoutés aux classes JCA/JCE pertinentes dans les packages java.security.spec et javax.crypto.spec pour la prise en charge de paramètres RSASSA-PSS supplémentaires.
Reportez-vous à JDK-8146293
Autres notes : WebEngine limite les appels de méthode JavaScript pour certaines classes
Les programmes JavaScript exécutés dans le contexte d'une page Web chargée par WebEngine peuvent communiquer avec les objets Java transmis à partir de l'application vers le programme JavaScript. Les programmes JavaScript référençant les objets java.lang.Class sont désormais limités aux méthodes suivantes :
getCanonicalName getEnumConstants getFields getMethods getName getPackageName getSimpleName getSuperclass getTypeName getTypeParameters isAssignableFrom isArray isEnum isInstance isInterface isLocalClass isMemberClass isPrimitive isSynthetic toGenericString toString

Aucune méthode ne peut être appelée sur les classes suivantes :
java.lang.ClassLoader java.lang.Module java.lang.Runtime java.lang.System java.lang.invoke.* java.lang.module.* java.lang.reflect.* java.security.* sun.misc.*

JDK-8236798 (non public)
Autres notes : nouvelle propriété système propre aux mises à jour d'Oracle JDK 8 pour le basculement vers le format d'encodage Base64 hérité
Oracle JDK 8u231 a mis à niveau les bibliothèques Apache Santuario vers la version 2.1.3. Cette mise à niveau a introduit un problème : la signature XML utilisant l'encodage Base64 provoque l'ajout de &#xd ou de &#13 à la sortie encodée. Cette modification de comportement a été apportée à la base de code Apache Santuario à des fins de conformité avec la norme RFC 2045. L'équipe Santuario a choisi de maintenir la conformité de ses bibliothèques à la norme RFC 2045.
Reportez-vous à JDK-8236645

Maintien à jour du JDK

Oracle recommande de mettre à jour le JDK à chaque mise à jour des patches critiques. Pour déterminer si une version donnée est la dernière, vous pouvez utiliser la page de référence de sécurité suivante afin d'identifier la dernière version de chaque famille de versions.

Les mises à jour des patches critiques, qui contiennent des corrections de vulnérabilité de sécurité, sont annoncées un an à l'avance sur Mises à jour des patches critiques, alertes de sécurité et bulletins. Il n'est pas recommandé d'utiliser ce JDK (version 8u251) après la prochaine mise à jour de patches critiques prévue pour le 14 juillet 2020.

Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u251) le 14 août 2020. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente. Pour plus d'informations, reportez-vous à Date d'expiration du JRE 23.1.2 dans le guide de déploiement de la plate-forme Java, Standard Edition.

Corrections de bug

» Notes sur la version 8u251

Java 8 Update 241 (8u241)

Principales nouveautés de cette version

Données IANA 2019c
JDK 8u241 contient les données de fuseau horaire IANA version 2019c. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Nouvelle fonctionnalité : autorisation de la limitation des mécanismes SASL
Une propriété de sécurité nommée jdk.sasl.disabledMechanisms a été ajoutée et permet de désactiver les mécanismes SASL. Tout mécanisme désactivé sera ignoré s'il est spécifié dans l'argument mechanisms de Sasl.createSaslClient ou dans l'argument mechanism de Sasl.createSaslServer. La valeur par défaut de cette propriété de sécurité est vide, ce qui signifie qu'aucun mécanisme n'est désactivé par défaut.
Reportez-vous à JDK-8200400
Nouvelle fonctionnalité : fournisseur SunPKCS11 mis à niveau avec prise en charge de PKCS#11 version 2.40
Le fournisseur SunPKCS11 a été mis à jour avec prise en charge de PKCS#11 version 2.40. Cette version ajoute la prise en charge de plus d'algorithmes tels que le cryptage AES/GCM/NoPadding, les signatures DSA utilisant la famille SHA-2 des algorithmes Digest de message, et les signatures RSASSA-PSS lorsque les mécanismes PKCS11 correspondants sont pris en charge par la bibliothèque PKCS11 sous-jacente.
Reportez-vous à JDK-8080462
Autres notes : nouvelles vérifications sur les certificats de point d'ancrage
De nouvelles vérifications ont été ajoutées pour s'assurer que les points d'ancrage sont des certificats d'autorité de certification et contiennent des extensions appropriées. Les points d'ancrage permettent de valider des chaînes de certificat utilisées dans le protocole TLS et dans du code signé. Les certificats de point d'ancrage doivent inclure une extension des contraintes de base avec le champ de l'autorité de certification défini sur True. En outre, s'ils incluent une extension d'utilisation de clé, le bit keyCertSign doit être défini.
JDK-8230318 (non public)
Autres notes : correspondance exacte requise pour le certificat du serveur TLS sécurisé
Pour être considéré comme sécurisé lors de l'établissement d'une connexion TLS, un certificat de serveur TLS doit être la correspondance exacte d'un certificat sécurisé sur le client.
JDK-8227758 (non public)
Autres notes : ajout d'un certificat LuxTrust Global Root 2
Le certificat racine LuxTrust a été ajouté au truststore des certificats CA
Reportez-vous à JDK-8232019
Autres notes : ajout de 4 certificats CA racine Amazon
Un certificat racine Amazon a été ajouté au truststore des certificats CA
Reportez-vous à JDK-8233223
Corrections de bug : prise en charge des polices CFF OpenType
Auparavant, JDK 8 n'incluait pas les polices CFF OpenType (polices .otf) dans les polices logiques standard (telles que "Dialog" et "SansSerif"). Il manquait donc des glyphes dans le texte affiché. Dans les cas les plus extrêmes où seules les polices CFF étaient installées sur le système, une exception Java pouvait être générée.
Plusieurs distributions Linux étaient concernées par ce problème car elles s'appuyaient sur les polices CFF afin de prendre en charge certaines langues, ce qui est courant pour les langues CJC (chinois, japonais et coréen).
Oracle JDK 8 utilise désormais ces polices CFF, et ce problème a été résolu.
Reportez-vous à JDK-8209672
Corrections de bug : amélioration de la gestion des filtres en série
La propriété système jdk.serialFilter peut uniquement être définie sur la ligne de commande. Si le filtre n'a pas été défini sur la ligne de commande, il peut être défini à l'aide de java.io.ObjectInputFilter.Config.setSerialFilter. La définition de jdk.serialFilter avec java.lang.System.setProperty n'a aucun effet.
JDK-8231422 (non public)

Date d'expiration de Java

La date d'expiration pour 8u241 est le 14 avril 2020. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u241) le 14 mai 2020. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

» Notes sur la version 8u241

Java 8 Update 231 (8u231)

Principales nouveautés de cette version

Données IANA 2019b
JDK 8u231 contient les données de fuseau horaire IANA version 2019b. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Nouvelle fonctionnalité : nouvelle propriété système jdk.jceks.iterationCount
Une nouvelle propriété système a été introduite afin de contrôler la valeur du nombre d'itérations utilisée pour le fichier de clés jceks. La valeur par défaut reste 200 000, mais des valeurs comprises entre 10 000 et 5 000 000 peuvent être indiquées. Le nom de la nouvelle propriété système est jdk.jceks.iterationCount et la valeur fournie doit être un entier compris dans la plage autorisée. La valeur par défaut est utilisée en cas d'erreur d'analyse.
JDK-8223269 (non public)
Nouvelle fonctionnalité : nouveaux événements de sécurité JFR (Java Flight Recorder)
Quatre nouveaux événements JFR ont été ajoutés à la zone de bibliothèque de sécurité. Ces événements sont désactivés par défaut et peuvent être activés via les fichiers de configuration JFR ou via les options JFR standard.
Reportez-vous à JDK-8148188
Suppression d'options et de fonctionnalités : suppression d'ICU Layout Engine et de T2K Rasterizer de JavaFX
T2K Rasterizer et ICU Layout Engine ont été enlevés de JavaFX.
Reportez-vous à JDK-8187147
Autres notes : [Client-Libs] et [JavaFX] de GTK3 sont désormais les valeurs par défaut sous Linux/Unix
Les versions plus récentes de Linux, de Solaris et d'autres environnements de bureau au format Unix utilisent GTK3 et prennent encore en charge GTK2.
Auparavant, le JDK chargeait par défaut les bibliothèques GTK2 plus anciennes. Toutefois, ce sont les bibliothèques GTK3 qui sont chargées par défaut dans cette version. Le chargement est généralement déclenché par l'utilisation de la présentation GTK Swing.
L'ancien comportement peut être restauré en utilisant la propriété système : -Djdk.gtk.version=2.2
Reportez-vous à JDK-8222496
Autres notes : suppression des courbes NIST EC obsolètes des algorithmes TLS par défaut
Cette modification entraîne la suppression des courbes NIST EC obsolètes des groupes nommés par défaut utilisés lors de la négociation TLS. Courbes enlevées : sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1 et secp256k1.
Pour activer de nouveau ces courbes, utilisez la propriété système jdk.tls.namedGroups. La propriété contient une liste de groupes nommés activés séparés par des virgules et entre guillemets classés par ordre de préférence. Par exemple :
java -Djdk.tls.namedGroups="secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1" ...
JDK-8228825 (non public)

Date d'expiration de Java

La date d'expiration de la version 8u231 est le 14 janvier 2020. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u231) le 14 février 2020. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

» Notes sur la version 8u231

Java 8 Update 221 (8u221)

Principales nouveautés de cette version

Données IANA 2018i
JDK 8u221 contient des données de fuseau horaire IANA version 2018i. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Nouvelle fonctionnalité : la détection du système d'exploitation Windows de HotSpot identifie correctement Windows Server 2019
Avant cette correction, Windows Server 2019 était reconnu comme "Windows Server 2016", ce qui générait des valeurs incorrectes dans la propriété système os.name et le fichier hs_err_pid.
Reportez-vous à JDK-8211106
Suppression de fonctionnalités et d'options : suppression de deux certificats d'autorité de certification racine DocuSign
Deux certificats d'autorité de certification racine DocuSign ont expiré et ont été enlevés du fichier de clés cacerts :
- nom d'alias "certplusclass2primaryca [jdk]"
  Nom distinctif : CN=Class 2 Primary CA, O=Certplus, C=FR
- nom d'alias "certplusclass3pprimaryca [jdk]"
  Nom distinctif : CN=Class 3P Primary CA, O=Certplus, C=FR
Reportez-vous à JDK-8223499
Suppression de fonctionnalités et d'options : suppression de deux certificats d'autorité de certification racine Comodo
Deux certificats d'autorité de certification racine Comodo ont expiré et ont été enlevés du fichier de clés cacerts :
- nom d'alias "utnuserfirstclientauthemailca [jdk]"
  Nom distinctif : CN=UTN-USERFirst-Client Authentication and Email, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
- nom d'alias "utnuserfirsthardwareca [jdk]"
  Nom distinctif : CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
Reportez-vous à JDK-8222136
Suppression de fonctionnalités et d'options : suppression du certificat T-Systems Deutsche Telekom Root CA 2
Le certificat T-Systems Deutsche Telekom Root CA 2 a expiré et a été enlevé du fichier de clés cacerts :
- nom d'alias "deutschetelekomrootca2 [jdk]"
  Nom distinctif : CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE
Reportez-vous à JDK-8222137
Autres notes : solution de contournement pour l'installation de Java Access Bridge
Lors de l'installation de Java sur un système Windows sur lequel une version de Java est déjà installée et sur lequel une instance de JAWS est en cours d'exécution, la fonctionnalité Java Access Bridge risque d'être endommagée. Après le redémarrage, le système peut se retrouver sans le fichier WindowsAccessBridge-64.dll dans le répertoire système (C:\Windows\System32) pour les produits Java 64 bits ou le répertoire système utilisé par WOW64 (C:\Windows\SysWoW64) pour les produits Java 32 bits.
Pour éviter d'endommager la fonctionnalité Java Access Bridge, employez l'une des solutions de contournement suivantes :
- Arrêtez JAWS avant de lancer le programme d'installation de Java.
- Désinstallez les environnements JRE existants avant d'installer la nouvelle version de Java.
- Désinstallez les environnements JRE existants après avoir installé la nouvelle version de Java et redémarré l'ordinateur.
Le but des solutions de contournement est d'éviter d'avoir à désinstaller les environnements JRE existants du programme d'installation Java lorsque JAWS est en cours d'exécution.
JDK-8223293 (non public)

Date d'expiration de Java

La date d'expiration de la version 8u221 est le 15 octobre 2019. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u221) le 15 novembre 2019. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

» Notes sur la version 8u221

Java 8 Update 211 (8u211)

Principales nouveautés de cette version

Données IANA 2018g
JDK 8u211 contient les données de fuseau horaire IANA version 2018g. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Nouvelle fonctionnalité : prise en charge du caractère en forme de carré pour la nouvelle ère japonaise
Le point de code U+32FF est réservé par le consortium Unicode afin de représenter le caractère japonais en forme de carré pour la nouvelle ère qui commence en mai 2019. Les méthodes pertinentes dans la classe Character renvoient les mêmes propriétés que les caractères de l'ère japonaise actuelle (par exemple : U+337E pour "Meizi"). Pour obtenir des informations sur le point de code, reportez-vous à http://blog.unicode.org/2018/09/new-japanese-era.html.
Reportez-vous à JDK-8211398
Modification : ajout du certificat racine GlobalSign R6
Le certificat racine suivant a été ajouté au truststore de certificats CA OpenJDK :
- GlobalSign
  - globalsignrootcar6
    Nom distinctif : CN=GlobalSign, O=GlobalSign, OU=Autorité de certification racine GlobalSign - R6
JDK-8216577 (non public)
Modification : fin de l'acceptation des certificats de serveur TLS ancrés par les certificats racine Symantec
Le kit JDK n'acceptera plus les certificats de serveur TLS émis par Symantec, faisant écho à des stratégies similaires annoncées par Google, Mozilla, Apple et Microsoft. La liste des certificats concernés inclut les certificats GeoTrust, Thawte et VeriSign, qui étaient gérés par Symantec.
Les certificats de serveur TLS émis au plus tard le 16 avril 2019 seront acceptés jusqu'à leur expiration. Les certificats émis après cette date seront refusés. Reportez-vous à la page de prise en charge de DigiCert pour obtenir des informations sur la manière de remplacer les certificats Symantec par un certificat DigiCert (DigiCert a pris le contrôle de l'émission et de la validation de tous les certificats SSL/TLS de sécurité du site Web de Symantec le 1er décembre 2017).
Exception : les certificats de serveur TLS émis via deux autorités de certification subordonnées gérées par Apple et identifiés ci-dessous seront acceptés s'ils sont émis au plus tard le 31 décembre 2019.
Reportez-vous à JDK-8207258
Modification : nom de la nouvelle ère japonaise
Le nom de l'espace réservé "NewEra" destiné à l'ère japonaise débutant le 1er mai 2019 a été remplacé par le nom annoncé par le gouvernement japonais, à savoir "Reiwa". Les applications qui comptent sur le nom de l'espace réservé pour obtenir la nouveau singleton de l'ère (JapaneseEra.valueOf("NewEra")) ne fonctionneront plus.
Reportez-vous à JDK-8205432
Modification : prise en charge de la nouvelle ère japonaise dans java.time.chrono.JapaneseEra
La classe JapaneseEra et ses méthodes of(int), valueOf(String) et values() sont clarifiées afin de prendre en compte les prochains ajouts de l'ère japonaise, tels que la façon dont sont définies les instances singleton, les valeurs de nombre entier associées, etc.
Reportez-vous à JDK-8212941

Date d'expiration de Java

La version 8u211 expire le 16 juillet 2019. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u211) le 16 août 2019. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

Cette version corrige les vulnérabilités de sécurité décrites dans les conseils sur la mise à jour de patches critiques Oracle Java SE. Pour consulter une liste plus exhaustive des corrections de bug incluses dans cette version, reportez-vous à la page Corrections de bug de JDK 8u211.

» Notes sur la version 8u211

Java 8 Update 201 (8u201)

Principales nouveautés de cette version

Données IANA 2018e
JDK 8u201 contient les données de fuseau horaire IANA version 2018e. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Modification : désactivation des mécanismes de cryptage TLS anon et NULL
Les mécanismes de cryptage TLS anon (anonymes) et NULL ont été ajoutés à la propriété de sécurité jdk.tls.disabledAlgorithms et sont désormais désactivés par défaut.
Reportez-vous à JDK-8211883
Modification : impression de la date d'expiration d'un horodatage par jarsigner
L'outil jarsigner affiche désormais plus d'informations sur la durée de vie d'un fichier JAR horodaté. De nouveaux messages d'avertissement et d'erreur sont affichés lorsqu'un horodatage a expiré ou expire dans l'année.
Reportez-vous à JDK-8191438

Date d'expiration de Java

La date d'expiration pour 8u201 est le 16 avril 2019. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u201) le 16 mai 2019. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

» Notes sur la version 8u201

Java 8 Update 191 (8u191)

Principales nouveautés de cette version

Données IANA 2018e
JDK 8u191 contient les données de fuseau horaire IANA version 2018e. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Modification : emplacement du système de fichiers central modifié pour le fichier usagetracker.properties
L'emplacement du système de fichiers dans Windows pour le fichier usagetracker.properties a été déplacé de %ProgramData%\Oracle\Java\ vers %ProgramFiles%\Java\conf
Le chemin de fichier reste le même pour Linux, Solaris ou macOS. JDK-8204901 (non public)
Modification : désactivation de tous les mécanismes de cryptage TLS DES
Les mécanismes de cryptage TLS basés sur DES sont considérés obsolètes et ne doivent plus être utilisés. Les mécanismes de cryptage basés sur DES ont été désactivés par défaut dans l'implémentation SunJSSE en ajoutant l'identificateur "DES" à la propriété de sécurité jdk.tls.disabledAlgorithms. Ces mécanismes de cryptage peuvent être réactivés en enlevant "DES" de la propriété de sécurité jdk.tls.disabledAlgorithms dans le fichier java.security ou en appelant de façon dynamique la méthode Security.setProperty(). Dans les deux cas, la réactivation de DES doit être suivie de l'ajout de mécanismes de cryptage DES à la liste des mécanismes de cryptage autorisés à l'aide des méthodes SSLSocket.setEnabledCipherSuites() ou SSLEngine.setEnabledCipherSuites().
Avant ce changement, les mécanismes DES40_CBC (mais pas l'ensemble des DES) ont été désactivés par le biais de la propriété de sécurité jdk.tls.disabledAlgorithms.
Reportez-vous à JDK-8208350
Modification : suppression de plusieurs autorités de certification racine Symantec
Les certificats racine Symantec suivants ne sont plus utilisés et ont été enlevés :
- Symantec
  - equifaxsecureca
    DN : OU=Equifax Secure Certificate Authority, O=Equifax, C=US
  - equifaxsecureglobalebusinessca1
    DN : CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
  - equifaxsecureebusinessca1
    DN : CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US
  - verisignclass1g3ca
    DN : CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
  - verisignclass2g3ca
    DN : CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
  - verisignclass1g2ca
    DN : OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
  - verisignclass1ca
    DN : OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
Reportez-vous à JDK-8191031
Modification : suppression de l'autorité de certification de signature de code CyberTrust Baltimore
Le certificat racine de signature de code CyberTrust Baltimore suivant n'est plus utilisé et a été enlevé :
- baltimorecodesigningca
  DN : CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE
Reportez-vous à JDK-8189949
Correction de bug : échec de communication LDAPS
Code d'application utilisant LDAPS avec un délai d'expiration de connexion du socket de <= 0 (valeur par défaut), exécuté sur la mise à jour des patches critiques de juillet 2018 (8u181, 7u191 et 6u201), peut rencontrer une exception lors de l'établissement de la connexion.
La plupart des principaux cadres des traces de pile d'exception des applications rencontrant de tels problèmes peuvent se présenter comme suit :
javax.naming.ServiceUnavailableException: ; socket closed
at com.sun.jndi.ldap.Connection.readReply(Unknown Source)
at com.sun.jndi.ldap.LdapClient.ldapBind(Unknown Source) ...
Le problème a été résolu et la correction est disponible dans les versions suivantes :
- 8u181
- 7u191
Reportez-vous à JDK-8211107

Date d'expiration de Java

La date d'expiration de la version 8u191 est le 15 janvier 2019. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u191) le 15 février 2019. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

» Notes sur la version 8u191

Java 8 Update 181 (8u181)

Principales nouveautés de cette version

Données IANA 2018e
JDK 8u181 contient les données de fuseau horaire IANA version 2018e. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Fonctionnalité supprimée : suppression de Java DB
Java DB, également connu comme Apache Derby, a été supprimé de cette version.
Nous vous recommandons d'obtenir la dernière version d'Apache Derby directement auprès du projet Apache à l'adresse suivante :
https://db.apache.org/derby
JDK-8197871 (non public)
Modification : amélioration de la prise en charge LDAP
L'identification des adresses a été activée sur les connexions LDAPS.
Pour améliorer la robustesse des connexions LDAPS (LDAP sécurisé sur TLS), les algorithmes d'identification d'adresse ont été activés par défaut.
Dans certains cas, cependant, des applications qui pouvaient auparavant se connecter à un serveur LDAPS ne sont plus forcément en mesure de le faire. Le cas échéant, ces applications permettent de désactiver l'identification des adresses à l'aide d'une nouvelle propriété système : com.sun.jndi.ldap.object.disableEndpointIdentification.
Définissez cette propriété système (ou attribuez-lui la valeur true) pour désactiver les algorithmes d'identification d'adresse.
JDK-8200666 (non public)
Modification : amélioration de la navigation dans la pile
De nouveaux contrôles d'accès ont été ajoutés à la phase de désérialisation lors de la création de l'objet. Cela ne devrait pas influer sur les utilisations courantes de la désérialisation. Cependant, les infrastructures miroirs qui utilisent les API internes JDK risquent d'en ressentir les effets. Si nécessaire, ces nouveaux contrôles peuvent être désactivés en définissant la propriété système jdk.disableSerialConstructorChecks sur la valeur "true". Pour ce faire, ajoutez l'argument -Djdk.disableSerialConstructorChecks=true à la ligne de commande Java.
JDK-8197925 (non public)
Correction de bug : arrêt de la JVM pendant G1 GC
Une classe considérée comme inaccessible par le marquage simultané de G1 peut faire l'objet d'une recherche dans ClassLoaderData/SystemDictionary et ses champs _java_mirror ou _class_loader peuvent être stockés à la racine ou dans tout autre objet accessible qui réactive la JVM. Lorsqu'une classe est réactivée de cette façon, la partie SATB de G1 doit en être informée. Sinon, la phase de nouveau marquage du marquage simultané déchargera indûment cette classe.
Reportez-vous à JDK-8187577
Correction de bug : amélioration de la stabilité avec les anciennes bibliothèques NUMA (-XX+UseNuma)
Un correctif inclus dans JDK 8 Update 152 a introduit une régression pouvant entraîner l'arrêt de la JVM HotSpot au démarrage lorsque l'indicateur UseNUMA est utilisé sur les systèmes Linux avec des versions de libnuma antérieures à 2.0.9. Ce problème a été résolu.
Reportez-vous à JDK-8198794

Date d'expiration de Java

La date d'expiration de la version 8u181 est le 16 octobre 2018. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u181) le 16 novembre 2018. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

» Notes sur la version 8u181

Java 8 Update 171 (8u171)

Principales nouveautés de cette version

Données IANA 2018c
JDK 8u171 contient les données de fuseau horaire IANA version 2018c. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Nouvelle fonctionnalité : mécanismes de fichier de clés améliorés
Une nouvelle propriété de sécurité nommée jceks.key.serialFilter a été introduite. Si ce filtre est configuré, le fichier de clés JCEKS l'utilise pendant la désérialisation de l'objet clé crypté stocké dans une entrée SecretKeyEntry. S'il n'est pas configuré ou si le résultat de filtre est NON DECIDE (par exemple, aucun des modèles ne correspond), le filtre configuré par jdk.serialFilter est alors consulté.
Si la propriété système jceks.key.serialFilter est également indiquée, elle remplace la valeur de propriété de sécurité définie ici.
Le modèle de filtre utilise le même format que jdk.serialFilter. Le modèle par défaut autorise java.lang.Enum, java.security.KeyRep, java.security.KeyRep$Type et javax.crypto.spec.SecretKeySpec mais rejette tous les autres.
Les clients qui stockent une clé secrète qui ne sérialise pas vers les types ci-dessus doivent modifier le filtre pour que la clé puisse être extraite.
JDK-8189997 (non public)
Nouvelle fonctionnalité : propriété système permettant de désactiver le suivi de dernière utilisation de l'environnement JRE
Une nouvelle propriété système jdk.disableLastUsageTracking a été introduite pour désactiver le suivi de dernière utilisation de l'environnement JRE pour une machine virtuelle en cours d'exécution. Cette propriété peut être définie dans la ligne de commande en utilisant -Djdk.disableLastUsageTracking=true ou -Djdk.disableLastUsageTracking. Une fois cette propriété système définie, le suivi de dernière utilisation de l'environnement JRE sera désactivé, quelle que soit la valeur de la propriété com.oracle.usagetracker.track.last.usage définie dans usagetracker.properties.
JDK-8192039 (non public)
Remarque : utilisation de CipherOutputStream
La spécification de javax.crypto.CipherOutputStream a été clarifiée pour indiquer que cette classe détecte l'exception BadPaddingException et les autres exceptions générées par des vérifications d'intégrité qui ont échoué au cours du décryptage. Ces exceptions ne sont pas générées à nouveau. Le client n'est donc pas informé de l'échec des vérifications d'intégrité. En raison de ce comportement, cette classe peut ne pas convenir à une utilisation avec le décryptage dans un mode authentifié de fonctionnement (par exemple, GCM) si l'application requiert une notification explicite lors de l'échec de l'authentification. Ces applications peuvent utiliser directement l'API de cryptage en tant qu'alternative à l'utilisation de cette classe.
JDK-8182362 (non public)
Modification : ajout d'un certificat racine TeliaSonera
La version 1 de l'autorité de certification racine TeliaSonera a été ajoutée au fichier de clés cacerts.
JDK-8190851 (non public)
Modification : désactivation des signatures XML signées avec des clés EC inférieures à 224 bits
Afin d'améliorer l'efficacité des connexions SSL/TLS, les mécanismes de cryptage 3DES ont été désactivés dans les connexions SSL/TLS dans JDK via la propriété de sécurité jdk.tls.disabledAlgorithms.
JDK-8175075 (non public)
Correction de bug : désactivation des connexions RMI par tunnel HTTP côté serveur
Les connexions RMI par tunnel HTTP côté serveur ont été désactivées par défaut dans cette version. Ce comportement peut être rétabli en définissant la propriété d'exécution sun.rmi.server.disableIncomingHttp sur False. Ne pas confondre avec la propriété sun.rmi.server.disableHttp, qui désactive le tunneling HTTP du côté client et dont la valeur par défaut est False.
JDK-8193833 (non public)

Date d'expiration de Java

La version 8u171 expire le 17 juillet 2018. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u171) le 17 août 2018. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

» Notes sur la version 8u171

Java 8 Update 161 (8u161)

Principales nouveautés de cette version

Données IANA 2017c
JDK 8u161 contient les données de fuseau horaire IANA version 2017c. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Nouvelle fonctionnalité : prise en en charge de tailles DHE jusqu'à 8192 bits et de tailles DSA jusqu'à 3072 bits
Améliore les fournisseurs de sécurité JDK pour prendre en charge la génération de paramètres DSA et Diffie-Hellman 3072 bits, les paramètres Diffie-Hellman précalculés jusqu'à 8192 bits et les paramètres DSA précalculés jusqu'à 3072 bits.
Reportez-vous à JDK-8072452
Nouvelle fonctionnalité : négociation de paramètres Finite Field Diffie-Hellman Ephemeral pour TLS
L'implémentation de JDK SunJSSE prend maintenant en charge les mécanismes TLS FFDHE définis dans la RFC 7919. Si un serveur ne peut pas traiter l'extension TLS supported_groups ou les groupes nommés dans l'extension, les applications peuvent soit personnaliser les noms de groupe pris en charge avec jdk.tls.namedGroups, soit désactiver les mécanismes FFDHE en définissant la propriété système jsse.enableFFDHEExtension sur false.
Reportez-vous à JDK-8140436
Nouvelle fonctionnalité : ajout de vérifications supplémentaires de type de stub IDL à la méthode org.omg.CORBA.ORBstring_to_object
Les applications qui appellent de manière implicite ou explicite la méthode org.omg.CORBA.ORB.string_to_object et qui garantissent l'intégrité du type de stub IDL impliqué dans le flux d'appels ORB::string_to_object doivent indiquer une vérification supplémentaire de type de stub IDL. Il s'agit d'une fonctionnalité de type "opt-in", qui n'est pas activée par défaut.
Afin de tirer parti de la vérification de type supplémentaire, la liste des noms de classe d'interface IDL valides des classes de stub IDL est configurée de l'une des façons suivantes :
- Indication de la propriété de sécurité com.sun.CORBA.ORBIorTypeCheckRegistryFilter située dans le fichier conf/security/java.security dans Java SE 9 ou dans le fichier jre/lib/security/java.security dans Java SE 8 et versions antérieures.
- Indication de la propriété de sécurité com.sun.CORBA.ORBIorTypeCheckRegistryFilte avec la liste des classes. Si la propriété système est définie, sa valeur remplace la propriété correspondante définie lors de la configuration de java.security.
Si la propriété com.sun.CORBA.ORBIorTypeCheckRegistryFilter n'est pas définie, la vérification de type est exécutée uniquement sur un ensemble de noms de classe des types d'interfaces IDL correspondant aux classes de stub IDL intégrées.
JDK-8160104 (non public)
Modification : validation de clé publique RSA
Dans la version 8u161, l'implémentation de RSA dans le fournisseur SunRsaSign rejettera toute clé publique RSA dotée d'un exposant qui n'est pas compris dans la plage valide définie par PKCS#1 version 2.2. Cette modification concerne les connexions JSSE ainsi que les applications créées sur JCE.
JDK-8174756 (non public)
Modification : restriction des clés Diffie-Hellman inférieures à 1 024 bits
Les clés Diffie-Hellman inférieures à 1 024 bits sont considérées comme trop faibles pour être utilisées dans la pratique et doivent par défaut faire l'objet d'une restriction dans les connexions SSL/TLS/DTLS. Ainsi, les clés Diffie-Hellman inférieures à 1 024 bits ont été désactivées par défaut en ajoutant "DH keySize < 1024" à la propriété de sécurité "jdk.tls.disabledAlgorithms" dans le fichier java.security. Bien que ce ne soit pas recommandé, les administrateurs peuvent mettre à jour la propriété de sécurité ("jdk.tls.disabledAlgorithms") et autoriser des tailles de clé plus petites (par exemple, en définissant "DH keySize < 768").
JDK-8148108 (non public)
Modification : mise à jour de la taille de clé par défaut de fournisseur
Cette modification met à jour les fournisseurs JDK afin qu'ils utilisent une taille de clé par défaut pour DSA de 2 048 bits au lieu de 1 024 bits, lorsque les applications n'ont pas explicitement initialisé les objets java.security.KeyPairGenerator et java.security.AlgorithmParameterGenerator avec une taille de clé.
Si des problèmes de compatibilité surviennent, les applications existantes peuvent définir la propriété système jdk.security.defaultKeySize introduite dans JDK-8181048 avec l'algorithme et la taille de clé par défaut souhaitée.
JDK-8178466 (non public)

Date d'expiration de Java

La date d'expiration pour 8u161 est le 17 avril 2018. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u161) le 17 mai 2018. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

» Notes sur la version 8u161

Java 8 Update 151 (8u151)

Principales nouveautés de cette version

Données IANA 2017b
JDK 8u151 contient les données de fuseau horaire IANA version 2017b. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Modifications de certificat : suppression du certificat racine Swisscom révoqué "swisscomrootevca2"
Un certificat racine Swisscom a été révoqué par Swisscom et a été enlevé : Swisscom Root EV CA 2 alias: "swisscomrootevca2 [jdk]" DN: CN=Swisscom Root EV CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch
JDK-8186330 (non public)
Nouvelles fonctionnalités Nouvelle propriété de sécurité pour contrôler la stratégie de cryptage
Cette version introduit une nouvelle fonctionnalité avec laquelle les fichiers JCE Jurisdiction Policy Files utilisés par le JDK peuvent être contrôlés par le biais d'une nouvelle propriété de sécurité. Dans les anciennes versions, ces fichiers devaient être téléchargés et installés séparément afin de permettre au JDK d'utiliser la cryptographie illimitée. Les étapes de téléchargement et d'installation ne sont plus nécessaires. Pour activer la cryptographie illimitée, vous pouvez utiliser la nouvelle propriété de sécurité crypto.policy. Si la nouvelle propriété de sécurité (crypto.policy) est définie dans le fichier java.security ou qu'elle a été définie de façon dynamique à l'aide de l'appel Security.setProperty() avant l'initialisation de la structure JCE, ce paramètre sera respecté. Par défaut, la propriété n'est pas définie. Si la propriété n'est pas définie et que les fichiers de juridiction JCE hérités n'existent pas dans le répertoire lib/security hérité, le niveau cryptographique par défaut reste 'limited'. Pour configurer le JDK avec la cryptographie illimitée, définissez crypto.policy sur la valeur 'unlimited'. Pour plus d'informations, reportez-vous aux remarques du fichier java.security compris dans cette version.
Remarque : sur Solaris, il est recommandé d'enlever les anciens packages SVR4 avant d'installer les nouvelles mises à jour du JDK. Si une mise à niveau SVR4 (sans désinstallation des anciens packages) est réalisée sur une version JDK antérieure à 6u131, 7u121 ou 8u111, vous devez définir la nouvelle propriété de sécurité crypto.policy dans le fichier java.security.

Etant donné que les anciens fichiers de juridiction JCE restent dans <java-home>/lib/security, il est possible qu'ils ne soient pas conformes aux dernières normes de signature JAR de sécurité, qui ont été actualisées dans les versions 6u131, 7u121, 8u111 et ultérieures. Une exception semblable à la suivante peut apparaître en cas d'utilisation des anciens fichiers :

Cause : java.lang.SecurityException : les fichiers de stratégie de juridiction ne sont pas signés par des émetteurs sécurisés ! sur javax.crypto.JceSecurity.loadPolicies(JceSecurity.java:593) sur javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:524)
Reportez-vous à JDK-8157561
Modifications Refactorisation des fournisseurs existants afin qu'ils fassent référence aux mêmes constantes pour les valeurs par défaut en matière de longueur de clé
Deux modifications importantes ont été apportées pour régler ce problème :
1. Une nouvelle propriété système a été introduite, qui permet aux utilisateurs de configurer la taille de clé par défaut utilisée par les implémentations de fournisseur JDK de KeyPairGenerator et d'AlgorithmParameterGenerator. Cette propriété s'appelle "jdk.security.defaultKeySize" et sa valeur correspond à une liste d'entrées séparées par une virgule. Chaque entrée correspond à un nom d'algorithme non sensible à la casse et à la taille de clé par défaut correspondante (valeur décimale) séparés par le signe deux-points (:). En outre, l'espace est ignoré.
Par défaut, cette propriété n'a pas de valeur, et les fournisseurs JDK utilisent leurs propres valeurs par défaut. Les entrées comportant un nom d'algorithme non reconnu sont ignorées. Si la taille de clé par défaut spécifiée n'est pas un nombre entier décimal analysable, cette entrée est également ignorée.
1. L'implémentation KeyPairGenerator DSA du fournisseur SUN n'implémente plus java.security.interfaces.DSAKeyPairGenerator. Les applications qui convertissent l'objet KeyPairGenerator DSA du fournisseur SUN en java.security.interfaces.DSAKeyPairGenerator peuvent définir la propriété système "jdk.security.legacyDSAKeyPairGenerator". Si la valeur de cette propriété est True, le fournisseur SUN renvoie un objet KeyPairGenerator DSA qui implémente l'interface java.security.interfaces.DSAKeyPairGenerator. Cette implémentation héritée utilise la valeur par défaut spécifiée par l'élément javadoc sur l'interface.
Par défaut, cette propriété n'a aucune valeur, et le fournisseur SUN renvoie un objet KeyPairGenerator DSA qui n'implémente pas l'interface mentionnée précédemment et qui, par conséquent, peut déterminer sa propre valeur par défaut de fournisseur comme indiqué dans la classe java.security.KeyPairGenerator ou par la propriété système 'jdk.security.defaultKeySize' si elle est définie.
JDK-8181048 (non public)

Date d'expiration de Java

La date d'expiration de la version 8u151 est le 16 janvier 2018. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u151) le 16 février 2018. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

» Notes sur la version 8u151

Java 8 Update 144 (8u144)

Principales nouveautés de cette version

Données IANA 2017b
JDK 8u144 contient les données de fuseau horaire IANA version 2017b. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Correction de bug : désormais, java.util.zip.ZipFile.getEntry() renvoie toujours l'instance ZipEntry avec un nom d'entrée se terminant par une barre oblique / pour l'entrée de répertoire
La documentation d'API java.util.zip.ZipEntry indique 'Une entrée de répertoire est définie de sorte que son nom se termine par une barre oblique /'. Cependant, dans les versions de JDK précédentes, java.util.zip.ZipFile.getEntry(String entryName) peut renvoyer une instance ZipEntry avec un nom d'entrée ne se terminant pas par / pour une entrée de répertoire .zip existante lorsque l'argument transmis entryName ne se termine pas par une barre oblique / et s'il existe une entrée de répertoire .zip correspondante portant le nom entryName + / dans le fichier .zip. Avec cette version, le nom de l'instance ZipEntry renvoyée par java.util.zip.ZipFile.getEntry() se termine toujours par / pour toute entrée de répertoire .zip.
Pour rétablir le comportement précédent, définissez la propriété système jdk.util.zip.ensureTrailingSlash sur 'false'.

Cette modification a été effectuée pour corriger une régression introduite dans JDK 8u141 lors de la vérification des fichiers JAR signés, et a entraîné l'échec du chargement de certaines applications WebStart.
Reportez-vous à JDK-8184993

Date d'expiration de Java

La date d'expiration de la version 8u144 est le 17 octobre 2017. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u144) le 17 novembre 2017. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

» Notes sur la version 8u144

Java 8 Update 141 (8u141)

Principales nouveautés de cette version

Données IANA 2017b
JDK 8u141 contient les données de fuseau horaire IANA version 2017b. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Modifications de certificat : nouveaux certificats Let's Encrypt ajoutés aux autorités de certification racine
Un nouveau certificat racine a été ajouté :
ISRG Root X1 alias : letsencryptisrgx1 DN : CN=ISRG Root X1, O=Internet Security Research Group, C=US
JDK-8177539 (non public)
Améliorations du diagnostic JMX
com.sun.management.HotSpotDiagnostic::dumpHeap L'API a été modifiée pour générer une exception IllegalArgumentException si le nom du fichier fourni ne se termine pas par le suffixe ".hprof". Les applications existantes qui ne fournissent pas un nom de fichier se terminant par l'extension ".hprof" échoueront avec l'exception IllegalArgumentException. Dans ce cas, les applications peuvent choisir soit de gérer les exceptions, soit de restaurer l'ancien comportement en définissant la propriété système 'jdk.management.heapdump.allowAnyFileSuffix' sur True.
JDK-8176055 (non public)
Vérifications plus sécurisées au niveau du traitement des fichiers WSDL avec l'outil wsimport
L'outil wsimport a été modifié pour désactiver les DTD dans les descriptions de service Web, en particulier :
- Le déclaration DOCTYPE n'est pas autorisée dans les documents
- Les entités générales externes ne sont pas incluses par défaut
- Les entités de paramètre externes ne sont pas incluses par défaut
- Les DTD externes sont complètement ignorées
Pour restaurer le comportement précédent, procédez comme suit :
- Définissez la propriété système com.sun.xml.internal.ws.disableXmlSecurity sur True
- Utilisez l'option de ligne de commande de l'outil wsimport –disableXmlSecurity
  Remarque : la prise en charge de JDK 7 et JDK 6 pour cette option dans wsimport sera fournie via une publication de version de patch après la mise à jour de patches critiques de juillet
JDK-8182054 (non public)
Le vérificateur de nom d'hôte personnalisé active l'extension SNI
Les précédentes versions des mises à jour de JDK 8 n'envoyaient pas toujours l'extension SNI (Server Name Indication) dans la phase TLS ClientHello si un vérificateur de nom d'hôte personnalisé était utilisé. Le vérificateur est défini via la méthode setHostnameVerifier(HostnameVerifier v) dans HttpsURLConnection. La correction permet de garantir que le nom de serveur est bien envoyé dans le corps ClientHello.
Reportez-vous à JDK-8144566
Amélioration de la vérification des contraintes d'algorithme
Pour répondre au besoin de restriction de l'utilisation des algorithmes faibles dans les situations où ils sont les plus vulnérables, des fonctionnalités supplémentaires ont été ajoutées lors de la configuration des propriétés de sécurité jdk.certpath.disabledAlgorithms et jdk.jar.disabledAlgorithms dans le fichier java.security.
jdk.certpath.disabledAlgorithms : la propriété certpath a subi le plus de modifications. Elle était auparavant limitée à deux types de contrainte, soit une désactivation complète d'un algorithme par nom, soit une désactivation complète d'un algorithme par taille de clé lors de la vérification des certificats, des chaînes de certificat et des signatures de certificat. Cette limite crée des configurations qui sont absolues et dont l'utilisation manque de flexibilité. Trois nouvelles contraintes ont été ajoutées pour offrir plus de flexibilité dans l'autorisation et le rejet des certificats.

"jdkCA" examine la fin de la chaîne de certificat en fonction du fichier cacerts. En cas d'utilisation de "SHA1 jdkCA". L'utilisation de SHA1 est vérifiée via la chaîne de certificat, mais la chaîne doit se terminer à un point d'ancrage marqué dans le fichier de clés des certificats CA pour être rejetée. Cela est utile pour les organisations qui ont leur propre autorité de certification qui utilise SHA1 avec leur point d'ancrage, mais qui veulent empêcher les chaînes de certificat ancrées par une autorité de certification publique d'employer SHA1.

"denyAfter" vérifie si la date indiquée est antérieure à la date actuelle ou à la date PKIXParameter. Dans le cas de "SHA1 denyAfter 2018-01-01", un certificat avec SHA1 peut être utilisé avant 2018, mais après cette date, le certificat est rejeté. Vous pouvez vous en servir pour une stratégie dans une organisation qui supprime un algorithme avec une date butoir. Pour les fichiers JAR signés, la date est comparée à l'horodatage TSA. La date est exprimée en temps GMT.

"usage" examine l'algorithme indiqué pour une utilisation spécifiée. Vous pouvez vous en servir lorsque la désactivation d'un algorithme pour toutes les utilisations n'est pas pratique. Vous pouvez spécifier trois utilisations :
- 'TLSServer' restreint l'algorithme dans les chaînes de certificat de serveur TLS lorsque l'authentification de serveur est effectuée en tant que client.
- 'TLSClient' restreint l'algorithme dans les chaînes de certificat de client TLS lorsque l'authentification de serveur est effectuée en tant que serveur.
- 'SignedJAR' restreint les algorithmes dans les certificats des fichiers JAR signés. Le type d'utilisation suit le mot-clé et plusieurs types d'utilisation peuvent être indiqués avec un délimiteur non imprimable.
  Par exemple, "SHA1 usage TLSServer TLSClient" interdirait les certificats SHA1 pour les opérations TLSServer et TLSClient, mais les fichiers JAR signés seraient autorisés
Vous pouvez combiner toutes ces contraintes pour contraindre un algorithme en les séparant par '&'. Par exemple, pour désactiver les chaînes de certificat SHA1 qui se terminent à des points d'ancrage marqués uniquement pour les opérations TLSServer, la contrainte est la suivante : "SHA1 jdkCA & usage TLSServer".

jdk.jar.disabledAlgorithms : une contrainte supplémentaire a été ajoutée à cette propriété .jar pour restreindre les algorithmes de manifeste JAR.

"denyAfter" vérifie les contraintes d'algorithme sur les algorithmes de manifeste Digest dans un fichier JAR signé. La date indiquée dans la contrainte est comparée à l'horodatage TSA du fichier JAR signé. Si le fichier ne contient aucun horodatage ou si l'horodatage correspond à la date indiquée ou à une date ultérieure à cette dernière, le fichier JAR signé est traité comme non signé. Si l'horodatage correspond à une date antérieure à la date indiquée, le fichier .jar sera exécuté comme un fichier JAR signé. La syntaxe pour restreindre SHA1 dans les fichiers JAR signés après le 1er janvier 2018 est : "SHA1 denyAfter 2018-01-01". La syntaxe est la même que celle de la propriété certpath, mais la vérification de certificat ne sera pas exécutée par cette propriété.
Reportez-vous à JDK-8176536

Date d'expiration de Java

La date d'expiration de la version 8u141 est le 17 octobre 2017. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u141) le 17 novembre 2017. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), l'environnement JRE fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

» Notes sur la version 8u141

Java 8 Update 131 (8u131)

Principales nouveautés de cette version

Données IANA 2016j
JDK 8u131 contient des données de fuseau horaire IANA version 2016j. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Correction de bug : introduction d'un nouveau modèle d'organisation des fenêtres
Sur la plate-forme OS X, la structure AWT utilisait des services natifs pour implémenter des relations parent/enfant entre les fenêtres. Cela générait des effets visuels négatifs, en particulier dans les environnements à plusieurs écrans. Pour éviter les désavantages que présente une telle approche, le nouveau modèle d'organisation des fenêtres a été introduit. Il est entièrement implémenté au niveau de la couche du JDK. Ses principes majeurs sont répertoriés ci-dessous :
- Une fenêtre doit être placée au-dessus de sa fenêtre parent la plus proche.
- Si une fenêtre comporte plusieurs fenêtres enfant, elles doivent toutes se trouver sur la même couche, et la fenêtre de la chaîne de fenêtres active doit être placée au-dessus de ses soeurs.
- Le tri ne doit pas être réalisé pour une fenêtre réduite en icône ou lorsque la transition vers un état d'icône est en cours.
Ces règles s'appliquent à chaque cadre ou boîte de dialogue de la hiérarchie de fenêtres contenant la fenêtre actuellement ciblée. Reportez-vous à JDK-8169589
Correction de bug : correction de l'exception IllegalArgumentException provenant de l'établissement de liaison TLS
Un problème récent issu de la correction JDK-8173783 peut être à l'origine d'erreurs pour certains serveurs TLS. Le problème provient d'une exception IllegalArgumentException générée par le code d'établissement de liaison TLS :

java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves

Le problème peut survenir lorsque le serveur ne dispose d'aucune prise en charge de la cryptographie de courbe elliptique pour gérer un champ d'extension de nom de courbe elliptique (le cas échéant). Il est recommandé aux utilisateurs de procéder à la mise à niveau vers cette version. Par défaut, les mises à jour du JDK 7 et les familles de JDK ultérieures sont fournies avec le fournisseur de sécurité SunEC proposant la prise en charge de la cryptographie de courbe elliptique. Cela ne devrait pas avoir de répercussions sur ces versions, sauf si les fournisseurs de sécurité sont modifiés. Reportez-vous à JDK-8173783
Ajout de MD5 à la propriété de sécurité jdk.jar.disabledAlgorithms
Cette version de JDK introduit une nouvelle restriction sur la façon dont les fichiers JAR signés MD5 sont vérifiés. Si le fichier JAR signé utilise MD5, les opérations de vérification de signature ignoreront la signature et traiteront le fichier JAR comme s'il était non signé. Cela peut éventuellement se produire dans les types d'application suivants qui utilisent des fichiers JAR signés :
- Applets ou applications Web Start
- Applications autonomes ou de serveur exécutées avec SecurityManager activé, et configurées avec un fichier de stratégies qui octroie des droits d'accès en fonction des signataires de code du fichier JAR.
La liste des algorithmes désactivés est contrôlée via la propriété de sécurité, jdk.jar.disabledAlgorithms, dans le fichier java.security. La propriété contient la liste des algorithmes désactivés et les tailles de clés pour les fichiers JAR signés de manière cryptographique.

Pour vérifier si une clé ou un algorithme faible a été utilisé pour signer un fichier JAR, vous pouvez utiliser le fichier binaire jarsigner fourni avec ce JDK. L'exécution de "jarsigner -verify" sur un fichier JAR signé avec une clé ou un algorithme faible générera plus d'informations sur la clé ou l'algorithme désactivé.

Par exemple, pour vérifier un fichier JAR nommé test.jar, utilisez la commande suivante :

jarsigner -verify test.jar

Si le fichier dans cet exemple a été signé avec un algorithme de signature faible comme MD5withRSA, la sortie suivante est affichée :

Le fichier JAR sera traité comme non signé, car il est signé avec un algorithme de signature faible qui est désormais désactivé. Réexécutez jarsigner avec l'option -verbose pour plus de détails.

Plus de détails peuvent être affichés à l'aide de l'option verbose :

jarsigner -verify -verbose test.jar

Plus de détails peuvent être affichés à l'aide de l'option verbose :
```
 - Signed by "CN=weak_signer" Digest algorithm: MD5 (weak) Signature algorithm: MD5withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key 
```
Pour résoudre le problème, le fichier JAR devra être resigné avec un algorithme renforcé ou une taille de clé plus importante. Les restrictions peuvent également être rétablies en enlevant les algorithmes ou les tailles de clé faibles applicables de la propriété de sécurité jdk.jar.disabledAlgorithms ; cependant, cette option n'est pas recommandée. Pour que les fichiers JAR concernés puissent être resignés, les signatures existantes doivent être enlevées du fichier JAR. Pour ce faire, vous pouvez utiliser l'utilitaire ZIP comme suit :

zip -d test.jar 'META-INF/.SF' 'META-INF/.RSA' 'META-INF/*.DSA'

Vérifiez régulièrement les restrictions planifiées relatives aux fichiers JAR signés et autres composants de sécurité dans le plan d'informations Oracle JRE and JDK Cryptographic Roadmap à l'adresse http://java.com/cryptoroadmap. JDK-8171121 (non public)
Nouvelle propriété système permettant de contrôler la mise en cache pour les connexions SPNEGO HTTP.
Une nouvelle propriété système propre à l'implémentation de JDK permettant de contrôler la mise en cache pour les connexions SPNEGO (Negotiate/Kerberos) HTTP a été introduite. La mise en cache pour les connexions SPNEGO HTTP reste activée par défaut. Par conséquent, si la propriété n'est pas explicitement indiquée, aucune modification comportementale ne surviendra. Lors de la connexion à un serveur HTTP qui utilise SPNEGO pour négocier l'authentification, et lorsque la connexion et l'authentification auprès du serveur sont réalisées, les informations d'authentification sont ensuite mises en cache et réutilisées pour les connexions futures à ce même serveur. En outre, la connexion à un serveur HTTP à l'aide de SPNEGO implique généralement de garder la connexion sous-jacente active et de la réutiliser pour les demandes futures au même serveur. Dans certaines applications, il peut être recommandé de désactiver la mise en cache pour le protocole SPNEGO (Negotiate/Kerberos) HTTP afin de forcer la demande de nouvelle authentification à chaque nouvelle demande envoyée au serveur.

Avec cette modification, nous fournissons désormais une nouvelle propriété système qui permet de contrôler la stratégie de mise en cache pour les connexions SPNEGO HTTP. Si jdk.spnego.cache est défini et évalué sur False, la mise en cache est désactivée pour toutes les connexions SPNEGO HTTP. La définition de cette propriété système sur False peut toutefois générer des effets secondaires indésirables :
- Les performances des connexions SPNEGO HTTP peuvent être extrêmement réduites car la connexion devra être réauthentifiée à chaque nouvelle demande, ce qui nécessitera plusieurs échanges avec le serveur.
- Vous devrez obtenir de nouvelles informations d'identification pour chaque nouvelle demande, ce qui, en fonction de la disponibilité de l'authentification transparente et de l'implémentation de l'authentificateur global, peut générer une fenêtre instantanée demandant à l'utilisateur de fournir ses informations d'identification à chaque nouvelle demande.
JDK-8170814 (non public)
Nouvelle propriété système permettant de contrôler la mise en cache pour les connexions NTLM HTTP.
Une nouvelle propriété système propre à l'implémentation de JDK permettant de contrôler la mise en cache pour les connexions NTLM HTTP a été introduite. La mise en cache pour les connexions NTLM HTTP reste activée par défaut. Par conséquent, si la propriété n'est pas explicitement indiquée, aucune modification comportementale ne surviendra. Sur certaines plates-formes, l'implémentation NTLM HTTP dans le JDK peut prendre en charge l'authentification transparente, où les informations d'identification utilisateur système sont utilisées au niveau du système. Lorsque l'authentification transparente n'est pas disponible ou ne fonctionne pas, le JDK prend uniquement en charge l'obtention d'informations d'identification auprès d'un authentificateur global. Si la connexion au serveur est établie, les informations d'authentification sont ensuite mises en cache et réutilisées pour les connexions futures à ce même serveur. En outre, la connexion à un serveur NTLM HTTP implique généralement de garder la connexion sous-jacente active et de la réutiliser pour les requêtes futures au même serveur. Dans certaines applications, il peut être recommandé de désactiver la mise en cache pour le protocole NTLM HTTP afin de forcer la demande de nouvelle authentification à chaque nouvelle demande envoyée au serveur.

Avec cette modification, nous fournissons désormais une nouvelle propriété système qui permet de contrôler la stratégie de mise en cache pour les connexions NTLM HTTP. Si jdk.ntlm.cache est défini et évalué sur False, la mise en cache est désactivée pour toutes les connexions NTLM HTTP. La définition de cette propriété système sur False peut toutefois générer des effets secondaires indésirables :
- Les performances des connexions NTLM HTTP peuvent être extrêmement réduites car la connexion devra être réauthentifiée à chaque nouvelle demande, ce qui nécessitera plusieurs échanges avec le serveur.
- Vous devrez obtenir de nouvelles informations d'identification pour chaque nouvelle demande, ce qui, en fonction de la disponibilité de l'authentification transparente et de l'implémentation de l'authentificateur global, peut générer une fenêtre instantanée demandant à l'utilisateur de fournir ses informations d'identification à chaque nouvelle demande.
JDK-8163520 (non public)
Nouvelle version de VisualVM
VisualVM 1.3.9 a été publié le 4 octobre 2016http://visualvm.github.io/relnotes.html et intégré à 8u131. Reportez-vous à JDK-8167485.

Date d'expiration de Java

La version 8u131 expire le 18 juillet 2017. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u131) le 18 août 2017. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), Java fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

Cette version comprend des correctifs concernant les vulnérabilités de sécurité. Pour plus d'informations, reportez-vous aux conseils sur la mise à jour des patches critiques Oracle Java SE. Pour consulter la liste des corrections de bug incluses dans cette version, reportez-vous à la page Corrections de bug de JDK 8u131.

» Notes sur la version 8u131

Java 8 Update 121 (8u121)

Principales nouveautés de cette version

Données IANA 2016i
JDK 8u121 contient des données de fuseau horaire IANA version 2016i. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Correction de bug : le défilement de texte à l'aide du trackpad sous OS X 10.12 Sierra est très rapide
La méthode MouseWheelEvent.getWheelRotation() a renvoyé les événements NSEvent deltaX/Y natifs arrondis sous Mac OS X. La dernière version de macOS Sierra 10.12 produit des valeurs NSEvent deltaX/Y très faibles. Par conséquent, le fait de les arrondir ou de les additionner génère une valeur très élevée renvoyée par MouseWheelEvent.getWheelRotation(). Le correctif JDK-8166591 cumule NSEvent deltaX/Y et la méthode MouseWheelEvent.getWheelRotation() renvoie des valeurs non nulles uniquement lorsque la valeur cumulée dépasse un seuil et est supérieure à zéro. Cela est conforme à la spécification MouseWheelEvent.getWheelRotation() : "Renvoie le nombre de 'clics' de rotation de la molette de la souris sous la forme d'un nombre entier. Une rotation partielle peut se produire si la souris dispose d'une molette haute résolution. Dans ce cas, la méthode renvoie zéro jusqu'à ce qu'un 'clic' entier ait été cumulé. Pour obtenir des valeurs de rotation de molette précises, utilisez plutôt la méthode MouseWheelEvent.getPreciseWheelRotation(). Reportez-vous à JDK-8166591.
Améliorer la puissance EC par défaut dans JDK
Pour améliorer la puissance par défaut de la cryptographie EC, les clés EC inférieures à 224 bits ont été désactivées dans le traitement de chemin de certification (via la propriété de sécurité jdk.certpath.disabledAlgorithms) et les connexions SSL/TLS (via la propriété de sécurité jdk.tls.disabledAlgorithms) dans JDK. Les applications peuvent mettre à jour cette restriction dans les propriétés de sécurité et autoriser des clés de plus petite taille si besoin (par exemple, "EC keySize < 192"). Les courbes EC inférieures à 256 bits sont enlevées de l'implémentation SSL/TLS dans JDK. La nouvelle propriété système jdk.tls.namedGroups définit la liste des courbes nommées activées pour les mécanismes de cryptage EC, par ordre de préférence. Si une application doit personnaliser les courbes EC activées par défaut ou la préférence des courbes, mettez à jour la propriété système en conséquence. Par exemple :
```
 jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1" 
```
Les courbes EC personnalisées ou activées par défaut suivent les contraintes d'algorithme. Par exemple, les courbes EC personnalisées ne peuvent pas réactiver les clés EC désactivées définies par les propriétés de sécurité Java. Reportez-vous à JDK-8148516.
Nouvelle option --allow-script-in-comments pour javadoc
L'outil javadoc rejettera désormais toute occurrence du code JavaScript dans les options de commentaires de documentation et de ligne de commande javadoc, à moins que l'option de ligne de commande --allow-script-in-comments soit indiquée. Avec l'option --allow-script-in-comments, l'outil javadoc conservera le code JavaScript dans les options de commentaires de documentation et de ligne de commande. L'outil javadoc renverra une erreur si du code JavaScript est trouvé et que l'option de ligne de commande n'est pas définie.
JDK-8138725 (non public)
Augmenter la longueur de clé minimale jusqu'à 1 024 pour les signatures XML
Le mode de validation sécurisé de l'implémentation de signature XML a été amélioré afin de restreindre les clés RSA et DSA inférieures à 1 024 bits par défaut, car elles ne sont plus assez sûres pour les signatures numériques. En outre, une nouvelle propriété de sécurité nommée jdk.xml.dsig.SecureValidationPolicy a été ajoutée au fichier java.security et permet de contrôler les différentes restrictions en vigueur lorsque le mode de validation sécurisé est activé. Le mode de validation sécurisé est activé soit en définissant la propriété de signature XML org.jcp.xml.dsig.secureValidation sur True avec la méthode javax.xml.crypto.XMLCryptoContext.setProperty, soit en exécutant le code avec SecurityManager. Si une signature XML est générée ou validée avec une clé RSA ou DSA faible, une exception XMLSignatureException sera générée avec le message "Les clés RSA inférieures à 1 024 bits sont interdites lorsque la validation sécurisée est activée" ou "Les clés DSA inférieures à 1 024 bits sont interdites lorsque la validation sécurisée est activée".
JDK-8140353 (non public)
Restreindre les certificats avec des clés DSA inférieures à 1 024 bits
Les clés DSA inférieures à 1 024 bits ne sont pas assez résistantes et doivent être restreintes dans la création et la validation de chemin de certification. Par conséquent, les clés DSA inférieures à 1 024 bits ont été désactivées par défaut en ajoutant "DSA keySize < 1024" à la propriété de sécurité "jdk.certpath.disabledAlgorithms". Les applications peuvent mettre à jour cette restriction dans la propriété de sécurité ("jdk.certpath.disabledAlgorithms") et autoriser des tailles de clé plus petites en cas de besoin (par exemple, "DSA keySize < 768"). JDK-8139565 (non public)
Plus de vérifications ajoutées au code d'analyse d'encodage DER
Plus de vérifications sont ajoutées au code d'analyse d'encodage DER pour détecter diverses erreurs d'encodage. En outre, les signatures qui contiennent un encodage construit à longueur indéfinie génèrent désormais une exception IOException lors de l'analyse. Les signatures générées à l'aide des fournisseurs par défaut de JDK ne sont pas concernées par cette modification. JDK-8168714 (non public)
Restrictions d'accès supplémentaires pour URLClassLoader.newInstance
Les chargeurs de classe créés par les méthodes java.net.URLClassLoader.newInstance permettent de charger des classes à partir d'une liste d'URL données. Si le code d'appel n'a pas accès aux URL et que les artefacts d'URL accessibles ne contiennent pas la classe requise, une exception ClassNotFoundException ou similaire est générée. Avant, une exception SecurityException aurait été générée en cas de refus d'accès à une URL. Si vous devez revenir au comportement précédent, cette modification peut être désactivée en définissant la propriété système jdk.net.URLClassPath.disableRestrictedPermissions. JDK-8151934 (non public)
Nouvelle propriété configurable dans logging.properties java.util.logging.FileHandler.maxLocks
Une nouvelle propriété configurable "java.util.logging.FileHandler.maxLocks" est ajoutée à java.util.logging.FileHandler. Cette nouvelle propriété de journalisation peut être définie dans le fichier de configuration de journalisation et rend possible la configuration du nombre maximal de verrouillages simultanés de fichiers journaux que peut gérer un élément FileHandler. La valeur par défaut est 100. Dans un environnement hautement simultané où de nombreuses applications client autonomes (plus de 101) utilisent l'API de journalisation JDK simultanément avec FileHandler, la limite par défaut de 100 peut être atteinte, générant ainsi un échec de l'acquisition des verrouillages de fichier FileHandler et une exception d'E/S. Dans un tel scénario, la nouvelle propriété de journalisation permet d'augmenter le nombre maximal de verrouillages avant le déploiement de l'application. Si elle n'est pas remplacée, la valeur par défaut de maxLocks (100) reste inchangée. Pour plus de détails, reportez-vous à la documentation d'API java.util.logging.LogManager et java.util.logging.FileHandler. Reportez-vous à JDK-8153955.

Remarques

Protection améliorée pour le chargement de classe distante JNDI

Le chargement de classe distante via des fabriques d'objets JNDI stockées dans les services d'annuaire et de noms est désactivé par défaut. Pour activer le chargement de classe distante par le registre RMI ou le fournisseur de services de noms COS, définissez la propriété système suivante sur la chaîne "true", le cas échéant :


 com.sun.jndi.rmi.object.trustURLCodebase com.sun.jndi.cosnaming.object.trustURLCodebase

JDK-8158997 (non public)

jarsigner -verbose -verify doit imprimer les algorithmes utilisés pour signer le fichier JAR

L'outil jarsigner a été amélioré afin d'afficher les détails des algorithmes et clés utilisés pour générer un fichier JAR signé. Il indiquera également si l'un de ces éléments est considéré comme faible.

Plus précisément, lorsque "jarsigner -verify -verbose filename.jar" est appelé, une section distincte est imprimée et contient des informations sur la signature et l'horodatage (le cas échéant) dans le fichier JAR signé, même s'il est traité comme non signé pour plusieurs raisons. Si un algorithme ou une clé est considéré comme faible, comme indiqué dans la propriété de sécurité jdk.jar.disabledAlgorithms, cet élément sera marqué comme faible "(weak)".

Par exemple :


 - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key

Reportez-vous à JDK-8163304.

Problèmes connus

javapackager et fx:deploy fournissent l'ensemble du JDK au lieu du JRE

Il existe un bug connu dans Java Packager pour Mac où l'ensemble du JDK peut être fourni avec le groupe d'applications, générant ainsi un package beaucoup plus volumineux que la normale. La solution de contournement consiste à utiliser l'option -Bruntime. Par exemple : -Bruntime=JavaAppletPlugin.plugin où JavaAppletPlugin.plugin pour le JRE souhaité à fournir se trouve dans le répertoire en cours. Reportez-vous à JDK-8166835.

Echec de l'installation de Java pour les non-administrateurs pour lesquels l'UAC est désactivé

L'installation de Java sous Windows échoue sans avertissement ou invite pour les non-administrateurs pour lesquels le contrôle d'accès utilisateur (UAC) est désactivé. Le programme d'installation laissera un répertoire, jds<numéro>.tmp, dans le répertoire %TEMP%.
JDK-8161460 (non public)

Nouvelles fonctionnalités

Ajout d'une propriété de sécurité pour configurer le mode de validation sécurisé de signature XML

Une nouvelle propriété de sécurité nommée jdk.xml.dsig.secureValidationPolicy a été ajoutée et vous permet de configurer les restrictions individuelles appliquées lorsque le mode de validation sécurisé de la signature XML est activé. La valeur par défaut pour cette propriété dans le fichier de configuration java.security est la suivante :


 jdk.xml.dsig.secureValidationPolicy=\ disallowAlg http://www.w3.org/TR/1999/REC-xslt-19991116,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#rsa-md5,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#md5,\ maxTransforms 5,\ maxReferences 30,\ disallowReferenceUriSchemes file http https,\ noDuplicateIds,\ noRetrievalMethodLoops

Pour plus d'informations, reportez-vous à la définition de la propriété dans le fichier java.security. Reportez-vous à JDK-8151893.

Configuration du filtre de sérialisation

Le filtrage de sérialisation introduit un nouveau mécanisme qui permet de filtrer les flux entrants de données de sérialisation d'objet afin d'améliorer la sécurité et la robustesse. Chaque élément ObjectInputStream applique un filtre, s'il est configuré, au contenu du flux lors de la désérialisation. Les filtres sont définis à l'aide d'une propriété système ou d'une propriété de sécurité configurée. La valeur des modèles "jdk.serialFilter" est décrite sur la page relative au filtrage de sérialisation JEP 290 et dans <JRE>/lib/security/java.security. Les actions de filtrage sont consignées dans le journaliseur 'java.io.serialization', s'il est activé. Reportez-vous à JDK-8155760.

Meilleure vérification de contrainte RMI

Le registre RMI et le nettoyage de la mémoire distribué utilisent les mécanismes du filtrage de sérialisation JEP 290 pour améliorer la robustesse du service. Le registre RMI et le nettoyage de la mémoire distribué implémentent des filtres intégrés de liste blanche pour les classes standard dont l'utilisation est attendue pour chaque service. Des modèles de filtre supplémentaires peuvent être configurés à l'aide d'une propriété système ou d'une propriété de sécurité. La syntaxe de modèle de propriété "sun.rmi.registry.registryFilter" et "sun.rmi.transport.dgcFilter" est décrite dans JEP 290 et dans <JRE>/lib/security/java.security. JDK-8156802 (non public)

Ajoutez un mécanisme permettant aux autorités de certification racine autres que celles par défaut de ne pas faire l'objet de restrictions d'algorithme.

Dans le fichier java.security, une contrainte supplémentaire nommée "jdkCA" est ajoutée à la propriété jdk.certpath.disabledAlgorithms. Cette contrainte interdit l'algorithme spécifié uniquement si celui-ci est utilisé dans une chaîne de certificat qui se termine à un point d'ancrage marqué dans le fichier de clés lib/security/cacerts. Si la contrainte jdkCA n'est pas définie, toutes les chaînes utilisant l'algorithme spécifié sont limitées. jdkCA ne peut être utilisée qu'une seule fois dans une expression DisabledAlgorithm. Exemple : pour appliquer la contrainte aux certificats SHA-1, incluez l'élément suivant : SHA1 jdkCA
. Reportez-vous à JDK-8140422.

Date d'expiration de Java

La date d'expiration pour 8u121 est le 18 avril 2017. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u121) le 18 mai 2017. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), Java fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

» Notes sur la version 8u121

Java 8 Update 111 (8u111)

Principales nouveautés de cette version

Données IANA 2016f
JDK 8u111 contient des données de fuseau horaire IANA version 2016f. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE. Reportez-vous à JDK-8159684.
Modifications de certificat : nouvelle autorité de certification racine de signature de code JCE
Afin de prendre en charge des longueurs de clé plus importantes et des algorithmes de signature renforcés, une autorité de certification racine de signature de code de fournisseur JCE a été créée et son certificat a été ajouté à Oracle JDK. Les nouveaux certificats de signature de code de fournisseur JCE émis par cette autorité de certification seront utilisés pour la signature des fournisseurs JCE à partir de maintenant. Par défaut, les nouvelles demandes de certificats de signature de code de fournisseur JCE seront émises par cette autorité de certification.

Les certificats existants provenant de la racine de signature de code de fournisseur JCE en cours continueront à être validés. Toutefois, cette autorité de certification racine peut être désactivée à un moment donné à l'avenir. Nous recommandons de demander de nouveaux certificats et de resigner les fichiers JAR de fournisseur existants. Pour plus d'informations sur le processus de signature de fournisseur JCE, reportez-vous à la documentation relative à l'implémentation d'un fournisseur dans l'architecture de cryptographie Java. JDK-8141340 (non public)
Services de menu Service
La gestion du cycle de vie des composants de menu AWT a présenté des problèmes sur certaines plates-formes. Ce correctif améliore la synchronisation d'état entre les menus et leurs conteneurs. JDK-8158993 (non public)
Désactivation de l'authentification de base pour le tunneling HTTPS
Dans certains environnements, des modèles d'authentification peuvent être indésirables lors du processus proxy HTTPS. Par conséquent, le modèle d'authentification de base a été désactivé, par défaut, dans Oracle Java Runtime, par son ajout à la propriété réseau jdk.http.auth.tunneling.disabledSchemes. Les proxies nécessitant l'authentification Basic lors de la configuration d'un tunnel pour HTTPS ne réussiront plus par défaut. Si nécessaire, ce modèle d'authentification peut être réactivé en enlevant Basic de la propriété réseau jdk.http.auth.tunneling.disabledSchemes ou en définissant une propriété système du même nom sur "" (vide) sur la ligne de commande. Par ailleurs, les propriétés réseau jdk.http.auth.tunneling.disabledSchemes et jdk.http.auth.proxying.disabledSchemes, ainsi que les propriétés systèmes du même nom, peuvent être utilisées pour désactiver d'autres modèles d'authentification susceptibles d'être actifs lors de la configuration d'un tunnel pour HTTPS ou du processus proxy HTTP ordinaire, respectivement. JDK-8160838 (non public)
Restreindre les fichiers JAR signés avec des clés et des algorithmes faibles
Cette version de JDK inclut de nouvelles restrictions concernant la vérification des fichiers JAR signés. Si le fichier JAR signé utilise un algorithme désactivé ou une taille de clé inférieure à la longueur minimale, les opérations de vérification de signature ignoreront la signature et traiteront le fichier JAR comme s'il était non signé. Cela peut éventuellement se produire dans les types d'application suivants qui utilisent des fichiers JAR signés :
1. Applets ou applications Web Start
2. Applications autonomes ou de serveur exécutées avec SecurityManager activé, et configurées avec un fichier de stratégies qui octroie des droits d'accès en fonction des signataires de code du fichier JAR.

La liste des algorithmes désactivés est contrôlée via une nouvelle propriété de sécurité, jdk.jar.disabledAlgorithms dans le fichier java.security. La propriété contient la liste des algorithmes désactivés et les tailles de clés pour les fichiers JAR signés de manière cryptographique.

Les algorithmes et longueurs de clé ci-après sont restreints dans cette version :
1. MD2 (dans l'algorithme Digest ou de signature)
2. Clés RSA de moins de 1 024 bits
Remarque : nous prévoyons de restreindre les signatures basées sur MD5 dans les fichiers JAR signés dans la mise à jour des patches critiques d'avril 2017.

Pour vérifier si une clé ou un algorithme faible a été utilisé pour signer un fichier JAR, vous pouvez utiliser le fichier binaire jarsigner fourni avec ce JDK. L'exécution de jarsigner -verify -J-Djava.security.debug=jar sur un fichier JAR signé avec une clé ou un algorithme faible générera plus d'informations sur la clé ou l'algorithme désactivé.

Par exemple, pour vérifier un fichier JAR nommé test.jar, utilisez la commande suivante :
jarsigner -verify -J-Djava.security.debug=jar test.jar

Si le fichier dans cet exemple a été signé avec un algorithme de signature faible comme MD2withRSA, la sortie suivante est affichée :
jar: beginEntry META-INF/my_sig.RSA
jar: processEntry: processing block
jar: processEntry caught: java.security.SignatureException: Signature check failed. Disabled algorithm used: MD2withRSA
jar: done with meta!

La commande jarsigner mise à jour sera fermée avec l'avertissement suivant généré sur la sortie standard :
"Signature non analysable ou vérifiable. Le fichier JAR sera traité comme non signé. Le fichier JAR peut avoir été signé avec un algorithme faible qui est maintenant désactivé. Pour plus d'informations, réexécutez jarsigner avec le débogage activé (-J-Djava.security.debug=jar)"

Pour résoudre le problème, le fichier JAR devra être resigné avec un algorithme renforcé ou une taille de clé plus importante. Les restrictions peuvent également être rétablies en enlevant les algorithmes ou les tailles de clé faibles applicables de la propriété de sécurité jdk.jar.disabledAlgorithms ; cependant, cette option n'est pas recommandée. Pour que les fichiers JAR concernés puissent être resignés, les signatures existantes doivent être enlevées du fichier JAR. Pour ce faire, vous pouvez utiliser l'utilitaire zip comme suit :

zip -d test.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*.DSA'

Vérifiez régulièrement les restrictions planifiées relatives aux fichiers JAR signés et autres composants de sécurité dans le plan d'informations Oracle JRE and JDK Cryptographic Roadmap à l'adresse http://java.com/cryptoroadmap. Nous prévoyons notamment de restreindre les signatures basées sur MD5 dans les fichiers JAR signés dans la mise à jour des patches critiques d'avril 2017.

Pour tester si vos fichiers JAR ont été signés avec MD5, ajoutez MD5 à la propriété de sécurité jdk.jar.disabledAlgorithms, par exemple :

jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024

, puis exécutez jarsigner -verify -J-Djava.security.debug=jar sur vos fichiers JAR comme indiqué ci-dessus.
JDK-8155973 (non public)
Ajout d'un message d'avertissement à la boîte de dialogue d'authentificateur de déploiement
Un avertissement a été ajouté à la boîte de dialogue d'authentification de plug-in lors de l'utilisation de l'authentification de base HTTP (envoi des informations d'identification non cryptées) lorsqu'un proxy est employé ou que les protocoles SSL/TLS ne sont pas utilisés :
"Avertissement : le modèle d'authentification de base transmettra vos informations d'identification en clair. Voulez-vous continuer ?"
JDK-8161647 (non public)

Problèmes connus

Certains événements ne sont pas disponibles dans les enregistrements JFR sur Windows

Les événements suivants ne sont pas disponibles dans les enregistrements JFR sur Windows pour la version 8u111 :

hotspot/jvm/os/processor/cpu_load
os/processor/context_switch_rate

Cela est dû à la régression JDK-8063089 qui a été introduite dans la version 8u111 avec les modifications pour JDK-8162419. Le correctif pour JDK-8063089 n'a pas pu être inclus dans la version 8u111. Il sera disponible dans le build 8u111 BPR suivant et dans la prochaine version publique.
JDK-8063089 (non public)

La JVM génère des exceptions NullPointerExceptions sur macOS Sierra 10.12

Sous macOS Sierra 10.12, si un utilisateur appuie sur des touches de modification (telles que Commande, Maj ou Alt) pendant l'exécution d'une applet dans un navigateur, une fenêtre d'erreur de type Erreur interne peut apparaître. L'icône "exec" est également affichée dans le Dock macOS. L'utilisateur peut fermer l'applet ou tenter de la réexécuter sans appuyer sur une touche de modification. Reportez-vous à JDK-8165867.

Date d'expiration de Java

La date d'expiration de la version 8u111 est le 17 janvier 2017. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u111) le 17 février 2017. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), Java fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

» Notes sur la version 8u111

Java 8 Update 101 (8u101)

Principales nouveautés de cette version

Données IANA 2016d
JDK 8u101 contient des données de fuseau horaire IANA version 2016d. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE. Reportez-vous à JDK-8151876.
Modifications de certificat
Nouveaux certificats DTrust ajoutés aux autorités de certification racine
Deux nouveaux certificats racine ont été ajoutés :
- D-TRUST Root Class 3 CA 2 2009 Alias : dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE
- D-TRUST Root Class 3 CA 2 EV 2009 Alias : dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE
Reportez-vous à JDK-8153080

Nouveaux certificats Iden ajoutés aux autorités de certification racine
Trois nouveaux certificats racine ont été ajoutés :
- IdenTrust Public Sector Root CA 1 Alias : identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US
- IdenTrust Commercial Root CA 1 Alias : identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US
- IdenTrust DST Root CA X3 Alias : identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co.
Reportez-vous à JDK-8154757

Autorité de certification racine Comodo enlevée
L'autorité de certification racine Comodo "UTN - DATACorp SGC" a été enlevée du fichier cacerts. Reportez-vous à JDK-8141540

Autorité de certification Sonera Class1 CA enlevée
L'autorité de certification racine "Sonera Class1 CA" a été enlevée du fichier cacerts. Reportez-vous à JDK-8141276.
Amélioration du contrôle d'accès à javax.rmi.CORBA.ValueHandler
La classe javax.rmi.CORBA.Util fournit des méthodes pouvant être utilisées par des stubs et des liaisons pour réaliser des opérations courantes. Elle a également un rôle de fabrique pour ValueHandlers. L'interface javax.rmi.CORBA.ValueHandler fournit des services pour la prise en charge de la lecture et de l'écriture de types de valeur dans des flux de données GIOP. Les implications en matière de sécurité ont été améliorées pour ces utilitaires avec l'introduction d'un droit d'accès java.io.SerializablePermission("enableCustomValueHanlder"). Cela permet d'établir une relation d'approbation entre les utilisateurs des API javax.rmi.CORBA.Util et javax.rmi.CORBA.ValueHandler.

Le droit d'accès requis est SerializablePermission "enableCustomValueHanlder". Un code tiers qui est exécuté avec SecurityManager installé, mais qui ne dispose pas du nouveau droit d'accès lors de l'appel de Util.createValueHandler() échoue avec une exception AccessControlException.

Dans JDK8u et les versions antérieures, ce comportement de vérification de droit d'accès peut être remplacé en définissant une propriété système : "jdk.rmi.CORBA.allowCustomValueHandler".

Par conséquent, les applications externes qui appellent explicitement javax.rmi.CORBA.Util.createValueHandler doivent faire l'objet d'une modification de configuration pour fonctionner lorsque SecurityManager est installé et que les deux exigences suivantes ne sont pas respectées :
1. Le droit d'accès java.io.SerializablePermission("enableCustomValueHanlder") n'est pas octroyé par SecurityManager.
2. Si des applications sont exécutées sous JDK8u et versions antérieures, la propriété système "jdk.rmi.CORBA.allowCustomValueHandler" n'est pas définie ou est définie sur une valeur égale à "false" (sans respect maj/min).
Notez que la typo "enableCustomValueHanlder" sera corrigée dans les versions d'octobre 2016. Dans ces versions de JDK et dans les futures versions, "enableCustomValueHandler" sera le droit d'accès SerializationPermission correct à utiliser.
JDK-8079718 (non public)
Prise en charge ajoutée à jarsigner pour la spécification d'un algorithme de hachage d'horodatage
Une nouvelle option -tsadigestalg est ajoutée à jarsigner pour indiquer l'algorithme Digest de message utilisé pour générer l'empreinte de message à envoyer au serveur TSA. Dans les anciennes versions de JDK, l'algorithme Digest de message utilisé était SHA-1. Si cette nouvelle option n'est pas indiquée, SHA-256 sera utilisé pour les mises à jour JDK 7 et pour les versions ultérieures de la famille JDK. Pour les mises à jour JDK 6, SHA-1 restera l'algorithme par défaut, mais un avertissement sera imprimé sur le flux en sortie standard. Reportez-vous à JDK-8038837.
Le fichier de clés MSCAPI peut gérer les certificats du même nom
Le fichier de clés Java SE n'autorise pas les certificats portant le même alias. Cependant, sous Windows, plusieurs certificats stockés dans le même fichier de clés peuvent posséder des noms conviviaux non uniques. Le correctif pour JDK-6483657 rend possible l'exploitation de ces certificats aux noms non uniques via l'API Java en rendant artificiellement les alias visibles uniques. Ce correctif n'active toutefois pas la création de certificats de même nom avec l'API Java. Il permet uniquement de gérer les certificats de même nom ajoutés au fichier de clés par des outils tiers. Nous recommandons toujours que votre conception n'utilise pas plusieurs certificats du même nom. Plus particulièrement, la recommandation suivante ne sera pas enlevée de la documentation Java :
"Pour éviter tout problème, il est recommandé de ne pas utiliser des alias dont seule la casse diffère dans un fichier de clés".
Reportez-vous à JDK-6483657.
Les méthodes d'API de toolkit de déploiement n'installent plus l'environnement JRE
Les méthodes installLatestJRE() et installJRE(requestedVersion) d'API de toolkit de développement à partir de deployJava.js et la méthode install() à partir de dtjava.js n'installent plus l'environnement JRE. Si la version de Java d'un utilisateur est inférieure à la référence de sécurité, elle redirige l'utilisateur vers java.com pour obtenir une version mise à jour de l'environnement JRE. JDK-8148310 (non public)
DomainCombiner ne consultera plus la stratégie d'exécution pour les objets ProtectionDomain statiques lors de la combinaison d'objets ProtectionDomain
Les applications qui utilisent des objets ProtectionDomain statiques (créés à l'aide du constructeur à deux arguments) avec un ensemble de droits d'accès insuffisant peuvent désormais obtenir une exception AccessControlException avec ce correctif. Elles devront remplacer les objets ProtectionDomain statiques par des objets dynamiques (à l'aide du constructeur à 4 arguments) dont l'ensemble de droits d'accès sera développé par la stratégie en cours, ou créer l'objet ProtectionDomain statique avec tous les droits d'accès nécessaires. JDK-8147771 (non public)

Problèmes connus

L'environnement JRE 8u101 n'est pas reconnu par Internet Explorer (IE) lors de l'utilisation de l'ID de classe statique

Lorsqu'un ID de classe statique est employé pour lancer une applet ou une application Web Start lors de l'utilisation de l'environnement JRE 8u101, les utilisateurs obtiennent une boîte de dialogue non souhaitée leur indiquant d'utiliser le dernier environnement JRE ou d'annuler le lancement même s'ils ont déjà installé et utilisent le dernier environnement JRE (JRE 8u101). Ce cas spécifique s'applique uniquement à Windows et IE.

Nous ne recommandons pas l'utilisation d'un ID de classe statique pour la sélection de la version de l'environnement JRE (depuis le JDK 5u6, décembre 2005) conformément à la page http://www.oracle.com/technetwork/java/javase/family-clsid-140615.html.

Pour contourner ce problème, les utilisateurs peuvent effectuer l'une des deux actions suivantes :

Choisir le lancement avec la dernière version (8u101) et ignorer l'avertissement.
Installer l'environnement JRE 8u102 plutôt que l'environnement JRE 8u101 pour éviter ce problème.

Pour résoudre ce problème, les développeurs peuvent effectuer l'une des deux actions suivantes :

Utiliser un ID de classe dynamique plutôt qu'un ID de classe statique.
Utiliser java_version avec une applet HTML ou utiliser un descripteur JNLP avec JNLP.

JDK-8147457 (non public)

Corrections de bug

Date d'expiration de Java

La date d'expiration de la version 8u101 est le 19 octobre 2016. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u101) le 19 novembre 2016. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), Java fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

» Notes sur la version 8u101

Java 8 Update 91 (8u91)

Principales nouveautés de cette version

Données IANA 2016a
JDK 8u91 contient des données de fuseau horaire IANA version 2016a. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Résolution de bug : régression dans l'heure de démarrage de l'applet corrigée
JDK-8080977 retardait le lancement de l'applet. Le retard apparaît uniquement dans IE et dure environ 20 secondes. JDK-8136759 a enlevé ce retard. Reportez-vous à JDK-8136759.
Correction de bug : la génération de signature DSA est maintenant soumise à une vérification de puissance de clé
Pour la génération de signature, si la puissance de sécurité de l'algorithme Digest est inférieure à celle de la clé utilisée pour réaliser la signature (par exemple, utilisation de clés DSA de 2 048 ou 256 bits avec la signature SHA1withDSA), l'opération entraîne le message d'erreur suivant : "La puissance de sécurité de l'algorithme Digest SHA1 est insuffisante pour la taille de cette clé." JDK-8138593 (non public)
Correction de bug : problème avec LiveConnect dans Firefox 42
Le navigateur pouvant être bloqué, nous ne traitons pas les appels de JavaScript à Java lorsque le plug-in Java est lancé à partir de plugin-container.exe (comportement par défaut pour Firefox 42) et que le statut de l'applet n'est pas Prêt (2). Si l'applet n'est pas prête (le statut ne correspond pas à 2), nous n'exécutons pas la méthode Java réelle et nous renvoyons uniquement la valeur NULL.

Si le plug-in est lancé à partir de plugin-container.exe, n'utilisez pas les appels de JavaScript à Java pouvant nécessiter plus de 11 secondes (valeur par défaut de dom.ipc.plugins.hangUITimeoutSecs) et n'affichez pas une boîte de dialogue modale pendant l'appel de JavaScript à Java. Dans ce cas, le thread de navigateur principal doit être bloqué, ce qui peut provoquer le blocage du navigateur et l'arrêt du plug-in.

Solution de contournement pour Firefox 42 : les utilisateurs peuvent définir dom.ipc.plugins.enabled=false. Cette solution a pour effet secondaire la modification du paramètre pour l'ensemble des plug-ins. JDK-8144079 (non public)
Correction de bug : le nouvel attribut pour les serveurs JRMP RMI JMX indique la liste des noms de classe à utiliser lors de la désérialisation des informations d'identification du serveur
Un nouvel attribut Java a été défini pour l'environnement afin de permettre à un serveur JRMP RMI JMX d'indiquer la liste des noms de classe. Ces noms correspondent à la délimitation des noms de classe qui sont prévus par le serveur lors de la désérialisation des informations d'identification. Par exemple, si les informations d'identification attendues étaient :
```
 List<string>
```
la fermeture constitue toutes les classes concrètes attendues dans le format de série d'une liste de chaînes.

Par défaut, cet attribut est utilisé uniquement par l'agent par défaut avec les éléments suivants :
```
 { "[Ljava.lang.String;", "java.lang.String" } 
```
Seuls les tableaux de chaînes et les chaînes seront acceptés lors de la désérialisation des informations d'identification. Nom de l'attribut :
```
"jmx.remote.rmi.server.credential.types" 
```
Voici l'exemple d'un utilisateur démarrant un serveur avec les noms de classe d'informations d'identification indiqués :
```
 Map<string, object=""> env = new HashMap<>(1); env.put ( "jmx.remote.rmi.server.credential.types", new String[]{ String[].class.getName(), String.class.getName() } ); JMXConnectorServer server = JMXConnectorServerFactory.newJMXConnectorServer(url, env, mbeanServer); 
```
La nouvelle fonctionnalité doit être utilisée en spécifiant directement :
"jmx.remote.rmi.server.credential.types"

JDK-8144430 (non public)
Correction de bug : désactivation de l'algorithme de signature MD5withRSA dans le fournisseur JSSE
. L'algorithme de signature MD5withRSA est maintenant considéré comme non sécurisé et ne peut plus être utilisé. Par conséquent, MD5withRSA a été désactivé par défaut dans l'implémentation Oracle JSSE en ajoutant "MD5withRSA" à la propriété de sécurité "jdk.tls.disabledAlgorithms". Désormais, les messages d'établissement de liaison TLS et les certificats X.509 signés avec l'algorithme MD5withRSA ne sont plus acceptables par défaut. Cette modification étend la restriction de certificat MD5 précédente ("jdk.certpath.disabledAlgorithms") afin d'inclure également les messages d'établissement de liaison dans la version 1.2 de TLS. Le cas échéant, cet algorithme peut être réactivé en enlevant "MD5withRSA" de la propriété de sécurité "jdk.tls.disabledAlgorithms". JDK-8144773 (non public)
Correction de bug : nouveaux certificats ajoutés aux autorités de certification racine
Huit nouveaux certificats racine ont été ajoutés :
- QuoVadis Root CA 1 G3 alias : quovadisrootca1g3 DN : CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM
- QuoVadis Root CA 2 G3 alias : quovadisrootca2g3 DN : CN=QuoVadis Root CA 2 G3
- QuoVadis Root CA 3 G3 alias : quovadisrootca3g3 DN : CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM
- DigiCert Assured ID Root G2 alias : digicertassuredidg2 DN : CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
- DigiCert Assured ID Root G3 alias : digicertassuredidg3 DN : CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US
- DigiCert Global Root G2 alias : digicertglobalrootg2 DN : CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
- DigiCert Global Root G3 alias : digicertglobalrootg3 DN : CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US
- DigiCert Trusted Root G4 alias : digicerttrustedrootg4 DN : CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US
Reportez-vous à JDK-8145954 et JDK-8145955.

Remarques

Suppression des environnements JRE statiques
Les programmes d'installation Java pour Windows qui ont été publiés avant la version 8u91 n'enlevaient pas les environnements JRE installés de manière statique par défaut. Pour enlever les environnements JRE installés de manière statique, les utilisateurs devaient les sélectionner manuellement dans l'interface utilisateur du programme d'installation Java. Désormais, dans les versions de Java 8u91 et ultérieures, les environnements JRE qui ont été installés de manière statique seront automatiquement enlevés s'ils sont inférieurs à la référence de sécurité. Pour plus d'informations sur l'installation statique, reportez-vous à la configuration de l'environnement JRE.

Date d'expiration de Java

La version 8u91 expire le 19 juillet 2016. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u91) le 19 août 2016. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), Java fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

» Notes sur la version 8u91

Java 8 Update 77 (8u77)

Principales nouveautés de cette version

Données IANA 2016a
8u77 contient des données de fuseau horaire IANA version 2016a. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.

Date d'expiration de Java

La date d'expiration pour 8u77 est le 19 avril 2016. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u77) le 19 mai 2016. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), Java fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Remarques

Cette alerte de sécurité (8u77) repose sur la publication de la mise à jour d'ensemble de patches 8u74 précédente. Tous les utilisateurs des versions JDK 8 précédentes doivent effectuer une mise à jour vers cette version. Pour plus d'informations sur la différence entre les mises à jour de patches critiques et les mises à jour d'ensemble de patches, consultez la page Java CPU and PSU Releases Explained.

Les démos, les exemples et les lots de documentation pour 8u77 ne sont pas concernés par l'alerte de sécurité relative à CVE-2016-0636. Par conséquent, les démos, les exemples et les lots de documentation de la version 8u73 demeurent la version la plus à jour jusqu'à la publication de la mise à jour de patches critiques d'avril.

Corrections de bug

Cette version comprend des correctifs concernant les vulnérabilités de sécurité. Pour plus d'informations, reportez-vous aux conseils sur la mise à jour des patches critiques Oracle Java SE.

» Notes sur la version 8u77

Java 8 Update 73 (8u73)

Principales nouveautés de cette version

Données IANA 2015g
JDK 8u71 contient des données de fuseau horaire IANA version 2015g. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.

Date d'expiration de Java

La date d'expiration pour 8u73 est le 19 avril 2016. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u73) le 19 mai 2016. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), Java fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Remarques

Oracle recommande vivement aux utilisateurs Java qui ont téléchargé des versions affectées et qui prévoient de réaliser des installations avec ces versions de supprimer ces anciens téléchargements. Les utilisateurs Java qui ont installé les versions de mise à jour des patches critiques de janvier 2016 de Java SE 6, 7 ou 8 n'ont besoin d'entreprendre aucune action. Les utilisateurs Java qui n'ont pas installé les versions de mise à jour des patches critiques de janvier 2016 de Java SE 6, 7 ou 8 doivent effectuer une mise à niveau vers Java SE 6, 7 ou 8 à partir de l'alerte de sécurité pour CVE-2016-0603.

Les démos, les exemples et les lots de documentation pour 8u73 ne sont pas concernés par l'alerte de sécurité relative à CVE-2016-0603. Par conséquent, les démos, les exemples et les lots de documentation de la version 8u71 demeurent la version la plus à jour jusqu'à la publication de la mise à jour de patches critiques d'avril.

Corrections de bug

Cette version comprend des correctifs concernant les vulnérabilités de sécurité. Pour plus d'informations, reportez-vous aux conseils sur la mise à jour des patches critiques Oracle Java SE. La version 8u73 ne comporte pas les builds de mise à jour d'ensemble de patches de la version 8u72. Les clients qui exigent les corrections de bug supplémentaires contenues dans la version 8u72 doivent effectuer une mise à jour vers 8u74 au lieu de 8u73.

» Notes sur la version 8u73

Java 8 Update 71 (8u71)

Principales nouveautés de cette version

Données IANA 2015g
JDK 8u71 contient des données de fuseau horaire IANA version 2015g. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Correction de bug : l'exécution de JPS en tant que racine n'affiche pas toutes les informations
Après la correction de JDK-8050807 (dans 8u31, 7u75 et 6u91), l'exécution de JPS en tant que racine n'affiche pas toutes les informations des processus Java démarrés par d'autres utilisateurs sur certains systèmes. Ce bug a été corrigé. Reportez-vous à JDK-8075773.
Correction de bug : les programmes d'installation semblent bloqués sur les configurations ESC
Les utilisateurs appliquant la configuration de sécurité renforcée (ESC) d'Internet Explorer sur Windows Server 2008 R2 peuvent avoir rencontré des difficultés lors de l'installation de Java en mode interactif. Ce problème a été résolu dans la version 8u71. Les programmes d'installation exécutés en mode interactif n'apparaîtront plus comme bloqués sur les configurations ESC. Reportez-vous à JDK-8140197.
Correction de bug : problème avec les algorithmes PBE utilisant le cryptogramme AES corrigé
Une erreur a été corrigée pour les algorithmes PBE utilisant des cryptages AES 256 bits, de sorte que la clé dérivée puisse être différente et ne corresponde pas aux clés précédemment dérivées du même mot de passe. JDK-8138589 (non public).
Correction de bug : limite par défaut ajoutée pour la taille maximale d'entité XML
Une limite par défaut pour la taille maximale d'entité a été ajoutée. Pour plus d'informations sur les limites de traitement XML, reportez-vous aux tutoriels Java relatifs aux limites de traitement. JDK-8133962 (non public)
Correction de bug : problème avec la documentation sur le commutateur Enterprise MSI 'REMOVEOLDERJRES' corrigé
La documentation Enterprise MSI répertorie les options de configuration. L'option REMOVEOLDERJRES permettant de désinstaller les anciens environnements JRE était manquante. Ajout de cette option, avec la description :
Si l'option est définie sur 1, les versions plus anciennes de l'environnement JRE installé sur le système sont enlevées.
La valeur par défaut 0 n'enlève pas les anciens environnements JRE
JDK-8081237 (non public)

Date d'expiration de Java

La date d'expiration pour 8u71 est le 19 avril 2016. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u71) le 19 mai 2016. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), Java fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

Cette version comprend des correctifs concernant les vulnérabilités de sécurité. Pour plus d'informations, reportez-vous aux conseils sur la mise à jour des patches critiques Oracle Java SE.

Pour consulter la liste des corrections de bug incluses dans cette version, reportez-vous à la page Corrections de bug de JDK 8u71.

» Notes sur la version 8u71

Java 8 Update 66 (8u66)

Principales nouveautés de cette version

La version 8u66 build 18 résout un problème sur Firefox.

Correction de bug : _releaseObject appelé à partir du mauvais thread
Une modification récente apportée à Firefox entraînait l'appel de _releaseObject à partir d'un thread autre que le thread principal. Cela peut causer un accès concurrent, pouvant lui-même causer une défaillance du navigateur. Ce problème est résolu dans le build 18 de la version 8u66. Pour plus d'informations, reportez-vous à Bugs@Mozilla 1221448. Reportez-vous à JDK-8133523.

Le plug-in Java ne fonctionne pas dans Firefox après l'installation de Java

Firefox 42 peut connaître une défaillance en cas de tentative d'exécution du plug-in Java. Les options de solution de contournement sont répertoriées dans la FAQ. Reportez-vous à JDK-8142908 (non public).

Date d'expiration de Java

La date d'expiration de la version 8u66 est le 19 janvier 2016. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u66) le 19 février 2016. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), Java fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

Cette version comprend des correctifs concernant les vulnérabilités de sécurité. Pour plus d'informations, reportez-vous aux conseils sur la mise à jour des patches critiques Oracle Java SE.

Pour consulter la liste des corrections de bug incluses dans cette version, reportez-vous à la page Corrections de bug de JDK 8u66.

» Notes sur la version 8u66

Java 8 Update 65 (8u65)

Principales nouveautés de cette version

Données IANA 2015f
JDK 8u65 contient des données de fuseau horaire IANA version 2015f. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Prise en charge du tableau "Codes des types de fonds" (A.2) de la norme ISO 4217
Cette amélioration ajoute la prise en charge des codes de fonds du tableau A.2 de la norme ISO 4217. Auparavant, le JDK prenait uniquement en charge les devises répertoriées dans le tableau A.1. Reportez-vous à JDK-8074350.
Correction de bug : [mac osx] échec de la mise à jour du client JRE AU installé vers NEXTVER sur Mac 10.11
Un nouveau programme d'installation est introduit dans la version 8u65 pour mettre à jour les utilisateurs OS X vers la dernière version. Le programme d'installation s'appliquera aux mises à jour planifiées et manuelles, et des packages seront mis à disposition sur java.com et OTN. Les utilisateurs qui rencontrent des problèmes de compatibilité avec le nouveau programme d'installation peuvent télécharger et installer manuellement le programme d'installation ".pkg" disponible sur My Oracle Support.
Correction de bug : HotSpot doit utiliser l'interface PICL pour obtenir la taille de ligne de cache sur SPARC
La bibliothèque libpicl est désormais requise sur Solaris/SPARC pour déterminer la taille des lignes de cache. Si la bibliothèque n'est pas présente ou si le service PICL n'est pas disponible, la JVM affichera un avertissement et les optimisations de compilateur qui utilisent l'instruction BIS (Block Initializing Store, stockage d'initialisation de bloc) seront désactivées. Reportez-vous à JDK-8056124.
Correction de bug : dns_lookup_realm doit être défini sur False par défaut
Le paramètre dns_lookup_realm dans le fichier krb5.conf de Kerberos est défini sur False par défaut. Reportez-vous à JDK-8080637.
Correction de bug : le préchargement de libjsig.dylib provoque un interblocage quand signal() est appelé
Les applications doivent précharger la bibliothèque libjsig pour activer le chaînage de signal. Auparavant, sur OS X, une fois libjsig.dylib préchargé, tout appel du code natif à signal() provoquait un interblocage. Ce bug a été corrigé. Reportez-vous à JDK-8072147.
Correction de bug : meilleure dynamique de groupe
Dans l'implémentation OpenJDK SSL/TLS/DTLS (fournisseur SunJSSE), les principaux groupes Diffie-Hellman sécurisés sont utilisés par défaut. Les utilisateurs peuvent personnaliser les groupes Diffie-Hellman via la propriété de sécurité jdk.tls.server.defaultDHEParameters.
Correction de bug : défaillance de la machine virtuelle lors de la redéfinition de la classe avec Instrumentation.redefineClasses
La machine virtuelle Java pouvait connaître une défaillance lorsqu'une classe était redéfinie avec Instrumentation.redefineClasses(). La défaillance pouvait être due à une erreur de segmentation dans SystemDictionary::resolve_or_null ou à une erreur interne accompagnée d'un message indiquant une non-concordance des balises avec la table des erreurs de résolution. Ce bug a été corrigé. Reportez-vous à JDK-8076110.

Remarques

En cas d'exécution sur OSX 10.11 El Capitan, quand SIP est activé, certaines variables d'environnement destinées au débogage des applications, comme DYLD_LIBRARY_PATH peuvent être supprimées de l'environnement lors de l'exécution de Java à partir de la ligne de commande ou lors d'un double-clic sur un fichier JAR. Dans les environnements de production, les applications ne doivent pas reposer sur ces variables. Ces dernières sont uniquement destinées au débogage en cours de développement.

MD5 ne doit pas être utilisé pour les signatures numériques si la résistance aux collisions est requise. Afin d'empêcher l'utilisation de MD5 en tant qu'algorithme de signature numérique pendant les opérations de certificat X.509, MD5 est ajouté à la propriété de sécurité jdk.certpath.disabledAlgorithms. Pour les applications qui utilisent toujours le certificat signé MD5, mettez le certificat faible à niveau dès que possible.

Problèmes connus

[mac osx] Problèmes d'accessibilité (a11y) des écrans d'offre parrainée
Les utilisateurs qui utilisent le clavier pour accéder à des interfaces utilisateur dans le programme d'installation Java ne pourront pas accéder aux liens hypertexte et aux cases à cocher des écrans d'offre de logiciel d'extension. Pour contourner le problème de la définition des préférences liées au logiciel d'extension dans l'interface utilisateur, les utilisateurs peuvent désactiver les offres concernées en accédant au panneau de configuration Java ou en transmettant SPONSORS=0 via la ligne de commande. Pour plus d'informations, reportez-vous à la FAQ sur l'installation de Java sans offre parrainée. Reportez-vous à JDK-8061886 (non public).

Date d'expiration de Java

La date d'expiration de la version 8u65 est le 19 janvier 2016. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u65) le 19 février 2016. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), Java fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

Cette version comprend des correctifs concernant les vulnérabilités de sécurité. Pour plus d'informations, reportez-vous aux conseils sur la mise à jour des patches critiques Oracle Java SE.

Pour consulter la liste des corrections de bug incluses dans cette version, reportez-vous à la page Corrections de bug de JDK 8u65.

» Notes sur la version 8u65

Java 8 Update 60 (8u60)

Principales nouveautés de cette version

Données IANA 2015e
JDK 8u60 contient des données de fuseau horaire IANA version 2015e. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Correction de bug : dns_lookup_realm doit être défini sur False par défaut
Le paramètre dns_lookup_realm dans le fichier krb5.conf de Kerberos est défini sur false par défaut. Reportez-vous à 8080637.
Correction de bug : désactivation des mécanismes de cryptage RC4
Les mécanismes de cryptage TLS reposant sur RC4 (par exemple, TLS_RSA_WITH_RC4_128_SHA) sont désormais considérés comme non appropriés et ne doivent plus être utilisés (voir RFC 7465). Par conséquent, les mécanismes de cryptage TLS reposant sur RC4 ont été désactivés par défaut dans l'implémentation Oracle JSSE en ajoutant "RC4" à la propriété de sécurité "jdk.tls.disabledAlgorithms" et en les enlevant de la liste des mécanismes de cryptage activés par défaut. Ces mécanismes de cryptage peuvent être réactivés en enlevant "RC4" de la propriété de sécurité "jdk.tls.disabledAlgorithms" dans le fichier java.security ou en appelant dynamiquement Security.setProperty() et en les rajoutant à la liste des mécanismes de cryptage activés à l'aide des méthodes SSLSocket/SSLEngine.setEnabledCipherSuites(). Vous pouvez également utiliser l'option de ligne de commande -Djava.security.properties pour remplacer la propriété de sécurité jdk.tls.disabledAlgorithms. Par exemple :
java -Djava.security.properties=my.java.security ...
où my.java.security est un fichier contenant la propriété sans RC4 :
jdk.tls.disabledAlgorithms=SSLv3
Même si cette option est définie dans la ligne de commande, les mécanismes de cryptage reposant sur RC4 doivent être rajoutés à la liste des mécanismes de cryptage activés à l'aide des méthodes SSLSocket/SSLEngine.setEnabledCipherSuites(). Reportez-vous à 8076221.
Correction de bug : prise en charge de la détection du type de fichier de clés pour les fichiers de clés JKS et PKCS12
Mode de compatibilité entre les fichiers de clés : pour améliorer l'interopérabilité, le type de fichier de clés Java JKS prend désormais en charge le mode de compatibilité entre les fichiers de clés par défaut. Ce mode permet aux fichiers de clés JKS d'accéder à des fichiers au format JKS et PKCS12. Pour désactiver le mode de compatibilité entre les fichiers de clés, définissez la propriété de sécurité keystore.type.compat sur la valeur de chaîne false. Reportez-vous à 8062552.
Correction de bug : abandon des méthodes de surveillance non sécurisées dans la version JDK 8u
Les méthodes monitorEnter, monitorExit et tryMonitorEnter sur sun.misc.Unsafe sont marquées comme étant en phase d'abandon dans JDK 8u60 et seront enlevées dans une prochaine version. Ces méthodes ne sont pas utilisées au sein du JDK lui-même et le sont très rarement en dehors de ce dernier. Reportez-vous à 8069302.
Correction de bug : extraction de l'enregistrement JFR à partir du dump noyau à l'aide de l'agent de maintenance
DumpJFR est un outil reposant sur un agent de maintenance qui peut être utilisé pour extraire des données Java Flight Recorder (JFR) à partir des dumps noyau et des processus HotSpot actifs. DumpJFR peut être utilisé dans l'une des méthodes suivantes :
- Attacher DumpJFR à un processus actif :
  
  The embedded asset does not exist:
  Asset Type: jWidget_C
  Asset Id: 1371164883097
  PAGENAME: JCOM/jWidget_C/Raw_HTML/Display
- Attacher DumpJFR à un dump noyau :
  
  The embedded asset does not exist:
  Asset Type: jWidget_C
  Asset Id: 1371164883117
  PAGENAME: JCOM/jWidget_C/Raw_HTML/Display
L'outil DumpJFR archive les données JFR dans un fichier nommé recording.jfr dans le dossier de travail en cours. Reportez-vous à 8065301 (non public).
Correction de bug : les variables locales nommées 'enum' entraînent des pannes de compilateur incorrectes
L'analyseur javac n'analyse pas correctement les variables locales nommées 'enum'. Cela entraîne des échecs incorrects lorsqu'un programme contenant ces variables locales est compilé avec l'indicateur 'source' correspondant à une version dans laquelle la construction enum n'est pas disponible (par exemple, '-source 1.4'). Reportez-vous à 8069181.

Java Development Kit pour ARM version 8u60

Cette version inclut Java Development Kit pour ARM version 8u60 (JDK 8u60 pour ARM). Pour plus d'informations sur la prise en charge des périphériques ARM, reportez-vous à la page Téléchargements JDK pour ARM. Pour obtenir les exigences système, des instructions d'installation et des conseils de dépannage, reportez-vous à la page Instructions d'installation.

Limite : la prise en charge du suivi de la mémoire native est limitée dans JDK pour ARM. L'option de ligne de commande Java XX:NativeMemoryTracking=detail n'est pas prise en charge pour les cibles ARM (l'utilisateur voit un message d'erreur). Vous devez utiliser l'option suivante à la place :
XX:NativeMemoryTracking=summary

Mises à jour de la documentation suite aux améliorations apportées à Nashorn

JDK 8u60 inclut les nouvelles améliorations apportées à Nashorn. Par conséquent, les modifications suivantes doivent être consultées en parallèle à la documentation actuelle sur Nashorn :

Ajout : dans la section précédente, nous avons mentionné que chaque objet JavaScript, lorsqu'il est affiché dans une API Java, implémente l'interface java.util.Map. Cela vaut également pour les tableaux JavaScript. Cependant, ce comportement n'est souvent pas souhaité ou attendu lorsque le code Java attend des objets analysés par JSON. Les bibliothèques Java qui manipulent des objets analysés par JSON s'attendent généralement à ce que les tableaux affichent l'interface java.util.List. Si vous devez afficher vos objets JavaScript de sorte que les tableaux soient présentés sous forme de listes et non de correspondances, vous pouvez utiliser la fonction Java.asJSONCompatible(obj), où obj correspond à la racine de votre arborescence d'objets JSON.
Correction : la mise en garde mentionnée à la fin de la section relative aux types de données de mapping ne s'applique plus. Nashorn s'assure que les chaînes JavaScript internes sont converties en java.lang.String lorsqu'elles sont affichées en externe.
Correction : l'instruction dans la section relative aux types de données de mapping indiquant "Par exemple, les tableaux doivent être convertis de manière explicite..." n'est pas correcte. Les tableaux sont automatiquement convertis en tableaux Java, tels que java.util.List, java.util.Collection, java.util.Queue, java.util.Deque, etc.

Modifications apportées à la fonctionnalité Jeu de règles de déploiement v1.2

JDK 8u60 implémente le jeu de règles de déploiement (DRS) 1.2, qui comprend les modifications suivantes :

Ajout de l'élément "checksum" en tant que sous-élément de "id" qui permet l'identification de fichiers JAR non signés par le total de contrôle SHA-256 de la forme non compressée d'un fichier JAR :
- L'élément "checksum" sera mis en correspondance uniquement avec les fichiers JAR non signés, et la valeur de hachage donnée sera uniquement comparée à la forme non compressée du fichier JAR.
- L'élément "checksum" (semblable à l'élément "certificate") est composé de deux arguments "hash" et "algorithm". Cependant, contrairement à l'élément "certificate", l'unique valeur prise en charge pour "algorithm" est "SHA-256". Toute autre valeur fournie sera ignorée.
Autorisation de l'application de l'élément "message" à tous les types de règle, alors qu'il n'était auparavant appliqué qu'aux règles de blocage :
- Dans une règle d'exécution, le sous-élément d'un message entraînera l'affichage d'une boîte de dialogue de message alors que sans règle d'exécution, le comportement par défaut consisterait à afficher une boîte de dialogue non signée ou un certificat. Le message sera affiché dans la boîte de dialogue de message.
- Dans le cas d'une règle par défaut, le message sera affiché uniquement si l'action par défaut est un blocage. Dans ce cas, le message sera inclus dans la boîte de dialogue de blocage.
Répétition des blocs "customer" dans la console Java, les fichiers trace et les enregistrements Java Usage Tracker.
- Dans les versions antérieures à DRS 1.2, les éléments "customer" pouvaient être inclus (avec n'importe quel sous-élément) dans le fichier ruleset.xml. Cet élément et tous ses sous-éléments sont ignorés. Dans la version de DRS 1.2, les éléments sont toujours ignorés sur le plan fonctionnel. Toutefois :
  - Lors de l'analyse du fichier ruleset.xml, tous les blocs "customer" seront répétés dans la console Java et le fichier trace de déploiement (si les fonctions de console et de trace sont activées).
  - Lors de l'utilisation d'une règle, tous les enregistrements "customer" inclus dans cette règle seront ajoutés à l'enregistrement JUT (Java Usage Tracker) (si JUT est activé).

En raison des modifications ci-dessus, la définition de type de document de DRS 1.2 se présente comme suit :
The embedded asset does not exist:
Asset Type: jWidget_C
Asset Id: 1385352043373
PAGENAME: JCOM/jWidget_C/Raw_HTML/Display

Date d'expiration de Java

La date d'expiration de la version 8u60 est le 20 octobre 2015. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u60) le 20 novembre 2015. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), Java fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

Pour consulter la liste des corrections de bug incluses dans cette version, reportez-vous à la page Corrections de bug de JDK 8u60.

» Notes sur la version 8u60

Java 8 Update 51 (8u51)

Principales nouveautés de cette version

Données IANA 2015d
JDK 8u51 contient des données de fuseau horaire IANA version 2015d. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Correction de bug : ajout de nouveaux certificats racine Comodo aux autorités de certification racine
Quatre nouveaux certificats racine ont été ajoutés pour Comodo :
1. COMODO ECC Certification Authority alias : comodoeccca DN: CN=COMODO ECC Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
2. COMODO RSA Certification Authority alias : comodorsaca DN : CN=COMODO RSA Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
3. USERTrust ECC Certification Authority alias : usertrusteccca DN : CN=USERTrust ECC Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
4. USERTrust RSA Certification Authority alias : usertrustrsaca DN : CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
Reportez-vous à JDK-8077997 (non public).
Correction de bug : ajout de nouveaux certificats racine GlobalSign aux autorités de certification racine
Deux nouveaux certificats racine ont été ajoutés pour GlobalSign :
1. GlobalSign ECC Root CA - R4 alias : globalsigneccrootcar4 DN : CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4
2. GlobalSign ECC Root CA - R5 alias : globalsigneccrootcar5 DN : CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R5
Reportez-vous à JDK-8077995 (non public).
Correction de bug : ajout d'Actalis aux autorités de certification racine
Ajout d'un nouveau certificat racine :
Actalis Authentication Root CA alias : actalisauthenticationrootca DN : CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT
Reportez-vous à JDK-8077903 (non public).
Correction de bug : ajout d'un nouveau certificat racine ECC Entrust
Ajout d'un nouveau certificat racine :
Entrust Root Certification Authority - EC1 alias : entrustrootcaec1 DN : CN=Entrust Root Certification Authority - EC1, OU="(c) 2012 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US
Reportez-vous à JDK-8073286 (non public).
Correction de bug : suppression d'anciens certificats racine ValiCert Class 1 and 2 Policy
Suppression de deux certificats racine avec des clés 1 024 bits :
1. ValiCert Class 1 Policy Validation Authority alias : secomvalicertclass1ca DN : EMAILADDRESS=info@valicert.com, CN=http://www.valicert.com/, OU=ValiCert Class 1 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
2. ValiCert Class 2 Policy Validation Authority alias : valicertclass2ca DN : EMAILADDRESS=info@valicert.com, CN=http://www.valicert.com/, OU=ValiCert Class 2 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
Reportez-vous à JDK-8077886 (non public).
Correction de bug : suppression d'anciens certificats racine Thawte
Suppression de deux certificats racine avec des clés 1 024 bits :
1. Thawte Server CA alias : thawteserverca DN : EMAILADDRESS=server-certs@thawte.com, CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
2. Thawte Personal Freemail CA alias : thawtepersonalfreemailca DN : EMAILADDRESS=personal-freemail@thawte.com, CN=Thawte Personal Freemail CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA
Reportez-vous à JDK-8074423 (non public).
Correction de bug : suppression de certificats racine Verisign, Equifax et Thawte plus anciens
Suppression de cinq certificats racine avec des clés 1 024 bits :
1. Verisign Class 3 Public Primary Certification Authority - G2 alias : verisignclass3g2ca DN : OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
2. Thawte Premium Server CA alias : thawtepremiumserverca DN : EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
3. Equifax Secure Certificate Authority alias : equifaxsecureca DN : OU=Equifax Secure Certificate Authority, O=Equifax, C=US
4. Equifax Secure eBusiness CA-1 alias : equifaxsecureebusinessca1 DN : CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US
5. Equifax Secure Global eBusiness CA-1, alias : equifaxsecureglobalebusinessca1 DN : CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
Reportez-vous à JDK-8076202 (non public).
Correction de bug : suppression de certificats d'autorité de certification racine TrustCenter de cacerts
Suppression de trois certificats racine :
1. TC TrustCenter Universal CA I alias : trustcenteruniversalcai DN : CN=TC TrustCenter Universal CA I, OU=TC TrustCenter Universal CA, O=TC TrustCenter GmbH, C=DE
2. TC TrustCenter Class 2 CA II alias : trustcenterclass2caii DN : CN=TC TrustCenter Class 2 CA II, OU=TC TrustCenter Class 2 CA, O=TC TrustCenter GmbH, C=DE
3. TC TrustCenter Class 4 CA II alias : trustcenterclass4caii DN : CN=TC TrustCenter Class 4 CA II, OU=TC TrustCenter Class 4 CA, O=TC TrustCenter GmbH, C=DE
Reportez-vous à JDK-8072958 (non public).
Correction de bug : abandon de RC4 dans le fournisseur SunJSSE
RC4 est désormais considéré comme un cryptage faible. Les serveurs ne doivent pas sélectionner RC4, sauf si celui-ci est l'algorithme le plus élevé dans les mécanismes de cryptage demandés par le client. Une nouvelle propriété de sécurité, jdk.tls.legacyAlgorithms, est ajoutée pour définir les algorithmes hérités dans l'implémentation Oracle JSSE. Les algorithmes associés à RC4 sont ajoutés à la liste des algorithmes hérités. Reportez-vous à JDK-8074006 (non public).
Correction de bug : interdiction des mécanismes de cryptage RC4
RC4 est désormais considéré comme un mécanisme de cryptage dangereux. Les mécanismes de cryptage RC4 ont été supprimés de la liste des mécanismes de cryptage activée par défaut du serveur et du client dans l'implémentation Oracle JSSE. Ces mécanismes de cryptage peuvent tout de même être activés à l'aide des méthodes SSLEngine.setEnabledCipherSuites() et SSLSocket.setEnabledCipherSuites(). Reportez-vous à JDK-8077109 (non public).
Correction de bug : amélioration de la vérification de la certification
Avec cette correction, l'identification d'adresse JSSE n'effectue pas de recherche de nom inverse pour les adresses IP par défaut dans JDK. Si une application doit effectuer une recherche de nom inverse pour des adresses IP brutes dans des connexions SSL/TLS, et qu'elle rencontre un problème de compatibilité d'identification d'adresse, la propriété système "jdk.tls.trustNameService" peut être utilisée pour activer la recherche de nom inverse. Si le service de nom n'est pas fiable, l'activation de la recherche de nom inverse peut comporter des risques d'attaques MITM. Reportez-vous à JDK-8067695 (non public).

Date d'expiration de Java

La date d'expiration de la version 8u51 est le 20 octobre 2015. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u51) le 20 novembre 2015. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), Java fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

Cette version comprend des correctifs concernant les vulnérabilités de sécurité. Pour plus d'informations, reportez-vous aux conseils sur la mise à jour des patches critiques Oracle Java SE.

Pour consulter la liste des corrections de bug incluses dans cette version, reportez-vous à la page Corrections de bug de JDK 8u51.

» Notes sur la version 8u51

Java 8 Update 45 (8u45)

Principales nouveautés de cette version

Données IANA 2015a
JDK 8u45 contient des données de fuseau horaire IANA version 2015a. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Correction de bug : améliorer le traitement des fichiers JAR. A compter de JDK version 8u45, l'outil jar ne permet plus l'utilisation du composant de chemin ".."(point-point) et de la barre oblique initiale "/" dans le nom de fichier d'entrée ZIP lors de la création d'un fichier et/ou de l'extraction à partir de fichier zip et jar. Si nécessaire, la nouvelle option de ligne de commande "-P" doit être utilisée explicitement pour conserver le composant de chemin absolu et/ou point-point. Reportez-vous à 8064601 (non public).
Correction de bug : l'application jnlp avec la section "ressource" imbriquée échoue avec une exception de pointeur NULL lors du chargement dans jre8u40. Une application jnlp, avec des balises imbriquées dans une balise <java> ou , peut générer une exception de pointeur NULL. Le problème est maintenant résolu. La balise doit être utilisée uniquement si la balise <java> est réellement utilisée. Reportez-vous à 8072631 (non public).

Date d'expiration de Java

La version 8u40 expire le 14 juillet 2015. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u45) le 14 août 2015. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), Java fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

Cette version comprend des correctifs concernant les vulnérabilités de sécurité. Pour plus d'informations, reportez-vous aux conseils sur la mise à jour des patches critiques Oracle Java SE.

Pour consulter la liste des corrections de bug incluses dans cette version, reportez-vous à la page Corrections de bug de JDK 8u45.

» Notes sur la version 8u45

Java 8 Update 40 (8u40)

Principales nouveautés de cette version

Données IANA 2014j
JDK 8u40 contient des données de fuseau horaire IANA version 2014j. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Correction de bug : méthodes d'interface par défaut et statique dans JDI, JDWP et JDB. Depuis le JDK 8, il est possible d'exécuter directement les méthodes par défaut et statique dans les interfaces. Ces méthodes ne sont pas exécutables via JDI ou JDWP, et ne peuvent donc pas être déboguées correctement. Pour plus d'informations, reportez-vous au manuel JDK 8 Compatibility Guide. Reportez-vous à 8042123.
Correction de bug : vous pouvez activer Java Access Bridge à partir du panneau de configuration pour les environnements JRE 32 bits. Auparavant, la case Activer Java Access Bridge a été enlevée du panneau de configuration Java en cas de désinstallation de l'environnement JRE 64 bits, même lorsque l'environnement JRE 32 bits était toujours présent sur le système. A compter de la version du JDK 8u40, la case Activer Java Access Bridge est conservée (Panneau de configuration -> Accessibilité -> Centre d'accessibilité -> Utiliser l'ordinateur sans affichage) si un environnement JRE 32 bits est présent. Un utilisateur peut donc activer Java Access Bridge via le panneau de configuration. Reportez-vous à 8030124.
Correction de bug : modernisation de la pile de supports JavaFX sur Mac OS X. Une plate-forme de lecteur basée sur AVFoundation est ajoutée aux supports JavaFX. Vous pouvez désormais enlever l'ancienne plate-forme basée sur QTKit pour la compatibilité avec le Mac App Store. Reportez-vous à 8043697 (non public).
Correction de bug : API DOM manquantes. Dans le JDK 8u40, les anciennes API DOM de plug-in ont été accidentellement enlevées. Si l'applet requiert l'utilisation de com.sun.java.browser.dom.DOMService pour communiquer avec le navigateur, les utilisateurs devront peut-être mettre à jour l'applet afin d'employer netscape.javascript.JSObject ou continuer avec le JDK 8 Update 31. Ce problème a été résolu dans le build 26 et de nouveaux programmes d'installation 8u40 ont été publiés. Si vous rencontrez ce problème, téléchargez et exécutez les programmes d'installation du JDK 8u40 mis à jour. Reportez-vous à 8074564.
Correction de bug : Mac 10.10 - Problèmes de focus dans une application exécutée avec l'écran de démarrage Le focus sur le clavier est impossible dans les applications démarrées via des applications autonomes ou WebStart, qui utilisent l'écran de démarrage. Solution de contournement : lancez javaws avec l'option -Xnosplash. Ce problème a été résolu dans le build 27 et un nouveau programme d'installation 8u40 a été publié. Si vous rencontrez ce problème, téléchargez et exécutez le programme d'installation du JDK 8u40 mis à jour. Reportez-vous à 8074668.
Améliorations de l'outil Java Packager
La version JDK 8u40 comprend les améliorations suivantes apportées à Java Packager :
- Les arguments de ligne de commande peuvent être transmis aux applications autonomes. Les arguments par défaut sont définis lors de la création du package et peuvent être remplacés par l'utilisateur lors du démarrage de l'application.
- Les associations de fichier peuvent être configurées lorsqu'une application autonome est installée de sorte que le système d'exploitation exécute automatiquement l'application pour les extensions de fichier inscrites ou les types MIME.
- L'API UserJvmOptionsService est disponible pour modifier les options de JVM dans les applications autonomes. Les nouveaux paramètres sont utilisés au prochain démarrage de l'application.
- Plusieurs points d'entrée sont pris en charge pour les applications autonomes, ce qui permet le regroupement d'une suite de produits dans le même package d'application.
API en phase d'abandon
Le mécanisme de remplacement des normes approuvées et le mécanisme d'extension sont en phase d'abandon et susceptibles d'être enlevés dans une version à venir. Aucune modification d'exécution n'est apportée. Les applications existantes utilisant les mécanismes de remplacement des normes approuvées ou d'extension sont recommandées pour une migration vers l'exclusion de ces mécanismes. Pour identifier les utilisations existantes de ces mécanismes, l'option de ligne de commande -XX:+CheckEndorsedAndExtDirs est disponible. Celle-ci échoue en présence de l'une des conditions suivantes :
- La propriété système -Djava.endorsed.dirs ou -Djava.ext.dirs est définie pour modifier l'emplacement par défaut.
- Le répertoire ${java.home}/lib/endorsed existe.
- ${java.home}/lib/ext contient des fichiers JAR qui excluent ceux du JDK.
- Un répertoire d'extension à l'échelle du système propre à la plate-forme contient des fichiers JAR.
L'option de ligne de commande -XX:+CheckEndorsedAndExtDirs est prise en charge dans le JDK 8u40 et versions ultérieures.
Différences de page pour l'outil JJS
La version japonaise de la page d'aide JJS est différente de la version anglaise. Certaines des options non prises en charge ont été enlevées de la version anglaise de la page de l'outil JJS. La version japonaise du document sera mise à jour à l'avenir. Reportez-vous à 8062100 (non public). Pour découvrir les autres modifications de page pour l'outil JJS, reportez-vous à Améliorations des outils dans le JDK 8.
Modification des valeurs par défaut pour G1HeapWastePercent et G1MixedGCLiveThresholdPercent
La valeur par défaut pour G1HeapWastePercent est passée de 10 à 5 pour réduire les besoins de nettoyage de mémoire complet. Pour la même raison, la valeur par défaut pour G1MixedGCLiveThresholdPercent est passée de 65 à 85.
Nouvelle interface de filtrage des accès aux classes Java
L'interface jdk.nashorn.api.scripting.ClassFilter permet de restreindre l'accès aux classes Java spécifiées à partir des scripts exécutés par un moteur de scripts Nashorn. Pour plus d'informations, reportez-vous à la section relative à la restriction de l'accès des scripts aux classes Java spécifiées dans le Guide de l'utilisateur Nashorn et 8043717 (non public).
Problèmes avec les fournisseurs JCE tiers
Le correctif pour JDK-8023069 (dans JDK 8u20) a mis à jour les fournisseurs SunJSSE et SunJCE, y compris certaines interfaces internes. Certains fournisseurs JCE tiers (tels que RSA JSAFE) utilisent des interfaces internes sun.* et ne fonctionneront donc pas avec le fournisseur SunJSSE mis à jour. Ces fournisseurs doivent être mis à jour pour fonctionner avec le fournisseur SunJSSE mis à jour. Si ce problème vous concerne, contactez votre fournisseur JCE pour obtenir la mise à jour. Reportez-vous à 8058731.
Cryptages réactivés dans la structure cryptographique Solaris
Si vous utilisez Solaris 10, une modification a été apportée pour réactiver les opérations avec MD5, SHA1 et SHA2 via la structure cryptographique Solaris. Si vous obtenez une erreur CloneNotSupportedException ou PKCS11 (message CKR_SAVED_STATE_INVALID) avec le JDK 8u40, vérifiez et appliquez les patches ci-dessous ou une version plus récente :
- 150531-02 sur Sparc
- 150636-01 sur x86
Mises à jour du guide de dépannage pour NMT
Le suivi de mémoire native (NMT) est une fonctionnalité de machine virtuelle Java Hotspot qui suit l'utilisation de la mémoire interne pour une JVM HotSpot. Le suivi de mémoire native peut être utilisé pour surveiller les allocations de mémoire interne de machine virtuelle et diagnostiquer les pertes de ressources mémoire. La page relative aux améliorations de machine virtuelle est mise à jour avec les fonctionnalités NMT. Reportez-vous à Améliorations de JVM dans Java SE 8. Le guide de dépannage est mis à jour avec les fonctionnalités NMT. Reportez-vous à Suivi de mémoire native.
Fonctionnalité de lanceur d'environnement JRE multiple en phase d'abandon
La fonctionnalité de sélection de version de l'environnement JRE au lancement ou lanceur d'environnement JRE multiple est en phase d'abandon dans JDK 8u40. Les applications qui requièrent le déploiement de versions de Java spécifiques avec cette fonctionnalité doivent basculer sur des solutions de déploiement alternatives, telles que Java WebStart.
Améliorations de JavaFX
A compter de la version JDK 8u40, les contrôles JavaFX sont améliorés pour prendre en charge les technologies d'assistance, ce qui signifie qu'ils sont désormais accessibles. De plus, une API publique est fournie pour permettre aux développeurs d'écrire leurs propres contrôles accessibles. La prise en charge de l'accessibilité est assurée sur les plates-formes Windows et Mac OS X, et inclut les fonctions suivantes :
- Prise en charge de la lecture des contrôles JavaFX par un lecteur d'écran
- Contrôles JavaFX traversables à l'aide du clavier
- Prise en charge d'un mode de contraste élevé spécial qui rend les contrôles plus visibles pour les utilisateurs
Reportez-vous à 8043344 (non public).

La version JDK 8u40 inclut les nouveaux contrôles d'interface utilisateur JavaFX, un contrôle de boîte d'incrément, la prise en charge du texte formaté et un ensemble standard de boîtes de dialogue d'alerte.
- Contrôle de boîte d'incrément : une boîte d'incrément est un champ de texte d'une ligne permettant à l'utilisateur de sélectionner un nombre ou une valeur d'objet à partir d'une séquence ordonnée. Pour plus d'informations, reportez-vous à la classe javafx.scene.control.Spinner.
- Texte formaté : la nouvelle classe TextFormatter fournit une fonction de formatage du texte pour les sous-classes de TextInputControl (par exemple, TextField et TextArea). Pour plus d'informations, reportez-vous à la classe javafx.scene.control.TextFormatter.
- Boîtes de dialogue : la classe Dialog permet aux applications de créer leurs propres boîtes de dialogue personnalisées. De plus, la classe Alert est également fournie. Elle étend la classe Dialog et prend en charge de nombreux types de boîte de dialogue prédéfinis pouvant facilement être affichés aux utilisateurs pour les inviter à donner une réponse. Pour plus d'informations, reportez-vous aux classes javafx.scene.control.Dialog, javafx.scene.control.Alert, javafx.scene.control.TextInputDialog et javafx.scene.control.ChoiceDialog.
Reportez-vous à 8043350 (non public).

Fonctionnalités commerciales

Partage de données de classe d'application (AppCDS)
Le partage de données de classe d'application (AppCDS) étend CDS pour vous permettre de placer des classes à partir des répertoires d'extensions standard et du chemin de classe d'application dans l'archive partagée. Il s'agit d'une fonctionnalité expérimentale et n'ayant reçu aucune licence d'utilisation commerciale. Reportez-vous à l'option -XX:+UseAppCDS sur la page de l'outil de lanceur Java.
Gestion de mémoire coopérative
A compter de JDK 8u40, la notion de "pression de mémoire" a été ajoutée. La pression de mémoire est une propriété qui représente l'utilisation totale de la mémoire (RAM) sur le système. Plus la pression de mémoire est élevée, plus le système est proche du manque de mémoire. Il s'agit d'une fonctionnalité expérimentale et n'ayant reçu aucune licence d'utilisation commerciale. En réaction à l'augmentation de la pression de mémoire, le JDK va tenter de réduire son utilisation de mémoire. Il y parvient principalement en réduisant la taille de portion de mémoire Java. Les actions effectuées par le JDK pour réduire l'utilisation de mémoire peuvent entraîner une diminution des performances. Il s'agit d'un choix intentionnel. Le niveau de pression est fourni par l'application via un MXBean JMX selon une échelle allant de 0 (aucune pression) à 10 (mémoire insuffisante). Pour activer cette fonctionnalité, vous devez inscrire jdk.management.cmm.SystemResourcePressureMXBean. La pression de mémoire est alors définie à l'aide de l'attribut "MemoryPressure".
Le nouvel indicateur de ligne de commande -XX:MemoryRestriction acceptant l'un des arguments 'none', 'low', 'medium' ou 'high' est également disponible. Cet indicateur définit la pression initiale du JDK et fonctionne également dans les cas où le MXBean n'est pas inscrit. La gestion de mémoire coopérative requiert le nettoyage de mémoire G1 (-XX:+UseG1GC). Cette fonctionnalité n'est pas compatible avec l'indicateur -XX:+ExplicitGCInvokesConcurrent.
Nouveaux indicateurs commerciaux
Deux nouvelles options de machine virtuelle sont désormais disponibles pour les détenteurs de licence commerciale :
- -XX:+ResourceManagement
- -XX:ResourceManagementSampleInterval=value (millisecondes)
Pour plus d'informations, reportez-vous à la documentation du lanceur Java.
Nouvelle documentation du programme d'installation MSI :
Le manuel relatif au programme d'installation de l'environnement JRE Microsoft Windows Installer (MSI) Enterprise est disponible. Le programme d'installation de l'environnement JRE MSI Enterprise requiert une licence commerciale pour être utilisé en production. Découvrez les fonctionnalités commerciales et apprenez à les activer.

Date d'expiration de Java

La date d'expiration pour 8u40 est le 14 avril 2015. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u40) le 14 mai 2015. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), Java fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

Pour consulter la liste des corrections de bug incluses dans cette version, reportez-vous à la page Corrections de bug de JDK 8u40.

» Notes sur la version 8u40

Java 8 Update 31 (8u31)

Principales nouveautés de cette version

Données IANA 2014j
JDK 8u31 contient des données de fuseau horaire IANA version 2014j. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Le protocole SSLv3 est désactivé par défaut
A compter de la version JDK 8u31, le protocole SSLv3 (Secure Socket Layer) a été désactivé et n'est en principe pas disponible. Reportez-vous à la propriété jdk.tls.disabledAlgorithms dans le fichier \lib\security\java.security. Si le protocole SSLv3 est absolument nécessaire, vous pouvez le réactiver en enlevant 'SSLv3' de la propriété jdk.tls.disabledAlgorithms dans le fichier java.security ou en définissant cette propriété de sécurité de façon dynamique avant l'initialisation de JSSE.
Modifications apportées au panneau de configuration Java
A compter de la version JDK 8u31, le protocole SSLv3 a été enlevé des options avancées du panneau de configuration Java. Si vous devez utiliser le protocole SSLv3 pour certaines applications, réactivez-le manuellement en procédant comme suit :
- Pour activer le protocole SSLv3 au niveau de l'environnement JRE, suivez les opérations décrites dans la section précédente.
- Pour activer le protocole SSLv3 au niveau du déploiement, modifiez le fichier deployment.properties et ajoutez-y le paramètre suivant :
  
  deployment.security.SSLv3=true

Date d'expiration de Java

La date d'expiration pour 8u31 est le 14 avril 2015. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u31) le 14 mai 2015. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), Java fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

Cette version comprend des correctifs concernant les vulnérabilités de sécurité. Pour plus d'informations, reportez-vous aux conseils sur la mise à jour des patches critiques Oracle Java SE.

Pour consulter la liste des corrections de bug incluses dans cette version, reportez-vous à la page Corrections de bug de JDK 8u31.

» Notes sur la version 8u31

Java 8 Update 25 (8u25)

Principales nouveautés de cette version

Données IANA 2014c
JDK 8u25 contient des données de fuseau horaire IANA version 2014c. Pour plus d'informations, reportez-vous à Versions de données de fuseau horaire dans le logiciel JRE.
Correction de bug : diminuer le mode de préférence de RC4 dans la liste des mécanismes de cryptage activés
Ce correctif diminue la préférence des mécanismes de cryptage RC4 dans la liste des suites activées du fournisseur SunJSSE. Reportez-vous à 8043200 (non public).
Correction de bug : défaillance de l'environnement JRE 8u20 lors de l'utilisation de la messagerie instantanée en japonais sous Windows
La machine virtuelle connaît une défaillance lors de l'utilisation des contrôles Swing lorsque certains caractères japonais ou chinois sont entrés sur la plate-forme Windows. Le problème est maintenant résolu. Reportez-vous à 8058858 (non public).

Instructions de désactivation de SSL v3.0 dans Oracle JDK et l'environnement JRE

Oracle recommande aux utilisateurs et aux développeurs de désactiver le protocole SSLv3.
» Confirmation pour les utilisateurs Java de l'absence d'affectation par la vulnérabilité SSL V3.0 "Poodle"

Date d'expiration de Java

La date d'expiration de la version 8u25 est le 20 janvier 2015. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u25) le 20 février 2015. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), Java fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

Cette version comprend des correctifs concernant les vulnérabilités de sécurité. Pour plus d'informations, reportez-vous aux conseils sur la mise à jour des patches critiques Oracle Java SE.

Pour consulter la liste des corrections de bug incluses dans cette version, reportez-vous à la page Corrections de bug de JDK 8u25.

» Notes sur la version 8u25

Java 8 Update 20 (8u20)

Principales nouveautés de cette version

Nouveaux indicateurs ajoutés à l'API de gestion Java
Les indicateurs MinHeapFreeRatio et MaxHeapFreeRatio ont été rendus gérables. Ainsi, ils peuvent être modifiés lors de l'exécution à l'aide de l'API de gestion dans Java. La prise en charge de ces indicateurs a également été ajoutée à ParallelGC dans le cadre de la stratégie de taille adaptative.
Modifications du programme d'installation de Java
- Un nouveau programme d'installation Microsoft Windows Installer (MSI) Enterprise JRE est disponible. Il permet d'installer l'environnement JRE dans toute l'entreprise. Pour plus d'informations, reportez-vous à Downloading the Installer, dans le guide JRE Installation for Microsoft Windows. Le programme d'installation MSI Enterprise JRE n'est disponible qu'avec Java SE Advanced ou Java SE Suite. Pour plus d'informations sur ces produits commerciaux, reportez-vous à Java SE Advanced et Java SE Suite.
- L'outil de désinstallation Java est intégré au programme d'installation afin de permettre la suppression des anciennes versions de Java du système. La modification s'applique aux plates-formes Windows 32 bits et 64 bits. Reportez-vous à Désinstallation de l'environnement JRE.
Modifications du panneau de configuration Java
- L'onglet Mise à jour du panneau de configuration Java permet désormais aux utilisateurs de mettre à jour automatiquement les JRE 64 bits (en plus des versions 32 bits) installés sur leur système.
- Le niveau de sécurité Moyen a été enlevé. Il ne reste plus que les niveaux Elevé et Très élevé. L'exécution d'applets non conformes aux dernières pratiques de sécurité peut tout de même être autorisée en incluant les sites qui les hébergent dans la liste des sites avec exception. La liste des sites avec exception propose aux utilisateurs d'autoriser les mêmes applets que celles qui auraient été autorisées en sélectionnant l'option Moyen mais sur une base site par site, réduisant ainsi le risque lié à l'utilisation de paramètres plus permissifs.
Compilateur Java mis à jour
Le compilateur javac a été mis à jour afin d'implémenter l'analyse des affectations définies pour l'accès au champ final vide à l'aide de "this". Pour plus d'informations, reportez-vous au manuel JDK 8 Compatibility Guide.
Modification de la version minimale requise de Java pour le plug-in Java et Java Webstart
La version minimale requise de Java pour le plug-in Java et Java Webstart est désormais Java 5. Les applets Java qui ne sont pas exécutées sous Java 5 ou une version ultérieure doivent être mises à jour pour continuer de fonctionner. Les applets écrites pour les versions précédentes mais compatibles avec au moins 5 Java continueront de fonctionner.
Modification du format de sortie de UsageTracker
Le format de sortie de UsageTracker utilise désormais des guillemets pour éviter toute confusion dans le journal. Cela peut vous amener à modifier la méthode de lecture des informations. Cette fonction peut être configurée pour obtenir un comportement identique à celui des versions précédentes, bien que le nouveau format soit recommandé. Reportez-vous à la documentation de Java Usage Tracker.
Modification des outils de création de package Java
- javafxpackager a été renommé javapackager.
- L'option "-B" a été ajoutée à la commande de déploiement javapackager pour vous permettre de transmettre des arguments aux outils de création de lots, qui servent à créer des applications autonomes. Pour plus d'informations, reportez-vous à la documentation de javapackager (Windows)/(Unix).
- L'argument de paramètre de helper a été ajouté au manuel JavaFX Ant Task Reference. Il permet de spécifier un argument (dans l'élément ) de l'outil de création de lots afin de créer des applications autonomes.

Date d'expiration de Java

La date d'expiration de la version 8u20 est le 14 octobre 2014. Java expire chaque fois qu'une nouvelle version comportant des corrections de vulnérabilité de sécurité devient disponible. Pour les systèmes qui ne parviennent pas à atteindre les serveurs Oracle, un mécanisme secondaire fait expirer cet environnement JRE (version 8u20) le 14 novembre 2014. Lorsque l'une des deux conditions est remplie (une nouvelle version est mise à disposition ou la date d'expiration est atteinte), Java fournit aux utilisateurs des avertissements et des rappels supplémentaires pour qu'ils effectuent une mise à jour vers la version plus récente.

Corrections de bug

Pour consulter la liste des corrections de bug incluses dans cette version, reportez-vous à la page Corrections de bug de JDK 8u20.

» Notes sur la version 8u20

Java 8 Update 11 (8u11)

Cette version comprend des correctifs concernant les vulnérabilités de sécurité. Pour plus d'informations, reportez-vous aux conseils sur la mise à jour des patches critiques Oracle.

Pour consulter la liste des corrections de bug incluses dans cette version, reportez-vous à la page Corrections de bug de JDK 8u11.

» Notes sur la version 8u11

Java 8 Update 5 (8u5)

Cette version comprend des correctifs concernant les vulnérabilités de sécurité. Pour plus d'informations, reportez-vous aux conseils sur la mise à jour des patches critiques Oracle.

Pour consulter la liste des corrections de bug incluses dans cette version, reportez-vous à la page Corrections de bug de JDK 8u5.

» Notes sur la version 8u5

Version de Java 8

» Notes sur la version JDK et JRE 8