Notes de mise à jour JavaTM 2 SDK, Standard Edition Version 1.3.1

Table des matières

Généralités
Machine virtuelle Java (JVM)
Propriétés des polices
Bogue de Xserver sous Solaris
RMI
CORBA, RMI-IIOP et Java IDL
Technologie Java 2D^TM
Glisser-Déposer
Accessibilité
AWT et Swing
JDBC
Sécurité
Gestion de réseaux
Java^TM Plug-in
Notes de localisation
Documentation
Les outils ne peuvent pas convertir les chaînes PCK japonaises sous Solaris 2.6
Problème concernant les polices Chinois traditionnel
Prise en charge de Windows 2000
Installation sous Windows NT

Le kit Java 2 SDK, Standard Edition, version 1.3.1 (J2SDK 1.3.1) est une version de maintenance contenant des corrections de débogage pour les problèmes rencontrés dans les versions antérieures. Pour plus de détails sur ces corrections, voir

Corrections de débogage dans cette version

En outre, J2SDK 1.3.1 contient les améliorations suivantes.

• Améliorations du Plug-in Java^TM
  Cette version contient un Plug-in Java amélioré avec de nouvelles fonctions qui le rendent plus souple, plus convivial et plus facile à configurer et lui permettent de prendre en charge les nouvelles fonctions de l'interface Open JVM du navigateur Netscape 6. Voir Nouvelles fonctions du Plug-in Java pour plus d'informations. Ces améliorations ont été introduites pour la première fois dans la mise à jour J2SDK 1.3.0_01.

• Fonction de traitement des erreurs dans la machine virtuelle Java
  Les machines virtuelles Java de J2SDK 1.3.1 possèdent un nouveau mécanisme de traitement des erreurs qui affiche des informations de débogage à l'écran lorsqu'une panne survient dans le code natif. Voir Traitement des erreurs dans J2SDK 1.3.1 pour plus d'informations.

• Convertisseur HTML intégré au kit Java 2 SDK
  Le convertisseur HTML est maintenant intégré au kit Java 2 SDK. Dans les versions antérieures, y compris la version bêta de J2SDK 1.3.1, le convertisseur HTML était disponible sous la forme d'un fichier à télécharger distinct.

Pour obtenir la documentation du Plug-in Java, voir le Site Web Plug-in Java.

Une documentation complète sur le J2SDK 1.3.1 peut être téléchargée. Consultez également le nouveau document en ligne Tuning Garbage Collection with the 1.3.1 Java Virtual Machine.

Les notes ci-dessous contiennent des informations qui peuvent s'avérer utiles aux utilisateurs de J2SDK 1.3.1, y compris des descriptions d'importantes corrections de bogues, des bogues connus et des palliatifs, ainsi que divers trucs et astuces concernant l'utilisation de cette version.

Les notes suivantes concernent la machine virtuelle Java.

• Sur les plates-formes Linux, un thread qui attend une opération d'E/S ne démarrera pas si un fichier impliqué dans l'opération d'E/S est fermé. Ce problème est consigné sous le numéro de bogue 4344135. Pour éviter ce problème, attribuez la valeur 1 à la variable d'environnement J2SE_PREEMPTCLOSE.

  J2SE_PREEMPTCLOSE=1
  export J2SE_PREEMPTCLOSE
  

• Bogue 4323062 : tous les services Windows NT intégrant la machine virtuelle Java s'interrompent lorsque l'utilisateur se déconnecte.

  Ce bogue a été corrigé dans J2SDK 1.3.1. Pour activer cette correction, l'option de ligne de commande -Xrs doit être envoyée à la machine virtuelle Java. L'argument de ligne de commande supplémentaire est nécessaire étant donné que la correction désactive obligatoirement le mécanisme de crochets de fermeture du J2SDK 1.3 et empêche l'utilisation de la classe sun.misc.Signal . Pour plus d'informations, consultez au moins la dernière section de l'évaluation de la "Bug Parade" :

  http://developer.java.sun.com/developer/bugParade/bugs/4323062.html

