# IBM 32-bit SDK pour plateformes Windows, Java Technology Edition, Version 6

# Guide d'utilisation SDK et Runtime

Important

Avant d'utiliser le présent document et le produit associé, prenez connaissance des informations générales figurant à la section Remarques.

LE PRESENT DOCUMENT EST LIVRE EN L'ETAT SANS AUCUNE GARANTIE EXPLICITE OU IMPLICITE. IBM DECLINE NOTAMMENT TOUTE RESPONSABILITE RELATIVE A CES INFORMATIONS EN CAS DE CONTREFACON AINSI QU'EN CAS DE DEFAUT D'APTITUDE A L'EXECUTION D'UN TRAVAIL DONNE.

Ce document est mis à jour périodiquement. Chaque nouvelle édition inclut les mises à jour. Les informations qui y sont fournies sont susceptibles d'être modifiées avant que les produits décrits ne deviennent eux-mêmes disponibles. En outre, il peut contenir des informations ou des références concernant certains produits, logiciels ou services non annoncés dans ce pays. Cela ne signifie cependant pas qu'ils y seront annoncés.

Pour plus de détails, pour toute demande d'ordre technique, ou pour obtenir des exemplaires de documents IBM, référez-vous aux documents d'annonce disponibles dans votre pays, ou adressez-vous à votre partenaire commercial.

Vous pouvez également consulter les serveurs Internet suivants :

- http://www.fr.ibm.com (serveur IBM en France)
- http://www.can.ibm.com (serveur IBM au Canada)
- http://www.ibm.com (serveur IBM aux Etats-Unis)

    Compagnie IBM France
    Direction Qualité
    Tour Descartes
    92066 Paris-La Défense Cedex 50

(C) Copyright IBM France 2007. Tous droits réservés.

Copyright International Business Machines Corporation 2003, 2007. All Rights Reserved.

# Table des matières

Préface
Généralités
Compatibilité des versions
Migration à partir d'autres machines virtuelles IBM
Sommaire du SDK et de Runtime Environment
Classes et outils d'environnement d'exécution
Outils SDK et informations de référence
Installation et configuration de SDK et Runtime Environment
Avant l'installation
Installation des packages
Installation sous surveillance (interactive)
Installation de Runtime Environment comme machine virtuelle Java système
Installation automatisée
Activation d'IBM Accessibility Bridge
Désactivation de la prise en charge de Java Accessibility
Informations pour les utilisateurs de langues européennes
Définition du PATH
Définition du chemin d'accès aux classes
Désinstallation
Exécution des applications Java
Les commandes java et javaw
Obtention des informations de version
Indication des options Java et des propriétés système
Options standard
Globalisation de la commande java
Exécution automatique d'un fichier Java
Exécution des applications Java avec des technologies d'assistance natives
Compilateur JIT (Just-In-Time)
Désactivation du JIT
Activation du JIT
Déterminer si le JIT est activé
Définition des règles de récupération de place
Options de récupération de place
Délai d'interruption
Réduction du délai d'interruption
Environnements à segments très saturés
Prise en charge du symbole Euro
| |
Utilisation des méthodes de saisie indiennes et thaïs
Utilisation de SDK pour développer des applications Java
| |
Utilisation de XML
| |
Migration vers le compilateur XL-TXE-J
| |
Informations de référence relatives à XML
Débogage des applications Java
Débogueur Java (JDB)
Détermination si votre application s'exécute sur une machine virtuelle Java 32 ou 64 bits
Traitement des signaux par la JVM
Signaux utilisés par la JVM
Création d'un lien entre un pilote de code natif et une bibliothèque de chaînage de signaux
Ecriture d'applications JNI
Configuration de l'allocation de mémoire à grandes pages
Prise en charge de CORBA
Propriétés système de traçage de l'ORB
Propriétés système d'optimisation de l'ORB
Droits de sécurité Java pour l'ORB
Classes d'implémentation ORB
RMI sur IIOP
Implémentation du pool de gestionnaires de connexion pour RMI
Big Decimal amélioré
Plug-in, Applet Viewer et Web Start
Utilisation du plug-in Java
Navigateurs pris en charge
Prise en charge de la vérification statique et sécurisée des versions
Prise en charge du modèle DOM (Document Object Model) commun
Utilisation des paramètres DBCS
Utilisation d'applets
Exécution d'applets à l'aide d'Applet Viewer
CLSID uniques
Débogage d'applets à l'aide d'Applet Viewer
Utilisation de Web Start
Exécution de Web Start
Gestion sécurisée des versions statiques de WebStart
Livraison d'applications Java
Partage de données de classes entre JVM
Présentation du partage de données de classes
Activation et configuration du partage de données de classes
Création, remplissage, contrôle et suppression d'un cache
Performances et sollicitation de la mémoire
Considérations et limitations concernant l'utilisation du partage de données de classes
Limites de la taille du cache
Modification du code intermédiaire d'exécution
Limitations du système d'exploitation
Utilisation de SharedClassPermission
Adaptation de chargeurs de classes personnalisés pour partager des classes
Utilisation de l'API Java Communications (JavaComm)
Installation de l'API Java Communications à partir d'un fichier compressé
Configuration de l'API Java Communications
Spécification des périphériques dans le fichier javax.comm.properties
Limitation d'impression avec l'API Java Communications
Désinstallation de l'API Java Communications
Documentation de l'API Java Communications
Service et prise en charge pour des éditeurs de logiciels indépendants
Accessibilité
Passage clavier des composants JComboBox dans Swing
Accessibilité de Web Start
Remarque générale sur la sécurité
Commentaires sur le guide d'utilisation
Annexe A. Options non standard
Annexe B. Restrictions connues
Remarques
Marques

# Préface

Ce guide d'utilisation fournit des informations générales sur IBM 32-bit SDK et Runtime Environment pour Windows, Java Technology Edition, Version 6 et d'autres informations spécifiques sur les différences entre les implémentations IBM et Sun.

Consultez-le en complément de la documentation plus détaillée disponible sur le site Web de Sun à l'adresse http://java.sun.com.

SDK et Runtime Environment sont pris en charge sur les produits suivants :

- Windows 2000
- Windows XP
- Windows Server 2003
- Windows Vista

Ces environnements virtuels sont pris en charge :

- VMWare
- Xen
- Microsoft Virtual Server

Notez qu'IPv6 est pris en charge uniquement sous Windows XP et Windows Server 2003.

Le document Diagnostics Guide fournit des informations détaillées sur IBM Virtual Machine for Java.

Ce guide d'utilisation fait partie intégrante d'une édition et s'applique uniquement à cette édition spécifique. Assurez-vous d'être en possession du guide d'utilisation approprié pour l'édition utilisée.

Les termes "Runtime Environment" et "Java Virtual Machine" sont utilisés indifféremment dans ce guide d'utilisation.

|Les modifications techniques apportées à cette version du guide d'utilisation, autres que les modifications mineures ou importantes, sont indiquées par des chevrons bleus lors de l'affichage dans un centre de documentation, en rouge avec des barres verticales placées à leurs gauches lors de l'affichage au format HTML ou sur une impression en couleurs ou par des barres verticales placées à leur gauche lors de l'affichage au format PDF.

Le code de programme n'est pas conçu pour ou destiné à une utilisation dans des applications en temps réel telles que (mais de façon non limitative) le contrôle en ligne des avions, du trafic aérien, de la navigation aérienne ou des communications aériennes ; ou la conception, construction, l'opération ou l'entretien de toute installation nucléaire.

# Généralités

Le SDK IBM est un environnement de développement permettant d'écrire et d'exécuter des applets et des applications conformes à Java 6 Core Application Program Interface (API).

Le SDK inclut Runtime Environment for Windows, qui permet d'exécuter uniquement des applications Java. Si vous avez installé SDK, IBM Runtime Environment est inclus.

L'environnement d'exécution contient la machine virtuelle Java ainsi que les fichiers de prise en charge incluant les fichiers de classe. L'environnement d'exécution contient seulement un sous-ensemble des classes se trouvant dans le SDK. Il permet de prendre en charge un programme Java lors de l'exécution mais ne permet pas de compiler les programmes Java. Le Runtime Environment for Windows n'inclut aucun des outils de développement, tels que appletviewer.exe ou le compilateur Java (javac.exe), ni les classes destinées aux systèmes de développement uniquement.

En outre, le module de l'API Java Communications est fourni pour une utilisation avec Runtime Environment for Windows. Vous pouvez trouver des informations à ce sujet dans Utilisation de l'API Java Communications (JavaComm).

## Compatibilité des versions

En général, les applets ou les applications ayant déjà été exécutées avec une version antérieure du SDK doivent fonctionner correctement avec IBM 32-bit SDK pour Windows, v6. Il n'est pas garanti que les classes compilées avec cette version fonctionnent sur les versions antérieures.

IBM 32-bit SDK pour Windows, v6, est créé avec Microsoft Visual Studio .NET 2003.

Pour plus d'informations sur les problèmes de compatibilité entre les différentes éditions, reportez-vous aux pages Web Sun suivantes :

|http://java.sun.com/javase/6/webnotes/compatibility.html

http://java.sun.com/j2se/5.0/compatibility.html

http://java.sun.com/j2se/1.4/compatibility.html

http://java.sun.com/j2se/1.3/compatibility.html

Si vous utilisez le SDK comme faisant partie d'un autre produit (par exemple, IBM WebSphere Application Server) et que vous effectuez une mise à niveau depuis une version antérieure du SDK, par exemple v5.0, il se peut que les classes sérialisées ne soient pas compatibles. Ces dernières sont toutefois compatibles entre les diverses actualisations de service.

## Migration à partir d'autres machines virtuelles IBM

A partir de la version 5.0, IBM Runtime Environment for Windows contient les nouvelles versions d'IBM Virtual Machine for Java et du compilateur JIT (Just-In-Time).

Si vous effectuez une migration à partir d'une version d'IBM Runtime Environment plus ancienne, notez que :

- Pour correspondre davantage à l'organisation de la machine virtuelle Sun, la bibliothèque de liaison dynamique de la JVM jvm.dll est désormais stockée dans jre\bin\j9vm et jre\bin\classic.
- Depuis la version 5.0, l'interface JVMMI (JVM Monitoring Interface) n'est plus disponible. Vous devez récrire les applications JVMMI afin d'utiliser l'interface JVMTI (JVM Tool Interface) à la place. JVMTI n'est pas l'équivalent de JVMMI du point de vue de la fonctionnalité. Pour plus d'informations sur JVMTI, reportez-vous à la page http://java.sun.com/javase/6/docs/technotes/guides/jvmti/ et consultez le document Diagnostics Guide.
- Depuis la version 5.0, la mise en oeuvre de JNI est conforme à la spécification JNI, mais diffère de la mise en oeuvre de la version 1.4.2. Elle renvoie des copies des objets au lieu de les réserver. Cette différence peut exposer des erreurs dans le code d'application JNI. Pour plus d'informations sur le débogage du code JNI, voir -Xcheck:jni dans Annexe A. Options non standard.
- Depuis la version 5.0, le format et le contenu des journaux prolixes de récupération de place obtenus à l'aide de la commande -verbose:gc ont changé. Les données sont à présent fournies au format XML. Le contenu des données reflète les modifications apportées à la mise en oeuvre de la récupération de place dans la machine JVM et la plupart des statistiques en sortie ont changé. Vous devez modifier tous les programmes qui traitent la sortie prolixe de récupération de place afin qu'ils puissent fonctionner avec le nouveau format et les nouvelles données. Pour obtenir un exemple des nouvelles données prolixes de récupération de place, voir le document Diagnostics Guide.
- Les versions 1.4 SDK de la machine virtuelle IBM comportaient les classes spécifiques à JVM dans un fichier appelé core.jar. A partir de la version 5.0, ces classes sont incluses dans un fichier nommé vm.jar.
- Les versions précédentes du JRE IBM incluaient un fichier appelé rt.jar situé dans le répertoire jre/lib. Depuis la version 1.4, ce fichier est remplacé par plusieurs fichiers JAR résidant dans le répertoire jre/lib.
- |Pour obtenir plus d'informations sur la compatibilité et les API déconseillées, voir Sun's Java 6 Compatibility Documentation et Sun's Java 6 Deprecated API List.
- Le traçage des dépendances de classe, appelé à l'aide de -verbose:Xclassdep, n'est pas pris en charge. Si vous spécifiez -verbose:Xclassdep, la machine JVM émet un message d'erreur et ne démarre pas.

# Sommaire du SDK et de Runtime Environment

Le SDK contient plusieurs outils de développement ainsi qu'un Java Runtime Environment (JRE). Cette section décrit le contenu des outils du SDK et de l'environnement d'exécution.

Les applications entièrement écrites en Java ne doivent pas être dépendantes de l'arborescence des répertoires du SDK d'IBM (ou des fichiers contenus dans ces répertoires). Toute dépendance de cette arborescence (ou de ces fichiers) peut compromettre la portabilité de l'application. Les applications JNI (Java Native Interface) ont des dépendances mineures.

Les guides d'utilisation, la documentation utilisateur ainsi que la licence, les fichiers de droit d'auteur, la documentation utilisateur et le répertoire demo qui les accompagnent constituent la seule documentation comprise dans ce SDK pour Windows. Vous pouvez consulter ou télécharger la documentation des logiciels Sun sur le site Web de Sun à l'adresse : http://java.sun.com.

## Classes et outils d'environnement d'exécution

Liste des classes et des outils que vous pouvez utiliser avec l'environnement d'exécution standard.

