Java.com

Télécharger Aide

Version imprimable

Principales modifications de la version Java 8


Cet article s'applique aux éléments suivants:
  • 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 de version.
» Dates de publication des versions de Java


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
    Voir 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.
    Voir 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. Voir 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. Voir 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 de données de 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)

Date d'expiration 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.

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 8u101.

» Notes de 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 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

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 8u91.

» Notes de la version 8u91


Java 8 Update 77 (8u77)

Date d'expiration 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 de la version 8u77


Java 8 Update 73 (8u73)

Principales nouveautés de cette version
Date d'expiration 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.
    Valeur par défaut : 0 n'enlève pas les anciens environnements JRE
    JDK-8081237 (non public)
Date d'expiration 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 de 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 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 de la version 8u25


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.

Date d'expiration 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 de 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 ...
    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 :
    • Joindre DumpJFR à un processus actif :

      java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.tools.DumpJFR <pid>

    • Joindre DumpJFR à un dump noyau :

      java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.tools.DumpJFR <java> <core>
    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 dispositifs 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. Cependant :
      • 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 :
<!ELEMENT ruleset (rule*)>
<!ATTRIBUTE ruleset href CDATA #IMPLIED>
<!ATTRIBUTE ruleset version CDATA #REQUIRED>

<!ELEMENT rule (id, action)>

<!ELEMENT id (certificate?) (checksum?) >
<!ATTRIBUTE id title CDATA #IMPLIED>
<!ATTRIBUTE id location CDATA #IMPLIED>

<!ELEMENT certificate EMPTY>
<!ATTLIST certificate algorithm CDATA #IMPLIED>
<!ATTLIST certificate hash CDATA #REQUIRED>

<!ELEMENT checksum EMPTY>
<!ATTLIST checksum algorithm CDATA #IMPLIED>
<!ATTLIST checksum hash CDATA #REQUIRED>
 
<!ELEMENT action (message?)>
<!ATTRIBUTE permission (run | block | default) #REQUIRED>
<!ATTRIBUTE version CDATA #IMPLIED>
<!ATTRIBUTE force (true|false) "false">

<!ELEMENT message (#PCDATA)>
<!ATTLIST message locale CDATA #IMPLIED>

Date d'expiration 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 de 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 Commodo :
    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 :
    Autorité de certification racine d'authentification Actalis
    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 :
    Autorité de certification racine Entrust - 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 des certificats d'autorité de certification
    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 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 de 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 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 de 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 du JDK 8u40 comprend les améliorations suivantes apportées à Java Packager :
  • 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 manuel Nashorn User's Guide et 8043717 (non public).
  • Problèmes avec les fournisseurs JCE tiers
    Le correctif pour le JDK-8023069 (dans le 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 documentée est en phase d'abandon dans le 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 du 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 du 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 du 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.
  • Documentation du programme d'installation MSI ajoutée
    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 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 de 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 partir 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 partir 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 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 de 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ées
    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 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 de 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 avec champs finaux vides à l'aide de "ceci". 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 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 de 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 de 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 de la version 8u5


Publication de Java 8

» Notes de version JDK et JRE 8


Les éléments suivants pourraient également vous intéresser:




Sélectionner une langue | A propos de Java | Support technique | Développeurs
Politique de confidentialité  | Conditions d'utilisation | Trademarks | Avis de non-responsabilité

Oracle