• Un bogue JNI provoque le blocage de la machine virtuelle Java après la fin d'un programme, avec un message d'erreur semblable à ce qui suit.

  Another exception has been detected while we were handling last error.
  Dumping information about last error: 
  ERROR REPORT FILE = (N/A) 
  PC                = 0x0x41621c7a 
  SIGNAL            = 11 
  FUNCTION NAME     = (N/A) 
  LIBRARY NAME      = (N/A) 
  Please check ERROR REPORT FILE for further information, if there is any. Good bye.
  

  Ce problème intervient surtout sous Linux Red Hat 7.1 SMP, bien qu'il puisse théoriquement apparaître aussi sur des plates-formes Microsoft Windows et Solaris.

  Palliatif - Ajouter un appel explicite à exit à la fin de la méthode main de l'application : Runtime.getRuntime().exit(0)

• L'exécution de code sur la plate-forme Java sur un répertoire NFS monté automatiquement sous Red Hat 7.1 peut entraîner des blocages fréquents dans dlopen() sous Red Hat. Ce problème est apparemment dû au programme de montage automatique NFS et disparaît si vous montez explicitement le répertoire à l'aide de mount -t nfs.

Les problèmes relatifs aux propriétés des polices suivants ont été décelés dans cette version.

• Lorsque vous utilisez des versions de Red Hat Linux autres que 6.1, il se peut que le fichier font.properties ne permettent pas l'affichage correct de certains caractères des polices Symbol/Dingbats sur des composants AWT. Pour y remédier, remplacez-le par le fichier font.properties révisé en le copiant dans le répertoire <JAVA_HOME>/jre/lib/.

• A cause du bogue 4419794, les propriétés des polices peuvent émettre des messages d'avertissement pour les localisations UTF-8 sous Solaris 8 (architecture Intel). Si vous devez les utiliser sous Solaris 8 avec du matériel Intel, mettez votre système à jour à l'aide de Solaris 8, version de mise à jour 4, dans laquelle ce problème a été résolu.

Un bogue de Xserver sous Solaris peut provoquer un blocage du système lorsqu'une application écrite en langage de programmation Java fait référence à des polices. Ce problème est décrit dans le rapport de bogue 4391019. Les correctifs Solaris suivants pour Xserver seront disponibles à la mi-juin 2001 et sont susceptibles de contribuer à résoudre ce problème.

Pour Solaris 2.6 : 105633-55 (Sparc) 106248-41 (Intel)
Pour Solaris 7 : 108376-24 (Sparc) 108377-22 (Intel)
Pour Solaris 8 : 108652-31 (Sparc) 108653-26 (Intel)

Consultez régulièrement le site Web de SunSolve pour connaître la disponibilité de ces correctifs.

Comme vous pouvez le constater ci-dessous, des modifications fondamentales ont été apportées à la fonctionnalité RMI (Remote Method Invocation) dans cette version.