- Classes Core -- Il s'agit des fichiers de classes compilés pour la plateforme ; ils doivent rester zippés pour que le compilateur et l'interpréteur puisse y accéder. Ne modifiez pas ces classes. Au lieu de cela, créez des sous-classes et effectuez un remplacement lorsque c'est nécessaire.
- Outils JRE -- Les outils suivants font partie du Runtime Environment et se trouvent dans le répertoire C:\Program Files\IBM\Java60\jre\bin, sauf indications contraires.
  ikeyman.exe (utilitaire d'interface graphique iKeyman)
    Permet de gérer les clés, certificats et demandes de certificats. Pour plus d'informations, reportez-vous au document Security Guide et au site http://www.ibm.com/developerworks/java/jdk/security. Le SDK fournit également une version en ligne de commande de cet utilitaire.
  java.exe (interpréteur Java)
    Exécute les classes Java. L'interpréteur Java exécute les programmes écrits avec le langage de programmation Java.
  javaw.exe (interpréteur Java)
    Exécute les classes Java de la même façon que la commande java mais n'utilise pas de fenêtre de console.
  javaws.exe (Java Web Start)
    Permet le déploiement et la maintenance automatique des applications Java. Pour plus d'informations, voir Exécution de Web Start.
  jextract.exe (extracteur)
    Convertit un vidage système en un format commun pouvant être utilisé par jdmpview. Pour plus d'informations, voir jdmpview.
  keytool.exe (outil de gestion des clés et des certificats)
    Gère un magasin (une base de données) des clés privées et des chaînes de certificats X.509 associés qui authentifient les clés publiques correspondantes.
  kinit.exe
    Obtient et met en cache les tickets permettant d'attribuer les tickets Kerberos.
  klist.exe
    Affiche les entrées des caches de certificats locaux et de la table de clés.
  ktab.exe
    Gère les noms principaux et les clés de service stockés dans une table de clés locale.
  pack200.exe
    Transforme un fichier JAR en un fichier pack200 compressé à l'aide du compresseur Java gzip.
  policytool.exe (outil de création et de gestion de fichiers de règles)
    Crée et modifie les fichiers de configuration de règles externes qui définissent la règle de sécurité Java de votre installation.
  rmid.exe (démon système d'activation RMI)
    Démarre le démon système d'activation de façon à pouvoir enregistrer et activer les objets dans une machine virtuelle Java.
  rmiregistry.exe (registre d'objets distant Java)
    Crée et démarre un registre d'objets distant sur le port indiqué de l'hôte actuel.
  tnameserv.exe (service annuaire transitoire CORBA (Common Object Request Broker Architecture))
    Démarre le service annuaire transitoire CORBA.
  unpack200.exe
    Transforme un fichier comprimé produit par pack200 en un fichier JAR.

## Outils SDK et informations de référence

Une liste des outils et des informations de référence inclus dans le SDK standard.

Les outils suivants font partie du SDK et sont situés dans le répertoire C:\Program Files\IBM\Java60\bin :
  appletviewer.exe (Applet Viewer Java)
    Teste et exécute les applets en dehors d'un navigateur Web.
  apt.exe (Outils de traitement d'annotations)
    Cherche et exécute des processeurs d'annotations en fonction des annotations présentes dans l'ensemble des fichiers source indiqués en cours d'analyse.
  extcheck.exe (utilitaire Extcheck)
    Détecte les conflits de version entre un fichier jar cible et les fichiers jar d'extension déjà installés.
  HtmlConverter.exe (convertisseur HTML pour Java Plug-in)
    Convertit les pages HTML contenant des applets en un format pouvant utiliser le plug-in Java.
  idlj.exe (compilateur IDL vers Java)
    Génère des liaisons Java à partir d'un fichier IDL donné.
  ikeycmd.exe (utilitaire de ligne de commande iKeyman)
    Permet de gérer les clés, certificats et demandes de certificats à partir de la ligne de commande. Pour plus d'informations, reportez-vous au document Security Guide et au site http://www.ibm.com/developerworks/java/jdk/security.
  jar.exe (Outil d'archivage Java)
    Combine plusieurs fichiers en un seul fichier d'archive Java (JAR).
  jarsigner.exe (outil de signature et de vérification JAR)
    Génère des signatures pour les fichiers JAR et vérifie les signatures des fichiers JAR signés.
  java-rmi.exe (outil de transmission de demande HTTP vers CGI)
    Accepte les demandes RMI via HTTP et les transmet à un serveur RMI à l'écoute sur un port.
  javac.exe (compilateur Java)
    Compile les programmes écrits avec le langage de programmation Java en code intermédiaire (code Java compilé).
  javadoc.exe (Générateur de documentation Java)
    Génère des pages HTML de la documentation d'API à partir des fichiers source Java.
  javah.exe (générateur d'en-tête C et de fichier de raccord)
    Permet d'associer les méthodes natives au code Java.
  javap.exe (désassembleur de fichier classe)
    Désassemble les fichiers compilés et peut imprimer une représentation du code intermédiaire.
  javaw.exe (interpréteur Java)
    Exécute les classes Java de la même façon que la commande java mais n'utilise pas de fenêtre de console.
  javaws.exe (Java Web Start)
    Permet le déploiement et la maintenance automatique des applications Java. Pour plus d'informations, voir Exécution de Web Start.
  jconsole.exe (JConsole Monitoring and Management Tool)
    Contrôle les machines virtuelles locales ou distantes à l'aide de l'interface graphique. Compatible JMX.
  jdb.exe (débogeur Java)
    Aide le débogage des programmes Java.
  jdmpview.exe (composant de formatage de vidage multiplateformes)
    Analyse les vidages. Pour plus d'informations, consultez le document Diagnostics Guide.
  native2ascii.exe (convertisseur natif-ASCII)
    Convertit les fichiers à encodage natif en fichier ASCII contenant des caractères Latin-1 et/ou Unicode.
  rmic.exe (convertisseur de talon RMI Java)
    Génère des talons, des squelettes et des liens pour les objets distants. Prend en charge RMI-IIOP.
  schemagen.exe
    Crée un fichier schéma pour chaque espace de nom référencé dans vos classes Java.
  serialver.exe (commande de version de série)
    Renvoie l'UID de version de série d'une ou plusieurs classes dans un format approprié pour la copie dans une classe évolutive.
  wsgen.exe
    Génère des artefacts JAX-WS portables utilisés dans les services Web JAX-WS.
  wsimport.exe
    Génère des artefacts JAX-WS portables à partir d'un fichier WSDL.
  xjc.exe
    Compile des fichiers schéma XML.
Inclusion des fichiers
  En-têtes C pour programmes JNI.
Demos
  Le répertoire demo contient plusieurs sous-répertoires contenant des exemples de code source, de démonstrations, d'applications et d'applets que vous pouvez utiliser. |A partir de la version 6, l'exemple de démonstration RMI-IIOP n'est pas inclus dans le SDK.
copyright
  La mention de droits d'auteur pour le logiciel SDK for Windows.
Licence

  Le fichier de licence, C:\Program Files\IBM\Java60\docs\content\<locale>\LA_<locale>, contient le contrat de licence SDK du logiciel Windows (où <locale> correspond au nom de votre environnement, par exemple Fr_FR). Pour afficher ou imprimer le contrat de licence, ouvrez ce fichier dans un navigateur Web.

# Installation et configuration de SDK et Runtime Environment

Installez le SDK à l'aide de l'assistant d'installation ou du fichier compressé. Configurez le SDK à l'aide de variables d'environnement, d'options de ligne de commande et de fichiers de propriétés.

## Avant l'installation

Pour installer le SDK ou Runtime Environment, téléchargez le package d'installation correspondant. Veillez bien à télécharger tous les packages dans le même répertoire et assurez-vous qu'il y a suffisamment d'espace dans le répertoire temporaire.

Les packages et les noms de fichiers sont répertoriés dans Installation des packages ; ne les modifiez pas.

Avant d'entamer l'installation, assurez-vous que l'espace est suffisant dans le répertoire C:\WINDOWS\TEMP. La quantité d'espace temporaire dans le répertoire TEMP doit être comme suit :

- Package d'installation de SDK : 130 Mo
- Package d'installation de Runtime Environment : 85 Mo

Si vous n'avez pas assez d'espace temporaire, le programme d'installation émet une erreur et interrompt l'installation. Si l'espace temporaire est suffisant mais qu'un message d'erreur est émis, vérifiez que les packages ont été totalement téléchargés. Pour ce faire, comparez les tailles des fichiers de vos packages à celles affichées dans les pages Web d'où vous les avez téléchargés.

## Installation des packages

De nombreux packages peuvent être installés indépendamment, notamment le SDK, Runtime Environment, Javacomm, la documentation et les démos.

Les packages pouvant être installés sont les suivants :

- Package d'installation de SDK : ibm-java-sdk-60-win-i386.exe
- Package d'installation de Runtime Environment : ibm-java-jre-60-win-i386.exe
- Package d'installation de Runtime Environment (matériel IBM uniquement) : ibm-java-jre-60-ibmpc-win-i386.exe

Les autres packages sont fournis en tant que fichiers compressés :

- Package de Runtime Environment : ibm-java-jre-60-win-i386.zip
- Package de SDK : ibm-java-sdk-60-win-i386.zip
- Package de l'API Java Communications pour Windows : ibm-java-javacomm-60-win-i386.zip. Voir la section Installation de l'API Java Communications à partir d'un fichier compressé pour les instructions d'installation.
- Package de documentation : ibm-java-docs-60-win-i386.zip
- Package de démos : ibm-java-demos-60-win-i386.zip

Si vous installez le SDK ou Runtime Environment à partir du package compressé, vous ne pourrez pas utiliser Web Start ou le plug-in Java. L'onglet Update du panneau de configuration ne pourra également pas être utilisé.

### Installation sous surveillance (interactive)

Une installation sous surveillance du SDK et du JRE peut être effectuée sur un seul client.

1. Lancez ibm-java-sdk-60-win-i386.exe (pour le SDK) ou ibm-java-jre-60-win-i386.exe (pour Runtime Environment uniquement).
2. Suivez les instructions dans l'assistant d'installation.

   Runtime Environment est installé par défaut dans le répertoire C:\Program Files\IBM\Java60\jre.

   Si vous avez téléchargé le package d'installation de SDK, vous pouvez choisir les composants à installer :

   - les outils de développement SDK (par exemple, le compilateurJava),
   - l'environnement d'exécution,
   - le code source des bibliothèques de classes, utilisé par certains outils pour déboguer les applications.

   Dans l'assistant d'installation, vous disposez des options suivantes :

   - Standard - cette option installe les trois composants.
   - Compact - cette option installe uniquement Runtime Environment.
   - Personnalisé - cette option vous permet de choisir les composants à installer.

   Sous Windows Vista, il se peut qu'il y ait un temps d'attente après avoir sélectionné le langage d'installation.

   Si l'installation échoue et que le message d'erreur «Error applying transform» s'affiche, il se peut que les informations de configuration de Windows Installer soient corrompues.

### Installation de Runtime Environment comme machine virtuelle Java système

Lorsque vous installez Runtime Environment (comme élément du package d'installation de SDK ou à partir d'un package d'installation propre), vous devez préciser s'il doit être installé comme machine virtuelle Java système. Si tel est le cas, le programme d'installation copie les fichiers java.exe, javacpl.cpl, javaws.exe et javaw.exe dans le répertoire système Windows.

Si une version de java.exe ou javaw.exe existe déjà dans le répertoire système Windows, vous devez l'écraser avec celle en cours. L'installation de ces fichiers dans le répertoire système Windows fait de Runtime Environment la machine virtuelle Java par défaut pour le système. Par ailleurs, la clé de registre «Version» est définie de façon à correspondre à cette installation.

Remarque : L'installation de Runtime Environment comme machine virtuelle Java système copie uniquement java.exe et javaw.exe dans le répertoire système Windows. Les autres programmes (par exemple javac.exe ou appletviewer.exe) ne sont pas copiés.

### Installation automatisée

Une installation automatisée du SDK ou du JRE peut être effectuée sur plusieurs clients.

Pour une installation automatisée, vous devez d'abord effectuer une installation sous surveillance et créer un fichier de réponses (setup.iss) enregistrant les choix réalisés. Ce fichier de réponses doit être adapté aux ordinateurs sur lesquels vous pensez l'utiliser. Si besoin est, créez plusieurs fichiers de réponses pour installer les packages sur des ordinateurs de configuration distincte.

Pour créer un fichier de réponses lors du processus d'installation, entrez la commande suivante :

    ibm-java-sdk-60-win-i386 /r

ou

    ibm-java-jre-60-win-i386 /r

En fonction du produit Windows, un fichier de réponses (setup.iss) est créé dans le répertoire C:\Windows ou C:\Winnt.

Le message suivant peut apparaître lors d'une installation interactive :

    Another Java Runtime Environment is currently
    installed as the System JVM. Select Yes to
    overwrite this version or No to exit this
    installation.

Si ce message s'affiche, cliquez sur No et quittez l'installation. Accédez au répertoire système Windows et supprimez les deux fichiers suivants :

- java.exe
- javaw.exe

Après cela, relancez l'installation interactive à l'aide de la commande indiquée en début de section.

Sur le système où vous effectuerez l'installation automatisée, copiez le fichier de réponses setup.iss dans le répertoire C:\Windows. Après la copie, entrez à une invite de commande :

    ibm-java-sdk-60-win-i386 /s /f1c:\Windows\setup.iss /f2c:\setup.log
    ibm-java-jre-60-win-i386 /s /f1c:\Windows\setup.iss /f2c:\setup.log

Remarque :

1. Il n'y a pas d'espace après `/f1` ou `/f2`.
2. L'indicateur `/f1` désigne le nom et l'emplacement du fichier de réponses. L'indicateur `/f2` désigne le nom et l'emplacement du fichier journal.

Si l'installation aboutit, le fichier journal contient la chaîne `ResultCode=0`. Si tel n'est pas le cas, le fichier journal contient un code de résultat différent.

## Activation d'IBM Accessibility Bridge

IBM Accessibility Bridge est installé, mais désactivé par défaut. Pour activerIBM Accessibility Bridge, supprimez la mise en commentaire de l'entrée assistive_technologies du fichier Accessibility.properties.

Le fichier Accessibility.properties se trouvent dans le répertoire jre/lib. Supprimez le symbole # qui se trouve au début de la ligne :

    #assistive_technologies=JawBridge

Ce site Web offre plus d'informations sur les utilitaires d'accessibilité :

http://java.sun.com/products/jfc/accessibility.html

## Désactivation de la prise en charge de Java Accessibility

Vous pouvez désactiver la prise en charge de Java Accessibility pour améliorer les performances de chargement par la machine virtuelle d'applications Java ne prenant pas en charge la technologie d'assistance Java, notamment sur des liaisons réseau. Pour désactiver la prise en charge de Java Accessibility, définissez la variable d'environnement JAVA_ASSISTIVE à OFF.

Une technologie d'assistance telle que JawBridge n'est pas disponible si cette variable d'environnement a la valeur OFF, même si la technologie est activée dans le fichier Accessibility.properties.

## Informations pour les utilisateurs de langues européennes

Dans Windows, un processus possède deux pages de codes : ANSI (ou Windows) et OEM (ou DOS). La commande javaw utilise toujours la page de codes ANSI, sauf si la propriété système console.encoding est définie.

La fenêtre de commande emploie normalement la page de codes OEM. La sortie de la console Java utilise la même page de codes que la fenêtre de commande depuis laquelle Java a été démarré. Cependant, la commande javaw utilise toujours la page de codes ANSI. Pour indiquer la page de codes à utiliser dans la sortie de la console, entrez l'option -Dconsole.encoding avec la commande java ou le programme de lancement javaw. Par exemple, avec -Dconsole.encoding=Cp1252, la sortie de la console se trouve dans la page de codes Windows ANSI Latin1 (1252).

## Définition du PATH

Si vous modifiez la variable d'environnement PATH, tous les programmes de lancement Java du chemin seront remplacés.

La variable d'environnement PATH permet à Windows de localiser les programmes et utilitaires tels que javac, java et javadoc, à partir du répertoire de travail. Pour afficher la valeur actuelle de PATH, entrez ce qui suit à l'invite de commande :

    echo %PATH%

Pour ajouter les programmes de lancement Java au chemin d'accès, procédez comme suit :

1. Si vous avez installé le SDK ou Runtime Environment dans C:\Program Files\IBM\Java60\, ajoutez les répertoires suivants à la variable d'environnement PATH :
   - C:\Program Files\IBM\Java60\bin (SDK uniquement)
   - C:\Program Files\IBM\Java60\jre\bin (SDK et environnement d'exécution)
2. Fermez, puis rouvrez toutes les fenêtres d'invite de commande pour activer la nouvelle variable d'environnement PATH.

Une fois le chemin défini, vous pouvez exécuter un outil en entrant son nom à l'invite de commande à partir de n'importe quel répertoire. Par exemple, pour compiler le fichier Myfile.Java, entrez ce qui suit à l'invite de commande :

    javac Myfile.Java

## Définition du chemin d'accès aux classes

Le chemin d'accès aux classes indique aux outils SDK, tels que java, javac et javadoc, l'emplacement des bibliothèques de classes Java.

Vous devez définir le chemin d'accès aux classes de manière explicite uniquement dans les cas suivants :

- Vous avez besoin d'une bibliothèque ou d'un fichier de classes différent, que vous pouvez développer par exemple, et elle/il ne se trouve pas dans le répertoire de travail.
- Vous changez l'emplacement des répertoires bin et lib et ils n'ont plus le même répertoire parent.
- Vous prévoyez de développer ou d'exécuter des applications qui utilisent différents environnements d'exécution sur le même système.

Pour afficher la valeur actuelle de la variable d'environnement CLASSPATH, entrez la commande suivante à l'invite de commande :

      echo %CLASSPATH%

Si vous développez et exécutez des applications qui utilisent différents environnements d'exécution, y compris d'autres versions que vous avez installées séparément, vous devez définir CLASSPATH et PATH explicitement pour chaque application. Si vous exécutez plusieurs applications simultanément et utilisez des environnements d'exécution différents, chaque application doit être exécutée dans l'invite de commande qui lui est propre.

## Désinstallation

Utilisez l'application Ajout/Suppression de programmes de Windows pour désinstaller le SDK ou Runtime Environment.

Pour désinstaller le SDK, qu'il ait été installé automatiquement ou manuellement :

1. Cliquez deux fois sur Poste de travail sur le bureau Windows.
2. Cliquez deux fois sur Panneau de configuration.
3. Cliquez deux fois sur Ajout/Suppression de programmes.
4. Cliquez sur IBM 32-bit SDK for Java 2 v6 dans la liste, puis sur Modifier/Supprimer.
5. Cliquez sur OK.

Cette procédure supprime tous les modules installés avec le programme d'installation. Elle ne supprime pas le module de l'API Java Communications (voir Désinstallation de l'API Java Communications), ni les fichiers supplémentaires ayant été extraits de modules zip.

Remarque : Des messages d'avertissement peuvent s'afficher pour indiquer que tous les fichiers et/ou entrées de registre n'ont pas été supprimés. Ces avertissements sont émis parce que Windows suppose que certains fichiers sont encore en cours d'utilisation. Ces fichiers ou ces entrées de registre sont supprimés lors du redémarrage suivant.

Si vous ne disposez pas des droits requis pour désinstaller le SDK ou Runtime Environment, le nom de fichier court «Error1325.launchpad n'est pas valide». Pour désinstaller le SDK ou Runtime Environment, restaurez les droits appropriés.

Lorsque vous gérez plusieurs installations entre IBM 32-bit SDK pour Windows, v6 et les versions 1.3.1 ou antérieures, si vous désinstallez la version antérieure alors qu'une version v6 est encore installée sur le système, le programme de désinstallation de la version 1.3.1 supprime les clés et sous-clés de registre ci-dessous requises par la version v6, ce qui endommage l'installation de v6 :

- HKEY_LOCAL_MACHINE/Software/IBM/Java2 Runtime Environment
- HKEY_LOCAL_MACHINE/Software/IBM/Java Development Kit

Par conséquent, vous devez réinstaller v6 après avoir désinstallé la version 1.3.1. Cette limitation du programme de désinstallation a été corrigée pour la version 1.4.0 et les versions ultérieures.

# Exécution des applications Java

Les applications Java peuvent être démarrées à l'aide du programme de lancement java ou via l'interface JNI. Les paramètres sont transmis à une application Java à l'aide des arguments de ligne de commande, des variables d'environnement et des fichiers de propriétés.

## Les commandes java et javaw

Brève description des commandes java et javaw.

### Fonction

Les outils java et javaw lancent une application Java en démarrant Java Runtime Environment et en chargeant une classe déterminée.

La commande javaw est identique à java, sauf qu'elle n'est associée à aucune fenêtre de console. Utilisez la commande javaw lorsque vous ne souhaitez pas qu'une fenêtre d'invite de commande s'affiche. Si le lancement échoue, le programme de lancement de javaw affiche une boîte de dialogue contenant un message d'erreur.

### Utilisation

La machine virtuelle recherche la classe initiale (ainsi que les autres classes utilisées) à trois emplacements : le chemin d'accès à la classe d'amorce, les extensions installées et le chemin d'accès à la classe utilisateur. Les arguments ajoutés après le nom de classe ou le nom de fichier jar sont transmis à la fonction main.

Les commandes java et javaw ont la syntaxe suivante :

    java [ options ] <classe> [ arguments ... ]
    java [ options ] -jar <fichier.jar> [ arguments ... ]
    javaw [ options ] <classe> [ arguments ... ]
    javaw [ options ] -jar <fichier.jar> [ arguments ... ]

### Paramètres

[options]
  Options de ligne de commande à transmettre à l'environnement d'exécution.
<classe>
  Classe de démarrage. La classe doit contenir une méthode main().
<fichier.jar>
  Nom du fichier jar à appeler. Il est uniquement employé avec l'option -jar. Le fichier JAR nommé doit contenir les fichiers de ressources et de classes de l'application, avec la classe de démarrage indiquée par l'en-tête de manifeste de la classe principale.
[arguments ...]
  Arguments de ligne de commande à transmettre à la fonction main() de la classe de démarrage.

### Obtention des informations de version

Vous pouvez obtenir le numéro de compilation et de version IBM de votre installation Java à l'aide de l'option -version. |Vous pouvez également obtenir les informations de version de tous les fichiers jar figurant dans le chemin d'accès aux classes à l'aide de l'option -Xjarversion.

1. Ouvrez une invite de commande.
2. Entrez la commande suivante :

       java -version

   Les informations suivantes s'affichent :

       java version "1.6.0-internal" Java(TM) SE Runtime Environment (build 20070227_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20070226_11758 (JIT enabled) J9VM - 20070226_11758_lHdSMR JIT  - dev_20070215_1800 GC   - 20070208_AA)

   Les dates de création ainsi que les versions exactes seront modifiées.

| |

Vous pouvez également afficher les informations de version relatives à tous les fichiers jar figurant dans le chemin d'accès, le chemin d'accès de l'initialisation et le répertoire d'extensions en entrant la commande suivante :

|

    java -Xjarversion

|

Les informations suivantes s'affichent :

|

    ...
    |C:\Program Files\IBM\Java60\jre\lib\ext\ibmpkcs11impl.jar  VERSION: 1.0 build_20070125
    |C:\Program Files\IBM\Java60\jre\lib\ext\dtfjview.jar
    |C:\Program Files\IBM\Java60\jre\lib\ext\xmlencfw.jar  VERSION: 1.00, 20061011  LEVEL: -20061011
    |
    |...

|

Les informations disponibles varient selon les fichiers jar et sont obtenues à partir des propriétés Implementation-Version et Build-Level du manifeste du fichier jar.

### Indication des options Java et des propriétés système

Vous pouvez indiquer les options Java et les propriétés système sur la ligne de commande à l'aide d'un fichier d'options ou d'une variable d'environnement.

Ces méthodes d'indication des options Java sont répertoriées par ordre de priorité :

1. En indiquant l'option ou la propriété sur la ligne de commande. Par exemple :

       java -Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump MyJavaClass

2. En créant un fichier qui contient les options et en l'indiquant sur la ligne de commande en utilisant -Xoptionsfile=<file>.
3. En créant une variable d'environnement appelée IBM_JAVA_OPTIONS contenant les options. Par exemple :

       set IBM_JAVA_OPTIONS="-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump"

Les options les plus à droite sur la ligne de commande ont priorité sur celles de gauche ; par exemple, si vous indiquez :

    java -Xint -Xjit myClass

l'option -Xjit est prioritaire.

### Options standard

Définitions des options standard.

-agentlib:<libname>[=<options>]
  Charge la bibliothèque agent native <libname> ; par exemple-agentlib:hprof. Pour plus d'informations, spécifiez -agentlib:jdwp=help et -agentlib:hprof=help sur la ligne de commande.
-agentpath:libname[=<options>]
  Charge une bibliothèque agent native en utilisant le chemin d'accès complet.
-cp <répertoires et fichiers ZIP ou JAR séparés par ;>
  Définit le chemin de recherche pour les classes et ressources de l'application. Si -classpath et -cp ne sont pas utilisées et que la variable d'environnement CLASSPATH n'est pas définie, le chemin d'accès aux classes de l'utilisateur par défaut est le répertoire courant (.).
-classpath <répertoires et fichiers ZIP ou JAR séparés par ;>
  Définit le chemin de recherche pour les classes et ressources de l'application. Si -classpath et -cp ne sont pas utilisées et que la variable d'environnement CLASSPATH n'est pas définie, le chemin d'accès aux classes de l'utilisateur par défaut est le répertoire courant (.).
-D<nom de propriété>=<valeur>
  Définit une propriété système.
-help ou -?
  Affiche un message d'aide.
-javaagent:<jarpath>[=<options>]
  Charge l'agent de langage de programmation Java. Pour plus d'informations, voir la documentation de l'API java.lang.instrument.
-jre-restrict-search
  Inclut les JRE privés de l'utilisateur dans la recherche de version.
-no-jre-restrict-search
  Exclut les JRE privés de l'utilisateur dans la recherche de version.
-showversion
  Affiche la version du produit et continue la procédure.
-verbose:<option>
  Active le mode prolixe. Les options disponibles sont :
  class
    Consigne une entrée dans stderr pour chaque classe chargée.
  gc
    Consigne des informations relatives à la récupération de place en mode prolixe dans stderr. Utilisez -Xverbosegclog pour contrôler la sortie. Voir le document Diagnostics Guide pour en savoir plus.
  jni
    Consigne des informations dans stderr décrivant les services JNI appelés par l'application et la machine virtuelle JVM.
  sizes
    Consigne des informations décrivant les paramètres d'utilisation de la mémoire active dans stderr.
  stack
    Consigne des informations décrivant l'utilisation de pile Java et C pour chaque unité d'exécution dans stderr.
-version
  Imprime la version du produit.
-version:<valeur>
  Requiert l'exécution de la version indiquée, par exemple «1.5».
-X
  Affiche l'aide concernant les options non standard.

### Globalisation de la commande java

Les programmes de lancement java et javaw acceptent les arguments et les noms de classes avec n'importe quel caractère contenu dans le jeu de caractères de l'environnement local courant. Vous pouvez également utiliser des séquences d'échappement Java pour spécifier n'importe quel caractère Unicode dans le nom de classe et les arguments.

Pour ce faire, utilisez l'option de ligne de commande -Xargencoding.

-Xargencoding
  Utilisez le codage d'arguments. Pour indiquer un caractère Unicode, utilisez les séquences d'échappement au format `\u####`, où # est un caractère hexadécimal (de 0 à 9, de A à F).
-Xargencoding:utf8
  Utilisez le codage UTF8.
-Xargencoding:latin
  Utilisez le codage ISO8859_1.

Par exemple, pour indiquer une classe nommée HelloWorld en codage Unicode pour les deux majuscules, utilisez cette commande :

    java -Xargencoding '\u0048ello\u0057orld'

Les commandes java et javaw fournissent des messages traduits. Ces messages diffèrent suivant l'environnement local dans lequel Java est exécuté. Les descriptions détaillées des erreurs et les autres informations de débogage renvoyées par la commande java sont en anglais.

## Exécution automatique d'un fichier Java

Pour configurer l'exécution automatique d'une classe Java ou d'un fichier JAR à partir de l'explorateur Windows, utilisez l'option Outils -> Options des dossiers -> Type de fichier de l'Explorateur Windows.

Sinon, entrez à une invite de commande :

    assoc .class=javaclass
    ftype javaclass=C:\Program Files\IBM\Java60\jre\bin\java.exe''%l''%*'

Remarque :

1. `%l` correspond au chiffre 1 et non à la lettre l.
2. Si Java est installé dans un répertoire autre que C:\Program Files\IBM\Java60\, remplacez votre répertoire d'installation.

## Exécution des applications Java avec des technologies d'assistance natives

Sun fournit le composantJava Access Bridge pour permettre aux technologies d'assistance Windows natives (par exemple, des lecteurs d'écran) d'accéder au support Java Accessibility dans une application Java. Ces programmes d'assistance Windows natifs doivent avoir été écrits pour effectuer des appels à Java Access Bridge.

Le composant Java Access Bridge disponible auprès de Sun comprend un programme d'installation qui place cinq fichiers dans les répertoires appropriés : access-bridge.jar, jaccess.jar, accessibility.properties, JavaAccessBridge.dll et WindowsAccessBridge.dll. IBM fournit une copie du fichier jaccess.jar dans le répertoire approprié, en vue d'une utilisation avec JawBridge.

Si vous avez déjà activé IBM Accessibility Bridge (JawBridge), qui permet àWindows 2000 Magnifier de fonctionner avec les applications Swing, et que vous souhaitez activer JawBridge en même temps que Java Access Bridge, modifiez la ligne dans le fichier accessibility.properties, pour obtenir :

    assistive_technologies=com.sun.java.accessibility.AccessBridge,JawBridge

Mettez la ligne en commentaire en la faisant précéder du caractère dièse `#` pour désactiver les deux composants. Consultez ce site Web pour connaître les modalités de téléchargement du composant Java Access Bridge :

http://java.sun.com/products/jfc/accessibility.html.

## Compilateur JIT (Just-In-Time)

Le compilateur IBM JIT (Just-In-Time) génère dynamiquement le code machine pour les séquences de code intermédiaire fréquemment utilisées dans les applications Java et les applets en phase d'exécution. Le compilateur JIT v6 propose de nouvelles optimisations suite à la recherche du compilateur, améliore les optimisations implémentées dans les versions précédentes du compilateur JIT et fournit une meilleure exploitation matérielle.

IBM SDK et Runtime Environment incluent le JIT, qui est activé par défaut dans les applications utilisateur ainsi que les outils SDK. Il n'est généralement pas nécessaire d'appeler explicitement le compilateur JIT. La compilation du code intermédiaire Java en code machine se produit de manière transparente. Vous pouvez désactiver le JIT pour isoler un incident. Si un incident survient lors de l'exécution d'une application Java ou d'une applet, vous pouvez désactiver le JIT afin d'isoler l'incident. La désactivation du compilateur JIT est uniquement une mesure temporaire, sa présence étant requise pour optimiser les performances.

Pour plus d'informations sur le JIT, voir document Diagnostics Guide.

### Désactivation du JIT

Le JIT peut être désactivé de différentes manières. Les options de ligne de commande remplacent la variable d'environnement JAVA_COMPILER.

La désactivation du compilateur JIT est une mesure temporaire permettant d'isoler des incidents lors du débogage des applications Java.

- Attribuez la valeur `NONE` ou une chaîne vide à la variable d'environnement JAVA_COMPILER avant l'exécution de l'application java. A l'invite de commande à partir de laquelle l'application est exécutée, entrez :

      set JAVA_COMPILER=NONE

  Vous pouvez également définir de manière permanente JAVA_COMPILER en utilisant l'interface utilisateur graphique. Ouvrez le Panneau de configuration, sélectionnez Système et dans l'onglet Avancé, sélectionnez Variables d'environnement.
- Utilisez l'option -D sur la ligne de commande de la JVM pour attribuer la valeur `NONE` ou une chaîne vide à la propriété java.compiler. A l'invite de commande, entrez :

      java -Djava.compiler=NONE <classe>

- Utilisez l'option -Xint sur la ligne de commande de la JVM. A l'invite de commande, entrez :

      java -Xint <
      class>

### Activation du JIT

Le JIT est activé par défaut. Vous pouvez activer explicitement le JIT de plusieurs façons. Les options de ligne de commande remplacent la variable d'environnement JAVA_COMPILER.

- Attribuez la valeur `jitc` à la variable d'environnement JAVA_COMPILER avant l'exécution de l'application Java. A l'invite de commande à partir de laquelle l'application est exécutée, entrez :

      set JAVA_COMPILER=jitc

  Vous pouvez également définir de manière permanente JAVA_COMPILER en utilisant l'interface utilisateur graphique. Ouvrez le Panneau de configuration, sélectionnez Système et dans l'onglet Avancé, sélectionnez Variables d'environnement. Si la valeur chaîne vide est attribuée à la variable d'environnement JAVA_COMPILER, le JIT reste désactivé. Pour désactiver la variable d'environnement, à l'invite de commande, entrez :

      set JAVA_COMPILER=

- Utilisez l'option -D sur la ligne de commande de la JVM pour attribuer la valeur `jitc` à la propriété java.compiler. A partir d'une invite de commande, entrez :

      java -Djava.compiler=jitc <classe>

- Utilisez l'option -Xjit sur la ligne de commande de la JVM. Ne spécifiez pas l'option -Xint en même temps. A partir d'une invite de commande, entrez :

      java -Xjit <classe>

### Déterminer si le JIT est activé

Vous pouvez déterminer l'état du JIT à l'aide de l'option -version.

Exécutez le programme de lancement java à l'aide de l'option -version. A l'invite de commande, entrez :

    java -version

Si le compilateur JIT est inactif, le message qui s'affiche contient ce qui suit :

    (JIT disabled)

Si le compilateur JIT est actif, le message qui s'affiche contient ce qui suit :

    (JIT enabled)

Pour plus d'informations sur le JIT, voir le document Diagnostics Guide.

## Définition des règles de récupération de place

Le récupérateur de place gère la mémoire utilisée par Java et par les applications exécutées dans la machine virtuelle.

Lorsque le récupérateur de place reçoit une demande de stockage, la mémoire inutilisée dans le segment de mémoire est mise de côté (on parle alors d'"allocation"). Le récupérateur de place vérifie également les zones de mémoire qui ne sont plus utilisées et les libère pour qu'elles puissent être réutilisées. Il s'agit de la "récupération".

La phase de récupération peut être déclenchée par un défaut d'allocation de mémoire, ce qui peut se produire lorsqu'il ne reste plus d'espace pour une demande de stockage ou par un appel System.gc() explicite.

La récupération de place peut avoir un impact considérable sur les performances des applications. Pour cette raison, la machine virtuelle IBM fournit différentes méthodes d'optimisation de la façon dont cette récupération est effectuée afin de limiter potentiellement l'incidence sur votre application.

Pour plus d'informations sur la récupération de place, reportez-vous au document Diagnostics Guide.

### Options de récupération de place

L'option -Xgcpolicy contrôle le comportement du récupérateur de place. Elle établit des compromis entre le débit de l'application et l'ensemble du système et les délais d'interruption nécessités par la récupération de place.

Le format et les valeurs de cette option sont les suivants :

-Xgcpolicy:optthruput
  (Valeur par défaut et recommandée.) Cette option offre un débit très élevé aux applications, mais au détriment d'interruptions occasionnelles.
-Xgcpolicy:optavgpause
  Réduit la durée des interruptions générées par le processus de récupération de place ainsi que l'impact de l'augmentation de taille du segment sur la durée des interruptions. Utilisez l'option optavgpause si le segment de votre configuration est très important.
-Xgcpolicy:gencon
  Demande l'utilisation combinée de récupérations de place concurrentes et générationnelles afin de réduire le temps des pauses dans ce processus.

### Délai d'interruption

Lorsque l'espace disponible dans le segment ne permet pas à une application de créer un objet, la fonction de récupération de place identifie les objets non référencés et les supprime, ce qui rétablit l'état du segment et permet de répondre rapidement aux demandes d'affectation de ressources actuelles et ultérieures.

Des cycles de récupération de place de ce type génèrent parfois des interruptions inattendues dans l'exécution du code d'application. A mesure que la taille et la complexité des applications augmentent, la taille des segments s'accroît et les interruptions causées par le processus de récupération de place deviennent plus longues et plus gênantes.

La valeur de récupération de place par défaut, -Xgcpolicy:optthruput, offre un débit très élevé aux applications, au prix d'interruptions fréquentes, d'une durée comprise entre quelques millisecondes et plusieurs secondes, selon la taille du segment et la quantité de place à récupérer.

### Réduction du délai d'interruption

La machine virtuelle JVM utilise deux techniques pour réduire les délais d'interruption : la récupération de place simultanée et la récupération de place de génération.

L'option de ligne de commande -Xgcpolicy:optavgpause spécifie l'utilisation d'une récupération de place simultanée pour réduire de façon significative le temps passé à la récupération de place. La récupération de place simultanée réduit les délais d'interruption en effectuant des opérations de récupération simultanément avec l'exécution normale du programme afin de minimiser les perturbations provoquées par la collecte du segment de mémoire. L'option -Xgcpolicy:optavgpause réduit également l'impact de l'augmentation de la taille du segment sur la durée des interruptions pour récupération de place. L'option -Xgcpolicy:optavgpause est particulièrement utile pour les configurations présentant de grandes tailles de segment. Ainsi, vous noterez une certaine baisse du débit de vos applications.

Lors de la récupération de place simultanée, un laps de temps considérable est perdu à identifier les objets de longue durée qui ne peuvent alors pas être collectés. Si la récupération de place ne se concentre que sur les objets susceptibles d'être recyclables, vous pouvez réduire encore davantage les délais d'interruption de certaines applications. La récupération de place de génération parvient à cela en divisant le segment en deux "générations" : les zones "nursery" (nouvelle génération) et "tenure" (génération titulaire). Les objets sont placés dans l'une ou l'autre de ces zones suivant leur ancienneté. La zone "nursery" est la plus petite des deux et contient les objets les plus récents alors que la zone "tenure" est plus importante et contient les objets plus anciens. Les objets sont d'abord affectés à la zone "nursery" ; s'ils survivent assez longtemps, ils finissent par passer dans la zone "tenure".

La récupération de place de génération dépend d'une courte durée de la plupart des objets. Cette technique réduit les délais d'interruption en s'efforçant de récupérer en priorité de l'espace disque dans la zone "nursery" car c'est dans cette dernière que l'espace est le plus facilement recyclable. Alors que la récupération intégrale du segment est plus occasionnelle mais plus lente, la récupération des éléments de la zone "nursery" est plus fréquente et, si la taille de cette zone est assez petite, les délais d'interruption sont comparativement plus courts. Il existe toutefois un inconvénient à cette technique qui est, qu'avec le temps, la zone "tenure" peut être saturée si trop d'objets durent trop longtemps. Pour minimiser le délai d'interruption lorsque ce cas survient, ayez recours à une combinaison des deux techniques. L'option -Xgcpolicy:gencon spécifie l'utilisation combinée de la récupération de place simultanée et de la récupération de place de génération pour limiter au minimum les temps d'interruption pour récupération de place.

### Environnements à segments très saturés

Si le segment Java est proche de la saturation et que la place à récupérer est très limitée, les demandes de nouveaux objets ne sont pas satisfaites rapidement car aucun espace n'est disponible immédiatement.

Si le segment est utilisé au maximum de sa capacité ou presque, une baisse de performance se produit au niveau des applications, indépendamment des options de récupération de place utilisées. Si des demandes d'espace supplémentaire sont effectuées, il se peut que l'application reçoive une exception OutOfMemoryError, qui entraîne l'arrêt de la JVM si cette dernière n'est pas interceptée et traitée. A ce stade, la machine virtuelle génère un fichier Javadump utilisé pendant les diagnostics. Dans ces cas de figure, il est recommandé d'augmenter la taille du segment à l'aide de l'option -Xmx ou de réduire le nombre d'objets utilisés.

Pour en savoir plus, voir le document Diagnostics Guide.

## Prise en charge du symbole Euro

IBM SDK et Runtime Environment définissent l'euro comme devise par défaut pour les pays de l'Union Monétaire Européenne (UME) pour les dates ultérieures au 31 décembre 2001. A partir du 1 janvier 2008, Chypre et Malte utiliseront également l'euro comme devise par défaut.

Pour utiliser l'ancienne devise nationale, entrez -Duser.variant=PREEURO sur la ligne de commande Java.

Si vous utilisez les paramètres nationaux du Royaume-Uni, du Danemark ou de la Suède et souhaitez utiliser l'euro, entrez -Duser.variant=EURO sur la ligne de commande Java.

| | |

## Utilisation des méthodes de saisie indiennes et thaïs

|
|

A partir de la version 6, les méthodes de saisie indiennes et thaïs ne sont pas disponibles par défaut. Vous devez inclure manuellement les fichiers jar de la méthode de saisie dans le chemin d'accès aux extensions Java pour pouvoir utiliser les méthodes de saisie indiennes et thaïs.

|

Dans la version 5.0, les fichiers jar de la méthode de saisie sont inclus dans le répertoire jre\lib\ext et sont automatiquement chargés par la machine virtuelle. Dans la version 6, les fichiers jar de la méthode de saisie sont inclus dans le répertoire jre\lib\im et doivent être ajoutés manuellement au chemin d'accès aux extensions Java pour permettre l'utilisation des méthodes de saisie indiennes et thaïs. Pour ce faire, utilisez l'une des méthodes suivantes :

|

|
- Copiez les fichiers indicim.jar et thaiim.jar du répertoire jre\lib\im vers le jre\lib\ext.
|
- Ajoutez le répertoire jre\lib\im à la propriété système du répertoire d'extension. Utilisez l'option de ligne de commande suivante : | |

      java -Djava.ext.dirs=C:\Program Files\IBM\Java60\jre\lib\ext;C:\Program Files\IBM\Java60\jre\lib\im <classe>

|

|

Si vous avez installé le SDK ouRuntime Environment dans un répertoire différent, |remplacez C:\Program Files\IBM\Java60\ par le répertoire dans lequel vous avez installé le SDK ou Runtime Environment.

# Utilisation de SDK pour développer des applications Java

Le SDK pour Windows contient plusieurs bibliothèques et outils requis pour le développement d'applications Java.

Voir Outils SDK et informations de référence pour en savoir plus sur les outils disponibles.

| | |

## Utilisation de XML

|
|

IBM SDK contient les analyseurs syntaxiques XML4J et |XL XP-J, le compilateur XL TXE-J 1.0 XSLT ainsi que l'interpréteur XSLT4J XSLT. |Ces outils vous permettent d'analyser, de valider, transformer et sérialiser des documents XML indépendamment de toute implémentation de traitement XML donnée.

|

|

Utilisez les localisateurs de fabrique pour rechercher les implémentations de classes Factory abstraites, comme décrit dans la section Sélection d'un processeur XML. |A l'aide des localisateurs de fabrique, vous pouvez sélectionner une bibliothèque XML différente sans modifier le code Java.

|

| |

### Bibliothèques XML disponibles

|

IBM SDK for Java comporte les bibliothèques XML répertoriées ci-dessous.

|

|
XML4J 4.5
|
  |

  XML4J est un analyseur syntaxique prenant en charge les normes suivantes : |

  |
  |
  - XML 1.0 (Quatrième édition)
  |
  - Espaces de nom dans XML 1.0 (Deuxième édition)
  |
  - XML 1.1 (Deuxième édition)
  |
  - Espaces de nom dans XML 1.1 (Deuxième édition)
  |
  - Schéma W3C XML version 1.0 (Deuxième édition)
  |
  - XInclude 1.0 (Deuxième édition)
  |
  - Catalogues OASIS XML version 1.0
  |
  - SAX 2.0.2
  |
  - DOM Level 3 Core, Load and Save
  |
  - DOM Level 2 Core, Events, Traversal and Range
  |
  - JAXP 1.4
  | |

  XML4J 4.5 est basé sur Apache Xerces-J 2.9.0. Voir http://xerces.apache.org/xerces2-j/ pour plus d'informations.

  |
|
XL XP-J 1.1
|
  |

  XL XP-J 1.1 est un analyseur syntaxique non-validant haute performance prenant en charge StAX 1.0 (JSR 173) ; une API bidirectionnelle utilisée pour l'analyse d'extraction et la sérialisation du flux des documents XML 1.0 et XML 1.1. Voir la section Informations de référence relatives à XL XP-J pour plus d'informations sur les éléments pris en charge par XL XP-J 1.1.

  |
|
XL TXE-J 1.0.1 version bêta
|
  |

  La version 5.0 de IBM SDK for Java contenait l'interpréteur et le compilateur XSLT4J. |L'interpréteur XSLT4J était utilisé par défaut.

  | |

  La version 6 deIBM SDK for Java comporte XL TXE-J. XL TXE-J contient l'interpréteur XSLT4J version 2.7.8 ainsi qu'un nouveau compilateur XSLT. |Le nouveau compilateur est utilisé par défaut. Le compilateur XSLT4J n'est plus compris dans IBM SDK |for Java, voir Migration vers le compilateur XL-TXE-J pour plus d'informations sur la migration vers XL TXE-J.

  | |

  XL TXE-J prend en charge les normes suivantes : |

  |
  |
  - XSLT 1.0
  |
  - XPath 1.0
  |
  - JAXP 1.4
  |
|

|

| |

### Sélection d'un processeur XML

|

La sélection d'un processeur XML est effectuée à l'aide de fournisseurs de services. Lors de l'utilisation d'un localisateur de fabrique, Java examine les éléments suivants afin de déterminer le fournisseur de services à utiliser : |

|

|
1. La propriété système ayant le même nom que le fournisseur de services.
|
2. Pour XMLEventFactory, XMLInputFactory et |XMLOutputFactory uniquement. La valeur du fournisseur de services du fichier C:\Program Files\IBM\Java60\jre\lib\stax.properties.
|
3. Pour les autres fabriques. La valeur du fournisseur de services du fichier C:\Program Files\IBM\Java60\jre\lib\jaxp.properties.
|
4. Le contenu du fichier META-INF\services\<service.provider>
|
5. Le fournisseur de services par défaut.

|

Les fournisseurs de services suivants contrôlent les bibliothèques de traitement XML utilisées par Java : |

|

|
javax.xml.parsers.SAXParserFactory
|
  Sélectionne l'analyseur syntaxique SAX. org.apache.xerces.jaxp.SAXParserFactoryImpl de la bibliothèque XML4J est utilisé par défaut. |
|
javax.xml.parsers.DocumentBuilderFactory
|
  Sélectionne le générateur de documents. org.apache.xerces.jaxp.DocumentBuilderFactoryImpl de la bibliothèque XML4J est utilisé par défaut. |
|
javax.xml.datatype.DatatypeFactory
|
  Sélectionne la fabrique datatype. org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl de la bibliothèque XML4J est utilisé par défaut. |
|
javax.xml.stream.XMLEventFactory
|
  Sélectionne la fabrique d'événements StAX. com.ibm.xml.xlxp.api.stax.XMLEventFactoryImpl de la bibliothèque XL XP-J est utilisé par défaut. |
|
javax.xml.stream.XMLInputFactory
|
  Sélectionne l'analyseur syntaxique StAX. com.ibm.xml.xlxp.api.stax.XMLInputFactoryImpl de la bibliothèque XL XP-J est utilisé par défaut. |
|
javax.xml.stream.XMLOutputFactory
|
  Sélectionne le sérialiseur StAX. com.ibm.xml.xlxp.api.stax.XMLOutputFactoryImpl de la bibliothèque XL XP-J est utilisé par défaut. |
|
javax.xml.transform.TransformerFactory
|
  Sélectionne le processeur XSLT. Les valeurs admises sont : | |
  |
  com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl
  |
    Utilise le compilateur XL TXE-J. Il s'agit du compilateur par défaut. |
  |
  org.apache.xalan.processor.TransformerFactoryImpl
  |
    Utilise l'interpréteur XSLT4J. |
  |
  |
|
javax.xml.validation.SchemaFactory:http://www.w3.org/2001/XMLSchema
|
  Sélectionne la fabrique de schémas du langage de schéma W3C XML. org.apache.xerces.jaxp.validation.XMLSchemaFactory de la bibliothèque XML4J est utilisé par défaut. |
|
javax.xml.xpath.XPathFactory
|
  Sélectionne le processeur XPath. org.apache.xpath.jaxp.XPathFactoryImpl de la bibliothèque XSLT4J est utilisé par défaut. |
|

| |

### Migration vers le compilateur XL-TXE-J

|
|

L'interpréteur XSLT4J est à présent remplacé par le compilateur XL TXE-J comme processeur XSLT par défaut. Procédez comme suit afin que votre application puisse utiliser la nouvelle bibliothèque.

|

|

Le compilateur XL TXE-J est plus rapide que l'interpréteur XSLT4J lorsqu'une seule transformation est appliquée plusieurs fois. Si vous exécutez une transformation plusieurs fois, la vitesse d'exécution du compilateur XL TXE-J est inférieure à celle de l'interpréteur XSLT4J en raison du temps système de compilation et d'optimisation.

|

Pour continuer à utiliser l'interpréteur XSLT4J comme processeur XSLT, attribuez la valeur org.apache.xalan.processor.TransformerFactoryImpl au fournisseur de services javax.xml.transform.TransformerFactory.

|

Procédez comme suit pour migrer vers le compilateur XL-TXE-J :

|

|
1. Paramétrez le fournisseur de services javax.xml.transform.TransformerFactory à l'aide de com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl.
|
2. Régénérez les fichiers de classes créés par le compilateur XSLT4J. XL TXE-J ne peut pas exécuter les fichiers de classes générés par le compilateur XSLT4J.
|
3. Il se peut que certaines méthodes générées par le compilateur excèdent la limite de taille de la méthode JVM. Dans ce cas, le compilateur tente de les diviser en méthodes plus petites. | |
   |
   - Si tel est le cas, le message d'avertissement suivant s'affiche : «Certaines fonctions générées excèdent la limite de taille de la méthode JVM et ont été automatiquement divisées en fonctions plus petites. Vous pouvez obtenir de meilleures performances en divisant manuellement les grands modèles en modèles plus petits, en utilisant l'option 'splitlimit' de la commande Process ou Compile, |ou en définissant l'attribut de fabrique du transformateur 'http://www.ibm.com/xmlns/prod/xltxe-j/split-limit'.». Les classes compilées peuvent être utilisées. Toutefois, vous pouvez optimiser les performances en contrôlant la limite de partage manuellement.
   |
   - Si le compilateur ne parvient pas à diviser la méthode, l'une des exceptions suivantes est générée : «com.ibm.xtq.bcel.generic.ClassGenException: |Branch target offset too large for short» ou «bytecode array size > 65535 |at offset=#####». Définissez manuellement une limite de partage ou utilisez une limite de partage inférieure.
   Pour définir la limite de partage, utilisez l'option -SPLITLIMIT de la commande Process ou Compile ou l'attribut de fabrique du transformateur http://www.ibm.com/xmlns/prod/xltxe-j/split-limit. La limite de partage doit être comprise entre 100 et 2000. Lorsque vous définissez la limite de partage manuellement, utilisez la limite de partage la plus élevée afin d'obtenir de meilleurs résultats.
|
4. Il se peut que XL TXE-J requiert plus de mémoire que le compilateur XSLT4J. Si votre système manque de mémoire ou que l'exécution du système est lente, augmentez la taille du segment de mémoire à l'aide de l'option -Xmx.
|
5. Faites migrer votre application pour utiliser les nouvelles clés d'attribut. Les clés d'attribut de l'ancienne fabrique de transformateur sont obsolètes. Elles seront acceptées, mais un message d'avertissement s'affichera. | | |

   Tableau 1. Modifications des clés d'attribut du compilateur XSL4J au compilateur XL TXE-J
   |Attribut du compilateur XSL4J | | Attribut du compilateur XL TXE-J |
   --- | ---
   |translet-name | | http://www.ibm.com/xmlns/prod/xltxe-j/translet-name |
   |destination-directory | | http://www.ibm.com/xmlns/prod/xltxe-j/destination-directory |
   |package-name | | http://www.ibm.com/xmlns/prod/xltxe-j/package-name |
   |jar-name | | http://www.ibm.com/xmlns/prod/xltxe-j/jar-name |
   |generate-translet | | http://www.ibm.com/xmlns/prod/xltxe-j/generate-translet |
   |auto-translet | | http://www.ibm.com/xmlns/prod/xltxe-j/auto-translet |
   |use-classpath | | http://www.ibm.com/xmlns/prod/xltxe-j/use-classpath |
   |debug | | http://www.ibm.com/xmlns/prod/xltxe-j/debug |
   |indent-number | | http://www.ibm.com/xmlns/prod/xltxe-j/indent-number |
   |enable-inlining | | Obsolète dans le nouveau compilateur |
   |

|
6. Facultatif : Pour obtenir des performances optimales, assurez-vous de ne pas recompiler les transformations XSLT pouvant être réutilisées. Vous pouvez réutiliser les transformations compilées à l'aide d'une des méthodes suivantes : | |
   |
   - Si votre feuille de style n'est pas modifiée au moment de l'exécution, compilez-la comme élément de votre processus de construction et placez les classes compilées dans votre chemin de classe. |Compilez la feuille de style à l'aide de la commande org.apache.xalan.xsltc.Compile et attribuez la valeur `true` à l'attribut de fabrique du transformateur http://www.ibm.com/xmlns/prod/xltxe-j/use-classpath afin de charger les classes à partir du chemin d'accès aux classes.
   |
   - Si votre application requiert la même feuille de style pour plusieurs exécutions, attribuez la valeur `true` à l'attribut de fabrique du transformateur http://www.ibm.com/xmlns/prod/xltxe-j/auto-translet pour enregistrer automatiquement la feuille de style sur disque à des fins de réutilisation. Le compilateur utilise une feuille de style compilée si celle-ci est disponible. Si tel n'est pas le cas ou si la feuille de style n'est pas actualisée, il la compile. Utilisez l'attribut de fabrique du transformateur http://www.ibm.com/xmlns/prod/xltxe-j/destination-directory pour définir le répertoire utilisé pour le stockage des feuilles de style compilées. |Par défaut, les feuilles de style compilées sont stockées dans le même répertoire que celui de la feuille de style.
   |
   - Si vous possédez une application à exécution longue qui utilise la même feuille de style plusieurs fois, utilisez la fabrique du transformateur pour compiler la feuille de style et créer un objet Templates. Vous pouvez créer des objets Transformer à l'aide de l'objet Templates sans recompiler la feuille de style. |Les objets Transformer peuvent également être réutilisés mais ne peuvent pas être utilisés simultanément par plusieurs unités d'exécution.

| |

### Informations de référence relatives à XML

|
|

Les bibliothèques XL XP-J et XL TXE-J XML sont de nouvelles options de la version 6 du SDK. Ces informations de référence décrivent les fonctions prises en charge par ces bibliothèques.

| | |

#### Informations de référence relatives à XL XP-J

|
|

XL XP-J 1.1 est un analyseur syntaxique non-validant haute performance prenant en charge StAX 1.0 (JSR 173) ; une API bidirectionnelle utilisée pour l'analyse d'extraction et la sérialisation du flux des documents XML 1.0 et XML 1.1.

|

| |

##### Fonctions non prises en charge

|

Les options StAX facultatives ci-après ne sont pas prises en charge par XL XP-J : |

|

|
- Validation du paramètre DTD lors de l'utilisation de XMLStreamReader ou XMLEventReader. |L'analyseur syntaxique XL XP-J est non-validant.
|
- Informations relatives à l'emplacement lors de l'utilisation deXMLStreamReader ou XMLEventReader. |L'interrogation des méthodes getCharacterOffset(), getColumnNumber() et getLineNumber() sur un objet Location renvoie la valeur -1, indépendamment de l'emplacement actuel de l'analyseur syntaxique dans le document.

|

| |

##### Référence XMLInputFactory

|

Les propriétés suivantes sont prises en charge par l'implémentation javax.xml.stream.XMLInputFactory, comme décrit dans la documentation Java |XMLInputFactory .

| |

Tableau 2.
|Nom de la propriété | | Pris en charge |
--- | ---
|javax.xml.stream.isValidating | | Non. Le scanner XL XP-J ne prend pas en charge la validation. |
|javax.xml.stream.isNamespaceAware | | Oui (prend en charge les valeurs true et false). Pour les propriétés XMLStreamReader créées à partir de DOMSource, le traitement des espaces de nom dépend des méthodes utilisées pour créer l'arborescence DOM. De plus, cette valeur n'a aucune incidence. |
|javax.xml.stream.isCoalescing | | Oui |
|javax.xml.stream.isReplacingEntityReferences | | Oui. Pour les propriétés XMLStreamReader créées à partir de DOMSource, la définition de ce paramètre n'a aucune incidence si des entités ont déjà été remplacées dans l'arborescence DOM. |
|javax.xml.stream.isSupportingExternalEntities | | Oui |
|javax.xml.stream.supportDTD | | Non. Les paramètres DTD sont toujours pris en charge. L'attribution de la valeur false n'a aucune incidence. |
|javax.xml.stream.reporter | | Oui |
|javax.xml.stream.resolver | | Oui |
|

|

XL XP-J prend également en charge la méthode facultative createXMLStreamReader(javax.xml.transform.Source), |permettant ainsi la création de programmes de lecture StAX à partir de sources DOM et SAX.

|

| |

##### Référence XMLStreamReader

|

Les propriétés suivantes sont prises en charge par l'implémentation javax.xml.stream.XMLStreamReader, |comme décrit dans la documentation Java XMLStreamReader.

| |

Tableau 3.
|Nom de la propriété | | Pris en charge |
--- | ---
|javax.xml.stream.entities | | Oui |
|javax.xml.stream.notations | | Oui |
|

|

XL XP-J prend également en charge la propriété javax.xml.stream.isInterning, qui renvoie une valeur booléenne indiquant si les noms XML et les URI espace de nom renvoyés par les appels d'API ont été pris en considération par l'analyseur syntaxique.

|

| |

##### Référence XMLOutputFactory

|

Les propriétés suivantes sont prises en charge par l'implémentation javax.xml.stream.XMLOutputFactory, |comme décrit dans la documentation JavaXMLOutputFactory.

| |

Tableau 4.
|Nom de la propriété | | Pris en charge |
--- | ---
|javax.xml.stream.isRepairingNamespaces | | Oui |
|

|

| |

##### Référence XMLStreamWriter

|

Les propriétés suivantes sont prises en charge par l'implémentation javax.xml.stream.XMLStreamWriter, |comme décrit dans la documentation JavaXMLStreamWriter.

| |

Tableau 5.
|Nom de la propriété | | Pris en charge |
--- | ---
|javax.xml.stream.isRepairingNamespaces | | Oui |
|

|

Les propriétés des objets XMLStreamWriter sont en lecture seule.

| | |

#### Informations de référence relatives à XL TXE-J

|
|

XL TXE-J est une bibliothèque XSLT contenant l'interpréteur XSLT4J 2.7.8 et un compilateur XSLT.

|

| |

##### Tableau de comparaison de fonctions

| |

Tableau 6. Comparaison des fonctions de l'interpréteur XSLT4J, du compilateur XSLT4J et du compilateur XL TXE-J.
|Fonction | | Interpréteur XSLT4J (inclus) | | Compilateur XSLT4J (non inclus) | | Compilateur XL TXE-J (inclus) |
--- | --- | --- | ---
|Fonction http://javax.xml.transform.stream.StreamSource/feature | | Oui | | Oui | | Oui |
|Fonction http://javax.xml.transform.stream.StreamResult/feature | | Oui | | Oui | | Oui |
|Fonction http://javax.xml.transform.dom.DOMSource/feature | | Oui | | Oui | | Oui |
|Fonction http://javax.xml.transform.dom.DOMResult/feature | | Oui | | Oui | | Oui |
|Fonction http://javax.xml.transform.sax.SAXSource/feature | | Oui | | Oui | | Oui |
|Fonction http://javax.xml.transform.sax.SAXResult/feature | | Oui | | Oui | | Oui |
|Fonction http://javax.xml.transform.stax.StAXSource/feature | | Oui | | Non | | Oui |
|Fonction http://javax.xml.transform.stax.StAXResult/feature | | Oui | | Non | | Oui |
|Fonction http://javax.xml.transform.sax.SAXTransformerFactory/feature | | Oui | | Oui | | Oui |
|Fonction http://javax.xml.transform.sax.SAXTransformerFactory/feature/xmlfilter | | Oui | | Oui | | Oui |
|Fonction http://javax.xml.XMLConstants/feature/secure-processing | | Oui | | Oui | | Oui |
|Attribut http://xml.apache.org/xalan/features/incremental | | Oui | | Non | | Non |
|Attribut http://xml.apache.org/xalan/features/optimize | | Oui | | Non | | Non |
|Attribut http://xml.apache.org/xalan/properties/source-location | | Oui | | Non | | Non |
|Attribut translet-name | | N/A | | Oui | | Oui (avec un nom nouveau) |
|Attribut destination-directory | | N/A | | Oui | | Oui (avec un nom nouveau) |
|Attribut package-name | | N/A | | Oui | | Oui (avec un nom nouveau) |
|Attribut jar-name | | N/A | | Oui | | Oui (avec un nom nouveau) |
|Attribut generate-translet | | N/A | | Oui | | Oui (avec un nom nouveau) |
|Attribut auto-translet | | N/A | | Oui | | Oui (avec un nom nouveau) |
|Attribut use-classpath | | N/A | | Oui | | Oui (avec un nom nouveau) |
|Attribut enable-inlining | | Non | | Oui | | Non (obsolète pour TL TXE-J) |
|Attribut indent-number | | Non | | Oui | | Oui (avec un nom nouveau) |
|Attribut debug | | Non | | Oui | | Oui (avec un nom nouveau) |
|Extensions Java | | Oui | | Oui (syntaxe abrégée uniquement, les constructions xalan:component/xalan:script |ne sont pas prises en charge) |
|Extensions JavaScript | | Oui | | Non | | Non |
|Eléments d'extension | | Oui | | Non | | Non |
|Fonctions d'extension EXSLT | | Oui | | Oui (excluant les extensions dynamiques) | | Oui (excluant les extensions dynamiques) |
|Extension Redirect | | Oui | | Oui (redirect:open et redirect:close sont exclus) | | Oui |
|Extension output | | Non | | Oui | | Oui |
|Extension nodeset | | Oui | | Oui | | Oui |
|Fonctions d'extension NodeInfo | | Oui | | Non | | Non |
|Extension de bibliothèque SQL | | Oui | | Non | | Non |
|Extension pipeDocument | | Oui | | Non | | Non |
|Extension evaluate | | Oui | | Non | | Non |
|Extension tokenize | | Oui | | Non | | Non |
|XML 1.1 | | Oui | | Oui | | Oui |
|

|

| |

##### Remarques

|

Avec la commande Process, utilisez -FLAVOR |sr2sw pour une transformation à l'aide du traitement du flux StAX et-FLAVOR |er2ew pour un traitement d'événement StAX.

|

Le nouveau compilateur ne recherche pas |le fournisseur de services org.apache.xalan.xsltc.dom.XSLTCDTMManager. A la place, si StreamSource est utilisé, le compilateur bascule vers un analyseur syntaxique XML de haute performance.

|

La mise en ligne est obsolète dans XL |TXE-J. |

|

|
- L'option -XN relative à la commande Process est automatiquement ignorée.
|
- L'option -n relative à la commande Compile est automatiquement ignorée.
|
- L'attribut de de fabrique du transformateur enable-inlining est automatiquement ignoré.

|

La classe org.apache.xalan.xsltc.trax.SmartTransformerFactoryImpl n'est plus prise en charge.

| |

#### Utilisation d'une ancienne version de Xerces ou Xalan

|
|

Si vous utilisez une ancienne version de Xerces (antérieure à 2.0) ou de Xalan (antérieure à 2.3) dans la substitution approuvée, il se peut qu'une variante NullPointerException soit émise lorsque vous lancez votre application. Cette exception se produit car les anciennes versions ne gèrent pas le fichier jaxp.properties correctement.

|

|

Pour éviter cette situation, utilisez l'une des solutions suivantes : |

|

|
- Effectuez une mise à jour vers une nouvelle version de l'application qui mette en oeuvre la spécification JAXP (Java API |for XML Programming) la plus récente (http://java.sun.com/xml/jaxp/index.html).
|
- Supprimez le fichier jaxp.properties de C:\Program Files\IBM\Java60\jre\lib.
|
- Supprimez la mise en commentaire des entrées du fichier jaxp.properties de C:\Program Files\IBM\Java60\jre\lib.
|
- Définissez la propriété système pour javax.xml.parsers.SAXParserFactory, javax.xml.parsers.DocumentBuilderFactory ou javax.xml.transform.TransformerFactory à l'aide de l'option de ligne de commande -D.
|
- Définissez la propriété système pour javax.xml.parsers.SAXParserFactory, javax.xml.parsers.DocumentBuilderFactory ou javax.xml.transform.TransformerFactory à partir du code de votre application. Pour obtenir un exemple, voir la spécification JAXP 1.4.
|
- Définissez de façon explicite l'analyseur SAX, le générateur de documents ou la fabrique de transformateur à l'aide de la variable d'environnement IBM_JAVA_OPTIONS. Par exemple : |

      set IBM_JAVA_OPTIONS=-Djavax.xml.parsers.SAXParserFactory=
      |  org.apache.xerces.jaxp.SAXParserFactoryImpl

  ou |

      set IBM_JAVA_OPTIONS=-Djavax.xml.parsers.DocumentBuilderFactory=
      |  org.apache.xerces.jaxp.DocumentBuilderFactoryImpl

  ou |

      set IBM_JAVA_OPTIONS=-Djavax.xml.transform.TransformerFactory=
      |  org.apache.xalan.processor.TransformerFactoryImpl

## Débogage des applications Java

Pour déboguer les programmes Java, vous pouvez utiliser l'application Java Debugger (JDB) ou d'autres débogueurs communiquant à l'aide de l'architecture JPDA (Java Platform Debugger Architecture) fournie par le SDK pour Windows.

Pour plus d'informations sur la procédure de diagnostic à l'aide de Java, reportez-vous au document Diagnostics Guide.

### Débogueur Java (JDB)

Le débogueur Java (JDB) est inclus dans le SDK de Windows. Il est appelé par la commande jdb et se connecte à la machine virtuelle à l'aide de JPDA.

Pour déboguer une applicationJava, procédez comme suit :

1. Démarrez la machine virtuelle Java avec les options suivantes :

       java -Xdebug -Xrunjdwp:transport=dt_shmem,server=y,address=<port> <classe>

   La machine virtuelle démarre mais interrompt l'exécution avant de démarrer l'application Java.
2. Dans une session distincte, vous pouvez rattacher le débogueur à la machine JVM avec la commande suivante :

       jdb -attach <port>

   Le débogueur se connecte à la machine virtuelle, ce qui vous permet à présent d'émettre une série de commandes pour examiner et contrôler l'application Java. Par exemple, entrez `run` pour permettre l'exécution de l'application Java.

Pour plus d'informations sur les options JDB, entrez :

    jdb -help

Pour plus d'informations sur les commandes JDB, entrez :

1. Entrez `jdb`
2. A l'invite jdb, entrez `help`

Vous pouvez également utiliser JDB pour déboguer les applications Java en cours d'exécution sur les machines distantes. JPDA utilise une socket TCP/IP pour la connexion à la machine virtuelle distante.

1. Démarrez la machine virtuelle Java avec les options suivantes :

       java -Xdebug -Xrunjdwp:transport=dt_shmem,server=y,address=<port> <classe>

   La machine virtuelle démarre mais interrompt l'exécution avant de démarrer l'application Java.
2. Raccordez le débogueur à la JVM distante :

       jdb -connect com.sun.jdi.SocketAttach:hostname=<host>,port=<port>

Cette version ne prend pas en charge l'interface JVMDI (Java Virtual Machine Debugging Interface). Elle a été remplacée par l'interface JVMTI (Java Virtual Machine Tool Interface).

Pour plus d'informations sur l'utilisation de JDB et JPDA, consultez les sites Web suivants :

- http://java.sun.com/products/jpda/
- http://java.sun.com/javase/6/docs/technotes/guides/jpda/
- http://java.sun.com/javase/6/docs/technotes/guides/jpda/jdb.html

## Détermination si votre application s'exécute sur une machine virtuelle Java 32 ou 64 bits

Certaines applications Java doivent pouvoir déterminer si elles s'exécutent sur une machine virtuelle Java 32 ou 64 bits. Par exemple, si votre application possède une bibliothèque de code native, celle-ci doit être compilée séparément en 32 et 64 bits pour des plateformes prenant en charge ces deux modes d'opération 32 et 64 bits. Dans ce cas, votre application doit charger la bibliothèque correcte lors de l'exécution car il est impossible de mélanger du code 32 et 64 bits.

La propriété système com.ibm.vm.bitmode permet aux applications d'identifier le mode dans lequel votre machine virtuelle Java fonctionne. Elle renvoie les valeurs suivantes :

- 32 - la machine virtuelle Java s'exécute en mode 32 bit
- 64 - la machine virtuelle Java s'exécute en mode 64 bits.

Vous pouvez observer la propriétécom.ibm.vm.bitmode depuis le code de votre application à l'aide de l'appel :

    System.getProperty("com.ibm.vm.bitmode");

## Traitement des signaux par la JVM

En cas de signal pertinent pour la JVM, un gestionnaire de signaux est appelé. Il détermine s'il a été appelé pour une unité d'exécution Java ou non Java.

Si le signal concerne une unité d'exécution Java, la JVM prend contrôle du traitement du signal. Si un gestionnaire d'applications pour ce signal est installé et que vous n'avez pas spécifié l'option de ligne de commande-Xnosigchain, le gestionnaire d'applications pour ce signal est appelé une fois le traitement de la machine virtuelle terminé.

Si le signal concerne une unité d'exécution non Java et que l'application qui a installé la JVM a déjà installé un gestionnaire spécifique pour ce signal, le contrôle est passé à ce gestionnaire. Sinon, si le signal est demandé par la JVM ou l'application Java, il est ignoré ou l'action par défaut est effectuée.

Lorsqu'un signal est généré de façon externe (lorsque vous appuyez sur CTRL-BREAK par exemple), une nouvelle unité d'exécution est créée pour le gestionnaire de signaux. Dans ce cas, le gestionnaire de signaux JVM effectue son traitement et si un gestionnaire d'applications pour ce signal est installé et que vous n'avez pas spécifié l'option de ligne de commande -Xnosigchain, le gestionnaire d'applications pour ce signal est appelé.

En cas de signaux d'exception ou d'erreur, la JVM effectue l'une des opérations suivantes :

- elle gère la condition et résout l'erreur ;
- elle démarre une séquence d'arrêt contrôlé avec les actions suivantes :
  1. elle génère un vidage pour décrire l'état de la machine virtuelle au point de défaillance ;
  2. elle appelle le gestionnaire de signaux de votre application pour le signal en question ;
  3. elle appelle un point d'abandon installé par l'application ;
  4. elle effectue le nettoyage nécessaire pour que la procédure d'arrêt s'effectue correctement.

Pour plus d'informations sur la manière d'écrire un programme de lancement spécifiant les points d'ancrage cités précédemment, voir : http://www.ibm.com/developerworks/java/library/i-signalhandling/. Ce document a été écrit pour Java version 1.3.1, mais il s'applique également aux versions ultérieures.

En cas de signaux d'interruption, la JVM démarre également une séquence d'arrêt contrôlé, mais cette fois, elle l'exécute comme un arrêt normal :

1. elle appelle le gestionnaire de signaux de votre application pour le signal en question ;
2. elle exécute tous les points d'arrêt de l'application ;
3. elle appelle un point de sortie installé par l'application ;
4. elle effectue le nettoyage nécessaire.

La procédure de fermeture est identique à celle démarrée par un appel de la méthode Java `System.exit()`.

D'autres signaux utilisés par la JVM sont réservés à des fins de contrôle interne et ne provoquent pas l'arrêt de la JVM. Le seul signal de contrôle intéressant est SIGBREAK qui entraîne un vidage Javadump.

### Signaux utilisés par la JVM

Les types de signaux sont Interruptions et Contrôles.

Le tableau 7 ci-dessous indique les signaux utilisés par la JVM. Ces signaux sont regroupés par type ou par utilisation, de la façon suivante :

Exceptions
  Le système d'exploitation déclenche de façon synchrone un signal d'exception approprié en cas de condition d'erreur fatale.
Erreurs
  La machine virtuelle JVM déclenche un signal SIGABRT si elle détecte une condition pour laquelle aucune récupération n'est possible.
Interruptions
  Les signaux d'interruption sont déclenchés de façon asynchrone, en dehors d'un processus JVM, et visent à demander l'arrêt.
Contrôles
  D'autres signaux utilisés par la machine virtuelle JVM à des fins de contrôle..

Tableau 7. Signaux utilisés par la JVM
Nom du signal | Type de signal | Description | Désactivé par -Xrs
--- | --- | --- | ---
SIGINT (2) | Interruption | Attention interactive (Ctrl-C). JVM s'arrête normalement. | Oui
SIGTERM (15) | Interruption | Demande d'arrêt. JVM s'arrête normalement. | Oui
SIGBREAK | Contrôle | Signal d'arrêt envoyé par un terminal. Un vidage Javadump est déclenché par défaut. | Oui

La machine virtuelle JVM IBM utilise la gestion structurée des exceptions et l'API SetConsoleCtrlHandler(). Ces éléments sont désactivés à l'aide de -Xrs. -Xnosigchain est ignoré sous Windows.

Utilisez l'option -Xrs (réduction de l'utilisation des signaux) pour empêcher la JVM de traiter la plupart des signaux. Pour plus d'informations, voir la page de lancement du programme d'applications Java de Sun.

Les signaux 2 (SIGINT) et 15 (SIGTERM) sur les unités d'exécution JVM provoquent l'arrêt de la machine JVM. Par conséquent, un gestionnaire de signaux d'application ne doit tenter aucune récupération à partir de ces signaux à moins qu'il n'ait plus besoin de la JVM.

### Création d'un lien entre un pilote de code natif et une bibliothèque de chaînage de signaux

L'environnement d'exécution dispose d'une fonction de chaînage de signaux. Cette fonction permet à la JVM d'interagir plus efficacement avec du code natif qui installe ses propres gestionnaires de signaux.

La fonction de chaînage de signaux permet à une application de créer un lien vers la bibliothèque partagée jsig.dll avant msvcrt.dll, et de la charger. La bibliothèque jsig.dll garantit l'interception des appels à signal(), afin que ses gestionnaires ne remplacent pas les gestionnaires de signaux de la JVM. Ces appels enregistrent les nouveaux gestionnaires de signaux ou les "chaînent" à la suite des gestionnaires qui sont installés par la JVM. Par la suite, lorsque l'un de ces signaux est déclenché ou qu'il s'avère qu'il ne s'adresse pas à la JVM, les gestionnaires préinstallés sont appelés.

La bibliothèque libjsig.dll masque également les gestionnaires de signaux JVM vis à vis de l'application. Ainsi, les appels tels que signal(), sigset() et sigaction() qui sont effectués après le démarrage de la JVM ne renvoient plus de référence au gestionnaire de signaux de la JVM mais à n'importe quel gestionnaire déjà installé avant le démarrage de la JVM.

La variable d'environnement JAVA_HOME doit être définie à l'emplacement du SDK, par exemple, C:\Program Files\IBM\Java60\.

Pour utiliser jsig.dll, liez-la à l'application qui crée ou incorpore une JVM.

## Ecriture d'applications JNI

Les numéros de versions JNI que des programmes natifs peuvent indiquer dans l'appel de l'API JNI_CreateJavaVM() sont : JNI_VERSION_1_2(0x00010002) et JNI_VERSION_1_4(0x00010004).

Restriction : La version 1.1 de l'interfaceJava Native Interface (JNI) n'est pas prise en charge.

Le numéro de version détermine uniquement le niveau de l'interface native JNI à utiliser. Le niveau de la machine virtuelle créée est précisé par les bibliothèques JSE (à savoir, v6). L'API de l'interface JNI n'affecte pas la spécification de langue implémentée avec la machine virtuelle, les API de bibliothèque de classe ou tout autre aspect du comportement de la machine virtuelle. Pour plus d'informations, voir http://java.sun.com/javase/6/docs/technotes/guides/jni/.

Si votre application a besoin de deux bibliothèques JNI, l'une pour 32 bit et l'autre pour 64 bits, employez la propriété système com.ibm.vm.bitmode afin de déterminer si vous travaillez avec une machine virtuelle 32 ou 64 bits et choisissez la bibliothèque en conséquence.

## Configuration de l'allocation de mémoire à grandes pages

Vous pouvez activer la prise en charge de grandes pages sur des systèmes l'autorisant en démarrant Java avec l'option -Xlp.

L'utilisation de grandes pages est principalement destinée à améliorer les performances des applications qui allouent une quantité de mémoire importante et qui accèdent fréquemment à cette mémoire. L'amélioration des performances en utilisant des grandes pages provient principalement du nombre réduit d'échecs dans le TLB (Translation Lookaside Buffer). Le TLB mappe une plus grande mémoire virtuelle, d'où cette amélioration.

Pour que la machine virtuelle Java utilise des grandes pages, votre système doit posséder un nombre adéquat de grandes pages contiguës disponibles. S'il est impossible d'allouer des grandes pages même si celles disponibles sont suffisantes, c'est qu'elles ne sont probablement pas contiguës.

Les allocations de grandes pages se produisent uniquement si la règle d'administration locale de l'utilisateur de la machine virtuelle Java est configurée pour autoriser «des pages verrouillées dans la mémoire».

## Prise en charge de CORBA

Java Platform, Standard Edition (JSE), prend au minimum en charge les spécifications définies dans la documentation relative à la conformité de Sun. Dans certains cas, la fonction ORB JSE IBM prend en charge les versions les plus récentes des spécifications.

Les spécifications prises au minimum en charge sont définies dans les spécifications officielles de prise en charge de CORBA dans Java SE 6.

### Prise en charge de GIOP 1.2

Ce SDK prend en charge toutes les versions de GIOP, telles qu'elles sont définies dans les chapitres 13 et 15 de la spécification CORBA 2.3.1, document OMG formal/99-10-07.

http://www.omg.org/cgi-bin/doc?formal/99-10-07

Le protocole GIOP bidirectionnel n'est pas pris en charge.

### Prise en charge des intercepteurs portables

Ce SDK prend en charge les intercepteurs portables, tels que définis par le groupe MG dans le document ptc/01-03-04, accessible sur le site Web suivant :

http://www.omg.org/cgi-bin/doc?ptc/01-03-04

Les intercepteurs portables sont des points d'ancrage dans la fonction ORB par le biais desquels les services ORB peuvent intercepter le flux normal d'exécution de l'ORB.

### Prise en charge d'INS (Interoperable Naming Service)

Ce SDK prend en charge INS (Interoperable Naming Service), tel que défini par le groupe OMG dans le document ptc/00-08-07, accessible sur le site Web suivant :

http://www.omg.org/cgi-bin/doc?ptc/00-08-07

Le port par défaut utilisé par le serveur de noms transitoire (commande tnameserv), lorsqu'aucun paramètre ORBInitialPort n'est fourni, est passé de 900 à 2809, c'est-à-dire au numéro de port enregistré auprès de l'IANA (Internet Assigned Number Authority) pour un service annuaire CORBA. Les programmes qui dépendent de cette valeur par défaut peuvent nécessiter une mise à jour pour fonctionner avec cette version.

Le contexte initial renvoyé par le serveur de noms transitoire est à présent un org.omg.CosNaming.NamingContextExt. Les programmes existants qui réduisent la référence à un contexte org.omg.CosNaming.NamingContext fonctionnent toujours et n'ont pas besoin d'être recompilés.

La fonction ORB prend en charge les paramètres -ORBInitRef et -ORBDefaultInitRef définis par la spécification INS (Interoperable Naming Service) et l'opération ORB::string_to_object prend désormais en charge les formats de chaîne ObjectURL (corbaloc: et corbaname:) définis par la spécification INS.

La fonction OMG définit une méthode ORB::register_initial_reference pour enregistrer un service auprès de l'INS. Toutefois, cette méthode n'est pas disponible dans l'API Sun Java centrale Version 6. Les programmes ayant besoin d'enregistrer un service dans la version actuelle doivent appeler cette méthode sur la classe d'implémentation ORB interne IBM. Par exemple, pour enregistrer un service «MonService» :

    ((com.ibm.CORBA.iiop.ORB)orb).register_initial_reference("MonService",
    serviceRef);

Où `orb` correspond à une instance d'org.omg.CORBA.ORB, renvoyée par ORB.init(), et `serviceRef` correspond à un objet CORBA, connecté à la fonction ORB. Ce mécanisme est temporaire et n'est pas compatible avec les versions ultérieures, ni portable sur les ORB non IBM.

### Propriétés système de traçage de l'ORB

Une fonction de débogage d'exécution améliore la maintenabilité. Elle peut être utile pour la procédure de diagnostic ou être demandée par le service de maintenance IBM.

#### Propriétés de traçage

com.ibm.CORBA.Debug=true
  Active le traçage ORB.
com.ibm.CORBA.CommTrace=true
  Ajoute les messages GIOP (envoyés et reçus) à la trace.
com.ibm.CORBA.Debug.Output=<fichier>
  Indique le fichier de sortie de trace. Le format par défaut est orbtrc.DDMMYYYY.HHmm.SS.txt.

#### Exemple de traçage ORB

Par exemple, pour tracer les événements et les messages GIOP mis en forme à partir de la ligne de commande, entrez :

    java -Dcom.ibm.CORBA.Debug=true
         -Dcom.ibm.CORBA.CommTrace=true <myapp>

#### Limitations

N'activez pas le traçage pour le fonctionnement normal car cela pourrait réduire les performances. Même si vous avez désactivé le traçage, l'outil de diagnostic de premier niveau fonctionne toujours, de sorte que les erreurs graves sont signalées. Si un fichier de sortie de débogage est généré, examinez-le pour identifier le problème. Par exemple, il se peut que le serveur se soit arrêté sans effectuer de ORB.shutdown().

Le contenu et le format du fichier de sortie de trace varie d'une version à l'autre.

### Propriétés système d'optimisation de l'ORB

La fonction ORB peut être ajustée afin d'être compatible avec votre réseau. Les propriétés requises pour ajuster l'ORB sont décrites dans cette section.

com.ibm.CORBA.FragmentSize=<taille en octets>
  Utilisée pour contrôler la fragmentation GIOP 1.2. La taille par défaut est 1024 octets.

  Pour désactiver la fragmentation, définissez une taille de fragmentation de 0 octets :

      java -Dcom.ibm.CORBA.FragmentSize=0 <monApp>

com.ibm.CORBA.RequestTimeout=<délai, en secondes>
  Définit le temps d'attente maximal pour une demande CORBA. Par défaut, l'ORB attend une réponse indéfiniment. Ne définissez pas un délai d'attente trop court pour ne pas risquer de mettre fin aux connexions inutilement.
com.ibm.CORBA.LocateRequestTimeout=<délai, en secondes>
  Définit le délai d'attente maximal des demandes de recherche CORBA. Par défaut, l'ORB attend une réponse indéfiniment.
com.ibm.CORBA.ListenerPort=<numéro de port>
  Définit le port à partir duquel l'ORB peut lire les demandes entrantes. Si cette propriété est définie, l'ORB se met en mode écoute dès qu'il est initialisé. Sinon, il commence l'écoute seulement lorsque cela est requis.

### Droits de sécurité Java pour l'ORB

Lors de l'exécution avec un gestionnaire de sécurité Java, l'appel de certaines méthodes des classes API CORBA peut donner lieu à des vérifications de droits et, par conséquent, générer une exception de sécurité. Si votre programme utilise l'une de ces méthodes, assurez-vous qu'il bénéficie des droits nécessaires.

Tableau 8. Méthodes concernées lors de l'exécution avec un gestionnaire de sécurité Java
Classe/Interface | Méthode | Droit requis
--- | --- | ---
org.omg.CORBA.ORB | init | java.net.SocketPermission resolve
org.omg.CORBA.ORB | connect | java.net.SocketPermission listen
org.omg.CORBA.ORB | resolve_initial_references | java.net.SocketPermission connect
org.omg.CORBA. portable.ObjectImpl | _is_a | java.net.SocketPermission connect
org.omg.CORBA. portable.ObjectImpl | _non_existent | java.net.SocketPermission connect
org.omg.CORBA. portable.ObjectImpl | OutputStream _request (chaîne, booléen) | java.net.SocketPermission connect
org.omg.CORBA. portable.ObjectImpl | _get_interface_def | java.net.SocketPermission connect
org.omg.CORBA. Request | invoke | java.net.SocketPermission connect
org.omg.CORBA. Request | send_deferred | java.net.SocketPermission connect
org.omg.CORBA. Request | send_oneway | java.net.SocketPermission connect
javax.rmi. PortableRemoteObject | narrow | java.net.SocketPermission connect

### Classes d'implémentation ORB

Liste des classes d'implémentation ORB.

Les classes d'implémentation ORB de cette version sont les suivantes :

- org.omg.CORBA.ORBClass=com.ibm.CORBA.iiop.ORB
- org.omg.CORBA.ORBSingletonClass=com.ibm.rmi.corba.ORBSingleton
- javax.rmi.CORBA.UtilClass=com.ibm.CORBA.iiop.UtilDelegateImpl
- javax.rmi.CORBA.StubClass=com.ibm.rmi.javax.rmi.CORBA.StubDelegateImpl
- javax.rmi.CORBA.PortableRemoteObjectClass=com.ibm.rmi.javax.rmi.PortableRemoteObject

Ces valeurs sont celles définies par défaut. Il est conseillé de ne pas définir ces propriétés, ni de faire directement référence aux classes d'implémentation. Pour garantir la portabilité de l'application, faites uniquement référence aux classes de l'API CORBA et non à l'implémentation. Il se peut que ces valeurs soient modifiées dans des versions futures.

## RMI sur IIOP

L'invocation RMI Java fournit un mécanisme simple de programmation Java distribuée. RMI sur IIOP (RMI-IIOP) utilise le protocole IIOP (Internet Inter-ORB Protocol) standard CORBA (Common Object Request Broker Architecture) pour étendre le RMI Java de base pour la communication. Une interaction directe est ainsi permise avec tout autre ORB CORBA, qu'il soit mis en oeuvre en Java ou dans un autre langage de programmation.

La documentation suivante est disponible :

- Le guide RMI-IIOP Programmer's Guide constitue une introduction à l'écriture de programmes RMI-IIOP.
- Le document Java Language to IDL Mapping est une spécification technique détaillée de RMI-IIOP.

## Implémentation du pool de gestionnaires de connexion pour RMI

Le regroupement d'unités d'exécution pour les gestionnaires de connexions RMI n'est pas activé par défaut.

Pour activer le regroupement de connexions implémenté au niveau du transport TCP du RMI, set définissez l'option

    -Dsun.rmi.transport.tcp.connectionPool=true

Cette version de Runtime Environment ne contient pas de paramètre permettant de restreindre le nombre d'unités d'exécution du pool de connexions.

## Big Decimal amélioré

Depuis Java 5.0, la classe Big Decimal IBM est adoptée par Sun en tant que java.math.BigDecimal. La classe com.ibm.math.BigDecimal est réservée pour une utilisation ultérieure probable par IBM et est actuellement obsolète. Migrez le code Java existant pour utiliser java.math.BigDecimal.

La nouvelle classe java.math.BigDecimal utilise les mêmes méthodes que les classes java.math.BigDecimal et com.ibm.math.BigDecimal précédentes. Le code existant qui utilise java.math.BigDecimal continue à fonctionner correctement. Les deux classes ne peuvent pas être sérialisées.

Pour faire migrer le code Java existant afin d'utiliser la classe java.math.BigDecimal, modifiez l'instruction d'importation au début du fichier .java en remplaçant `import com.ibm.math.*;` par `import java.math.*;`.

# Plug-in, Applet Viewer et Web Start

Le plug-in Java peut-être utilisé pour exécuter les applications Java dans le navigateur. Applet Viewer est utilisé pour tester les applications devant être exécutées dans un navigateur. Java Web Start est utilisé pour déployer les applications Java sur un réseau et fournit un mécanisme permettant de les conserver à jour.

## Utilisation du plug-in Java

Le plug-in Java est un plug-in de navigateur Web. Le plug-inJava peut être utilisé pour exécuter des applets dans le navigateur.

Vous devez laisser les applets se charger complètement pour éviter le blocage du navigateur. Par exemple, si vous cliquez sur le bouton Précédente puis Suivante alors qu'une applet est en cours de chargement, les pages HTML peuvent ne pas s'afficher.

Vous trouverez plus d'informations sur le plug-in Java sur le site de Sun à l'adresse http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/.

### Navigateurs pris en charge

Le plug-in Java prend en charge Internet Explorer, Netscape, Mozilla, ainsi que Mozilla Firefox.

Tableau 9. Navigateurs pris en charge par le plug-in Java
Navigateur | Versions prises en charge
--- | ---
Internet Explorer | 6.0 SP1, 7.0
Netscape (non pris en charge sousWindows Vista) | 7.2
Mozilla (non pris en charge sousWindows Vista) | 1.7, 1.8
Firefox | 2.0

Les navigateurs de versions secondaires ultérieures sont également pris en charge.

Internet Explorer 5.01, navigateur par défaut sousWindows 2000, n'est pas pris en charge.

### Prise en charge de la vérification statique et sécurisée des versions

La vérification statique des versions permet aux applets de demander une version de machine virtuelle JVM spécifique sur laquelle s'exécuter. Comme cette fonctionnalité permet également aux applets de profiter des anciennes failles de sécurité des systèmes mis à niveau vers une nouvelle machine virtuelle JVM, la vérification statique et sécurisée des versions est désormais utilisée sur Internet Explorer.

Par défaut, toutes les applets sont exécutées sur la dernière machine virtuelle JVM installée. Pour désactiver la vérification statique et sécurisée des versions, définissez la clé de registre suivante à 0 :

HKEY_LOCAL_MACHINE\Software\IBM\Java Deployment\Policy\EnableSecureStaticVersioning

Si cette clé de registre n'existe pas, la vérification statique et sécurisée des versions est activée.

Cette vérification ne fonctionne pas si les extensions tierce partie du navigateur sont désactivées dans Internet Explorer. Pour activer ces extensions :

1. Ouvrez Internet Explorer.
2. Cliquez sur Outils -> Options Internet.
3. Cliquez sur l'onglet Avancé.
4. Cochez la case Activer les extensions tierce partie du navigateur.

Si les extensions tierce partie du navigateur sont désactivées après utilisation de la vérification statique et sécurisée des versions, celle-ci continue à fonctionner.

Pour protéger les navigateurs Mozilla et Firefox, le plug-in d'Internet Explorer supprime automatiquement tous les plug-ins Java des répertoires de plug-ins Mozilla et Firefox. Ceci se produit à chaque fois qu'une applet est exécutée sous Internet Explorer.

Pour réinstaller un plug-in Java sur Mozilla ou Firefox, utilisez le panneau de configuration Java.

### Prise en charge du modèle DOM (Document Object Model) commun

En raison des limitations de certains navigateurs, vous ne pourrez peut-être pas implémenter toutes les fonctions du module org.w3c.dom.html.

Une des erreurs suivantes se produit :

- Une exception sun.plugin.dom.exception.InvalidStateException est déclenchée pour certaines de ces fonctions.
- Une exception sun.plugin.dom.exception.NotSupportedException est déclenchée lorsque le navigateur ne prend pas en charge une fonction spécifique.

### Utilisation des paramètres DBCS

Le plug-in Java prend en charge les caractères double octet (par exemple, le chinois traditionnel BIG-5, le coréen et le japonais) en tant que paramètres pour les balises `<APPLET>`, `<OBJECT>`, et `<EMBED>`. Vous devez sélectionner le codage des caractères correct pour le document HTML de sorte que le plug-in Java puisse analyser le paramètre.

Indiquez le codage des caractères pour le document HTML à l'aide de la balise `<META>` dans la section `<HEAD>`, comme suit :

    <meta http-equiv="Content-Type" content="text/html; charset=big5">

Cet exemple demande au navigateur d'analyser le fichier HTML à l'aide du codage de caractères Chinese BIG-5.

## Utilisation d'applets

Applet Viewer vous permet d'exécuter une ou plusieurs applets appelées par référence dans une page Web (fichier HTML) à l'aide de la balise APPLET. Il détecte les balises APPLET dans le fichier HTML et exécute les applets dans des fenêtres séparées, comme indiqué par les balises.

Applet Viewer étant réservé à l'affichage d'applets, il ne peut pas afficher la totalité d'une page Web contenant de nombreuses balises HTML. En effet, il analyse uniquement les balises APPLET et non les autres balises HTML présentes sur la page.

### Exécution d'applets à l'aide d'Applet Viewer

Utilisez la commande suivante pour exécuter un applet à l'aide d'Applet Viewer.

A partir d'une invite de commande, entrez :

       appletviewer <nom>

où <nom> correspond à l'un des éléments suivants :

- Nom d'un fichier HTML qui appelle un applet.
- URL d'une page Web qui appelle un applet.

Par exemple, pour appeler Applet Viewer sur un fichier HTML qui appelle un applet, entrez à l'invite de commande :

    appletviewer <demo>\GraphLayout\example1.html

où <demo> est remplacé par le chemin complet où vous avez dézippé le module de démonstration.

Pour appeler Applet Viewer sur une page Web, entrez à l'invite de commande :

    appletviewer http://java.sun.com/applets/NervousText/exemple1.html

Applet Viewer ne reconnaît pas l'option charset de la balise <META>. Si le fichier chargé par Applet Viewer n'est pas codé en tant que valeur par défaut du système, une exception E-S peut se produire. Pour éviter cette exception, utilisez l'option -encoding lorsque vous exécutez appletviewer. Par exemple :

    appletviewer -encoding JISAutoDetect sample.html

### CLSID uniques

Un ensemble unique de CLSID a été ajouté à la machine virtuelle d'IBM lors de l'actualisation de service 1 de la version 6.

Les nouveaux CLSID sont les suivants :

    1ACECAFE-0016-0000-0000-ABCDEFFEDCBA
    1ACECAFE-0016-0000-0000-ABCDEFFEDCBB
    1ACECAFE-0016-0000-0000-ABCDEFFEDCBC

Vous pouvez vous référer aux CLSID mentionnés ci-dessus dans la balise OBJECT de vos applets.

De plus, les CLSID suivants sont pris en charge pour des besoins de compatibilité :

    CAFEEFAC-0016-0000-0000-ABCDEFFEDCBA
    CAFEEFAC-0016-0000-0000-ABCDEFFEDCBB
    CAFEEFAC-0016-0000-0000-ABCDEFFEDCBC

### Débogage d'applets à l'aide d'Applet Viewer

L'option -debug d'Applet Viewer permet de déboguer les applets.

Par exemple :

    cd demo\applets\TicTacToe
    ..\..\..\bin\appletviewer -debug exemple1.html

Vous trouverez de la documentation sur le débogage d'applets à l'aide d'Applet Viewer sur le site Web de Sun à l'adresse http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/debugger.html.

## Utilisation de Web Start

Java Web Start est utilisé pour le déploiement d'applications Java.

Web Start vous permet de lancer et de gérer des applications directement à partir du Web. Les applications sont mises en cache pour réduire les temps d'installation. Elles sont automatiquement mises à niveau lorsque de nouvelles versions sont disponibles.

Web Start prend en charge ces java-vm-args décrits sur le site Web http://java.sun.com/javase/6/docs/technotes/guides/javaws/developersguide/syntax.html#resources :

- -verbose
- -version
- -showversion
- -help
- -X
- -ea
- -enableassertions
- -da
- -disableassertions
- -esa
- -enablesystemassertions
- -dsa
- -disablesystemassertions
- -Xint
- -Xnoclassgc
- -Xdebug
- -Xfuture
- -Xrs
- -Xms
- -Xmx
- -Xss

IBM Web Start prend également en charge -Xgcpolicy pour définir la règle de récupération de place.

Pour plus d'informations sur les navigateurs prenant en charge Web Start, voir Navigateurs pris en charge.

Pour plus d'informations sur Web Start, voir :

- http://java.sun.com/products/javawebstart et

- http://java.sun.com/javase/6/docs/technotes/guides/javaws/index.html.

Pour plus d'informations sur le déploiement des applications, voir

- http://java.sun.com/javase/6/docs/technotes/guides/deployment/index.html.

### Exécution de Web Start

Web Start peut être exécuté depuis une page Web ou une ligne de commande. Les applications Web Start sont stockées dans le cache de l'application Java.

Vous pouvez appeler Web Start de plusieurs façons.

- Sélectionnez un lien sur une page Web faisant référence à un fichier .jnlp.
- A partir d'une invite de commande, entrez :

      javaws <URL>

  où <URL> correspond à l'emplacement d'un fichier .jnlp.
- Si vous avez déjà utilisé Java Web Start pour ouvrir l'application, vous pouvez utiliser l'afficheur de cache de l'application Java. A partir d'une invite de commande, entrez :

      C:\Program Files\IBM\Java60\jre\bin\javaws| -viewer

  Toutes les applications Java Web Start sont stockées dans le cache de l'application Java. Une application est uniquement téléchargée si la version la plus récente de cette application n'est pas stockée dans le cache.

### Gestion sécurisée des versions statiques de WebStart

La gestion des versions statiques autorise les applications Web Start à demander une version JVM particulière sous laquelle s'exécuter. Puisque cette fonctionnalité permet également aux applications d'exploiter les anciennes défaillances relatives à la sécurité sur des systèmes qui ont été mis à niveau vers une nouvelle machine virtuelle, la gestion sécurisée des versions statiques (Secure Static Versioning, SSV) est désormais utilisée par défaut.

Avec SSV, l'utilisateur recevra un avertissement avant l'exécution de toute application Web Start non signée qui requiert l'utilisation d'une machine virtuelle spécifique. Les applications signées et celles qui requièrent la version la plus récente de la machine virtuelle s'exécutent normalement.

Vous pouvez désactiver SSV en attribuant la valeur false à la propriété deployment.javaws.ssv.enabled du fichier deployment.properties.

## Livraison d'applications Java

Les applications Java sont généralement composées de fichiers de classes, de ressources et de données.

Lorsque vous livrez une application Java, le package se compose probablement de ce qui suit :

- Vos propres fichiers de classes, ressources et données
- Une procédure ou un programme d'installation

Pour exécuter votre application, les utilisateurs ont besoin de Runtime Environment for Windows. SDK for Windows inclut un Runtime Environment. Toutefois, vous ne pouvez pas supposer que SDK for Windows est installé pour les utilisateurs.

Votre licence de SDK for Windows ne vous permet pas de redistribuer les fichiers du SDK avec votre application. Assurez-vous qu'une version sous licence de SDK for Windows est installée sur la machine cible.

# Partage de données de classes entre JVM

Le partage de données de classes permet à plusieurs machines JVM de partager le même espace en mémoire.

La machine virtuelle Java (JVM) vous permet de partager des données de classes entre JVM en les stockant dans unfichier cache mappé en mémoire sur disque. Le partage de classes réduit la consommation globale de mémoire virtuelle lorsque plusieurs machines virtuelles partagent un cache. Il diminue également le temps de démarrage d'une machine virtuelle après création du cache. Le cache de classes partagées est indépendant de toute machine virtuelle active et demeure jusqu'à ce qu'il soit détruit .

Un cache partagé peut contenir les éléments suivants :

- les classes d'amorce
- les classes d'application
- les métadonnées qui décrivent les classes
- |le code compilé AOT (Ahead-of-time)

## Présentation du partage de données de classes

Le partage de données de classes est une méthode transparente permettant de réduire l'encombrement de la mémoire et d'améliorer le temps de démarrage de la machine virtuelle. |Java 6 |propose de nouvelles fonctions permettant d'améliorer la gestion, l'isolement et la performance du cache.

### Activation du partage de données de classes

Activez le partage de données de classes à l'aide de l'option -Xshareclasses au démarrage de la machine virtuelle. La machine virtuelle JVM se connecte à un cache existant ou crée un cache s'il n'en existe pas déjà un.

Toutes les classes d'amorce et d'application chargées par la machine virtuelle sont par défaut partagées. Les chargeurs de classes personnalisés effectuent automatiquement un partage de classes s'ils étendent le chargeur de classes de l'application ; sinon, ils doivent utiliser l'API Java Helper fournie avec la machine virtuelle pour accéder au cache. (Voir Adaptation de chargeurs de classes personnalisés pour partager des classes.)

|La machine virtuelle peut également stocker le code AOT compilé dans le cache pour certaines méthodes afin d'améliorer le temps de démarrage des machines virtuelles suivantes. Le code AOT compilé n'est pas partagé entre plusieurs machines virtuelles, mais est mis en cache pour réduire le temps de compilation lors du démarrage de la machine virtuelle. Le nombre de codes AOT stockés dans le cache est déterminé de manière heuristique. Les méthodes pouvant être stockées dans le cache ne peuvent pas être contrôlées, mais vous pouvez définir des limites supérieures et inférieures pouvant être appliquées à la quantité d'espace de cache requise pour le code AOT. Vous pouvez également désactiver la mise en cache du code AOT complètement. |Voir Activation et configuration du partage de données de classes pour plus d'informations.

### Accès au cache

|Une machine virtuelle peut accéder à un cache en mode lecture-écriture ou en mode lecture seule. Toutes les machines virtuelles connectées à un cache dotés de droits d'accès en lecture-écriturepeuvent mettre le cache à jour. Plusieurs machines virtuelles peuvent lire en même temps à partir du cache, et ce, même lors de l'écriture dans le cache par une autre machine virtuelle.

Soyez vigilant si une modification de code intermédiaire d'exécution est appliquée. Voir Modification du code intermédiaire d'exécution pour plus d'informations.

### Mise à jour dynamique du cache

Comme le cache de classes partagées est conservé au-delà du cycle de vie d'une machine virtuelle, il est mis à jour de façon dynamique pour refléter les modifications apportées aux fichiers JAR ou aux classes du système de fichiers. La mise à jour dynamique rend le cache transparent pour l'application qui l'utilise.

### Sécurité du cache

L'accès au cache des classes est limité par les autorisations Java et du système d'exploitation. Seul un chargeur de classe qui est enregistré pour partager des données de classes peut mettre à jour le cache de classes partagées.

|La mémoire cache est protégée contre les corruptions accidentelles ou délibérées à l'aide de la protection de la page de mémoire. Cependant, il ne s'agit pas d'une protection optimale car la machine virtuelle doit désactiver la protection des pages afin d'écrire dans ces pages. Le seul moyen de garantir qu'un cache ne puisse pas être modifié est de l'ouvrir en lecture seule.

Si un gestionnaire de sécuritéJava SecurityManager est installé, les chargeurs de classe, à l'exception des chargeurs de classe d'extension, d'application et d'amorce, doivent disposer des droits permettant de partager des classes par l'ajout de SharedClassPermission au fichier java.policy. (Voir Utilisation de SharedClassPermission.) L'autorisation RuntimePermission «createClassLoader» restreint la création de chargeurs de classe et restreint donc l'accès au cache.

### Durée de vie du cache

Plusieurs caches peuvent se trouver sur un même système ; ils sont alors désignés par leur nom, comme sous-option de la commande -Xshareclasses. Une machine virtuelle ne peut se connecter qu'à un seul cache à la fois.

Vous pouvez remplacer la taille du cache par défaut au démarrage à l'aide de -Xscmx<n><size>, mais cette taille ne peut ensuite être modifiée pendant la durée de vie du cache. Les caches existent jusqu'à leur destruction explicite avec une sous-option de la commande -Xshareclasses oule fichier cache est supprimé manuellement.

### Utilitaires du cache

Tous les utilitaires du cache sont des sous-options de la commande -Xshareclasses. Voir Activation et configuration du partage de données de classes, ou utiliser -Xshareclasses:help pour consulter une liste des sous-options disponibles.

## Activation et configuration du partage de données de classes

Les utilitaires de partage de données de classes et de gestion de cache sont contrôlés à l'aide des options de ligne de commande du programme de lancement java.

Pour les options employant le paramètre <taille>, ajoutez "k" ou "K" au nombre pour indiquer qu'il s'agit de kilo-octets, "m" ou "M" de mégaoctets ou bien "g" ou "G" de gigaoctets.

-Xscmaxaot<taille>
  Définit le nombre maximal d'octets du cache pouvant être utilisés pour des données AOT. Cette option permet de garantir aux données non-AOT une certaine quantité d'espace de cache. Par défaut, le nombre maximal d'octets pouvant être attribués à des données AOT se limite à la quantité d'espace disponible dans le cache. La valeur de cette option ne peut être inférieure à la valeur de -Xscminaot et supérieure à la valeur de -Xscmx.
-Xscminaot<taille>
  Définit le nombre minimal d'octets du cache destinés aux données AOT. Par défaut, aucun espace n'est réservé pour les données AOT, même si des données AOT sont consignées dans le cache jusqu'à ce que celui-ci soit plein ou que la limite de -Xscmaxaot soit atteinte. La valeur de cette option ne doit pas être supérieure à la valeur de -Xscmx ou de -Xscmaxaot. La valeur de -Xscminaot doit être toujours largement inférieure à taille du cache car des données AOT peuvent être uniquement créées pour les classes mises en cache. Si la valeur de -Xscminaot est égale à la valeur de -Xscmx, aucune donnée de classe ou AOT n'est stockée car les données AOT doivent être associées à une classe du cache.
-Xscmx<taille>
  Indique la taille du cache. Cette option s'applique uniquement si un cache est créé et s'il n'existe aucun autre cache portant le même nom. La taille de cache par défaut dépend de la plateforme. Vous pouvez connaître la taille utilisée en ajoutant -verbose:sizes en tant qu'argument de ligne de commande. La taille de cache minimal est de 4 Ko. La taille de cache maximal dépend de la plateforme. (Voir Limites de la taille du cache.)
-Xshareclasses:<sous-option>[,<sous-option>...]
  Active le partage de données de classes et accepte un certain nombre de sous-options, dont des utilitaires du cache. Ces derniers réalisent l'opération requise sur le cache spécifié sans démarrer la machine virtuelle. Vous pouvez combiner plusieurs sous-options en les séparant par des virgules ; pour leur part, les utilitaires du cache s'excluent mutuellement. Lors de l'exécution des utilitaires de cache, le message «Impossible de créer la machine virtuelle Java » s'affiche. Les utilitaires de cache ne créent pas la machine virtuelle.

  Certains utilitaires de cache peuvent être utilisés avec des caches des versions Java précédentes ou des caches créés par des machines virtuelles dotées de largeurs de bits différentes. Ces caches sont appelés des caches «incompatibles».

  Vous pouvez utiliser les sous-options suivantes avec l'option -Xshareclasses :

  help
    Répertorie toutes les sous-options de ligne de commande.
  name=<nom>
    Etablit une connexion au cache du nom indiqué, en le créant s'il n'existe pas déjà. Egalement utilisé pour spécifier le cache à modifier par les utilitaires de cache, par exemple, pour destruction. L'option listAllCaches permet d'afficher les caches nommés actuellement disponibles. Si vous n'indiquez aucun nom, le nom par défaut «sharedcc_%u» est utilisé. %u inclus dans le nom de cache insère le nom d'utilisateur actuel.
  |cacheDir=<répertoire>
    |Définit le répertoire dans lequel les données du cache vont être lues et écrites. Par défaut, <répertoire> correspondau répertoire C:\Documents and Settings\<nom_utilisateur>\Local |Settings\Application Data\javasharedresources de l'utilisateur. L'utilisateur doit disposer des droits nécessaires dans le <répertoire>. Par défaut, la machine virtuelle écrit des fichiers de cache non volatile directement dans le répertoire spécifié. Les fichiers de cache non volatile peuvent être transférés et supprimés en toute sécurité du système de fichiers. Caches non volatiles sont stockés dans une mémoire partagée et sont dotés de fichiers de contrôle décrivant l'emplacement de la mémoire. Les fichiers de contrôle sont stockés dans le sous-répertoire javasharedresources du paramètre cacheDir spécifié. |Les fichiers de contrôle de ce répertoire ne doivent pas être transférés ou supprimés manuellement. Les utilitaires listAllCaches et destroyAll ainsi que la sous-option expire peuvent uniquement être utilisés avec un paramètre cacheDir donné.
  |readonly
    |Ouvre un cache existant avec des droits en lecture seule. La machine virtuelle ne crée pas de cache avec cette sous-option. L'ouverture d'un cache avec des droits en lecture seule empêche la machine virtuelle de mettre à jour le cache. Cela permet également à la machine virtuelle de se connecter aux caches créés par d'autres utilisateurs ou groupes sans demander un accès en écriture. Cette sous-option n'est pas définie par défaut.
  |nonpersistent
    |Utilise un cache non permanent. Par défaut, la machine virtuelle crée un fichier cache sur disque qui est conservé au-delà du redémarrage du système d'exploitation. L'utilisation de la sous-option nonpersistent entraîne la suppression du fichier cache lors de l'arrêt du système d'exploitation. Les caches permanents et non volatiles peuvent être dotés du même nom, la sous-option nonpersistent doit toujours être utilisée lors de l'exécution d'utilitaires tels que destroy sur un cache non volatile. Cette sous-option n'est pas définie par défaut.
  verbose
    Active la sortie prolixe, qui fournit des informations sur l'état global du cache de classe partagée ainsi que des messages d'erreur détaillés.
  |verboseAOT
    |Permet des sorties détaillées lorsque des codes AOT compilés sont trouvés ou stockés dans le cache. Les codes AOT sont générés de manière heuristique. Il se peut qu'il n'y ait aucun code AOT généré pour une petite application. La mise en cache du code AOT peut être désactivée à l'aide de la sous-option noaot.
  verboseIO
    Offre une sortie détaillée sur l'activité d'entrée-sortie du cache, avec des informations sur les classes stockées et trouvées. Chaque chargeur de classes reçoit un ID unique (le chargeur d'amorce correspond toujours à 0) et la sortie montre la hiérarchie des chargeurs de classes en pratique : chacun doit demander des classes à ses parents avant de les charger. Il est normal de constater de nombreuses demandes ayant échoué dans la hiérarchie de chargeurs de classes.
  verboseHelper
    Permet des sorties détaillées pour l'API Java Helper. Ces sorties vous montrent comment l'API Helper est utilisée par votre chargeur de classes.
  silent
    Désactive tous les messages relatifs aux partages de classes, y compris les messages d'erreurs.
  nonfatal
    Permet le démarrage de la machine virtuelle JVM même si le partage de données de classes est un échec. Généralement, la machine virtuelle ne démarre pas si le partage de données de classes échoue. Si l'option nonfatal est sélectionnée et que l'initialisation du partage de données de classes est un échec, la machine virtuelle tente de se connecter au cache en mode lecture seule. Si cette tentative échoue, la machine virtuelle démarre sans partage de données de classes.
  none
    Peut être ajoutée à la fin d'une ligne de commande pour désactiver le partage de données de classes. Cette sous-option remplace les arguments de partage qui la précèdent sur la ligne de commande.
  modified=<contexte modifié>
    Utilisé lorsqu'un agent JVMTI est installé et que celui-ci peut modifier le code intermédiaire pendant l'exécution. Si cette sous-option n'est pas indiquée et qu'un agent de modification de code intermédiaire est installé, les classes sont partagées de manière sécurisée avec un coût additionnel au niveau de la performance. Le <contexte modifié> est un descripteur choisi par l'utilisateur ; par exemple, «maModification1». Cette option partitionne le cache afin que seules les machines virtuelles utilisant le contexte maModification1 puissent partager les mêmes classes. Par exemple, si vous exécutez HelloWorld avec un contexte de modification, puis à nouveau avec un autre contexte, toutes les classes sont stockées deux fois dans le cache. Voir Modification du code intermédiaire d'exécution pour plus d'informations.
  |reset
    |Le cache est détruit, puis recréé lors du démarrage de la machine virtuelle. Peut être ajoutée à la fin d'une ligne de commande en tant que -Xshareclasses:reset.
  destroy (option d'utilitaire)
    Détruit un cache défini par les sous-options name, cacheDir, et nonpersistent. Un cache peut uniquement être détruit si toutes les machines virtuelles l'employant sont arrêtées et que l'utilisateur dispose des droits nécessaires.
  destroyAll (option d'utilitaire)
    Tente de détruire tous les caches disponibles à l'aide des sous-options cacheDir et nonpersistent spécifiées. Un cache peut uniquement être détruit si toutes les machines virtuelles l'employant sont arrêtées et que l'utilisateur dispose des droits nécessaires.
  expire=<durée en minutes>
    Détruit tous les caches inutilisés pendant la duré spécifiée avant le chargement des classes partagées. Il ne s'agit pas d'une option d'utilitaire car elle n'entraîne pas l'arrêt de la machine virtuelle. Pour les systèmes de fichiers NTFS, l'option d'expiration est précisée en fonction de l'heure la plus proche.
  listAllCaches (option d'utilitaire)
    Répertorie tous les caches compatibles et non compatibles qui figurent dans le répertoire de cache spécifié. Si cacheDir n'est pas défini, le répertoire par défaut est utilisé. Les informations récapitulatives, telles que la version Java et l'utilisation actuelle sont affichées pour chaque cache.
  printStats (option d'utilitaire)
    Affiche les informations récapitulatives relatives au cache défini par les sous-options name, cacheDir et nonpersistent. Les informations les plus utiles sont celles indiquant à quel point il est rempli et combien de classes il renferme. Les classes périmées sont celles n'ayant pas été mises à jour sur le système de fichiers et que le cache a donc marquées de la sorte. Ces classes ne sont pas supprimées du cache et peuvent être à nouveau utilisées. Voir le document Diagnostics Guide pour en savoir plus.
  printAllStats (option d'utilitaire)

    Affiche les informations détaillées relatives au cache spécifié par les sous-options name, cacheDir et nonpersistent. Chaque classe apparaît dans l'ordre chronologique, avec une référence à l'emplacement depuis lequel elle a été chargée. Le code AOT des méthodes de classe est également répertorié.

    Voir le

    Voir le document Diagnostics Guide pour plus d'informations.

  |mprotect=[ all || default | none ]
    |Par défaut, les pages de mémoire contenant le cache sont protégées en permanence, sauf si une page particulière est mise à jour. Cela permet de protéger le cache contre des corruptions accidentelles ou délibérées. Par défaut, l'en-tête de cache n'est pas protégé en raison d'un coût de performance peu élevé. La définition de la valeur «all» garantit la protection des pages de cache, y compris l'en-tête. La définition de la valeur «none» désactive le verrouillage des pages.
  |noBootclasspath
    |Empêche le stockage des classes chargées par le chargeur de classes d'amorce dans le cache de classes partagées. Peut-être utilisée avec l'API SharedClassURLFilter pour contrôler avec précision les classes à mettre en cache. Voir le document Diagnostics Guide pour plus d'informations sur le filtrage des classes partagées.
  |cacheRetransformed
    |Active la mise en cache des classes transformées à l'aide de la fonction JVMTI RetransformClasses.
  |noaot
    |Désactive la mise en cache et le chargement du code AOT.

## Création, remplissage, contrôle et suppression d'un cache

Cette section présente le cycle de vie d'un cache contenant des données de classe partagée et contient également des exemples d'utilitaires de gestion de cache.

Pour activer le partage de données de classes, ajoutez -Xshareclasses[:name=<name>] à la ligne de commande de votre application.

La machine virtuelle se connecte alors à un cache existant du nom indiqué ou en crée un de ce nom. Si un nouveau cache est créé, il est rempli avec toutes les classes d'amorce et d'application chargées jusqu'à ce qu'il soit saturé. Si deux machines virtuelles ou plus sont démarrées en même temps, elles remplissent en parallèle le cache.

Pour vérifier que le cache a bien été créé, exécutez `java -Xshareclasses:listAllCaches`. Pour savoir combien de classes et quelle quantité de données sont partagées, exécutez `java -Xshareclasses:[name=<name>],printStats`. (Ces utilitaires peuvent être exécutés au terme de la machine virtuelle de l'application ou dans une autre fenêtre de commande.)

Pour plus de retour d'informations sur l'utilisation du cache lors de l'exécution de la machine virtuelle, utilisez la sous-option verbose. Par exemple, `java -Xshareclasses:[name=<name>],verbose`.

Pour voir les classes chargées depuis le cache ou stockées dedans, ajoutez `-Xshareclasses:[name=<name>],verboseIO` à la ligne de commande de votre application.

Pour supprimer le cache créé, exécutez `java -Xshareclasses:[name=<name>],destroy`. Vous devez uniquement supprimer des caches s'ils contiennent de nombreuses classes périmées ou s'ils sont pleins et que vous souhaitez en créer un plus important.

Il est recommandé de régler la taille du cache pour votre application spécifique car il est peu probable que la valeur par défaut corresponde à la taille optimale. La meilleure méthode de déterminer la taille de cache optimale consiste à indiquer un cache de grande taille (à l'aide de l'option -Xscmx), d'exécuter l'application puis d'utiliser printStats afin de déterminer le montant de données de classe ayant été stockées. Ajoutez une petite quantité à la valeur affichée dans printStats pour la contingence. Etant donné que des classes peuvent être chargées à tout moment lors du cycle de vie de la machine virtuelle, il est préférable d'effectuer cette analyse une fois l'application terminée. Toutefois, un cache saturé n'a aucune répercussion négative sur les performances ou la capacité des machines virtuelles qui y sont connectées. Il peut donc être légitime de définir une taille de cache plus petite que nécessaire.

Si un cache arrive à saturation, un message est émis sur la ligne de commande de toutes les machines virtuelles utilisant la sous-option verbose. Toutes les machines virtuelles partageant ce cache chargeront alors les classes supplémentaires dans leur propre mémoire de processus. Les classes d'un cache saturé peuvent toujours être partagées mais ce dernier est en lecture seule et ne peut plus être mis à jour avec de nouvelles classes.

## Performances et sollicitation de la mémoire

Le partage de données de classes s'avère particulièrement utile sur des systèmes recourant à plusieurs machines virtuelles JVM qui exécutent un même code. Le système profite ainsi de la consommation réduite de mémoire virtuelle. Il est également bienvenu sur des systèmes démarrant et arrêtant souvent des machines virtuelles, profitant du meilleur temps de démarrage.

Le temps système pour créer et remplir un nouveau cache est minimal. Le temps de démarrage des machines virtuelles est généralement de 0 à 5 % supérieur à celui d'un système n'utilisant pas le partage de données de classes, en fonction du nombre de classes chargées. La réduction de ce temps avec un cache rempli oscille entre 10 et 40 % en comparaison avec un système n'utilisant pas le partage de données de classes, selon le système d'exploitation et le nombre de classes chargées. Plusieurs machines virtuelles exécutées de manière simultanée tirent un plus grand parti du temps de démarrage général.

Les classes en double sont consolidées dans le cache de classes partagées. Par exemple, une classe A chargée à partir de myClasses.jar et une classe A chargée à partir de myOtherClasses.jar (au contenu identique) sont stockées une seule fois dans le cache. L'utilitaire printAllStats affiche plusieurs entrées pour les classes en double, chaque entrée pointant vers la même classe.

Lorsque vous exécutez votre application avec le partage de données de classes, vous pouvez employer les outils du système d'exploitation pour constater la baisse de consommation de mémoire virtuelle.

## Considérations et limitations concernant l'utilisation du partage de données de classes

Facteurs à prendre en compte lorsque vous déployez le partage de données de classes dans un produit et utilisez cette option dans un environnement de développement.

### Limites de la taille du cache

La taille de cache théorique maximale est 2 Go. La taille de mémoire cache que vous pouvez spécifier est limitée par l'espace disque disponible ainsi que l'espace d'adresse virtuelle disponible.

La taille du cache est limitée par les facteurs suivants :

- Espace disque disponible. Un fichier est créé pour stocker les données de classes dans un répertoire appelé javasharedresources. Ce répertoire est créé dans le répertoire des profils de l'utilisateur à l'emplacement par défaut C:\Documents and Settings\<username>\Application Data\javasharedresources\. Le fichier partagé est supprimé à chaque redémarrage de Windows.
- Espace d'adresse virtuelle disponible. Etant donné que l'espace d'adresse virtuelle d'un processus est partagé entre le cache de classes partagées et le segment Java, l'augmentation de la taille maximale du segment Java réduit la taille du cache de classes partagées que vous pouvez créer.

### Modification du code intermédiaire d'exécution

Toute machine virtuelle utilisant un agent JVMTI (JVM Tool Interface) capable de modifier des données de code intermédiaire doit utiliser la sous-option modified=<modified_context> afin de partager les classes modifiées avec une autre machine virtuelle.

Le contexte modifié est un descripteur spécifique à l'utilisateur désignant le type de modification effectuée. Le contexte modifié partitionne le cache de sorte à ce que toutes les machines virtuelles exécutées avec le même contexte partagent une partition.

Ce partitionnement permet aux machines virtuelles n'utilisant pas des codes intermédiaires modifiés de partager un cache de manière sécurisée avec celles utilisant des codes intermédiaires modifiés. Toutes les machines virtuelles utilisant un contexte modifié doivent modifier le code intermédiaire de façon prévisible et réitérable ; ainsi, les classes modifiées stockées dans le cache intègrent les modifications attendues lorsqu'elles sont chargées par une autre machine virtuelle. Toute modification doit être prévisible car les classes chargées depuis le cache de classes partagées ne peuvent être à nouveau modifiées par l'agent.

Si un agent JVMTI est utilisé sans contexte de modification, les classes sont toujours partagées de manière sécurisée par la machine virtuelle, mais il y a une petite incidence sur la performance. L'utilisation d'un contexte de modification avec un agent JVMTI rend inutile des vérifications supplémentaires et donc, n'a aucune incidence sur la performance. Un chargeur de classes personnalisé qui étend java.net.URLClassLoader et modifie des codes intermédiaires lors du chargement sans utiliser JVMTI stocke les codes intermédiaires modifiés automatiquement dans le cache, mais celui-ci ne les traite pas comme des codes modifiés. Toute autre machine virtuelle partageant ce cache charge les classes modifiées. La sous-option modified=<contexte_modification> peut être utilisée de la même manière qu'avec les agents JVMTI pour partitionner les codes intermédiaires modifiés dans le cache. Si un chargeur de classes personnalisé doit procéder à des modifications de classes imprévues lors du chargement, ce chargeur de classes ne doit pas utiliser le partage de données de classes.

Voir le document Diagnostics Guide pour en savoir plus à ce sujet.

### Limitations du système d'exploitation

Vous ne pouvez pas partager de classes entre des machines virtuelles 32 et 64 bits. Un espace disque temporaire doit être disponible pour conserver les informations du cache. Les droits d'accès au cache sont appliqués par le système d'exploitation.

Pour les systèmes d'exploitation pouvant exécuter à la fois des applications de 32 et 64 bits, le partage de données de classe n'est pas autorisé entre des machines virtuelles 32 et 64 bits. La sous-option listAllCaches répertorie les caches de 32 et 64 bits, en fonction du mode d'adressage de la machine virtuelle utilisée.

Le cache de classes partagées requiert de l'espace disque pour stocker des informations d'identification sur les caches figurant sur le système. Ces informations se trouvent dans le répertoire du profil utilisateur. Si le répertoire contenant les informations d'identification est supprimé, la machine virtuelle ne peut identifier les classes partagées sur le système et doit créer le cache à nouveau.

Les droits permettant d'accéder à un cache de classe partagée sont appliqués par le système d'exploitation. Si aucun nom de cache n'est précisé, le nom d'utilisateur est ajouté au nom par défaut afin que plusieurs utilisateurs sur le même système créent leurs propres caches par défaut.

### Utilisation de SharedClassPermission

Si un gestionnaire SecurityManager est utilisé avec le partage de données de classes et que l'application en cours utilise ses propres chargeurs de classes, ces derniers doivent dispenser d'autorisations de classes partagés pour pouvoir partager des classes.

Vous ajoutez des autorisations de classes partagées au fichier java.policy en indiquant le nom de classe ClassLoader (les caractères génériques sont admis) et «read», «write» ou «read,write» pour déterminer l'accès accordé. Par exemple :

    permission com.ibm.oti.shared.SharedClassPermission "com.abc.customclassloaders.*", "read,write";

Si ClassLoader ne dispose pas des autorisations correctes, il ne peut partager les classes. Vous ne pouvez pas modifier les autorisations des chargeurs de classes d'extension, d'application ou d'amorçage par défaut.

## Adaptation de chargeurs de classes personnalisés pour partager des classes

Les chargeurs de classes qui étendent java.net.URLClassLoader peuvent partager des classes sans être modifiés. Les chargeurs de classes n'étendant pas java.net.URLClassLoader doivent être adaptés afin de partager les données de classes.

Le droit SharedClassPermissions doit être accordé à tous les chargeurs de classes personnalisés si un gestionnaire de sécurité est utilisé, voir Utilisation de SharedClassPermission. IBM fournit plusieurs interfaces Java pour différents types de chargeurs de classes personnalisés, permettant ainsi à ces derniers de rechercher et stocker des classes dans leur cache de classes partagées. Ces classes se trouvent dans le package com.ibm.oti.shared.

La documentation Java de ce package est fournie avec le SDK dans le répertoire docs/content/apidoc.

Voir le document Diagnostics Guide pour en savoir plus sur le mode d'utilisation de ces interfaces.

# Utilisation de l'API Java Communications (JavaComm)

Le package de l'API Java Communications (JavaComm) est fourni en option et doit être utilisé avec Runtime Environment for Windows. JavaComm doit être installé indépendamment du SDK ou de l'environnement d'exécution.

L'API JavaComm API permet aux applications Java sur toute plateforme d'effectuer des communications de port série et parallèles pour les technologies telles que la messagerie vocale, la télécopie et les cartes à puce.

L'API Java Communications prend en charge les ports série Electronic Industries Association (EIA)-232 (RS232) et les ports parallèles Institute of Electrical and Electronics Engineers (IEEE) 1284. Elle fonctionne sur les systèmes utilisant IBM Version 6 Runtime Environment.

L'API Java Communications vous permet d'effectuer les opérations suivantes :

- Obtenir la liste des ports d'un système
- Ouvrir et obtenir la propriété des ports
- Résoudre les conflits de propriété de port entre les applications utilisant l'API Java Communications
- Effectuer une surveillance de port E-S asynchrone et synchrone par le biais de la notification d'événements
- Recevoir des événements de type bean décrivant les changements d'état sur le port

## Installation de l'API Java Communications à partir d'un fichier compressé

Assurez-vous que le SDK ou l'environnement d'exécution est installé avant de procéder à l'installation de l'API Java Communications.

Pour installer l'API Java Communications à partir d'un fichier compressé, procédez comme suit :

1. Placez le fichier compressé relatif à l'APIJava Communications, ibm-javacomm-3.0-0.0-win-i386.zip, dans le répertoire dans lequel le SDK ou l'environnement d'exécution est installé. Si vous avez choisi d'effectuer l'installation dans le répertoire par défaut, il s'agit de C:\Program Files\IBM\Java60\.
2. Extrayez le fichier compressé. L'API Java Communications est extraite dans des sous-répertoires du répertoire existant.
3. |Copiez les fichiers javacomm dans les répertoires appropriés de votre SDK. | |
   |
   1. Copiezlib\win32com.dll dans le répertoire jre\bin\.
   |
   2. Copiez jar\comm.jar dans le répertoire jre\lib\ext\.
   |
   3. Copiez lib\javax.comm.properties dans le répertoire jre\lib\.
   Par défaut, le SDK est installé dans le répertoireC:\Program Files\IBM\Java60\.
4. |Ajoutez le fichier comm.jar au chemin de classe. Cette opération n'est pas requise lors de l'installation d'un JRE. | |
   |
   - Si aucun chemin d'accès aux classes n'est défini : `set CLASSPATH=\jre\lib\ext\comm.jar`
   |
   - Si un chemin de classe est défini `set CLASSPATH=\jre\lib\ext\comm.jar;%classpath%`

## Configuration de l'API Java Communications

Afin d'utiliser l'API Java Communications, vous devez modifier le mode d'accès des ports série et parallèle et définir le PATH si vous ne l'avait pas déjà fait lors de l'installation de Java.

Voir Définition du PATH.

### Spécification des périphériques dans le fichier javax.comm.properties

Le fichier javax.comm.properties vous permet de définir les préfixes des périphériques rendus disponibles pour l'API Java Communications et d'indiquer s'ils sont parallèles ou série. Les numéros de port sont attribués de manière séquentielle à tous les périphériques.

Par exemple, si vous définissez `/dev/ttyS=PORT_SERIAL` alors que les périphériques `/dev/ttyS0` et `/dev/ttyS1` existent, les ports COM1 et COM2 leur seront attribués.

Pour utiliser les connecteurs USB-série, supprimez la mise en commentaire de la ligne`/dev/ttyUSB=PORT_SERIAL` dans le fichier javax.comm.properties. Si les périphériques `/dev/ttyUSB0` et `/dev/ttyUSB1` existent alors que COM1 et COM2 ont déjà été définis, les ports suivants, COM3 et COM4, sont attribués aux périphériques USB-série.

## Limitation d'impression avec l'API Java Communications

Lors de l'impression avec l'API Java Communications, il se peut que vous deviez appuyer sur le bouton équivalent à «alimentation papier» ou «Continuer» sur l'imprimante.

## Désinstallation de l'API Java Communications

Pour désinstaller l'API Java Communications, supprimez les fichiers suivants du répertoire dans lequel vous avez installé l'environnement d'exécution :

| |
- jre\lib\ext\comm.jar
|
- jre\lib\javax.comm.properties
|
- jre\bin\win32comm.dll

Par défaut, l'environnement d'exécution est installé dans le répertoire C:\Program Files\IBM\Java60\.

## Documentation de l'API Java Communications

Vous trouverez de la documentation et des exemples de l'API Java Communications sur le site Web de Sun.

http://java.sun.com/products/javacomm/.

# Service et prise en charge pour des éditeurs de logiciels indépendants

Points de service :

Si vous avez droit à des services pour le code de programme appartenant à IBM Solutions Developer Program, contactez l'équipe de ce dernier en accédant au site Web à l'adresse :http://www.ibm.com/partnerworld/.

Si vous avez établi un contrat de service (tel qu'IBM Personal Systems Support Line ou équivalent selon le pays), les termes et conditions déterminent les services, le cas échéant, que vous avez le droit de recevoir par rapport au programme.

# Accessibilité

Les guides d'utilisation fournis avec ce SDK et Runtime Environment ont été testés à l'aide de lecteurs d'écran.

Pour modifier la taille des polices des guides d'utilisation, utilisez la fonction fournie par votre navigateur, habituellement située dans le menu Affichage.

Pour les utilisateurs nécessitant une navigation par clavier, une description des touches utiles pour les applications Swing est disponible dans la section Swing Key Bindings sur le site http://www.ibm.com/developerworks/java/jdk/additional/.

## Passage clavier des composants JComboBox dans Swing

Si vous parcourez la liste déroulante d'un composant JComboBox avec les touches fléchées, le bouton ou la zone modifiable du composant JComboBox ne change pas de valeur tant qu'un élément n'est pas sélectionné. Il s'agit du comportement correct de cette version. Il améliore l'accessibilité et augmente la facilité d'utilisation en garantissant que le comportement de passage par clavier soit identique à celui du passage par souris.

## Accessibilité de Web Start

A partir de la version 5.0, Java Web Start comporte plusieurs améliorations de l'accessibilité et de la facilité d'utilisation, qui incluent notamment une meilleure prise en charge des lecteurs d'écran et une navigation par clavier améliorée.

La ligne de commande peut uniquement être utilisée pour lancer une application Java activée pour Web Start. Pour modifier les options des préférences, vous devez éditer le fichier de configuration Application Data\IBM\Java\Deployment\deployment.properties situé dans le répertoire initial de l'utilisateur. Pensez à effectuer une sauvegarde avant de modifier ce fichier. Toutes les préférences pouvant être définies dans l'afficheur de cache de l'application Java ne sont pas disponibles dans le fichier de configuration.

# Remarque générale sur la sécurité

Vous pouvez obtenir des fichiers de règles de compétence illimitée JCE à l'adresse http://www.ibm.com/developerworks/java/jdk/security/index.html. La documentation sur les packages de sécurité IBM JCE, JCEFIPS, JSSE2, JSSEFIPS, JGSS, JAAS et la cryptographie du matériel est également disponible sur ce site Web.

# Commentaires sur le guide d'utilisation

Si vous avez des commentaires sur ce guide d'utilisation, contactez-nous via l'une des voies suivantes. Vous pouvez nous envoyer vos questions "non techniques" ou tout commentaire relatif à notre documentation.

Veuillez nous envoyer vos commentaires :

- par courrier électronique à l'adresse idrcf@hursley.ibm.com.
- par télécopie au numéro :
  - 01962 842327, à partir du Royaume-Uni ;
  - A partir d'un autre pays : +44 1962 842327
- par courrier, à l'adresse suivante :
  IBM United Kingdom Ltd
  User Technologies,
  Mail Point 095
  Hursley Park
  Winchester
  Hampshire
  SO21 2JN
  Royaume-Uni

Mention en petits caractères. Tout commentaire ou document envoyé à IBM tels que les questions, les commentaires, les suggestions ou ce qui est relatif au contenu de tels documents, sera considéré comme non confidentiel. IBM n'est assujettie à aucune sorte d'obligation relative à de telles informations et a le droit de reproduire, utiliser, divulguer, transformer ou créer des produits dérivés sans restriction. En outre, IBM a le droit d'utiliser les idées, concepts, savoir-faire ou techniques contenus dans de tels documents dans un but quelconque, y compris le développement, la fabrication et la commercialisation des produits.

# Annexe A. Options non standard

Les options -X ci-après ne sont pas standard et peuvent être modifiées sans préavis.

Pour les options employant le paramètre <taille>, ajoutez "k" ou "K" au nombre pour indiquer qu'il s'agit de kilo-octets, "m" ou "M" de mégaoctets ou bien "g" ou "G" de gigaoctets.

En ce qu'il s'agit des options employant le paramètre <percentage>, vous devez utiliser un nombre compris entre 0 et 1. Par exemple, 50 % correspond à 0,5.

-Xargencoding
  Vous permet d'intégrer des séquences d'échappement Unicode à la liste d'arguments. Cette option est par défaut désactivée.
-Xbootclasspath:<répertoires et fichiers ZIP ou JAR séparés par le symbole deux points (:)>
  Définit le chemin de recherche pour les classes et ressources d'amorce. Par défaut, les classes et ressources d'amorce sont recherchées dans les fichiers .jar et les répertoires internes de la machine virtuelle.
-Xbootclasspath/a:<répertoires et fichiers ZIP ou JAR séparés par le symbole deux points (:)>
  Ajoute les répertoires, zip ou fichiers jar indiqués à la fin du chemin d'accès aux classes d'amorce. Par défaut, les classes et ressources d'amorce sont recherchées dans les fichiers .jar et les répertoires internes de la machine virtuelle.
-Xbootclasspath/p:<répertoires et fichiers ZIP ou JAR séparés par le symbole deux points (:)>
  Place les répertoires, zip ou fichiers jar indiqués au début du chemin d'accès aux classes d'amorce. Ne déployez pas les applications utilisant l'option -Xbootclasspath: ou -Xbootclasspath/p: pour remplacer une classe dans l'API standard ; en effet, ce déploiement va à l'encontre de la licence du code binaire de Java Runtime Environment. Par défaut, les classes et ressources d'amorce sont recherchées dans les fichiers .jar et les répertoires internes de la machine virtuelle.
|-Xcheck:classpath
  |Affiche un message d'avertissement s'il existe une erreur dans le chemin d'accès aux classes, par exemple, un répertoire ou un fichier JAR manquant.
-Xcheck:gc[:<scan options>][:<verify options>][:<misc options>]
  Effectue des vérifications complémentaires pour la récupération de place. Par défaut, aucune vérification n'est réalisée. Voir la sortie de -Xcheck:gc:help pour plus d'informations.
-Xcheck:jni
  Effectue des vérifications complémentaires pour les fonctions JNI. Par défaut, aucune vérification n'est réalisée.
|-Xcheck:memory[:<option>]
  Identifie les fuites de mémoire à l'intérieur de la machine virtuelle Java à l'aide de vérifications strictes qui entraînent l'arrêt de la machine virtuelle en cas d'échec. Si aucune option n'est définie, le paramètre all est utilisé par défaut. Voir la sortie de -Xcheck:memory:help ou le documentDiagnostics Guide pour plus d'informations.
-Xcheck:nabounds
  Effectue des vérifications complémentaires pour les fonctions JNI. Par défaut, aucune vérification n'est réalisée.
-Xclassgc
  Active la collecte d'objets de classes à chaque récupération de place. Voir aussi -Xnoclassgc. Cette option est activée par défaut.
-Xcodecache<taille>
  Définit la taille des blocs de mémoire utilisés pour stocker le code natif des méthodes Java compilées. Une taille appropriée peut être choisie pour l'application en cours d'exécution. Par défaut, cette taille est sélectionnée en interne selon l'architecture de l'UC et la fonction de votre système.
-Xcompactexplicitgc
  Effectue une compression à chaque appel de `System.gc()`. Voir aussi -Xnocompactexplicitgc. Par défaut, la compression se produit uniquement si elle est déclenchée en interne.
-Xcompactgc
  Effectue une compression à chaque récupération de place. Voir aussi -Xnocompactgc. Par défaut, la compression se produit uniquement si elle est déclenchée en interne.
-Xconcurrentbackground<nombre>
  Indique le nombre d'unités d'exécution d'arrière-plan de faible priorité qui sont associées pour assister les unités d'exécution de mutation lors du marquage concurrent. La valeur par défaut est 1.
-Xconcurrentlevel<nombre>
  Indique le taux de "taxe" d'attribution. Elle indique le rapport entre la quantité de segments de mémoire alloués et celle de segments marqués. La valeur par défaut est 8.
-Xconmeter:<soa|loa|dynamique>
  Détermine l'usage de la zone (LOA ou SOA) qui est mesuré et donc les attributions taxées lors du marquage concurrent. La taxe d'attribution est appliquée à la zone sélectionnée. Si vous entrez -Xconmeter:dynamic, le collecteur identifie de façon dynamique la zone à mesurer en fonction de celle s'épuisant en premier. Par défaut, cette option a la valeur -Xconmeter:soa.
-Xdbg:<options>
  Charge les bibliothèques de débogage pour prendre en charge les applications de débogage éloignées. Voir Débogage des applications Java pour plus d'informations. Le même support est fourni lorsque -Xrunjdwp est défini.
-Xdebug
  Lance la machine virtuelle avec le débogueur activé. Par défaut, le débogueur est désactivé.
-Xdisableexcessivegc
  Désactive le lancement d'une exception OutOfMemoryError si la récupération de place prend trop de temps. Cette option est désactivée par défaut.
-Xdisableexplicitgc
  Signale à la machine virtuelle que des appels de System.gc() seront sans incidence. Par défaut, des appels de System.gc() déclenchent une récupération de place.
-Xdisablestringconstantgc
  Empêche la récupération de chaînes dans la table interne de chaînes. Cette option est désactivée par défaut.
-Xdisablejavadump
  Désactive la génération Javadump en cas d'erreurs et de signaux. Par défaut, la génération Javadump est activée.
-Xenableexcessivegc
  Si la récupération de place dure trop longtemps, cette option renvoie la valeur NULL pour une demande d'allocation et provoque le lancement d'une exception OutOfMemoryError. Cette action se produit uniquement lorsque le segment de mémoire a été totalement étendu et que la récupération de place prend 95 % du temps disponible. Il s'agit du comportement par défaut.
-Xenableexplicitgc
  Signale à la machine virtuelle que des appels de System.gc() déclenchent une récupération de place. Il s'agit du compilateur par défaut.
-Xenablestringconstantgc
  Active les chaînes dans la table interne de chaînes à récupérer. Cette option est activée par défaut.
-Xfuture
  Active des vérifications strictes de format de fichier de classe. Utilisez cette option lors du développement de code car des vérifications plus strictes seront à l'avenir appliquées par défaut. Par défaut, les vérifications strictes de format sont désactivées.
-Xgcpolicy:<optthruput|optavgpause|gencon>
  Contrôle le comportement du récupérateur de place. Voir Options de récupération de place pour plus d'informations.
-Xgcthreads<nombre d'unités d'exécution>
  Définit le nombre de threads auxiliaires employés pour des opérations en parallèle de la récupération de place. Par défaut, le nombre de threads équivaut au nombre d'unités centrales physiques -1, le minimum étant 1.
-Xgcworkpackets<nombre>
  Indique le nombre total de paquets de mots disponibles dans le collecteur. Si elle n'est pas indiquée, le collecteur attribue un nombre de paquets en fonction de la taille maximum du segment de mémoire.
-Xint
  Fait que la machine virtuelle Java utilise uniquement l'interpréteur, en désactivant le compilateur JIT (Just-In-Time). Par défaut, le compilateur JIT est activé.
-Xiss<taille>
  Définit la taille initiale de la pile d'unités d'exécution Java. 2 Ko par défaut. Utilisez l'option -verbose:sizes pour identifier la valeur utilisée par la machine virtuelle Java.
|-Xjarversion
  |Voir Obtention des informations de version.
-Xjit[:<suboption>,<suboption>...]
  Active le compilateur JIT. Pour en savoir plus sur les sous-options, voir le document Diagnostics Guide. Voir aussi -Xnojit. Par défaut, il est activé.
-Xlinenumbers
  Affiche les numéros de lignes dans les traces de pile pour le débogage. Voir aussi -Xnolinenumbers. Par défaut, les numéros de lignes sont activés.
-Xloa
  Attribue une zone d'objets volumineux, également appelée zone LOA. Les objets seront allouées dans cette zone et non dans la zone SOA. Par défaut, la zone LOA est activée pour les toutes les règles de récupération de place, sauf pour le sous-pool dans lequel la zone LOA n'est pas disponible. Voir aussi -Xnoloa.
-Xloainitial<pourcentage>
  <pourcentage> est compris entre 0 et 0,95 et représente le pourcentage initial de l'espace de conservation alloué à la zone d'objets volumineux (LOA). La valeur par défaut est 0,05 ou 5 %.
-Xloamaximum<pourcentage>
  <pourcentage> est compris entre 0 et 0,95 et représente le pourcentage maximal de l'espace de conservation alloué à la zone d'objets volumineux (LOA). La valeur par défaut est 0,5 ou 50 %.
-Xlp (Windows 2003)
  Demande à la machine virtuelle Java d'allouer le segment de mémoire Java avec de grandes pages. Si celles-ci ne sont pas disponibles, la machine virtuelle Java ne démarre pas et affiche le message d'erreur `GC: system configuration does not support option --> '-Xlp'`. Les grandes pages sont prises en charge sur les systèmes Windows 2003, où le système d'exploitation a été configuré pour utiliser des grandes pages. Par défaut, les grandes pages ne sont pas utilisées. Voir Configuration de l'allocation de mémoire à grandes pages.
-Xmaxe<taille>
  Définit la quantité maximum d'augmentation du segment de mémoire par le récupérateur de place. En général, le récupérateur de place augmente le segment de mémoire lorsque la quantité d'espace libre est inférieure à 30 % (ou la quantité indiquée avec -Xminf). Cette augmentation est la quantité requise pour restaurer l'espace libre à 30 %. L'option -Xmaxe limite l'augmentation à la valeur indiquée ; par exemple `-Xmaxe10M` limite l'augmentation à 10 Mo. Par défaut, il n'existe pas de taille d'augmentation maximum.
-Xmaxf<pourcentage>
  Indique le pourcentage maximum de segment de mémoire devant être libéré après une récupération de place. Si cet espace dépasse cette quantité, la machine virtuelle Java tente de réduire le segment de mémoire. La valeur par défaut est 0,6 (60 %).
-Xmca<taille>
  Définit l'ampleur d'augmentation de la mémoire allouée pour stocker la partie RAM des classes chargées. Chaque fois que plus de mémoire est requise pour stocker des classes dans la mémoire RAM, la mémoire allouée est augmentée de cette quantité. Par défaut, l'ampleur d'augmentation est de 32 Ko. Utilisez l'option -verbose:sizes pour identifier la valeur utilisée par la machine virtuelle Java.
-Xmco<taille>
  Définit l'ampleur d'augmentation de la mémoire allouée pour stocker la partie ROM des classes chargées. Chaque fois que plus de mémoire est requise pour stocker des classes dans la mémoire ROM, la mémoire allouée est augmentée de cette quantité. Par défaut, l'ampleur d'augmentation est de 128 Ko. Utilisez l'option -verbose:sizes pour identifier la valeur utilisée par la machine virtuelle Java.
-Xmine<taille>
  Définit la quantité minimum d'augmentation du segment de mémoire par le récupérateur de place. En général, le récupérateur de place augmente le segment de mémoire de la quantité requise pour restaurer l'espace libre à 30 % (ou la quantité indiquée avec -Xminf). L'option -Xmine spécifie que l'extension doit être au moins égale à la valeur spécifiée (par exemple `-Xmine50M` affecte 50 Mo comme taille d'extension minimale). Par défaut, la taille d'augmentation minimum est de 1 Mo.
-Xminf<pourcentage>
  Indique le pourcentage minimum de segment de mémoire devant être libéré après une récupération de place. Si cet espace est inférieur à cette quantité, la machine virtuelle Java tente d'augmenter le segment de mémoire. Par défaut, la valeur minimum est de 0,3 (30 %).
-Xmn<taille>
  Définit la taille initiale et maximum du nouveau segment de mémoire (nursery) à la valeur indiquée lors de l'utilisation de -Xgcpolicy:gencon. Le paramétrage de -Xmn revient à définir -Xmns et -Xmnx. Si vous définissez -Xmns ou -Xmnx, vous ne pouvez pas définir -Xmn. Si vous tentez de définir -Xmn avec -Xmns ou -Xmnx, la machine virtuelle ne démarre pas et renvoie une erreur. Par défaut, -Xmn est sélectionnée en interne selon la fonction de votre système. Utilisez l'option -verbose:sizes pour identifier la valeur utilisée par la machine virtuelle Java.
-Xmns<taille>
  Définit la taille initiale du nouveau segment de mémoire (nursery) à la valeur indiquée lors de l'utilisation de -Xgcpolicy:gencon. Par défaut, cette option est sélectionnée en interne selon la fonction de votre système. Cette option renvoie une erreur si vous tentez de l'utiliser avec -Xmn. Utilisez l'option -verbose:sizes pour identifier la valeur utilisée par la machine virtuelle Java.
-Xmnx<taille>
  Définit la taille maximale du nouveau segment de mémoire (nursery) à la valeur indiquée lors de l'utilisation de -Xgcpolicy:gencon. Par défaut, cette option est sélectionnée en interne selon la fonction de votre système. Cette option renvoie une erreur si vous tentez de l'utiliser avec -Xmn. Utilisez l'option -verbose:sizes pour identifier la valeur utilisée par la machine virtuelle Java.
-Xmo<taille>
  Définit la taille initiale et maximum de l'ancien segment de mémoire (conservation) à la valeur indiquée lors de l'utilisation de -Xgcpolicy:gencon. Revient à définir -Xmos et -Xmox. Si vous définissez -Xmos ou -Xmox, vous ne pouvez pas définir -Xmo. Si vous tentez de définir -Xmo avec -Xmos ou -Xmox, la machine virtuelle ne démarre pas et renvoie une erreur. Par défaut, -Xmo est sélectionnée en interne selon la fonction de votre système. Utilisez l'option -verbose:sizes pour identifier la valeur utilisée par la machine virtuelle Java.
-Xmoi<taille>
  Définit la quantité d'incrément du segment de mémoire Java lors de l'utilisation de -Xgcpolicy:gencon. S'il s'agit de zéro, aucune augmentation n'est autorisée. Par défaut, la taille d'incrément est calculée par rapport à celle d'augmentation, -Xmine et -Xminf.
-Xmos<taille>
  Définit la taille initiale de l'ancien segment de mémoire (conservation) à la valeur indiquée lors de l'utilisation de -Xgcpolicy:gencon. Par défaut, cette option est sélectionnée en interne selon la fonction de votre système. Cette option renvoie une erreur si vous tentez de l'utiliser avec -Xmo. Utilisez l'option -verbose:sizes pour identifier la valeur utilisée par la machine virtuelle Java.
-Xmox<taille>
  Définit la taille maximale de l'ancien segment de mémoire (conservation) à la valeur indiquée lors de l'utilisation de -Xgcpolicy:gencon. Par défaut, cette option est sélectionnée en interne selon la fonction de votre système. Cette option renvoie une erreur si vous tentez de l'utiliser avec -Xmo. Utilisez l'option -verbose:sizes pour identifier la valeur utilisée par la machine virtuelle Java.
-Xmr<taille>
  Définit la taille de l'ensemble de tâches à faire pour la récupération de place lors de l'utilisation de -Xgcpolicy:gencon. Il s'agit d'une liste d'objets dans l'ancien segment de mémoire (conservation) ayant des références à des objets dans le nouveau segment de mémoire (nursery). Par défaut, cette option est de 16 kilo-octets. Utilisez l'option -verbose:sizes pour identifier la valeur utilisée par la machine virtuelle Java.
-Xmrx<taille>
  Définit le paramètre de taille maximum mémorisé.
-Xms<taille>
  Définit la taille initiale du segment de mémoireJava. Vous pouvez également utiliser -Xmo. La valeur par défaut est définie en interne selon la fonction de votre système. Utilisez l'option -verbose:sizes pour identifier la valeur utilisée par la machine virtuelle Java.
-Xmso<taille>
  Définit la taille de la pile C pour les unités d'exécution Java créées par fork. Par défaut, cette option est définie à 32 Ko sur les plateformes 32 bits et à 256 Ko sur des plateformes 64 bits. Utilisez l'option -verbose:sizes pour identifier la valeur utilisée par la machine virtuelle Java.
-Xmx<taille>
  Définit la taille maximum du segment de mémoire Java. Par défaut, cette option est définie en interne selon la fonction de votre système. Utilisez l'option -verbose:sizes pour identifier la valeur utilisée par la machine virtuelle Java.
-Xnoclassgc
  Désactive la récupération de place pour les classes. Cette option désactive la récupération de place pour le stockage associé aux classes Java qui ne sont plus utilisées par la machine virtuelle Java. Voir aussi-Xclassgc. Par défaut, la collecte des classes pour la récupération de place est effectuée.
-Xnocompactexplicitgc
  Désactive la compression à un appel de `System.gc()`. Voir aussi -Xcompactexplicitgc. Par défaut, la compression est activée lors d'appels de `System.gc()`.
-Xnocompactgc
  Désactive la compression pour le récupérateur de place. Voir aussi -Xcompactgc. Par défaut, la compression est activée.
-Xnojit
  Désactive le compilateur JIT. Voir aussi -Xjit. Par défaut, le compilateur JIT est activé.
-Xnolinenumbers
  Désactive les numéros de lignes pour le débogage. Voir aussi -Xlinenumbers. Par défaut, les numéros de lignes sont activés.
-Xnoloa
  Empêche l'attribution d'une zone d'objets volumineux. Tous les objets sont attribués dans la zone SOA. Par défaut, la zone LOA est activée pour les toutes les règles de récupération de place, sauf pour le sous-pool dans lequel la zone LOA n'est pas disponible. Voir aussi -Xloa.
-Xnopartialcompactgc
  Désactive la compression incrémentielle. Voir aussi -Xpartialcompactgc.
-Xnosigcatch
  Désactive le code de gestion du signal de la machine virtuelle Java. Voir aussi -Xsigcatch. Par défaut, la gestion du signal est activée.
-Xnosigchain
  Désactive le chaînage du gestionnaire de signal. Voir aussi -Xsigchain. Par défaut, le chaînage du gestionnaire de signal est activé.
-Xoptionsfile=<fichier>
  Indique le fichier contenant les options de la machine virtuelle Java et le définit. Par défaut, aucun fichier d'options n'est utilisé.
-Xoss<taille>
  Définit la taille de la pile Java ainsi que la taille de la pile C pour les unités d'exécution. Cette option est fournie pour la compatibilité et équivaut à attribuer la valeur indiquée à -Xss et-Xmso.
-Xpartialcompactgc
  Active la compression partielle. Par défaut, cette option n'est pas définie et toutes les compressions sont complètes. Voir aussi -Xnopartialcompactgc.
-Xquickstart
  Améliore le temps de démarrage en retardant la compilation JIT et les optimisations. Par défaut, le démarrage rapide est désactivé et la compilation JIT est immédiate.
-Xrdbginfo:<hôte>:<port>
  Charge et transmet des options au serveur d'informations de débogage éloigné. Par défaut, le serveur d'informations de débogage éloigné est désactivé.
-Xrs
  Réduit l'utilisation des signaux du système d'exploitation. Par défaut, la machine virtuelle utilise complètement les signaux du système d'exploitation ; voir Signaux utilisés par la JVM.
-Xrun<nom de bibliothèque>[:<options>]
  Charge des bibliothèques auxiliaires. Pour charger plusieurs bibliothèques, indiquez-les à la ligne de commande. Exemples de bibliothèques :
  -Xrunhprof[:help] | [:<option>=<valeur>, ...]
    Définit le profil du segment de mémoire, de l'unité centrale ou du moniteur. Pour plus d'informations, consultez le document Diagnostics Guide.
  -Xrunjdwp[:help] | [:<option>=< valeur>, ...]
    Charge les bibliothèques de débogage pour prendre en charge les applications de débogage éloignées. Voir -Xdbg pour plus d'informations.
  -Xrunjnichk[:help] | [:<option>=<valeur>, ...]
    Obsolète, utilisez -Xcheck:jni.
-Xscmx<taille>
  Pour en savoir plus sur -Xscmx, voir Activation et configuration du partage de données de classes.
-Xshareclasses:<options>
  Pour en savoir plus sur les options -Xshareclasses, voir Activation et configuration du partage de données de classes.
-Xsigcatch
  Active le code de gestion du signal de la machine virtuelle. Voir aussi -Xnosigcatch. Par défaut, la gestion du signal est activée.
-Xsigchain
  Active le chaînage du gestionnaire de signal. Voir aussi -Xnosigchain. Par défaut, le chaînage du gestionnaire de signal est activé.
-Xsoftrefthreshold<nombre>
  Définit le nombre de récupérations de place au terme desquelles une référence est effacée si l'élément concerné n'a pas été marqué. La valeur par défaut est 3, ce qui signifie qu'à la troisième récupération de place sans marquage de l'élément, une référence est supprimée.
-Xss<taille>
  Définit la taille de pileJava maximale pour les unités d'exécution. Par défaut, cette option est définie à 256 Ko. Utilisez l'option -verbose:sizes pour identifier la valeur utilisée par la machine virtuelle Java.
-Xthr:<options>
  Définit les options de threads.
-Xverbosegclog:<chemin d'accès au fichier>[X,Y]

  Force l'écriture de la sortie de récupération de place en mode prolixe dans le fichier spécifié. Si ce fichier existe, la sortie remplace son contenu. Si ce fichier existe mais qu'il ne peut pas être ouvert ou s'il est impossible de créer un nouveau fichier, la sortie est redirigée sur l'erreur standard. Si vous définissez les arguments entiers X et Y, la sortie de la récupération de place en mode prolixe est redirigée vers un nombre X de fichiers, chaque fichier contenant un nombre Y de cycles gc pouvant générer une sortie verbose. Ces fichiers sont nommés nomfichier1, nomfichier2, etc. Par défaut, aucune consignation de la récupération de place en mode prolixe n'a lieu.

  Voir le document Diagnostics Guide pour en savoir plus sur la sortie de la récupération de place en mode prolixe.

-Xverify
  Active la vérification stricte de chaque classe chargée. Par défaut, cette vérification est désactivée.
-Xverify:none
  Désactive la vérification stricte des classes. Par défaut, cette vérification est désactivée.

# Annexe B. Restrictions connues

Restrictions d'utilisation de SDK et Runtime Environment pour Windows.

Pour plus d'informations sur la procédure de diagnostic, reportez-vous au document Diagnostics Guide à l'adresse http://www.ibm.com/developerworks/java/jdk/diagnosis/60.html.

## Problèmes relatifs à la police dans les paramètres nationaux pris en charge

IBM 32-bit SDK pour Windows, v6 prend en charge les paramètres nationaux suivants :

- Bengali (bn_IN)
- Malayalam (ml_IN)
- Oriya (or_IN)

Les polices associées peuvent cependant ne pas fonctionner sur les composants AWT.

## Utilisation de sockets avec IPv6

IBM 32-bit SDK pour Windows, v6 prend en charge IPv6. Cependant, la prise en charge actuelle d'IPv6 dans Windows n'étant pas à double pile, le SDK émule le comportement de double pile sur le système compatible IPv6. Votre application Java peut utiliser jusqu'à deux fois le nombre de connecteurs en raison de la nature de l'émulation. Pour désactiver cette émulation, désactivez la prise en charge IPv6 dans le SDK en attribuant la valeur `true` à la propriété système java.net.preferIPv4Stack.

## Onglet Local de l'outil de contrôle JConsole

Dans l'outil JConsole d'IBM, l'onglet Local qui permet de se connecter à d'autres machines virtuelles sur le même système n'est pas disponible. De plus, l'option pid de la ligne de commande correspondante n'est pas prise en charge. A la place, utilisez l'onglet Remote dans JConsole pour vous connecter à la machine virtuelle à contrôler. Vous pouvez également utiliser l'option de ligne de commande connection, en indiquant un numéro de port et un hôte `localhost`. Lorsque vous lancez l'application à contrôler, définissez les options de ligne de commande :

-Dcom.sun.management.jmxremote.port=<value>
  Définit le port sur lequel l'agent de gestion doit écouter.
-Dcom.sun.management.jmxremote.authenticate=false
  Désactive l'authentification sauf si vous avez créé un fichier de noms d'utilisateur.
-Dcom.sun.management.jmxremote.ssl=false
  Désactive le chiffrement SSL.

## Moteur Rhino Javascript non disponible

Le moteur Mozilla Rhino Javascript n'est pas inclus dans IBM SDK pour Java en raison des problèmes liés aux licences. Pour utiliser le moteur Rhino Javascript avec IBM SDK for Java, téléchargez le moteur de script jsr223 depuis https://scripting.dev.java.net/ et le moteur Rhino Javascript depuis le site Web Mozilla : http://www.mozilla.org/rhino/.

## IME (Input Method Editor)

Lorsque vous utilisez un IME (Input Method Editor), il est conseillé de terminer la composition des caractères et de sélectionner le candidat avant d'utiliser l'espace de travail pour toute autre opération.

Lorsqu'un utilisateur saisit du texte dans une zone de texte AWT à l'aide d'un éditeur IME et qu'il redimensionne la fenêtre de l'application avant de valider le texte, ce dernier est validé automatiquement.

## Création de paires de clés DSA sur des machines lentes

La création de paires de clés DSA de longueurs inhabituelles peut prendre longtemps sur des machines lentes. L'attente ne doit pas être interprétée comme un blocage ; si vous patientez, vous verrez que le processus aboutit. L'algorithme de génération de clés DSA a été optimisé pour obtenir des longueurs standard (par exemple, 512, 1024) plus rapidement que d'autres.

## Pare-feu

Les pare-feu peuvent poser problème pour le code NIO Windows, notamment provoquer l'échec de certaines opérations. Par exemple, l'appel de la méthodeSelector.open() peut émettre l'exception «java.io.IOException: Unable to establish loopback connection» avec la cause «java.net.ConnectException: Connection refused: connect». Cette exception est due à la connexion du système d'exploitation à un port bloqué par le pare-feu. La machine JVM tente une nouvelle fois l'opération de connexion en demandant au système d'exploitation de choisir un numéro de port différent. Si après plusieurs tentatives la connexion n'est toujours pas possible, une exception de connexion est émise.

Dans ce cas, vous pouvez définir la propriété système java.nio.debug=pipe pour déterminer les numéros de port bloqués.

## Saturation du descripteur de fichier

Sous Windows 2000 et XP, la valeur par défaut du nombre de fichiers pouvant être simultanément ouverts étant trop basse, et les applications dont l'activité d'entrée-sortie est intensive connaîtront des difficultés. Pour résoudre cette limitation, modifiez le fichier <windows>\system32\CONFIG.NT et définissez les valeurs suivantes :

    files=200
    buffers=60

où <windows> correspond au répertoire d'installation de Windows.

## Problèmes relatifs au mécanisme DirectDraw et au pointeur de la souris

Sous Windows 2000, avec une profondeur de couleur de 32 bits, le mécanisme DirectDraw de la machine virtuelle ne repeint pas la zone sous le pointeur. Des carrés gris ou noirs apparaissent donc sur les menus que le pointeur de la souris a passés. La solution consiste à désactiver le tracé direct (-Dsun.java2d.noddraw) ou à changer de résolution d'écran (par exemple 256 couleurs).

## Problèmes liés à la connexion NIO

L'appel NIO SocketChannel finishConnect() peut renvoyer la valeur `true` (le canal est connecté) ou `false` (le processus de connexion n'a pas encore abouti), ou bien lancer une exception. Sous Windows 2000, lorsque vous utilisez des connexions non bloquantes, la valeur `false` peut être renvoyée même si un appel select() Java a auparavant impliqué qu'un canal est prêt pour traitement.

## Intervalle de pile de l'unité d'exécution principale

Vous ne pouvez pas modifier l'intervalle de pile de l'unité d'exécution principale (primordiale) Java lors de l'exécution. Le thread principal possède une taille fixe de 256 kilobits, la valeur optimale pour des raisons de performances. Vous pouvez utiliser l'option -Xss pour modifier l'intervalle de pile uniquement sur des threads autres que le principal. N'utilisez pas l'unité d'exécution principale pour des calculs hautement récursifs car cette dernière est plus enclin que les autres au dépassement de pile.

## Caractères DBCS

Si vous entrez des caractères DBCS dans un JTextArea, JTextField ou JFileChooser, en passant d'un IME chinois (en particulier de Chinese Internal Code et de Zhengma) à un IME Intelligent ABC, vous risquez de provoquer un vidage mémoire.

## Installation relative à la langue tchèque

Pour les utilisateurs tchèques, le panneau de sélection de la langue du programme InstallShield comporte une entrée traduite, alors que l'installation n'est pas localisée. Cette limitation provient du programme InstallShield. La chaîne est extraite du système d'exploitation en fonction de la page de codes. Comme le polonais (dont l'installation est traduite) et le tchèque ont la page de code 1250, InstallShield tente de récupérer une liste de langues du système pour les deux, d'où la présence de cette chaîne.

## Chinois traditionnel et la commande more

Les utilisateurs travaillant en chinois traditionnel ne doivent pas diriger la sortie de l'application Java directement dans la commande more. Ils doivent à la place diriger la sortie vers un fichier temporaire et l'afficher à part.

## Corruption des lettres accentuées pour les utilisateurs catalans

Les utilisateurs catalans doivent employer la police Lucida Console afin d'éviter la corruption des lettres capitales accentuées. Concerne uniquement les utilisateurs de Windows 2000.

## Exception NullPointerException avec GTK Look and Feel

Environnements DBCS uniquement

Si votre application échoue en raison d'une exception NullPointerException avec GTK Look and Feel, désactivez la variable d'environnement GNOME_DESKTOP_SESSION_ID.

## Alias de page de codes Unicode Shift_JIS

Utilisateurs japonais uniquement

L'alias de page de codes Unicode «\u30b7\u30d5\u30c8\u7b26\u53f7\u5316\u8868\u73fe» pour Shift_JIS a été supprimé. Si vous utilisez cette page de codes dans vos applications, remplacez-la par Shift_JIS.

# Remarques

Le présent document peut contenir des informations ou des références concernant certains produits, logiciels ou services IBM non annoncés dans ce pays. Pour plus de détails, référez-vous aux documents d'annonce disponibles dans votre pays, ou adressez-vous à votre partenaire commercial IBM.

Toute référence à un produit, logiciel ou service IBM n'implique pas que seul ce produit, logiciel ou service puisse être utilisé. Tout autre élément fonctionnellement équivalent peut être utilisé, s'il n'enfreint aucun droit d'IBM. Il est de la responsabilité de l'utilisateur d'évaluer et de vérifier lui-même les installations et applications réalisées avec des produits, logiciels ou services non expressément référencés par IBM.

IBM peut détenir des brevets ou des demandes de brevet couvrant les produits mentionnés dans le présent document. La remise de ce document ne vous donne aucun droit de licence sur ces brevets ou demandes de brevet. Vous pouvez envoyer, par écrit, vos demandes de renseignements relatives aux licences au :

- IBM Director of Licensing
- IBM Corporation
- North Castle Drive, Armonk
- NY 10504-1758 U.S.A.

Les informations sur les licences concernant les produits utilisant un jeu de caractères double octet peuvent être obtenues par écrit à l'adresse suivante :

- IBM World Trade Asia Corporation Licensing
- 2-31 Roppongi 3-chome, Minato-ku
- Tokyo 106-0032, Japon

Le paragraphe suivant ne s'applique ni au Royaume-Uni, ni dans aucun autre pays dans lequel il serait contraire aux lois locales.

LE PRESENT DOCUMENT EST LIVRE EN L'ETAT. IBM DECLINE TOUTE RESPONSABILITE, EXPLICITE OU IMPLICITE, RELATIVE AUX INFORMATIONS QUI Y SONT CONTENUES, Y COMPRIS EN CE QUI CONCERNE LES GARANTIES DE VALEUR MARCHANDE OU D'ADAPTATION A VOS BESOINS. Certaines juridictions n'autorisent pas l'exclusion des garanties implicites, auquel cas l'exclusion ci-dessus ne vous sera pas applicable.

Le présent document peut contenir des inexactitudes ou des coquilles. Il est mis à jour périodiquement. Chaque nouvelle édition inclut les mises à jour. IBM peut modifier sans préavis les produits et logiciels décrits dans ce document.

Les références à des sites Web non IBM sont fournies à titre d'information uniquement et n'impliquent en aucun cas une adhésion aux données qu'ils contiennent. Les éléments figurant sur ces sites Web ne font pas partie des éléments du présent produit IBM et l'utilisation de ces sites relève de votre seule responsabilité.

IBM pourra utiliser ou diffuser, de toute manière qu'elle jugera appropriée et sans aucune obligation de sa part, tout ou une partie des informations qui lui seront fournies.

Les licenciés souhaitant obtenir des informations permettant : (i) l'échange des données entre des logiciels créés de façon indépendante et d'autres logiciels (dont celui-ci), et (ii) l'utilisation mutuelle des données ainsi échangées, doivent adresser leur demande à :

- JIMMAIL@uk.ibm.com
- [Hursley Java Technology Center (JTC) contact]

Ces informations peuvent être soumises à des conditions particulières, prévoyant notamment le paiement d'une redevance.

Le logiciel sous licence décrit dans ce document et tous les éléments sous licence disponibles s'y rapportant sont fournis par IBM conformément aux termes du Contrat sur les produits et services IBM, des Conditions internationales d'utilisation des logiciels IBM ou de tout autre accord équivalent.

Les données de performance indiquées dans ce document ont été déterminées dans un environnement contrôlé. Par conséquent, les résultats peuvent varier de manière significative selon l'environnement d'exploitation utilisé. Certaines mesures évaluées sur des systèmes en cours de développement ne sont pas garanties sur tous les systèmes disponibles. En outre, elles peuvent résulter d'extrapolations. Les résultats peuvent donc varier. Il incombe aux utilisateurs de ce document de vérifier si ces données sont applicables à leur environnement d'exploitation.

Les informations concernant des produits non IBM ont été obtenues auprès des fournisseurs de ces produits, par l'intermédiaire d'annonces publiques ou via d'autres sources disponibles. IBM n'a pas testé ces produits et ne peut confirmer l'exactitude de leurs performances ni leur compatibilité. Elle ne peut donc recevoir aucune réclamation concernant des produits non IBM. Toute question concernant les performances de produits non IBM doit être adressée aux fournisseurs de ces produits.

## Marques

IBM, AIX, developerWorks, eServer, iSeries, MVS, POWER4, POWER5+, PowerPC, pSeries, System i, System p, System z, WebSphere, System z9, z/OS, et zSeries sont des marques ou des marques déposées d'International Business Machines Corporation aux Etats-Unis et/ou dans certains autres pays.

Intel est une marque de Intel Corporation aux Etats-Unis et/ou dans certains autres pays.

Java ainsi que tous les logos et marques incluant Java, sont des marques déposées de Sun Microsystems, Inc. aux Etats-Unis et/ou dans certains autres pays.

Microsoft, Windows et le logo Windows sont des marques de Microsoft Corporation aux Etats-Unis et/ou dans certains autres pays.

Linux est une marque de Linus Torvalds aux Etats-Unis et/ou dans certains autres pays.

Les autres noms de sociétés, de produits et de services peuvent appartenir à des tiers.