• Exigence "accept" java.net.SocketPermission pour la réception d'appels distants
  En raison d'un bogue dans des mises en oeuvre antérieures de J2SDK, il était possible d'exporter un objet distant dans un contexte de contrôle d'accès donné, puis de recevoir un appel distant sur cet objet par le biais d'une connexion de socket donnée, même si le contexte de contrôle d'accès n'avait pas "accept" java.netSocketPermission pour l'adresse distante java.net.InetAddress et le port de la connexion de socket.

  Ce bogue a été corrigé. C'est la raison pour laquelle, dans certains cas, le code qui exporte des objets distants peut requérir plus d'autorisations qu'auparavant pour fonctionner correctement.

  A titre d'exemple concernant l'octroi de telles autorisations à l'aide de la syntaxe de politique de sécurité utilisée par défaut, la permission d'accepter des connexions de socket provenant d'un hôte appelé terrier.east.sun.com peut être exprimée par l'autorisation suivante (dans l'entrée pour la source de code appropriée) :

  permission java.net.SocketPermission "terrier.east.sun.com", "accept";
  

  Comme décrit dans la documentation java.netSocketPermission, la spécification de l'hôte peut commencer par un caractère générique "*" ; c'est la raison pour laquelle la permission d'accepter des connexions de socket pour n'importe quel hôte peut être exprimée par l'autorisation suivante dans une entrée donnée :

  permission java.net.SocketPermission "*", "accept";
  

• Objets distants non importés non libérés de la mémoire
  Dans les mises en oeuvre antérieures, sous certaines conditions, l'exécution du RMI se référait clairement à un objet distant même si celui-ci n'était explicitement pas exporté. Ce bogue a été corrigé de telle manière que l'exécution du RMI ne se réfère jamais à un objet distant explicitement non exporté.

• Performance de la table de remplacement ObjectOutputStream
  Dans les mises en oeuvre antérieures, une instance ObjectOutputStream se souvenait des objets remplacés (à savoir, ceux renvoyés par un appel au ObjectOutputStream.replaceObject ou par une méthode définie selon la classe writeReplace) en utilisant une recherche linéaire pour déterminer si un objet avait ou non un remplaçant. Ainsi, si le nombre d'objets remplacés dans un flux donné était important, la recherche devenait extrêmement lourde pour tout nouvel objet sérialisé. Ce bogue a été corrigé : la mise en oeuvre utilise désormais un algorithme plus efficace pour se souvenir des remplacements d'objets. Cette correction permet également l'évolutivité dans le cas d'un remplacement d'objets lors du classement des valeurs de retour et de l'argument RMI.

Les commentaires suivants concernent les fonctionnalités CORBA, RMI-IIOP et Java IDL de cette version.

• L'interopérabilité de l'ORB Sun avec les ORB d'autres fournisseurs n'a pas encore été testée. Par conséquent, elle n'est pas garantie.

• Si un serveur J2SDK 1.3.1 se connecte d'abord à un client J2SDK 1.3, puis qu'un client J2SDK 1.3.1 tente d'envoyer une instance sérialisable qui utilise writeUTF ou readUTF dans ses méthodes writeObject ou readObject respectivement, une exception MARSHAL survient. C'est également le cas si un serveur J2SDK 1.3.1 se connecte d'abord à un client J2SDK 1.3.1, puis qu'un client J2SDK 1.3 tente d'envoyer une instance du même type de classe. Ce problème est consigné sous le numéro de bogue 4434140.

  Palliatif - Modifiez la classe sérialisable pour utiliser writeObject et readObject plutôt que writeUTF et readUTF.

• J2SDK 1.3 a établi une correspondance entre les appels writeUTF/readUTF et les chaînes CORBA plutôt qu'avec les chaînes wstrings. Par conséquent, il était impossible d'utiliser ces méthodes pour envoyer des chaînes de caractères d'une valeur supérieure à 8 bits. Ce bogue est corrigé dans J2SDK 1.3.1, mais, dans le cas d'une communication avec J2SDK 1.3, le même problème se pose. Ce problème est consigné sous le numéro de bogue 4379597.

  Palliatif - Utilisez writeObject et readObject plutôt que writeUTF et readUTF. JDK 1.3.1 et J2SDK 1.3 établissent une correspondance entre ceux-ci et des appels de chaînes wstring CORBA lorsque les paramètres de la méthode sont "Chaînes".

• L'ORB Java livré avec J2SDK 1.3.1 contient des corrections permettant la prise en charge de l'évolutivité des classes sérialisables, comme indiqué dans la Spécification de sérialisation Java.

  Grâce à cette prise en charge, les versions J2SDK 1.3.1 et ultérieures peuvent gérer l'évolution des classes. Par exemple, si une classe V fournie dans J2SDK 1.3.1 évolue dans une future version de J2SDK, un client d'application (émetteur/récepteur de la classe V) tournant sur J2SDK 1.3.1 sera en mesure d'interagir avec le serveur (émetteur/récepteur de la classe V évoluée) tournant sur la future version J2SDK, et vice versa.

  Toutefois, la version antérieure J2SDK 1.3.0 comporte des bogues qui empêchent l'évolution des classes. (Voir, par exemple, le rapport 4365188 sur le site Web Java Developer Connection ^SM.) C'est la raison pour laquelle des problèmes d'interopérabilité se poseront lorsque J2SDK 1.3.1 tentera d'envoyer des classes évoluées à J2SDK 1.3.

• Lorsque vous rédigez du code dans OMG IDL, n'employez pas un nom d'interface comme nom de module, car cela pourrait produire des résultats incohérents pendant la compilation au moyen d'utilitaires d'autres fournisseurs, et ainsi compromettre la portabilité du code. Par exemple, l'utilisation de code contenant des mêmes mots pourrait produire des résultats différents selon qu'il est compilé au moyen du compilateur IDL-Java de Sun Microsystems ou de celui d'un autre fournisseur.

Le bogue 4178909 dans les bibliothèques Java 2D ^TM empêche parfois l'affichage correct des applications lorsque le système tourne en mode 8 bits. Ce problème ne devrait affecter que le premier lancement d'une application après un réamorçage ou le passage au mode d'affichage 8 bits.

Il existe également certains bogues associés à DirectDraw. Si vous rencontrez un problème relatif à DirectDraw, une solution consiste à le désactiver :

-Dsun.java2d.noddraw=true

Certains pilotes d'affichage produisent des défauts de synchronisation ou des sauts d'image au cours des accès à DirectDraw. Dans ce cas, visitez le site Web du fabricant pour savoir si un nouveau pilote corrigeant ce défaut est disponible.

La plate-forme Java ne prend pas en charge les affichages 16 couleurs. Si vous remarquez des problèmes de traçage des graphiques et des composantes de l'interface utilisateur graphique sur un affichage 16 couleurs, essayez de régler l'affichage en mode 256 couleurs ou plus.

Les fonctionnalités ci-dessous sont mises en oeuvre et fonctionnelles, mais n'ont pas été entièrement testées, et ne sont pas prises en charge dans cette version.

• Transferts par glisser-déposer :
  • de types de données natives de la plate-forme et/ou définis par l'utilisateur ;
  • d'instances de classes arbitraires, chargées par des instances de ClassLoader distinctes, dans la même machine virtuelle Java* ;
  • d'objets Java sérialisés entre machines virtuelles Java (ou instances de ClassLoader).
• Liaison de sous-interfaces RMI java.rmi.Remote entre machines virtuelles Java

Les composants AWT et Swing possèdent des classes internes intégrant l'API d'accessibilité Java et fournissant aux composants la prise en charge d'accessibilité appropriée. Cependant, l'accessibilité n'est pas entièrement prise en charge pour les classes AWT suivantes dans cette version :

java.awt.TextComponent
java.awt.Menu
java.awt.MenuItem
java.awt.List

La prise en charge complète de tous les composants sera intégrée dans une version future de la plate-forme Java 2.

Les commentaires suivants concernent les fonctionnalités AWT et Swing de cette version.

• Un programme appelant la méthode statique Toolkit.getDefaultToolkit ne se ferme pas pour retourner à la ligne de commande. Ce problème est consigné dans les rapports de bogue 4030718 et 4403762 et sera corrigé dans la version bêta de J2SDK 1.4.0.

  Palliatif - Appelez System.exit() lorsque vous souhaitez quitter votre application.

• La nouvelle méthode Component.getListeners() ne renvoie pas de récepteurs d'événements PropertyChangeListener. Si vous avez ajouté un récepteur d'événements avec addPropertyChangeListener(),

  myComponent.getListeners(PropertyChangeListener.class)
  

  renvoie un tableau vide.

• Le bogue 4199374 concerne un problème de gestion ciblée avec des objets JWindow. Il empêche notamment Component.requestFocus() de cibler les composants dans JWindow. Ce bogue a été corrigé dans les versions de mise à jour J2SDK 1.2.2_05 et J2SDK 1.3.0_02. Toutefois, il ne l'est pas dans J2SDK 1.3.1.

Sous Windows NT, le pont JDBC 2.0 prend en charge le gestionnaire de pilotes ainsi que les pilotes ODBC 2.x et ODBC 3.x. Le pont JDBC 2.0 a été testé uniquement avec un gestionnaire de pilotes ODBC 3.x ainsi qu'avec les pilotes ODBC 2.x et 3.x.

Merant recommande d'utiliser le pont JDBC 2.0 avec la version 3.5 ou supérieure des pilotes ODBC DataDirect Merant.

Les considérations de sécurité ci-dessous s'appliquent à cette version.

L'utilitaire jarsigner peut vérifier les fichiers signés par Netscape SignTool 1.3 à condition que les certificats de signature de code ne soient pas auto-signés. Remarque : des certificats de signature de code Netscape officiels sont fournis par VeriSign^TM. Ils sont émis par VeriSign, et ne sont pas auto-signés.

Netscape SignTool 1.3 n'insère pas de certificat dans le fichier de signature si le certificat de signature de code est auto-signé, et jarsigner ne peut pas vérifier un fichier JAR signé si le fichier de signature ne contient pas le certificat du signataire. Remarque : le certificat de signature de code généré par SignTool 1.3 ne sert qu'aux essais et est auto-signé. L'utilitaire jarsigner ne peut pas vérifier un fichier JAR signé par Netscape SignTool 1.3 si le certificat de signature de code est un certificat d'essai auto-signé.

Dans le kit Java 2 SDK, les classes d'application sont chargées par une instance de ClassLoader. Ainsi, elles peuvent utiliser des extensions installées. En outre, cela sépare le chemin de classes de l'application (spécifié par l'utilisateur) du chemin de classes d'initialisation (fixe et ne devant normalement pas être modifié par l'utilisateur). L'option -Xbootclasspath peut servir à remplacer le chemin de classes d'initialisation si nécessaire.

Cela signifie toutefois que dans le kit Java 2 SDK, les classes d'applications ne possèdent plus toutes les permissions par défaut. Elles reçoivent des permissions en fonction de la politique de sécurité du système configurée. Pour cette raison, certaines applications écrivant leur propre code de sécurité en fonction du modèle de sécurité original dans JDK 1.0/1.1 peuvent déclencher une exception et ne pas démarrer dans le kit Java 2 SDK. Pour éviter ce problème, exécutez ces applications au moyen du programme de lancement oldjava , documenté à la page de référence du programme de lancement des applications Java.

Les notes suivantes résument les règles relatives à la sécurité et à la signature.

• La politique de sécurité utilisée par défaut sur la plate-forme Java 2 est spécifiée par la propriété policy.provider dans le fichier des propriétés de sécurité Java, jre/lib/security/java.security. Si vous spécifiez une police de sécurité différente, vous devez placer votre nouveau fichier des propriétés de sécurité dans le chemin de la classe d'initialisation. Pour ce faire, utilisez l'option de ligne de commande -Xbootclasspath command-. Voir Page de référence du lancement des applications Java pour plus d'informations sur cette option. Ainsi, le fichier de politiques sera chargé par le chargeur de classes d'initialisation. Si le nouveau fichier de politiques par défaut est placé ailleurs, par exemple sur le chemin de classes ou dans une extension, il ne sera pas lu, et la politique par défaut spécifiée dans le fichier sun.security.provider.PolicyFile sera utilisée à sa place.

• A compter de la version 1.2.2, le kit Java 2 SDK utilise un nouveau mécanisme de chargement de classes. Avec le nouveau chargeur de classes, si un fichier de classe appartenant à un paquetage dans un fichier JAR est signé, tous les fichiers de classe de ce paquetage doivent avoir été signés par les mêmes signataires. Il n'est plus possible d'utiliser un fichier JAR où certaines classes d'un paquetage sont signées, et où d'autres sont non signées ou signées par un signataire différent. Les fichiers JAR peuvent toujours contenir des paquetages non signés. Cependant, si certains paquetages contiennent des classes signées, tous les fichiers de classes de ce paquetage doivent être signés par le même signataire. Les fichiers JAR existants ne satisfaisant pas ce critère ne seront pas utilisables avec cette version de la plate-forme Java 2.

L'utilitaire keytool peut actuellement importer ou imprimer un certificat codé Base64 à partir d'un fichier seulement si ce fichier se termine par un caractère NL (saut de ligne). S'il n'y a pas de caractère NL à la fin du fichier de certificat et que vous tentez d'importer ou d'imprimer le certificat, une exception de certificat &Codage non pris en charge; surviendra, ou un message d'erreur de keytool tel que &�chec d'analyse de l'entr�e; ou &L'entr�e n'est pas un certificat X.50; apparaîtra.

Si vous obtenez ce type de message ou d'exception, il est possible que le problème soit causé par l'absence d'un caractère NL de fin. En effet, il arrive parfois qu'une réponse de certificat provenant d'une autorité de certification (suite à une requête de signature de certificat) ne contienne pas de caractère NL de fin.

Sous UNIX, vous pouvez déterminer si un fichier contient un caractère NL de fin ou non en exécutant cette commande :

    od -xc <nom_du_certificat>

où <nom_du_certificat> désigne le fichier contenant le certificat. Par exemple, si le fichier se nommait moncert , la commande serait :

    od -xc moncert

Si la sortie résultante se termine par un caractère "\n" (sans les guillemets), il y a déjà un saut de ligne à la fin. Sinon, vous pouvez en ajouter un.

Si vous ne savez pas si le fichier de certificat contient un caractère NL de fin, vous pouvez simplement en ajouter un en suivant les directives du paragraphe ci-dessous (il ne coûte rien d'en mettre plusieurs), puis réessayer la commande -import ou -printcert. Si la commande fonctionne, c'est qu'il manquait un caractère NL de fin. Si l'erreur persiste, le certificat présente un problème différent.

Pour ajouter un saut de ligne à la fin d'un fichier de certificat codé Base64, ouvrez le fichier dans n'importe quel éditeur de texte, placez le curseur à la fin du fichier, puis ajoutez un caractère NL (ou un retour de chariot), par exemple en appuyant sur la touche Retour.

Gestion de réseaux

L'API de gestion de réseaux de cette version comporte les bogues et restrictions ci-dessous :

• Sous Windows 2000, les applications datagramme peuvent recevoir une exception de socket inattendue indiquant que le socket est fermé. Cela est dû au nouveau comportement de Windows 2000 lorsqu'une application distante n'est pas disponible. Une solution potentielle consiste à fermer et à recréer le DatagramSocket. Ce problème est consigné sous le numéro de bogue 4361783.

• J2SDK 1.3.0 a introduit une mise en oeuvre de client HTTP/1.1. Les serveurs Web tels qu'Apache renvoient des éléments de réponse codée aux clients HTTP 1.1, mais J2SDK 1.3.0 et 1.3.1 ne reconstituent pas la réponse du serveur. En pratique, cela signifie que des méthodes telles que java.net.URLConnection.getInputStream ne produisent pas de résultats avant la fin de la réponse du serveur. Ce problème est consigné sous le numéro de bogue 4333920.
  Palliatif : pour Apache, le palliatif consiste à insérer les éléments suivants dans httpd.conf.

  BrowserMatch "Java1\.3\..[0-1]" downgrade-1.0
  

• La spécification HTML 4.0 recommande de coder les caractères non-ASCII des identificateurs de ressources uniformes (URI) dans un ou plusieurs octets UTF-8. De nombreux scripts CGI existants traitent les caractères non-ASCII à l'aide d'octets provenant du codage dans lequel un document est reçu. Toutefois, les classes URLEncoder et URLDecoder ne prennent pas en charge ces méthodes de traitement des caractères non-ASCII dans les URI. En effet, ces classes substituent un ou plusieurs octets aux caractères, tel que défini dans le codage par défaut de la plate-forme sous-jacente. Il s'agit du bogue 4257115.

• Un appel à la méthode HttpURLConnection.getResponseCode sur le client peut entraîner le blocage de la machine virtuelle s'il y a des retours chariot supplémentaires dans l'en-tête HTTP envoyé par un serveur Win98 ou WinNT. Il s'agit du bogue 4258697.
  Palliatif : la surcharge peut être évitée en configurant le serveur http pour qu'il envoie une réponse HTTP 1.0. Pour Apache, insérez les éléments suivants dans httpd.conf.

  BrowserMatch "Java1\.3\..[0-1]" downgrade-1.0
  

Si votre application utilise les classes de gestion de réseaux, elle ne s'exécutera peut-être pas correctement sous Winsock 1.1. Si votre application de gestion de réseaux doit prendre en charge Windows 95, lequel inclut Winsock 1.1, les utilisateurs de votre application devront posséder Winsock 2.0. (Windows NT 4.0, Windows 2000 et Windows ME et Windows 98 incluent Winsock 2.0). Vous pouvez télécharger Winsock 2.0 à cette adresse :

http://www.microsoft.com/windows95/downloads/contents/wuadmintools/s_wunetworkingtools/w95sockets2/

L'URL suivante explique comment déterminer si les composantes Winsock 2.0 sont installées sur une plate-forme Windows 95 :

http://support.microsoft.com/support/kb/articles/Q177/7/19.asp

Sans la mise à niveau Winsock, il est possible que InetAddress.getByName produise une panne dans kernel32.dll si la recherche d'un nom échoue. Pour plus d'informations concernant ce bogue, consultez le site Web de Microsoft.

http://support.microsoft.com/support/kb/articles/Q176/3/54.ASP

Java^TM Plug-in

Les notes suivantes concernent le Plug-in Java de cette version.

• Sur les plates-formes Linux, plusieurs copies d'une applet ne peuvent pas être imprimées à partir d'un navigateur Web. Le navigateur doit être fermé et redémarré pour chaque impression suivant la première. Ce problème est consigné sous le numéro de bogue 4450194.

• Lorsque vous installez une extension à l'aide du Plug-in Java, une boîte de dialogue d'avertissement apparaît et vous en informe. Si vous cliquez sur le bouton "Refuser", la boîte de dialogue peut toutefois réapparaître, vous invitant à approuver ou refuser l'installation de la même extension. Ce bogue sera corrigé dans une version future.

• Dans la version 1.3.0_01, la vérification des signatures a été modifiée pour utiliser le centre de stockage des certificats de l'environnement d'exécution Sun Java, plutôt que celui livré avec Microsoft Internet Explorer. Cette modification a été apportée parce que l'utilisation du centre de stockage d'Internet Explorer ne fonctionne pas pour les applets exécutées dans les navigateurs Netscape. Un nouveau code de traitement des erreurs a été introduit dans la version 1.3.1 pour gérer les signatures non vérifiables. Voir le rapport de bogue 4424604.

Notes de localisation

Pour obtenir des informations générales sur la prise en charge des paramètres internationaux dans cette version, voir Notes de localisation.

Documentation

Les commentaires suivants concernent la documentation de cette version.

• En raison du bogue 4459595, la page Serialized Form de la spécification de l'API de cette version contient des liens rompus vers des fichiers de classes privées et privées de paquetage.

• Consultez le nouveau document en ligne Tuning Garbage Collection with the 1.3.1 Java Virtual Machine.

Les outils ne peuvent pas convertir les chaînes PCK japonaises sous Solaris 2.6

Une erreur se produit lors de l'utilisation de chaînes japonaises en arguments de la commande java sous Solaris 2.6 avec langue ja_JP.PCK. Pour résoudre ce problème, changez la ligne 89 /usr/java/bin/.java_wrapper de

exec $DEBUG_PROG "$prog" $opts "$@"

en

exec $DEBUG_PROG $prog $opts $@

Problèmes concernant les textes en chinois traditionnel

Les problèmes suivants ont été constatés dans cette version en relation avec les polices du chinois traditionnel.

• Microsoft Windows 95 pour chinois traditionnel version 2.0 ne contient pas les polices de caractères Chinois traditionnel spécifiées dans le fichier de propriétés des polices du kit Java 2 SDK. Si vous utilisez le kit Java 2 SDK ou l'environnement d'exécution Java 2 sous ce système d'exploitation, vous obtiendrez des messages d'avertissement de police introuvable, et le texte ne s'affichera peut-être pas correctement. Ce problème a été corrigé dans la deuxième édition de Microsoft Windows 95 pour chinois traditionnel version 2.0, lancée en octobre 1996, qui contient les polices spécifiées.

• Dans l'environnement Chinois traditionnel de Microsoft Windows 95, les caractères chinois ne s'affichent pas correctement sur les composants Swing. Pour plus de détails concernant ce problème, voir le rapport de bogue 4431319 du site Web Java Developer Connection ^SM.

Dans la version anglaise, la version 1.3.1 du kit Java 2 SDK est prise en charge sous Windows 2000 Professional, Windows 2000 Server, Window 2000 Advanced Server. L'édition DataCenter de Windows 2000 n'est pas prise en charge. Dans les autres versions, seule l'édition Professional de Windows 2000 est prise en charge. Voici certains problèmes connus relatifs à Windows 2000 :

• Windows 2000 et prise en charge de multiples moniteurs - Les moniteurs multiples ne sont pas encore entièrement fonctionnels sur la plate-forme Windows 2000. En particulier, le mode 256 couleurs ne se comporte correctement que si tous les moniteurs sont réglés en mode 256 couleurs. Le mode de couleurs 16 bits (ou plus) est fortement recommandé.

• Si le message d'erreur suivant apparaît au cours de l'installation sous Windows 2000 :

     config.nt. Le fichier système ne convient pas à l'exécution des applications MS-DOS ou Microsoft Windows.
  

  il indique un problème avec le fichier %SystemRoot%\System32\COMMAND.COM qui a été rencontré sur certaines installations de Windows 2000. Si ce message d'erreur s'affiche lorsque vous tentez de lancer le programme d'installation, consultez le site Web de Microsoft à l'adresse

  http://support.microsoft.com/support/kb/articles/Q142/2/71.asp

  pour plus d'informations sur les solutions à ce problème.

• Interruption de processus - Une application peut s'interrompre à cause d'un blocage dans Ntdll sous les systèmes d'exploitation Microsoft Windows 2000 Professional, Server et Advanced Server. Ce problème peut se poser, par exemple, dans des applications qui utilisent des flux E/S d'objets java.lang.Process . Consultez le site Web des services d'assistance techniques Microsoft pour plus d'informations et pour une solution au problème :

  http://support.microsoft.com/support/kb/articles/Q271/1/82.ASP

Installation sous Windows NT

Lorsque vous installez la version 1.3.1 de l'environnement d'exécution Java, le fichier de contrôles ActiveX à l'emplacement C:\Winnt\Downloaded  Program Files\Java Runtime Environment 1.3.1 aura un état "Endommagé". Ce n'est qu'un problème cosmétique et l'état "Endommagé" ne devrait avoir aucun effet négatif quelle que soit la situation.

Il existe néanmoins un palliatif si pour une raison quelconque, vous ne pouvez pas avoir un état "Endommagé". Sélectionnez "Démarrer -> Exécuter" et tapez "regedit". A partir des fenêtres de regedit, naviguez jusqu'à la clé de registre "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Code Store Database\Distribution Units\8AD9C840-044E-11D1-B3E9-00805F499D93\DownloadInformation". Double-cliquez sur la chaîne INF et supprimez la chaîne en surbrillance sous "Données". Le fichier de contrôle ActiveX aura l'état "Installé".

Copyright (c) 2001 Sun Microsystems, Inc. Tous droits réservés.