# IBM SDK et Runtime Environment pour plateformes Linux, Java 2 Technology Edition, Version 5.0

# Guide d'utilisation

# Notice de copyright

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

Cette édition du guide utilisateur s'applique aux programmes suivants :

- IBM 32-bit SDK and Runtime Environment for Linux sur architecture Intel, Java 2 Technology Edition, Version 5.0
- IBM 64-bit SDK and Runtime Environment for Linux sur architecture AMD64/EM64T, Java 2 Technology Edition, Version 5.0
- IBM 32-bit SDK and Runtime Environment for Linux sur iSeries et pSeries, Java 2 Technology Edition, Version 5.0
- IBM 64-bit SDK and Runtime Environment for Linux sur iSeries et pSeries, Java 2 Technology Edition, Version 5.0
- IBM 31-bit SDK and Runtime Environment for Linux sur zSeries, Java 2 Technology Edition, Version 5.0
- IBM 64-bit SDK and Runtime Environment for Linux sur zSeries, Java 2 Technology Edition, Version 5.0

et à toutes les versions et modifications suivantes, sauf indication contraire dans les nouvelles éditions.

(c) Copyright Sun Microsystems, Inc. 1997, 2004, 901 San Antonio Rd., Palo Alto, CA 94303 USA. All Rights Reserved.

(c) Copyright International Business Machines Corporation, 1999, 2005. All Rights Reserved.

U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

# Préface

Ce guide utilisateur fournit des informations générales sur IBM SDK et Runtime Environment pour plateformes Linux, Java 2 Technology Edition, Version 5.0 et d'autres 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 : http://java.sun.com.

Pour obtenir la liste des distributions dans lesquelles SDK et Runtime Environment for Linux ont été testées, reportez-vous au site : http://www-106.ibm.com/developerworks/java/jdk/linux/tested.html.

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

Les termes "Runtime Environment" et "machine virtuelle Java" sont utilisés indifféremment dans ce guide.

Les modifications techniques apportées à ce guide pour la version 5.0, autres que les changements mineurs ou évidents, tels que la mise à jour de "1.4.2" à "5.0", sont signalées en rouge au format HTML ou dans une impression en couleur et par des barres verticales à leur gauche.

# Table des matières

Notice de copyright
Préface
Généralités
Conventions
Compatibilité des versions
Mise à niveau du SDK
Migration à partir d'autres machines JVM IBM
| |
Matériel pris en charge pour zSeries
Sommaire du SDK et de Runtime Environment
Outils d'environnement d'exécution
Outils SDK
Installation et configuration de SDK et de Runtime Environment
Installation sous Red Hat Enterprise Linux (RHEL) 4
| |
Installation d'un SDK 32 bits sur une architecture 64 bits
Installation à partir d'un fichier RPM
Installation à partir d'un fichier .tgz
Configuration du SDK et de Runtime Environment pour Linux
Définition du PATH
Définition du CLASSPATH
Désinstallation de SDK et de Runtime Environment pour Linux
Désinstallation du package RPM
Désinstallation du package TAR compressé
Utilisation du Runtime Environment
Options
Indication des options Java et des propriétés système
Options standard
Options non standard
Obtention du numéro de compilation et de version IBM
Globalisation de la commande java
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
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
Utilisation de piles flottantes
Transformation de documents XML
Utilisation d'une ancienne version de Xerces ou Xalan
Utilisation de SDK pour développer des applications Java
Débogage des applications Java
Débogueur Java (JDB)
Détermination si votre application s'exécute sur une machine virtuelle Java 32 bit ou 64 bit
Ecriture d'applications JNI
| |
Prise en charge de la restauration de connecteurs bloqués au niveau de l'unité d'exécution
Utilisation d'applets
Exécution d'applets à l'aide d'Applet Viewer
Débogage d'applets à l'aide d'Applet Viewer
| |
Configuration de l'allocation de mémoire à grandes pages
Prise en charge de CORBA
Prise en charge de GIOP 1.2
Prise en charge des intercepteurs portables
Prise en charge d'INS (Interoperable Naming Service)
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 2 pour l'ORB
Classes d'implémentation ORB
RMI sur IIOP
Implémentation du pool de gestionnaires de connexion pour RMI
Prise en charge bidirectionnelle améliorée
Big Decimal amélioré
Prise en charge du symbole Euro
Utilisation de l'API Java Communications (JavaComm)
Installation de l'API Java Communications
Emplacement des fichiers de l'API Java Communications
Configuration de l'API Java Communications
Modification du mode d'accès des ports série et parallèles
Activation des ports série sur IBM ThinkPad
Limitation d'impression avec l'API Java Communications
Désinstallation de l'API Java Communications
Désinstallation du module RMP (Red Hat Package Manager) installable
Désinstallation du module TAR (Tape Archive) condensé
Documentation de l'API Java Communications
Déploiement des applications Java
(Linux IA 32 bits et PPC32 uniquement) Utilisation du plug-in Java
Navigateurs pris en charge
Installation et configuration de l'extension Java
Prise en charge du modèle DOM (Document Object Model) commun
Utilisation des paramètres DBCS
(Linux IA 32 bits, PPC32 et PPC64 uniquement) Utilisation de Java Web Start
Exécution de Web Start
Livraison d'applications Java
| |
Partage de données de classes entre JVM
| |
Présentation du partage de classes
| |
Contenu du cache
| |
Mise à jour dynamique du cache
| |
Activation du partage de classes
| |
Sécurité du cache
| |
Durée de vie du cache
| |
Utilitaires du cache
| |
Utilisation d'options de ligne de commande pour le partage de classes
| |
Création, remplissage, contrôle et suppression d'un cache
| |
Performances et sollicitation de la mémoire
| |
Limitations et considérations concernant l'utilisation du partage des classes
| |
Limites de la taille du cache
| |
Modification du code intermédiaire d'exécution
| |
Limitations du système d'exploitation
| |
Utilisation de SharedClassPermissions
| |
Adaptation de chargeurs de classes personnalisés pour partager des classes
Service et prise en charge pour des éditeurs de logiciels indépendants
Accessibilité
Accessibilité iKeyman
Passage clavier des composants JComboBox dans Swing
(Linux IA 32 bits, PPC32 et PPC64 uniquement) Accessibilité de Web Start
Restrictions d'utilisation
Limitations applicables à toutes les plateformes Linux, sauf indication contraire
Limitations de Linux IA 32 bits
Limitations Linux AMD64
Limitations de Linux PPC 32 bits et 64 bits
Limitations de Linux PPC 64 bits
Limitations de Linux zSeries 64 bits
Limitations Linux zSeries 31 et 64 bits
Commentaires sur le guide utilisateur
Remarques
Marques

# 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 à l'API IBM Java 5.0 Core Application Program Interface.

Il inclut Runtime Environment for Linux, 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 .so non débogablesles 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. Runtime Environment for Linux n'inclut aucun des outils de développement, tels que appletviewer ou le compilateur Java (javac), ni les classes destinées aux systèmes de développement uniquement.

En outre, pour les plateformes IA32, PPC32 et AMD64/EM64T,le module de l'API Java Communications est fourni pour une utilisation avec Runtime Environment for Linux. Vous pouvez trouver des informations à ce sujet dans Utilisation de l'API Java Communications (JavaComm).

Le fichier license_xx.html contient le contrat de licence du logiciel Runtime Environment for Linux. (xx est une abréviation de la langue.) Pour afficher ou imprimer le contrat de licence, ouvrez ce fichier dans un navigateur Web.

## Conventions

Dans ce guide utilisateur, le répertoire d'installation par défaut de SDK est désigné par /opt/ibm/java2-i386-50/. Les plateformes ci-après ont des répertoires d'installation différents : remplacez-les pour la plateforme utilisée lorsque vous voyez /opt/ibm/java2-i386-50/ :

- Linux IA 32 bits : /opt/ibm/java2-i386-50/
- Linux AMD 64 bits : /opt/ibm/java2-x86_64-50/
- Linux PPC 32 bits : /opt/ibm/java2-ppc-50/
- Linux PPC 64 bits : /opt/ibm/java2-ppc64-50/
- Linux zSeries 31 bits : /opt/ibm/java2-s390-50/
- Linux zSeries 64 bits : /opt/ibm/java2-s390x-50/

## Compatibilité des versions

En général, toute applet ou application ayant déjà été exécutée avec une version antérieure du SDK doit fonctionner correctement avec IBM SDK pour Linux, v5.0. Il n'est pas garanti que les classes compilées avec cette version fonctionnent sur des versions antérieures.

Pour en savoir plus sur la compatibilité, consultez la documentation de Sun sur le site Web http://java.sun.com.

## Mise à niveau du SDK

Si vous effectuez une mise à niveau du SDK à partir d'une version précédente, sauvegardez tous les fichiers de configuration et ceux de règles de sécurité avant de procéder.

Une fois la mise à niveau effectuée, il peut être nécessaire de restaurer ou de reconfigurer ces fichiers car ils peuvent avoir été modifiés lors du processus de mise à niveau. Vérifiez la syntaxe des nouveaux fichiers avant de restaurer les fichiers d'origine car le format ou les options des fichiers peuvent avoir été modifiés.

## Migration à partir d'autres machines JVM IBM

Pour la Version 1.4.2 pour AMD64/EM64T et la Version 5 pour les autres plateformes Linux, IBM Runtime Environment for Linux contient les nouvelles versions de d'IBM Java Virtual Machine et du compilateur JIT (Just-In-Time). Si vous effectuez une migration à partir d'une version d'IBM Runtime Environment plus ancienne, notez que :

- La bibliothèque partagée libjvm.so de la machine virtuelle JVM est installée dans le répertoirejre/bin/j9vm. Ceci n'est pas le cas, par exemple, pour Runtime Environment for Linux pour la Version 1.4.2 (pour toutes les plateformes autres que AMD64/EM64T), où elle est installée dans jre/bin/classic. Les applications natives qui utilisent l'interface JNI peuvent nécessiter l'ajout du nouveau chemin d'accès au répertoire à leurs variables d'environnement afin de pouvoir localiser la bibliothèque DLL JVM.
- |L'interface JVMMI (JVM Monitoring Interface) n'est plus disponible. |Vous devez récrire les applications qui utilisent cette API. Il est conseillé 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, consultez le site Web http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/ et le document Diagnostics Guide.
- |La nouvelle mise en oeuvre de JNI est conforme à la spécification JNI, |mais diffère de l'ancienne mise en oeuvre. 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 Options non standard.
- |Le format et le contenu des journaux prolixes de récupération de place obtenus à l'aide 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 document Diagnostics Guide.
- Les versions précédentes du JRE IBM incluaient un fichier appelé rt.jar situé dans le répertoire jre/lib. Depuis Java 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 5 Compatibility Documentation et Sun's Java 5 Depreciated API List

| | |

## Matériel pris en charge pour zSeries

|

Les SDK zSeries 31 et |64 bits et Runtime Environments s'exécutent sur les serveurs |System z9 et zSeries ou équivalents suivants :

|

|
- z9-109
|
- z990
|
- z900
|
- z890
|
- z800

# Sommaire du SDK et de Runtime Environment

Le SDK contient plusieurs outils de développement et 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 du tout être dépendantes de l'arborescence des répertoires du SDK 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.

## Outils d'environnement d'exécution

- 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 jre/bin sauf indications contraires.
  - java (interpréteur Java)
    - Exécute les classes Java. L'interpréteur Java exécute les programmes écrits avec le langage de programmation Java.
  - javaw (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.
  - keytool (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.
  - policytool (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 (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.
  - tnameserv (service annuaire CORBA)
    - Démarre le service annuaire transitoire CORBA.
  - rmiregistry (registre d'objets distants Java)
    - Crée et démarre un registre d'objets distant sur le port indiqué de l'hôte actuel.
  - ikeyman (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. Pour plus d'informations, voir Accessibilité iKeyman
  - jextract (extracteur)
    - Convertit un vidage système en un format commun pouvant être utilisé par jdmpview. Pour plus d'informations, voir document Diagnostics Guide.
  - (Linux IA 32 bits, PPC32 et PPC64 uniquement) javaws (Java Web Start)
    - Permet le déploiement et la maintenance automatique des applications Java.
  - (Linux IA 32 bits, PPC32 et PPC64 uniquement) |updateSettings.sh (paramètres Java Web Start)
    - Configure le système afin qu'il utilise Web Start avec le navigateur. Pour plus d'informations, voir Exécution de Web Start. Ce fichier est installé dans le répertoire jre/lib/javaws.

## Outils SDK

- Les outils suivants font partie du SDK et sont situés dans le répertoire /opt/ibm/java2-i386-50/bin :
  - javac (compilateur Java)
    - Compile les programmes écrits avec le langage de programmation Java en code intermédiaire (code Java compilé).
  - appletviewer (Applet Viewer Java)
    - Teste et exécute les applets en dehors d'un navigateur Web.
  - jdb (débogueur Java)
    - Aide de débogage des programmes Java.
  - javap (désassembleur de fichier classe)
    - Désassemble les fichiers compilés et peut imprimer une représentation du code intermédiaire.
  - javadoc (générateur de documentation Java)
    - Génère les pages HTML de la documentation d'API à partir des fichiers source Java.
  - javah (générateur d'en-tête C et de fichier de raccord)
    - Permet d'associer les méthodes natives au code Java.
  - jar (outil d'archivage Java)
    - Combine plusieurs fichiers en un seul fichier d'archive Java (JAR).
  - jarsigner (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.
  - jconsole (JConsole Monitoring and Management Tool - expérimental)
    - Outil graphique compatible JMX expérimental (non pris en charge) pour le contrôle des machines JVM locales et distantes.
  - native2ascii (convertisseur natif-ASCII)
    - Convertit les fichiers à encodage natif en fichier ASCII contenant des caractères Latin-1 et/ou Unicode.
  - rmic (convertisseur de talon RMI Java)
    - Génère des talons, des squelettes et des liens pour les objets distants. Prend en charge RMI-IIOP.
  - java-rmi.cgi (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.
  - idlj (compilateur IDL vers Java)
    - Génère des liaisons Java à partir d'un fichier IDL donné.
  - serialver (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.
  - extcheck (utilitaire Extcheck)
    - Détecte les conflits de version entre un fichier jar cible et les fichiers jar d'extension déjà installés.
  - jdmpview (composant de formatage de vidage multiplateformes)
    - Un outil permettant d'analyser les vidages. Pour plus d'informations, voir document Diagnostics Guide.
  - (Linux IA 32 bits, PPC32 et PPC64 uniquement) htmlconverter (convertisseur HTML pour Java Plug-in)
    - Convertit les pages HTML contenant des applets en un format pouvant être utilisé par le Java Plug-in.
- FICHIERS INCLUS
  - 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.
- DROITS D'AUTEUR
  - Mention de droits d'auteur pour le logiciel SDK for Linux.
- LICENCE
  - Le fichier de LICENCE, /opt/ibm/java2-i386-50/docs/<locale>/license_<locale>.html, contient le contrat de licence du logiciel SDK pour Linux (où <locale> correspond au nom de votre environnement local, par exemple Fr_FR). Pour afficher ou imprimer le contrat de licence, ouvrez le fichier dans un navigateur Web.
- FIXES.LST
  - Fichier texte décrivant tous les défauts résolus après l'édition initiale de cette version.

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

# Installation et configuration de SDK et de Runtime Environment

Vous pouvez installer IBM Java SDK and Runtime Environment à partir d'un package RPM ou d'un fichier .tgz. Utilisez la méthode d'installation .tgz. sauf si vous voulez permettre à tous les utilisateurs de la machine d'accéder à cette installation Java. Si vous ne disposez pas de droits root, utilisez le fichier .tgz.

Si vous effectuez l'installation à l'aide d'un fichier RPM, les fichiers Java sont installés dans /opt/ibm/java2-i386-50/. Les exemples de ce guide supposent que vous avez déjà installé Java dans ce répertoire.

## Installation sous Red Hat Enterprise Linux (RHEL) 4

Le SDK dépend de bibliothèques partagées qui ne sont pas installées par défaut pour Red Hat Enterprise Linux (RHEL) 4.0.

Les fichiers RPM contenant ces bibliothèques sont les suivants :

- `compat-libstdc++-33-3.2.3` et `xorg-x11-deprecated-libs-6.8.1` (Intel Architecture, PPC et PPC64)
- `compat-libstdc++-295-2.95.3` et `xorg-x11-deprecated-libs-6.8.1` (zSeries)

Pour inclure ces bibliothèques lors de l'installation RHEL 4, procédez comme suit :

1. Lorsque l'écran des packages par défaut s'affiche, sélectionnez l'option de personnalisation de l'ensemble de packages à installer.
2. Sur l'écran de sélection des groupes de packages sous l'option du système X Windows, sélectionnez l'option de détails et assurez-vous d'avoir sélectionné `xorg-x11-deprecated-libs`.
3. Sous les options de développement, sélectionnez l'option de développement de logiciels propriétaires .

| | |

## Installation d'un SDK 32 bits sur une architecture 64 bits

|

Pour exécuter le SDK, vous devez installer les versions correctes de toutes les |bibliothèques requises par le SDK, 32 ou 64 bits.

|

Dans RHEL4, les versions 64 bits des packages sont disponibles dans le groupe Compatibility Arch Support.

|

Vous pouvez utiliser l'outil RPM pour vérifier les versions des packages installées en ajoutant l'option |`--queryformat "%{NAME}.%{ARCH}\n"` à la commande RPM. Par exemple :

|

    /home/username : rpm --queryformat "%{NAME}.%{ARCH}\n" -q libstdc++
    |libstdc++.x86_64
    |libstdc++.i386

## Installation à partir d'un fichier RPM

1. Ouvrez une invite shell en tant qu'utilisateur root.
2. A l'invite shell, entrez `rpm -ivh <fichier RPM>`. Par exemple :

       |rpm -ivh ibm-java2-<arch>-sdk-5.0-0.0.<arch>.rpm

   ou

       |rpm -ivh ibm-java2-<arch>-jre-5.0-0.0.<arch>.rpm

   |où `<arch>` représente votre architecture : |i386, x86_64, ppc, ppc64, s390 ou s390x.

## Installation à partir d'un fichier .tgz

1. Créez un répertoire dans lequel placer les fichiers de package Java. Les exemple de ce guide supposent que vous avez effectué l'installation dans /opt/ibm/java2-i386-50/. Remplacez /opt/ibm/java2-i386-50/ par le répertoire dans lequel vous avez installé Java.
2. A l'invite du shell, entrez `tar -zxvf <fichier .tgz>`. Par exemple :

       |tar -zxvf ibm-java2-sdk-50-linux-<arch>.tgz

   ou

       |tar -zxvf ibm-java2-jre-50-linux-<arch>.tgz

   |où `<arch>` représente votre architecture : |i386, x86_64, ppc, ppc64, s390 ou s390x.

## Configuration du SDK et de Runtime Environment pour Linux

### Définition du PATH

Si vous modifiez la variable d'environnement PATH de la façon décrite ci-dessous, cela remplacera tous les fichiers exécutables Java présents dans le chemin.

Après avoir installé le SDK, vous pouvez exécuter un outil en entrant son nom à l'invite shell avec un nom de fichier comme argument.

Vous pouvez définir le chemin d'accès à un outil en l'entrant à chaque fois avant le nom de l'outil. Par exemple, si le SDK pour Linux est installé dans /opt/ibm/java2-i386-50/bin, vous pouvez compiler un fichier nommé myfile.java en entrant la commande suivante à l'invite shell :

      /opt/ibm/java2-i386-50/bin/javac monfichier.java

Pour modifier la variable d'environnement PATH :

1. Editez le fichier de démarrage shell dans votre répertoire initial (habituellement .bashrc, en fonction du shell utilisé) et ajoutez les chemins absolus à la variable d'environnement PATH. Par exemple :

       export PATH=/opt/ibm/java2-i386-50/bin:/opt/ibm/java2-i386-50/jre/bin:$PATH

2. Connectez-vous de nouveau ou exécutez le script de shell mis à jour pour activer le nouveau paramètre PATH.

### Définition du CLASSPATH

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

Vous ne devez définir le CLASSPATH de manière explicite que 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 commun.
- 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 du CLASSPATH, entrez ce qui suit à l'invite shell :

      echo $CLASSPATH

Si vous prévoyez de développer et d'exécuter 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 le CLASSPATH (et PATH) explicitement pour chaque application. Si vous prévoyez d'exécuter plusieurs applications simultanément et d'utiliser des environnements d'exécution différents, chaque application doit être exécutée dans le shell qui lui est propre.

Si vous souhaitez exécuter une seule version de Java à la fois, vous pouvez utiliser un script shell pour passer d'un environnement d'exécution à l'autre.

Remarque :
(Pour les utilisateurs de la version chinoise de Linux IA 32 bits uniquement) En raison des incohérences des codages de police sur Red Hat Advanced Server, lorsque vous effectuez une installation pour un environnement dont la langue par défaut doit être le chinois, il est recommandé d'utiliser l'anglais comme langue par défaut lors de l'installation, puis de passer au chinois une fois l'installation terminée. Si vous ne procédez pas ainsi, les polices chinoises risquent de ne pas s'afficher.

## Désinstallation de SDK et de Runtime Environment pour Linux

La procédure utilisée pour supprimer le SDK et le Runtime Environment pour Linux dépend du type d'installation. Pour obtenir des instructions, reportez-vous à la section Désinstallation du composant RPM ou Désinstallation du composant TAR compressé.

### Désinstallation du package RPM

Pour désinstaller le SDK ou le Runtime Environment pour Linux lorsque vous avez installé le package RTM :

1. A l'invite du shell,
   1. Pour savoir quels packages RTM sont installés, entrez :

          rpm -qa | grep -i java

   2. Une liste des packages Java IBM installés s'affiche, par exemple :

          ibm-java2-<arch>-jre-5.0-0.0.<arch>
          ibm-java2-<arch>-sdk-5.0-0.0.<arch>

   3. Cette sortie indique quels packages vous pouvez désinstaller, à l'aide de la commande`rpm -e`, par exemple :

          rpm -e ibm-java2-<arch>-jre-5.0-0.0.<arch>
          rpm -e ibm-java2-<arch>-sdk-5.0-0.0.<arch>

   Vous pouvez également utiliser un outil graphique, tel que kpackage ou yast2.
2. Supprimez de l'instruction PATH le répertoire d'installation du SDK et du Runtime Environment.
3. (Linux IA 32 bits et PPC32 uniquement)Si vous avez installé le plug-in Java, supprimez les fichiers correspondants du répertoire du navigateur Web.

### Désinstallation du package TAR compressé

Pour désinstaller le SDK ou le Runtime Environment pour Linux lorsque vous avez extrait le package TAR compressé :

1. Supprimez les fichiers SDK ou Runtime Environment des répertoires d'installation correspondants.
2. Supprimez de l'instruction PATH le répertoire d'installation du SDK ou du Runtime Environment.
3. Connectez-vous de nouveau ou exécutez le script de shell mis à jour pour activer le nouveau paramètre PATH.
4. (Linux IA 32 bits et AMD64/EM64T uniquement) Si vous avez installé le plug-in Java, supprimez les fichiers correspondants du répertoire du navigateur Web.

# Utilisation du Runtime Environment

L'outil java lance une application Java en démarrant Java Runtime Environment et en chargeant une classe déterminée.

La machine virtuelle recherche la classe initiale (et d'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 la classe ou du fichier JAR sont transmis à la fonction main.

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 s'affiche. Si le lancement échoue, le programme de lancement de javaw affiche une boîte de dialogue contenant un message d'erreur.

Les commandes java et javaw obéissent à la syntaxe suivante :

    java [ options ] class [ arguments ... ]
    java [ options ] -jar file.jar [ arguments ... ]
    javaw [ options ] class [ arguments ... ]
    javaw [ options ] -jar file.jar [ arguments ... ]

Les éléments placés entre crochets sont facultatifs.

options
  Options de ligne de commande.
class
  Nom de la classe à appeler.
file.jar
  Nom du fichier jar à appeler. Il est uniquement employé avec -jar.
arguments
  Arguments transmis à la fonction main.

Si l'option -jar est indiquée, le fichier JAR nommé contient des fichiers de classes et de ressources pour l'application, la classe d'amorce étant signalée par l'en-tête de manifeste de classe principale.

## Options

Le programme de lancement contient un jeu d'options standard qui sont prises en charge dans l'environnement d'exécution courant et qui le seront également dans les prochaines éditions. Il contient également un jeu d'options non standard. Les options par défaut ont été choisies pour une utilisation d'ordre général optimale. Vous devez être vigilant lorsque vous décidez d'apporter des modifications à ces options.

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

Vous pouvez indiquer des options Java et des propriétés systèmes de trois différentes manières : Voici ces différents méthodes classées par ordre de préférence :

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 indiquant ce fichier sur la ligne de commande de la manière suivante -Xoptionsfile=<nomfichier>.
3. En créant une variable d'environnement appelée IBM_JAVA_OPTIONS contenant les options, par exemple `export IBM_JAVA_OPTIONS="-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump"`.

Les options les plus à droite à la ligne de commande ont priorité sur celles à gauche : par exemple, si vous entrez les options `-Xint -Xjit myClass`, -Xjit est prioritaire.

### Options standard

- -D<nom_propriété>=<valeur>
  - Définit une propriété système.
- -assert
  - Affiche l'aide sur des options d'assertion.
- -cp ou -classpath <répertoires et fichiers ZIP ou JAR séparés par un point-virgule (:)>
  - 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 CLASSPATH n'est pas définie, le chemin d'accès aux classes de l'utilisateur correspond par défaut au répertoire en cours (.).
- -help ou -?
  - Affiche un message d'aide.
- -showversion
  - Affiche la version du produit et continue la procédure.
- -verbose:[class,gcterse,gc,dynload,stackwalk,sizes,stack,debug,jni]
  - Active le mode prolixe.
- -version
  - Affiche la version du produit.
- -version:<valeur>
  - Requiert l'exécution de la version indiquée.
- -jre-restrict-search
  - Inclue des JRE privés de l'utilisateur dans la recherche de version
- -no-jre-restrict-search
  - Exclut les JRE privés de l'utilisateur de la recherche de version
- -agentlib:<nombibliothèque>[=<options>]
  - load native agent library <libname>, par exemple -agentlib:hprof. Pour plus d'informations, indiquez -agentlib:jdwp=help et -agentlib:hprof=help sur la ligne de commande.
- -agentpath: nombibliothèque[=<options>]
  - Charge la bibliothèque agent native en utilisant le chemin complet
- -javaagent:<cheminjar>[=<options>]
  - Charge l'agent de langage de programmation Java. Pour plus d'informations, reportez-vous à la documentation de l'API java.lang.instrument.
- -X
  - Affiche l'aide concernant les options non standard.

### Options non standard

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

Pour celles employant le paramètre <taille>, vous devez ajouter "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.

- -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 un point-virgule (;)>
  - 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 un point-virgule (;)>
  - 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 un point-virgule (;)>
  - 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 des 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 2 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:jni
  - Effectue des vérifications complémentaires pour les fonctions JNI. Vous pouvez également utiliser -Xrunjnichk. Par défaut, aucune vérification n'est réalisée.
- -Xcheck:nabounds
  - Effectue des vérifications complémentaires pour les opérations de tableau JNI. Vous pouvez également utiliser -Xrunjnichk. Par défaut, aucune vérification n'est réalisée.
- |-Xclassgc |
  |
  - Cette option active la collection d'objets de classes à chaque |récupération de place. |Par défaut, elle est activée.
- -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 de chaque cycle du récupérateur de place. Voir aussi -Xnocompactgc. Par défaut, la compression se produit uniquement si elle est déclenchée en interne.
- |-Xconcurrentbackground <nombre> |
  |
  - Cette option indique le nombre de threads |d'arrière-plan de faible priorité qui sont associés pour assister |les threads de mutation lors du marquage concurrent. La valeur par |défaut est 1.
- |-Xconcurrentlevel <nombre> |
  |
  - Cette option 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 | |dynamic> |
  |
  - Cette option détermine l'usage de la zone (LOA ou SOA) qui est |mesuré et donc les attributions taxées lors du marquage |concurrent. -Xconmeter:soa applique la |taxe aux attributions à partir la zone de petits objets (SOA), |-Xconmeter:loa à la zone d'objets |volumineux (LOA). Si vous entrez |-Xconmeter:dynamic, le collecteur identifie |de façon dynamique la zone à mesurer en fonction de celle |s'épuisant en premier (SOA ou LOA). 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. Identique à -Xrunjdwp. Par défaut, les bibliothèques de débogage ne sont pas chargées et l'instance de la machine virtuelle ne peut procéder au débogage.
- -Xdbginfo:<chemin d'accès au fichier de symboles>
  - Charge et transmet des options au serveur d'informations de débogage. Par défaut, ce serveur est désactivé.
- -Xdebug
  - Lance la machine virtuelle avec le débogueur activé. Par défaut, le débogueur est désactivé.
- |-Xdisableexcessivegc |
  |
  - Cette option désactive le lancement d'une exception OutOfMemory |si la récupération de place prend trop de temps. Elle est par défaut |désactivée.
- -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 |
  |
  - Cette option empêche la récupération de chaînes dans la table |interne de chaînes. |Par défaut, elle est désactivée.
- -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 OutOfMemory. Cette action se produit |uniquement lorsque le segment de mémoire a été totalement étendu |et que le temps passé représente au moins 95 %. Il s'agit du |comportement par défaut.
- |-Xenablestringconstantgc |
  |
  - Cette option active des chaînes dans la table interne de |chaînes à récupérer. |Par défaut, elle est activée.
- -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]||[subpool] (subpool on PPC and zSeries)
  - Contrôle le comportement du récupérateur de place. L'option optthruput est celle par défaut : elle offre un rendement très élevé aux applications, mais implique parfois des pauses. L'option optavgpause réduit le temps passé aux pauses dans la récupération de place et limite l'effet d'une taille accrue de segment de mémoire sur la longueur de ces pauses. Utilisez cette option si votre configuration possède un segment de mémoire très important. L'option 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. |L'option subpool emploie un |algorithme amélioré d'attribution d'objets pour de meilleures |performances lors de l'attribution d'objets sur le segment de |mémoire. Cette option peut améliorer les performances sur des systèmes SMP de grande taille. Pour en savoir plus, voir Définition des règles de récupération de place.
- -Xgcthreads<nombre de threads>
  - 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> |
  |
  - Cette option 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 de threads Java. Par défaut, elle est de kilo-octets.
- -Xjit[:<sous-option>,<sous-option>,...]
  - 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 |
  |
  - Cette option 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 <nombre> |
  |
  - <nombre> 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 <nombre> |
  |
  - <nombre> 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
  - 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'`. La machine JVM utilise shmget() pour allouer de grandes pages au segment de mémoire. Les grandes pages sont prises en charge par des systèmes exécutant des noyaux Linux version 2.6 ou supérieure, ou des noyaux de versions antérieures pour lesquelles la prise en charge de grandes pages a été gérée par la distribution. 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` la limite à 10 Mo. Par défaut, il n'existe pas de taille d'augmentation maximum.
- -Xmaxf<taille>
  - 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. Indiquez la taille sous forme de valeur décimale comprise entre 0 et 1 : par exemple, `-Xmaxf0.5` définit l'espace libre maximum à 50 %. 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.
- -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.
- -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 définit l'augmentation moins à la valeur indiquée : par exemple, `-Xmine50M` définit la taille d'augmentation à un minimum de 50 Mo. Par défaut, la taille d'augmentation minimum est d'1 Mo.
- -Xminf<taille>
  - 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. Indiquez la taille sous forme de valeur décimale comprise entre 0 et 1 : par exemple, une valeur de `-Xminf0.3` demande que l'espace libre minimum représente 30 % du segment de mémoire. Par défaut, la valeur minimum est de 0,3.
- -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. 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. Vous pouvez utiliser l'option -verbose:sizes pour identifier les valeurs utilisées par la machine virtuelle.
- -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.
- -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.
- -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. Vous pouvez utiliser l'option -verbose:sizes pour identifier les valeurs utilisées par la machine virtuelle.
- -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.
- -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.
- -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.
- -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.
- -Xms<taille>
  - Définit la taille initiale du segment de mémoire Java. Vous pouvez également utiliser -Xmo. La valeur par défaut est définie en interne selon la fonction de votre système.
- -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 kilo-octets, et à 256 kilo-octets sur des plateformes 64 bit.
- -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.
- -Xnoclassgc
  - Désactive la récupération de place pour les classes. La récupération de place est désactivée pour le stockage associé aux classes Java qui ne sont plus utilisées par la machine virtuelle Java. Le comportement par défaut est -Xclassgc.
- -Xnocompactgc
  - Désactive la compression pour le récupérateur de place. Voir aussi -Xcompactgc. Par défaut, la compression est activé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()`.
- -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 |
  |
  - Cette option 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. Par défaut, cette option n'est pas définie et toutes les compressions sont complètes.
- -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 et la taille de la pile C pour les unités d'exécution. Cette action est fournie pour la compatibilité et équivaut à attribuer la valeur indiquée à -Xss et à -Xmso.
- -Xpartialcompactgc
  - Active la compression partielle. 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 en savoir plus, voir 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. Identique à -Xdbg. Pour en savoir plus, voir Débogage des applications Java.
    - -Xrunjnichk[:help] | [:<option>=<valeur>, ...]
      - Effectue d'autres vérifications pour les fonctions JNI afin d'assurer le suivi d'erreurs dans des programmes natifs accédant à la machine virtuelle Java avec JNI. Pour en savoir plus, voir le document Diagnostics Guide.
- |-Xscmx<taille>[k|m|g] |
  |
  - Pour en savoir plus sur -Xscmx, voir Utilisation d'options de ligne de commande pour le partage de |classes.
- |-Xshareclasses:<sous-options> |
  |
  - Pour en savoir plus sur les sous-options |-Xshareclasses, voir Utilisation d'options de ligne de commande pour le partage 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> |
  |
  - Cette option 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 pile Java maximale pour les unités d'exécution. Par défaut, cette option a la valeur 256 Ko. Pour plus d'informations, voir Working with floating stacks.
- -Xthr:<options>
  - Définit les options de threads.
- -Xverbosegclog:<chemin d'accès au fichier><nomfichier>[X, Y]
  - Force l'écriture de la sortie verboseGC 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 verboseGC est redirigée vers un nombre X de fichiers, chaque fichier contenant un nombre Y de cycles gc pouvant générer une sortie verboseGC. Ces fichiers sont nommés nomfichier1, nomfichier2, etc. Par défaut, aucune journalisation de la récupération de place en mode prolixe n'a lieu.
- -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.

## Obtention du numéro de compilation et de version IBM

Pour obtenir le numéro de compilation et de version IBM, entrez la commande suivante à l'invite de shell :

    java -version

## Globalisation de la commande java

La commande java et les autres commandes du programme de lancement java (telles que javaw) permettent d'indiquer un nom de classe 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, vous devez entrer -Xargencoding. 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).

De la même façon, pour indiquer que le nom de classe et les arguments de la commande sont de codage UTF8, voir -Xargencoding:utf8 ; s'ils sont de codage ISO8859_1, voir -Xargencoding:latin.

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 offrent des messages de sortie traduits. Ces messages varient selon l'environnement local dans lequel s'exécute Java. Les descriptions détaillées des erreurs et autres informations de débogage renvoyées par java sont en anglais.

## 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 V5.0 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. Toutefois, si un incident survient dans l'environnement d'exécution lors de l'exécution d'une application Java ou d'une applet, vous pouvez désactiver le compilateur JIT afin d'isoler plus facilement l'incident. La désactivation du compilateur JIT doit être uniquement une mesure temporaire, sa présence étant requise pour des performances appropriées.

### Désactivation du JIT

Il existe trois méthodes de désactivation du compilateur JIT :

- 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, entrez ce qui suit :

  1. Pour l'interpréteur de commandes Korn :

     -     export JAVA_COMPILER=NONE

       (Les commandes d'interpréteur Korn sont utilisées dans tout le reste de ce guide utilisateur.)

  2. Pour l'interpréteur de commandes Bourne :

     -     JAVA_COMPILER=NONE

     -     export JAVA_COMPILER

  3. Pour l'interpréteur de commandes C :

     -     setenv JAVA_COMPILER NONE

- Utilisez l'option -D sur la ligne de commande de la JVL afin d'attribuer la valeur "NONE" ou une chaîne vide à la propriété java.compiler :

      java -Djava.compiler=NONE MyApp

- Utilisez l'option -Xint sur la ligne de commande de la JVM. Par exemple :

      java -Xint MonApp

Les options de ligne de commande remplacent la variable d'environnement JAVA_COMPILER.

### Activation du JIT

Pour activer le JIT de manière exemplaire, attribuez la valeur "jitc" à la variable d'environnement JAVA_COMPILER ou utilisez l'option -D pour attribuer la valeur "jitc" à la propriété java.compiler. Vous pouvez également utiliser l'option -Xjit (et omettre l'option -Xint) sur la ligne de commande de la JVM pour activer le JIT.

Si la valeur "" (chaîne vide) est attribuée à la variable d'environnement JAVA_COMPILER ou à la propriété java.compiler, le JIT reste désactivé. Pour annuler la définition de la variable d'environnement correctement, entrez entrez `unset JAVA_COMPILER` au niveau de l'invite shell.

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

Pour savoir si le JIT est activé, entrez la commande suivante :

    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 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 l'incidence sur votre application.

Pour plus d'informations sur la récupération de place, voir document .

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

L'option -Xgcpolicy indique les règle de récupération de place.

-Xgcpolicy accepte les valeurs optthruput (valeur par défaut et recommandée), optavgpause|, subpool| (PPC et |zSeries uniquement) ou gencon. Cette option contrôle le comportement du récupérateur en établissant 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

> -Xgcpolicy:optavgpause

> -Xgcpolicy:gencon

|

> -Xgcpolicy:subpool (PPC et zSeries uniquement)

### 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 Java utilise les deux techniques suivantes pour réduire le délai d'interruption :

- Récupération de place simultanée
- 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 relativement longs qui ne peuvent alors pas être récupérés. Si la fonction de récupération de place se concentre uniquement 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 alloué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 performances se produit au niveau des applications, indépendamment du réglage des options définies ci-dessus. Si des demandes d'espace supplémentaire sont effectuées, l'application reçoit une exception OutofMemory 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 JVM génère un fichier de diagnostic "javadump". 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 d'application utilisés. Pour plus d'informations, voir document Diagnostics Guide.

## 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 le contrôle du traitement du signal. Si un gestionnaire d'application pour ce signal est installé et que vous ne définissez pas l'option de ligne de commande -Xnosigchain, une fois que la machine JVM a terminé le traitement, le gestionnaire d'application pour ce signal est appelé.

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 machine JVM ou l'application Java, il est ignoré ou l'action par défaut est effectuée.

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 Javadump pour décrire l'état de la JVM 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 afin que la procédure d'arrêt s'effectue correctement.

Pour plus d'informations sur l'écriture d'un programme de lancement spécifiant les points d'ancrage cités précédemment, voir http://www-106.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 :

- elle appelle le gestionnaire de signaux de votre application pour le signal en question ;
- elle appelle tous les points d'arrêt de l'application ;
- elle appelle un point de sortie installé par l'application ;
- 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 SIGQUIT qui entraîne un vidage Javadump.

### Signaux utilisés par la JVM

Le tableau tableau 1 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 une signal d'exception approprié en cas de condition d'erreur fatale.
- Erreurs : La JVM déclenche un signal SIGABRT si elle détecte une condition à partir de 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 sont utilisés par la JVM à des fins de contrôle.

Tableau 1. Signaux utilisés par la JVM
Nom du signal | Type de signal | Description | Désactivé par -Xrs
--- | --- | --- | ---
SIGBUS | Exception | Accès incorrect à la mémoire (données non alignées) | Oui
SIGSEGV | Exception | Accès incorrect à la mémoire (écriture dans une mémoire inaccessible) | Oui
SIGILL | Exception | Instruction non conforme (tentative d'appel d'une instruction machine inconnue) | Non
SIGFPE | Exception | Exception en virgule flottante (division par zéro) | Oui
SIGABRT | Erreur | Arrêt anormal. La JVM déclenche ce signal si elle détecte un incident JVM. | Oui
SIGINT | Interruption | Attention interactive (Ctrl-C). JVM s'arrête normalement. | Oui
SIGTERM | Interruption | Demande d'arrêt. JVM s'arrête normalement. | Oui
SIGHUP | Interruption | Arrêt de l'exécution. JVM s'arrête normalement. | Oui
SIGQUIT | Contrôle | Signal d'arrêt pour un terminal. Utilisé par la machine JVM pour les vidages Javadump. | Oui
|SIGTRAP (5) | |Contrôle | |Utilisé par le JIT. | |Oui
|__SIGRTMAX - 2 | |Contrôle | |Utilisé par le SDK. | |Non
|SIGCHLD | |Contrôle | |Utilisé par le SDK pour le contrôle interne. | |Non

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, reportez-vous à la page du programme de lancement d'applications Java, à l'adresse http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html.

Les signaux `1 (SIGHUP)`, `2 (SIGINT)`, `4 (SIGILL)`, `7 (SIGBUS)`, `8 (SIGFPE)`, `11 (SIGSEGV)` et `15 (SIGTERM)` sur unités d'exécution JVM provoquent l'arrêt de la machine JVM. Par conséquent, le 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.

Le chaînage de signaux permet à une application de créer un lien vers la bibliothèque partagée libjsig.so et de la charger avant les bibliothèques système. La bibliothèque libjsig.so garantit l'interception des appels à `signal()`, `sigset()` et `sigaction()`, par exemple, afin que leurs 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.

Pour utiliser libjsig.so :

- Liez la bibliothèque à l'application qui crée ou incorpore une JVM à l'aide de la commande suivante :

      gcc -L$JAVA_HOME/bin -ljsig -L$JAVA_HOME/bin/j9vm -ljvm java_application.c

  ou
- Utilisez la variable d'environnement LD_PRELOAD comme suit :

      export LD_PRELOAD=$JAVA_HOME/bin/libjsig.so; java_application (bash et ksh)

      setenv LD_PRELOAD=$JAVA_HOME/bin/libjsig.so; java_application (csh)

  (si `RACINE_JAVA` est configuré ; sinon, utilisez /opt/ibm/java2-i386-50/jre.)

Si vous installez des gestionnaires de signaux qui utilisent `sigaction()`, certains indicateurs sa_flags ne sont pas respectés lorsque la JVM utilise ce signal. Ces indicateurs sont les suivants :

- SA_NOCLDSTOP - Toujours désactivé.
- SA_NOCLDWAIT - Toujours désactivé.
- SA_RESTART - Toujours activé.

La bibliothèque libjsig.so 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.

## Utilisation de piles flottantes

Des distributions Linux particulières (Red Hat, par exemple) ont activé une fonction GLIBC appelée piles flottantes. En raison de limitations du noyau Linux, la machine JVM ne fonctionne pas sur du matériel SMP avec piles flottantes activées si le niveau de noyau est inférieur à 2.4.10. Dans cet environnement, les piles flottantes doivent être désactivées avant le démarrage de la machine JVM ou de toute application la démarrant. Avec Red Hat, utilisez la commande suivante pour désactiver les piles flottantes en exportant une variable d'environnement :

    export LD_ASSUME_KERNEL=2.2.5

Sur les systèmes Linux à piles non flottantes, une taille de pile native minimum de 256 Ko est fournie sur chaque unité d'exécution, quelle que soit la valeur de -Xss. Sur les systèmes Linux à piles flottantes, les valeurs de -Xss sont utilisées. Par conséquent, si vous effectuez une migration depuis un système Linux à piles non flottantes, vous devez vous assurer que toutes les valeurs -Xss soient suffisamment élevées et ne pas vous limiter au minimum de 256 Ko.

## Transformation de documents XML

IBM SDK contient le processeur XSLT4J et l'analyseur XML4J respectant la spécification JAXP 1.3. Ces outils vous permettent d'analyser et de transformer des documents XML indépendamment de toute implémentation de traitement XML donnée. Grâce aux localisateurs de fabrique recherchant les implémentations SAXParserFactory, DocumentBuilderFactory et TransformerFactory, votre application peut passer de l'une à l'autre sans devoir modifier le code.

|La technologie XML incluse avec le SDK IBM est similaire à |Apache Xerces Java et Apache Xalan Java. Pour plus d'informations, voir http://xml.apache.org/xerces2-j/ et http://xml.apache.org/xalan-j/.

Le processeur XSLT4J vous permet de choisir entre le processeur d'interprétation XSLT d'origine ou le nouveau processeur de compilation XSLT. Le processeur d'interprétation est conçu pour manipuler et déboguer des environnements. Il prend en charge les fonctions d'extension XSLT non prises en charge par le processeur de compilation XSLT. Ce dernier est conçu pour des environnements d'exécution hautes performances ; il génère un moteur de transformation, ou translet, à partir d'une feuille de style XSL. Cette approche distingue l'interprétation des instructions de la feuille de style de leur application à des données XML.

Le processeur d'interprétation XSLT est le processeur par défaut. Pour sélectionner le processeur de compilation XSLT, vous pouvez :

- changer l'entrée dans le fichier jaxp.properties (dans /opt/ibm/java2-i386-50/jre/lib), ou
- définir la propriétés système pour la clé javax.xml.transform.TransformerFactory en org.apache.xalan.xsltc.trax.TransformerFactoryImpl.

Pour implémenter des propriétés dans le fichier jaxp.properties file, copiez jaxp.properties.sample dans jaxp.properties, dans /opt/ibm/java2-i386-50/. Ce fichier contient également tous les détails sur la procédure à suivre pour identifier les implémentations à utiliser pour TransformerFactory, SAXParserFactory et DocumentBuilderFactory.

Pour améliorer les performances lorsque vous transformez un objet StreamSource à l'aide du processeur de compilation XSLT, indiquez la classe com.ibm.xslt4j.b2b2dtm.XSLTCB2BDTMManager comme fournisseur du service org.apache.xalan.xsltc.dom.XSLTCDTMManager. Pour identifier le fournisseur de services, essayez chaque étape jusqu'à org.apache.xalan.xsltc.dom.XSLTCDTMManager :

1. Vérifiez le paramètre de la propriété système org.apache.xalan.xsltc.dom.XSLTCDTMManager.
2. Vérifiez la valeur de la propriété org.apache.xalan.xsltc.dom.XSLTCDTMManager dans le fichier /opt/ibm/java2-i386-50/lib/xalan.properties.
3. Vérifiez le contenu du fichier META-INF/services/org.apache.xalan.xsltc.dom.XSLTCDTMManager pour un nom de classe.
4. Utilisez la fournisseur de services par défaut org.apache.xalan.xsltc.dom.XSLTCDTMManager.

Le processeur de compilation XSLT détecte le fournisseur de services pour le service org.apache.xalan.xsltc.dom.XSLTCDTMManager lorsqu'un objet javax.xml.transform.TransformerFactory est créé. Les objets javax.xml.transform.Transformer et javax.xml.transform.sax.TransformerHandler créés à l'aide de l'objet TransformerFactory utilisent le même fournisseur de services. Vous pouvez uniquement changer le fournisseur de services en modifiant l'un des paramètres décrits ci-dessus et en créant un nouvel objet TransformerFactory.

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

Si vous utilisez une ancienne version de Tomcat, cette limitation peut vous concerner.

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 exception de pointeur nul 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 à niveau 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 /opt/ibm/java2-i386-50/jre/lib.
- Supprimer la mise en commentaire des entrées du fichier jaxp.properties dans/opt/ibm/java2-i386-50/jre/lib.
- Définissez de façon explicite la fabrique d'analyseur SAX, la fabrique DocumentBuilder ou Transformer à l'aide de la variable d'environnement IBM_JAVA_OPTIONS. Par exemple :

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

  ou

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

  ou

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

- 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 spécification JAXP 1.3.

# Utilisation de SDK pour développer des applications Java

Les sections qui suivent offrent des informations sur l'utilisation de SDK for Linux pour développer des applications Java. Voir Outils SDK pour en savoir plus sur les outils disponibles.

## Débogage des applications Java

Pour déboguer les programmes Java, vous devez 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 Linux.

### Débogueur Java (JDB)

Le débogueur Java (JDB) est inclus dans le SDK de Linux. Il est appelé par la commande jdb et s'"attache" à la machine virtuelle Java à l'aide de JPDA. Pour déboguer une application Java, procédez comme suit :

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

       java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=<port>
            MonApp <MonApp args>

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

       jdb -attach <numéro de port>

   Le débogueur se rattache à la machine JVM, 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 obtenir des informations sur les options JDB, entrez :

    jdb -help

Pour obtenir des informations sur les commandes JDB :

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 JVM distante.

1. Démarrez la machine virtuelle Java comme précédemment.
2. Rattachez le débogueur à la machine distante :

       jdb -attach <nom de machine ou adresse ip>:<numéro de port>

Lorsque vous lancez une session de débogage à l'aide du transport dt_socket, assurez-vous que les ports indiqués sont libres.

|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/j2se/1.5.0/docs/guide/jpda/
- http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdb.html

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

Certaines applications Java doivent pouvoir déterminer si elles s'exécutent sur une machine virtuelle Java 32 bit ou 64 bit. 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 bit pour des plateformes prenant en charge ces deux modes d'opération 32 et 64 bit. 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 bit.

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 bit.

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

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

## 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)
- JNI_VERSION_1_4(0x00010004)

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 J2SE (à savoir, 5.0). 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/j2se/1.5.0/docs/guide/jni.

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

Pour compiler et relier une application native à IBM 5.0 SDK, utilisez la commande suivante :

    gcc -I/opt/ibm/java2-i386-50/include -L/opt/ibm/java2-i386-50/jre/bin/j9vm
    -ljvm -ldl -lpthread <nomfichier programme JNI>

L'option -ljvm indique que libjvm.so est la bibliothèque partagée implémentant la machine virtuelle. L'option -lpthread indique que vous travaillez avec une prise en charge pthread native. Si vous n'établissez pas de liaison à la bibliothèque pthread, une erreur de segmentation (signal SIGSEGV) peut se produire à l'exécution du programme JNI.

Remarque :
La version 1.1 de l'interface JNI (Java Native Interface) n'est pas prise en charge.
| | |

## Prise en charge de la restauration de connecteurs bloqués au niveau de l'unité d'exécution

|

Quatre nouvelles classes SDK propres à IBM ont été ajoutées au module com.ibm.jvm pour assurer la prise en charge de la restauration au niveau de l'unité d'exécution en cas de connecteur bloqué. Ces nouvelles classes |sont regroupées dans le fichier core.jar.

|

Elles permettent de débloquer les unité d'exécution bloquées sur des appels |réseau ou de synchronisation. Lorsqu'une application n'utilise pas ces |classes, elle doit mettre fin à l'ensemble du processus au lieu d'interrompre une seule |unité d'exécution bloquée.

|

Ces classes sont les suivantes :

|

|
public Interface InterruptibleContext()
|
  Définit deux méthodes, isblocked() et unblock(). Les trois autres classes |mettent en oeuvre InterruptibleContext. |
|
public class InterruptibleLockContext()
|
  Classe utilitaire pour l'interruption des appels de synchronisation. |
|
public class InterruptibleIOContext()
|
  Classe utilitaire pour l'interruption des appels réseau. |
|
public class InterruptibleThread()
|
  Classe utilitaire qui étend java.lang.Thread pour permettre l'encapsulage |des méthodes exécutables interruptibles. Elle utilise des instances de InterruptibleLockContext |et InterruptibleIOContext pour exécuter les méthodes isblocked() et unblock() |requises suivant que l'unité d'exécution est bloquée par une opération de synchronisation ou de réseau. |
|

|

Les instances InterruptibleLockContext et InterruptibleIOContext fonctionnent toutes les deux en faisant référence à l'unité d'exécution actuelle. Par conséquent, si vous n'utilisez pas InterruptibleThread, vous devez fournir votre |propre classe d'extension de java.lang.Thread pour utiliser ces nouvelles classes.

|

La documentation Java de ces classes est fournie avec le kit SDK dans le fichier docs/apidoc.zip.

## 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

Pour exécuter une applet à l'aide d'Applet Viewer, entrez la commande suivante à l'invite shell :

       appletviewer nom

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

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

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

      appletviewer $HOME/nomfichier.html

où nomfichier correspond au nom du fichier HTML.

Par exemple, `http://java.sun.com/applets/NervousText/example1.html` est l'URL d'une page Web qui appelle une applet. Pour appeler Applet Viewer sur cette page Web, entrez la commande suivante à l'invite shell :

    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 appletviewer n'est pas encodé comme 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

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

L'option -debug d'Applet Viewer permet de déboguer les applets. Lors du débogage d'applets, il est conseillé d'appeler Applet Viewer à partir du répertoire contenant le fichier HTML qui appelle l'applet. 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.

| | |

## 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.

|

La prise en charge de grandes pages doit être disponible dans le |noyau et activée pour permettre à Java d'utiliser ce type de |pages.

|

Pour configurer l'allocation de mémoire à grandes pages, vérifiez d'abord que le |noyau actif prend en charge les grandes pages. Vérifiez que le fichier /proc/meminfo |contient les lignes suivantes :

|

    HugePages_Total:     <nombre
    |de pages>
    |HugePages_Free:      <nombre de pages>
    |Hugepagesize:        <taille de page en ko>

Le nombre de |pages disponibles et leur taille varient selon les distributions.

|

Si la prise en charge de grandes pages n'est pas disponible dans |votre noyau, ces lignes ne figurent pas dans le fichier /proc/meminfo. Dans |ce cas, vous devez installer un nouveau noyau incluant la prise en |charge de grandes pages.

|

Si cette prise en charge est disponible en revanche mais n'est |pas activée, `HugePages_Total` a la valeur 0. Dans ce cas, |votre administrateur doit activer la prise en charge. Consultez le |manuel de votre système d'exploitation pour plus d'instructions.

|

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. Configurez le nombre de |grandes pages au démarrage pour qu'elles soient contiguës.

|

Les allocations de grandes pages se produisent uniquement si la |machine virtuelle Java possède un accès root. Pour utiliser ces |grandes pages, exécutez Java en tant que root ou définissez le bid |suid de l'exécutable Java.

## Prise en charge de CORBA

Java 2 Platform, Standard Edition (J2SE) prend au minimum en charge les spécifications définies dans les spécifications officielles de prise en charge de CORBA dans J2SE (V1.5). Dans certains cas, la fonction ORB J2SE IBM prend en charge des versions plus récentes des spécifications.

### 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 formal/99-10-07 du groupe OMG, accessible sur le site Web suivant :

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 service annuaire 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 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 5.0. 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 future versions, 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. Le traçage est géré à l'aide de trois propriétés système.

- Pour activer le traçage, entrez `com.ibm.CORBA.Debug=true`.
- Pour mettre en forme et ajouter les messages GIOP de trace reçus et envoyés, entrez `com.ibm.CORBA.CommTrace=true`. Par défaut, le traçage ORB se rend sur les fichiers dont le nom a la forme orbtrc.DDMMYYYY.HHmm.SS.txt.
- Pour l'envoyer à un fichier différent, entrez `com.ibm.CORBA.Debug.Output=<nom_fichier>`.

Par exemple, pour tracer les événements et les messages GIOP mis en forme, entrez :

     java -Dcom.ibm.CORBA.Debug=true
    		-Dcom.ibm.CORBA.CommTrace=true monApp

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 seules 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

Vous pouvez optimiser l'ORB à l'aide des propriétés suivantes :

- Pour contrôler la fragmentation GIOP 1.2, définissez la propriété système com.ibm.CORBA.FragmentSize.

  Par exemple, pour définir une taille de fragment de 4096 octets :

      java -Dcom.ibm.CORBA.FragmentSize=4096 monApp

  La taille de fragment par défaut est de 1024 octets. Vous pouvez désactiver la fragmentation en définissant une taille de fragment égale à 0.

- Dans les réseaux hétérogènes, la réponse à une demande CORBA peut être différée ou perdue. Pour limiter ce problème, vous pouvez définir une durée d'attente maximum à l'aide de la propriété système com.ibm.CORBA.RequestTimeout. Vous pouvez également utiliser com.ibm.CORBA.LocateRequestTimeout pour contrôler le délai d'attente des demandes de recherche. Par exemple, pour réduire les deux délais à 30 secondes, entrez

      java -Dcom.ibm.CORBA.RequestTimeout=30
           -Dcom.ibm.CORBA.LocateRequestTimeout=30 monApp

  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.

- Si votre programme fournit un service dans le réseau, vous devrez peut-être attribuer une valeur connue au numéro du port à partir duquel l'ORB lit les demandes entrantes. Pour ce faire, utilisez la propriété système com.ibm.CORBA.ListenerPort.

  Par exemple, pour forcer l'ORB à utiliser le port 1050, entrez :

      java -Dcom.ibm.CORBA.ListenerPort=1050 monApp

  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 2 pour l'ORB

Lors de l'exécution avec un gestionnaire de sécurité Java 2, 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é. Les méthodes concernées sont les suivantes :

Tableau 2. Les méthodes concernées lors de l'exécution avec Java 2 SecurityManager
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

Si votre programme utilise l'une de ces méthodes, assurez-vous qu'il bénéficie des droits nécessaires.

### 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 mise 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. Ce guide est installé en même temps que cette documentation.
- Le répertoire demo contient les éléments suivants :
  - Un exemple "Hello World" illustrant le basculement entre les protocoles JRMP (Java Remote Method Protocol) et IIOP demo/rmi-iiop/hello)
  - Un exemple "Hello World" interagissant avec un programme IDL standard (demo/rmi-iiop/idl)
- Le document Java Language to IDL Mapping est une spécification technique détaillée de RMI-IIOP. Il est accessible sur le site Web à l'adresse
  http://www.omg.org/cgi-bin/doc?ptc/00-01-06.pdf

## 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, définissez l'option

    -Dsun.rmi.transport.tcp.connectionPool=true (ou toute valeur non NULL)

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.

Pour plus d'informations, reportez-vous au site de Sun Java, à l'adresse suivante : http://java.sun.com.

## Prise en charge bidirectionnelle améliorée

Le SDK IBM inclut une meilleure prise en charge des données bidirectionnelles. Pour plus d'informations, consultez le site http://www-106.ibm.com/developerworks/java/jdk/bidirectional/index.html. La documentation Java du package bidirectionnel est fournie avec le kit SDK dans le fichier docs/apidoc.zip.

## Big Decimal amélioré

| |

Depuis Java 5.0, la classe Big Decimal IBM est adoptée par Sun en tant que java.math.BigDecimal. | IBM n'assure plus la gestion de com.ibm.math.BigDecimal, désormais obsolète. | Il est recommandé de migrer le code Java existant pour utiliser java.math.BigDecimal.

|

La nouvelle java.math.BigDecimal utilise les mêmes méthodes que les précédents |java.math.BigDecimal et com.ibm.math.BigDecimal. Le code existant qui utilise java.math.BigDecimal |continue à fonctionner correctement.

|

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,*;`.

## Prise en charge du symbole Euro

Le SDK et le Runtime Environment IBM définissentl'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.

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 de l'API Java Communications (JavaComm)

L'interface de programmation d'application Java Communications (JavaComm) est un module fourni en option à utiliser avec Runtime Environment for Linux sur les plateformes IA32, PPC32/PPC64 et AMD64/EM64T. JavaComm doit être installé indépendamment du SDK ou de l'environnement d'exécution.

L'API JavaComm 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. Après avoir écrit les communications de port série et parallèle pour votre application, vous pouvez inclure ces fichiers avec votre application.

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 Runtime Environment Version 5.0.

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

Vous devez tout d'abord vous assurer que le SDK ou l'environnement d'exécution est installé avant de procéder à l'installation de l'API Java Communications.

Si vous avez utilisé le module RPM pour installer Java à l'origine, installez l'API Java Communications à partir du fichier RPM. Pour installer l'API Java Communications à partir d'un module RPM :

1. Ouvrez une invite shell en tant qu'utilisateur root.
2. Installez le fichier RPM de l'API Java Communications à l'aide de la commande `rpm -ivh`. Par exemple :

       rpm -ivh ibm-java2-<arch>-javacomm-5.0-0.0.<arch>.rpm

   L'API Java Communications est installée dans l'arborescence de répertoires /opt/ibm/java2-i386-50/.

Pour installer l'API Java Communications à partir d'un fichier .tgz :

1. Placez le fichier archive de l'API Java Communications, ibm-java2-javacomm-50-linux-<arch>.tgz, dans le répertoire contenant le répertoire IBMJava2-50.
2. A l'invite shell, entrez la commande suivante pour extraire le contenu dans le répertoire contenant le fichier .tgz :

       tar -xvzf ibm-java2-javacomm-50-linux-<arch>.tgz

   L'API Java Communications est extraite dans des sous répertoires du répertoire IBMJava2-50 existant.

## Emplacement des fichiers de l'API Java Communications

Les fichiers de l'API Java Communications sont installés comme suit :

- jre/lib/ext/comm.jar
- jre/bin/libibmcomm.so
- jre/lib/javax.comm.properties

Si vous avez choisi d'effectuer l'installation dans le répertoire par défaut, le fichier comm.jar se trouve dans /opt/ibm/java2-i386-50/jre/lib/ext.

Si vous avez installé le module dans un autre répertoire, les fichiers se trouvent dans la même arborescence mais /opt/ibm/java2-i386-50/ est remplacé par le répertoire où vous avez installé l'API Java Communications.

## Configuration de l'API Java Communications

Une fois que vous avez installé l'API Java Communications, vous devez :

- changer le mode d'accès des ports série et parallèle ;
- définir le PATH, si vous ne l'avez pas déjà fait lors de l'installation de Java. Voir Définition du PATH.

### Modification du mode d'accès des ports série et parallèles

Une fois l'API Java Communications installée, vous devez modifier le mode d'accès des ports série et parallèle de façon à ce que les utilisateurs puissent accéder à ces périphériques. Vous devez attribuer aux utilisateurs l'accès en lecture/écriture aux périphériques requis. Connectez-vous en tant qu'utilisateur root et entrez les commandes suivantes, suivant les besoins :

        chmod 666 /dev/ttyS0    (également appelé port série COM1)
        chmod 666 /dev/lp0      (également appelé port parallèle LPT1)
        chmod 666 /dev/ttyS1    (également appelé port série COM2)
        chmod 666 /dev/ttyS2    (également appelé port série COM3)
        chmod 666 /dev/ttyS3    (également appelé port série COM4)

Ces commandes donnent l'accès en lecture/écriture à toutes les personnes connectées au système.

Une autre méthode consiste à définir des droits 660 et à ajouter des utilisateurs particuliers au groupe dans lequel les périphériques sont situés. Sur les systèmes SUSE, par exemple, les périphériques se trouvent dans le groupe `uucp`. Les utilisateurs peuvent donc être ajoutés au groupe `uucp` pour bénéficier de l'accès aux périphériques.

Modifiez le mode d'accès des autres ports selon vos besoins.

#### Spécification des périphériques dans le fichier de propriétés 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, respectivement.

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.

## Activation des ports série sur IBM ThinkPad

La plupart des ordinateurs ThinkPad sont dotés de ports série désactivés par défaut dans le BIOS. Il n'existe actuellement pas de moyen d'activer les ports sous Linux (le module tpctl n'active pas les ports si ceux-ci sont désactivés dans le BIOS).

Pour activer les ports dans le BIOS, utilisez la version DOS de l'utilitaire de configuration ThinkPad disponible sur le site de téléchargements IBM ThinkPad. Pour utiliser l'utilitaire de configuration ThinkPad, il vous faut une disquette DOS amorçable. Suivant les options de votre installation, il se peut que l'utilitaire de configuration ThinkPad ait été installé avec les utilitaires ThinkPad sous Windows et que vous puissiez l'exécuter à partir d'une invite de commande Windows.

L'application de configuration ThinkPad fournie avec Windows comporte des options permettant d'activer ou de désactiver les ports série et parallèle mais celles-ci ne modifient pas les paramètres au niveau du BIOS. Aussi, si vous utilisez cette application avec Windows, les ports sont disponibles ; toutefois, si vous redémarrez la machine sous Linux, les ports ne seront pas activés.

## 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

La procédure à suivre pour désinstaller l'API Java Communications varie suivant que vous avez installé le module RPM (Red Hat Package Manager) installable ou le module TAR (Tape Archive) condensé.

### Désinstallation du module RMP (Red Hat Package Manager) installable

Pour désinstaller l'API Java Communications si vous avez installé le module RPM installable :

1. A l'invite shell, entrez :

           rpm -e ibm-java2-<arch>-javacomm-5.0-0.0

   Vous pouvez également opter pour l'utilisation d'un outil graphique tel que kpackage ou yast2.

2. Si le répertoire où vous avez installé l'API Java Communications ne contient pas d'autres outils que vous pourriez nécessiter, supprimez ce répertoire de l'instruction PATH.

### Désinstallation du module TAR (Tape Archive) condensé

Pour désinstaller l'API Java Communications si vous avez installé le module TAR condensé, supprimez les fichiers suivants du répertoire où vous les avez installés :

- jre/lib/ext/comm.jar
- jre/bin/libibmcomm.so
- jre/lib/javax.comm.properties

## Documentation de l'API Java Communications

Vous trouverez de la documentation et des exemples de l'API Java Communications sur le site Web à l'adresse http://java.sun.com.

# Déploiement des applications Java

## (Linux IA 32 bits et PPC32 uniquement) Utilisation du plug-in Java

Java Plug-in est un plug-in de navigateur Web. Si vous l'employez, vous pouvez désactiver la machine virtuelle Java par défaut de votre navigateur Web et utiliser à la place un environnement d'exécution de votre choix pour exécuter des applets ou des beans 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.

Java Plug-in est expliqué par Sun à l'adresse : http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/.

### Navigateurs pris en charge

|Pour Linux PPC32, Mozilla 1.6 est le navigateur pris en charge.

|Pour Linux IA32, voir tableau 3.

|Tableau 3. Navigateurs pris en charge par Java Plug-in sur Linux IA32
|Distribution | |Version par défaut de Netscape | |Versions prises en charge de Netscape | |Version par défaut de Mozilla | |Versions prises en charge de Mozilla
--- | --- | --- | --- | ---
|Red Hat Enterprise Linux 3.0 | |- | |7.x | |1.4.2 | |1.4.1, 1.4.2, 1.7.8, Firefox 1.0.x
|Red Hat Enterprise Linux 4.0 | |4.8 | |7.x | |1.7.3 | |1.4.1, 1.4.2, 1.7.8, Firefox 1.0.x
|SUSE Linux Enterprise Server 9.0 | |- | |7.x | |1.6 | |1.4.1, 1.4.2, 1.6, 1.7.8, Firefox 1.0.x

|

### Installation et configuration de l'extension Java

|Plusieurs version du plug-in Java sont fournies avec le SDK. Vous choisissez la version la |plus appropriée pour votre navigateur. Les versions les plus répandues sont les suivantes :

| |
libjavaplugin_oji.so
|
  Le plug-in le plus commun. Elle se fonde sur l'initiative Open JVM Integration de Mozilla et est utilisée avec la plupart des produits Mozilla, y compris Firefox. |
|
libjavaplugin_ojigtk2.so
|
  Plug-in identique au plug-in décrit précédemment mais compilé avec les outils de développement GTK2. |

|Vous devez suivre certaines instructions pour l'installation du plug-in sur certains navigateurs communs.

|Vous devez créer un lien symbolique vers le plug-in et non le copier. De cette manière, vous pouvez |localiser la JVM.

#### Mozilla

|Seules versions 1.4 et versions ultérieures de Mozilla sont prises en charge.

Si vous voulez mettre le plug-in Java à la disposition de tous les utilisateurs du système, procédez comme suit :

1. Connectez-vous en tant qu'utilisateur root.
2. Accédez au répertoire de plug-ins Mozilla (il peut être différent sur certaines distributions Linux).

       cd /usr/local/mozilla/plugins/

3. |Créez un lien symbolique vers libjavaplugin_oji.so. |

       ln -s /opt/ibm/java2-i386-50/jre/bin/libjavaplugin_oji.so .

Vous devez créer un lien symbolique vers le plug-in et non le copier. De cette manière, vous pouvez localiser la JVM.

| | |

#### Firefox

|

Si vous voulez mettre le plug-in Java à la disposition de tous les |utilisateurs du système, procédez comme suit :

|

|
1. Connectez-vous en tant qu'utilisateur root.
|
2. Accédez au répertoire de plug-ins Firefox (il peut être différent sur certaines distributions Linux). |

       cd /usr/local/mozilla-firefox/plugins/

|
3. |Créez un lien symbolique vers libjavaplugin_oji.so. |

       ln -s /opt/ibm/java2-i386-50/jre/bin/libjavaplugin_oji.so .

   |

Vous devez créer un lien symbolique vers le plug-in et non le copier. De cette manière, vous pouvez |localiser la JVM.

#### Netscape 7.1 et versions supérieures

Pour installer et configurer le Java Plug-in pour Netscape, créez un lien symbolique entre le fichier de bibliothèque /opt/ibm/java2-i386-50/jre/bin/javaplugin_oji.so et le répertoire de plug-ins du navigateur (/browser-install-path/plugins).

1. Connectez-vous en tant qu'utilisateur root.
2. Accédez au répertoire de plug-ins Netscape (il peut être différent sur certaines distributions Linux).

       cd /usr/local/netscape/plugins/

3. Placez un lien symbolique au javaplugin_oji.so dans le répertoire de plug-ins.

       ln -s /opt/ibm/java2-i386-50/jre/bin/javaplugin_oji.so .

Vous devez créer un lien symbolique vers le plug-in et non le copier. De cette manière, vous pouvez localiser la JVM.

### 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 exception sun.plugin.dom.exception.NotSupportedException est émise pour certaines de ces fonctions.
- Une exception sun.plugin.dom.exception.InvalidStateException est émise 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 Java Plug-in 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 de l'encodage de caractères Chinese BIG-5. Tous les paramètres sont transmis correctement au plug-in Java. Cependant, il est possible que certaines des versions plus anciennes des navigateurs ne comprennent pas correctement cet indicateur. Dans ce cas, vous pouvez obliger le navigateur à ignorer cet indicateur, mais vous devrez peut-être modifier le codage manuellement.

Vous pouvez indiquer le codage à utiliser pour analyser le fichier HTML :

- Netscape 4 : Menu Affichage -> Jeu de caractères
- Mozilla : Menu Affichage -> Codage des caractères

## (Linux IA 32 bits, PPC32 et PPC64 uniquement) Utilisation de Java Web Start

Vous pouvez utiliser Java Web Start pour déployer des applications Java. Web Start permet à l'utilisateur de lancer et de gérer des applications directement à partir du Web. Avec Java Web Start, vous pouvez démarrer facilement les applications à partir du Web, en ayant la garantie d'exécuter la dernière version en date, ce qui élimine les procédures d'installation ou de mise à jour. Java Web Start évite le temps passé à télécharger et à installer des logiciels.

|Outre les java-vm-args décrits sur le site Web http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/syntax.html#resources, Web Start prend 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, consultez les sites Web http://java.sun.com/products/javawebstart et http://java.sun.com/j2se/1.5.0/docs/guide/javaws/index.html. Pour plus d'informations sur le déploiement d'applications, consultez le site Web http://java.sun.com/j2se/1.5.0/docs/guide/deployment/index.html.

### Exécution de Web Start

Java Web Start v5.0 est installé automatiquement en même temps que Java à l'aide des packages .rpm ou .tgz.

|Si vous extrayez Java du package .tgz, exécutez le |script de shell jre/lib/javaws/updateSettings.sh afin de mettre à |jour les fichiers .mailcap et .mime.types sur votre système.

Vous pouvez lancez Web Start de l'une des trois manières suivantes :

1. Cliquez sur un lien dans une page Web faisant référence à un fichier .jnlp.
2. A une invite shell, entrez `javaws <URL>`, où `<URL>` correspond à l'emplacement d'un fichier .jnlp.
3. |Si vous avez déjà utilisé Java Web Start |pour ouvrir l'application, exécutez javaws à partir |du répertoire jre/bin, afin de lancer Java Application Cache Viewer.

Une fois l'application téléchargée, elle est stockée dans le cache Java. Si vous accédez à nouveau à l'application, Java Web Start télécharge une version plus récente de l'application si elle est disponible ou emploie la version en cache dans le cas contraire.

Si une erreur se produit dans un fichier .jnlp (telle qu'un nom de balise erroné), Web Start s'interrompt sans afficher de message d'erreur.

## Livraison d'applications Java

Contrairement à une applet Java, une application Java ne peut reposer sur un navigateur Web pour les services d'installation et d'exécution. 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 Linux. SDK for Linux inclut un Runtime Environment. Toutefois, vous ne pouvez pas supposer que SDK for Linux est installé pour les utilisateurs.

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

| | |

# Partage de données de classes entre JVM

|

La machine virtuelle d'IBM vous permet de partager avec d'autres |des classes d'amorce et d'application en les stockant dans le cache |d'une mémoire partagée. 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 au-delà de la durée de vie de celle l'ayant |lancé.

| |

## Présentation du partage de classes

|

IBM SDK permet un partage de classes illimité qui semble transparent pour l'utilisateur.

| |

### Contenu du cache

|

Le cache de classes partagées contient des données et des |métadonnées descriptives de classes statiques en lecture seule. Toute |machine virtuelle peut lire et mettre à jour ce cache. Les machines |virtuelles le partageant doivent être de la même édition. Soyez vigilant si une modification de code intermédiaire |d'exécution est appliquée. (Voir Modification du code intermédiaire d'exécution.)

| |

### 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.

| |

### Activation du partage de classes

|

Activez le partage de classes à l'aide de l'option |-Xshareclasses au démarrage de la machine |virtuelle, afin que celle-ci se connecte à un cache existant ou en |crée 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 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.)

| |

### Sécurité du cache

|

L'accès au cache des classes est limitée par les droits Java et du système d'exploitation. Le cache de classes partagées est créé avec l'accès utilisateur par défaut sauf si la sous-option de ligne de commande groupAccess est utilisée. Seul un chargeur de classe qui est enregistré pour partager des classes peut en ajouter |à ce cache. Si un gestionnaire de sécurité Java est installé, les chargeurs de classe à l'exception des chargeurs de classe d'extension, d'application et d'amorce, doivent disposer de droits permettant de partager des classes par l'ajout de SharedClassPermissions au fichier java.policy. (Voir Utilisation de SharedClassPermissions.) |Le droit 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 |indiquez la taille du cache au démarrage via -Xscmx<n>[k|m|g], mais cette taille est ensuite déterminée |par rapport à la durée de vie du cache. Les caches existent |jusqu'à destruction explicite avec une sous-option de la |commande -Xshareclasses ou redémarrage du |système.

| |

### Utilitaires du cache

|

Tous les utilitaires du cache sont des sous-options de la |commande -Xshareclasses. Utilisez |-Xshareclasses:help pour obtenir la liste des |sous-options disponibles.

| |

## Utilisation d'options de ligne de commande pour le partage de |classes

|

Le partage de classes est activé et configuré à l'aide des options de ligne de commande -Xshareclasses et -Xscmx.

|

|
- -Xscmx<taille>[k|m|g] |
  |
  - 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 du |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 4 Ko. Le |maximum est également fonction de la plateforme. (Voir |Limites de la taille du cache.)
|
- -Xshareclasses:<sous-option1>[,<sous-option2>...] |
  |
  - Active le partage 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.
  Vous pouvez employer les sous-options suivantes avec |l'option -Xshareclasses : par exemple, -Xshareclasses:help |
  |
  - help |
    |
    - Répertorie toutes les 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à. Utilisez l'option listAllCaches pour afficher |les caches actuellement disponibles. Si vous ne précisez pas de nom, celui par |défaut "sharedcc_" est associé à votre nom d'utilisateur pour |créer le cache.
  |
  - groupAccess |
    |
    - Définit des droits de système d'exploitation sur un nouveau cache afin de permettre l'accès |de groupe dans ce cache. L'accès utilisateur uniquement constitue la valeur par défaut.
  |
  - verbose |
    |
    - Le mode prolixe 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. L'option standard -verbose:class permet également une sortie prolixe du partage |de classes si ce dernier est activé.
  |
  - modified=<contexte modifié> |
    |
    - Cette option est requise si un agent de code intermédiaire |installé peut modifier le code |intermédiaire lors de l'exécution. Si vous n'indiquez pas cette |option et qu'un agent de code intermédiaire est installé, aucune |classe n'est stockée ou trouvée dans le cache. Le |<contexte modifié> est un descripteur |choisi par l'utilisateur ; par exemple, "myModification1". Il |partitionne le cache, afin que seules les machines virtuelles |utilisant le contexte myModification1 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.
  |
  - destroy (option d'utilitaire) |
    |
    - Détruit un cache avec un nom indiqué dans la sous-option |name=<nom>. Si |aucun nom n'est précisé, le cache par défaut est détruit. 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 pour l'utilisateur. 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=<temps en minutes> |(option d'utilitaire) |
    |
    - Détruit tous les caches inutilisés pendant le temps spécifié.
  |
  - listAllCaches (option d'utilitaire) |
    |
    - Répertorie tous les caches sur le système en précisant s'ils |sont utilisés et à quand remonte leur dernière utilisation.
  |
  - printStats (option d'utilitaire) |
    |
    - Affiche des informations statistiques résumées sur le cache |indiqué dans la sous-option |name=<nom>. Si aucun nom n'est précisé, les statistiques concernent le cache par |défaut. 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. Voir le |document Diagnostics Guide pour en |savoir plus.
  |
  - printAllStats (option d'utilitaire) |
    |
    - Affiche des informations détaillées sur le contenu du cache |indiqué dans la sous-option |name=<nom>. |Si aucun nom n'est précisé, les statistiques concernent le cache par |défaut. |Chaque classe apparaît dans l'ordre chronologique, avec une |référence à l'emplacement depuis lequel elle a été chargée. Voir le |document Diagnostics Guide pour en |savoir plus.

| |

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

|

Pour activer le partage de classes, ajoutez |-Xshareclasses[:name=<nom>] à 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=<nom>],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 voir les classes chargées depuis le cache ou stockées dedans, |ajoutez `-Xshareclasses:[name=<nom>],verbose` à la ligne |de commande de votre application.

|

Pour supprimer le cache créé, exécutez `java |-Xshareclasses:[name=<nom>],delete`. 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 |à toute moment lors du cycle de vie de la machine virtuelle, il est préférable d'effectuer cette analyse |une fois l'application arrêté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 le cache. Ces dernières ne chargeront |plus aucune classe 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 classes s'avère particulièrement utile sur des |systèmes recourant à plusieurs machines virtuelles 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 |coût du temps de démarrage des machines virtuelles est généralement |compris entre 0 et 5 % pour une seule machine virtuelle, en fonction du nombre de classes chargées. L'amélioration de ce temps avec un cache rempli oscille entre 10 et |40 %, 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.

|

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

| |

## Limitations et considérations concernant l'utilisation du partage des classes

| |

### Limites de la taille du cache

|

Le cache du partage des classes est alloué à l'aide du mécanisme de mémoire partagée System |V IPC.

|

La taille de cache théorique maximale est 2Go. La taille du cache indiquée est limitée |par la quantité d'espace physique et de pagination disponible sur le système.

|

Etant 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.

|

La taille du cache est limitée par les paramètres |SHMMAX, ce qui limite la quantité de mémoire |partagée pouvant être allouée. Vous trouverez ces |paramètres dans le fichier /proc/sys/kernel/shmmax. SHMMAX a généralement la valeur 30 Mo.

| |

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

|

Toute machine virtuelle utilisant un agent JVMTI capable de |modifier du code intermédiaire ne peut partager des classes tant que |la sous-option modified=<contexte modifié> est utilisée à la ligne |de commande (voir ci-dessus). Le contexte modifié est un descripteur |spécifique à l'utilisateur et désignant le type de modification |effectuée. 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 |afin que les classes chargées depuis le cache ne puissent être à |nouveau modifiées par l'agent. Le code intermédiaire modifié et |inchangé peut être stocké dans le même cache. Voir le document |Diagnostics Guide pour en savoir |plus à ce sujet.

| |

### Limitations du système d'exploitation

|

Pour les systèmes d'exploitation pouvant exécuter |des applications tant 32 que 64 bit, le partage de classes n'est pas |autorisé entre des machines virtuelles 32 et 64 bit. |La sous-option |listAllCaches répertorie les caches de 32 et |64 bit, 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 /tmp/javasharedresources. 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 à nouveau le cache. Utilisez |la commande `ipcs` pour afficher les segments de mémoire |employés par une machine virtuelle ou une application.

|

Les utilisateurs exécutant une machine virtuelle doivent |appartenir au même groupe pour se servir du cache de classes |partagées. Les droits permettant d'accéder à un cache de classes partagées 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 SharedClassPermissions

|

Si un gestionnaire de sécurité est utilisé conjointement au partage de classes et que l'application |en cours d'exécution utilise ses propres chargeurs de classes, ces derniers doivent disposer du droit |SharedClassPermissions pour pouvoir partager des classes. Vous ajoutez SharedClassPermissions |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 un chargeur de classe ne dispose pas du droit SharedClassPermission correct et que |des tentatives de partage de classe sont effectuées, une exception AccessControlException est émise. Vous ne pouvez pas |modifier ou réduire les droits des chargeurs de classe d'amorçage, d'application ou d'extension par défaut.

| |

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

|

La plupart des applications Java utilisent les chargeurs de |classes des machines virtuelles ou disposent de chargeurs |personnalisés étendant java/net/URLClassLoader. Les applications |utilisant ces chargeurs peuvent automatiquement partager des classes d'amorce |et d'application. Les chargeurs de classes n'étendant pas |java/net/URLClassLoader requièrent des modifications afin de réaliser |un partage de classes. Le droit SharedClassPermissions doit être accordé |à tous les chargeurs de classes personnalisés si un gestionnaire est utilisé, voir Utilisation de SharedClassPermissions. IBM fournit plusieurs interfaces Java pour différents types de chargeurs de classes personnalisés, ce qui permet à |ceux-ci de rechercher et de 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 fichier docs/apidoc.zip. Voir le |document Diagnostics Guide pour en savoir |plus sur le mode d'utilisation de ces interfaces.

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

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-1.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 utilisateur fournis avec ce SDK et le Runtime Environment ont été testés à l'aide de lecteurs d'écran. Les lecteurs d'écran tels que Home Page Reader ou JAWS peuvent être utilisés avec ces guides.

Pour modifier la taille des polices des guides utilisateur, 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-128.ibm.com/developerworks/java/jdk/additional/

## Accessibilité iKeyman

|En plus de l'interface graphique, l'outil iKeyman fournit l'outil |de ligne de commande IKEYCMD, qui a les mêmes fonctions que l'interface |graphique iKeyman. IKEYCMD permet de gérer les clés, certificats et demandes de certificats. Vous pouvez appeler IKEYCMD à partir des scripts de shell natifs et à partir des programmes destinés à être utilisés lorsque les applications requièrent des interfaces personnalisées pour les tâches de gestion de certificats et de clés. IKEYCMD peut créer des fichiers de base de données de clés pour tous les |types actuellement pris en charge par iKeyman. IKEYCMD peut également créer des demandes de certificats, importer des certificats signés par CA et gérer les certificats auto-signés.

Pour exécuter une commande IKEYCMD, entrez :

    java [-Dikeycmd.properties=<properties file>]com.ibm.gsk.ikeyman.ikeycmd
    <object> <action> [options]

où :

<object>
  correspond à l'un des éléments suivants :
  -keydb
    Actions entreprises sur la base de données de clés (un fichier de base de données de clés CMS, un fichier de clés WebDB ou une classe SSLight)
  -cert
    Actions devant être entreprises dans une base de données de clés
  -certreq
    Actions devant être entreprises sur une demande de certificat dans une base de données de clés
  -version
    Affiche les informations de version pour IKEYCMD
  -help
    Affiche l'aide relative aux appels de IKEYCMD.
<action>
  |L'action précise à entreprendre sur l'objet. Pour voir les actions |disponibles pour un objet, appelez IKEYCMD en transmettant uniquement |l'objet en tant qu'argument. L'aide contextuelle s'affiche, décrivant uniquement les actions |disponibles pour cet objet.
-Dikeycmd.properties
  Indique le nom d'un fichier de propriétés facultatif à utiliser pour cet appel Java. Le fichier de propriétés par défaut ikeycmd.properties est fourni comme fichier exemple pouvant être modifié et utilisé par toute application Java.

Remarque :
Les mots-clés des objets et des actions doivent se trouver dans l'ordre défini. Toutefois, les options ne sont pas à position fixe et peuvent être placées dans tout ordre à condition qu'elles soient définies comme paires option-opérande.

Pour plus d'informations, consultez le guide utilisateur d'iKeyman accessible à l'adresse : http://www.ibm.com/developerworks/java/jdk/security/index.html.

## Passage clavier des composants JComboBox dans Swing

Si vous passez la boîte à liste déroulante d'un composant JComboBox avec les touches fléchées, le bouton ou le champ éditable de la zone de liste déroulante ne change pas de valeur tant qu'un élément n'est pas sélectionné. Ce comportement est voulu pour 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.

## (Linux IA 32 bits, PPC32 et PPC64 uniquement) Accessibilité de Web Start

IBM Java Web Start Version 5.0 comporte plusieurs améliorations de l'accessibilité et de la facilité d'utilisation par rapport à la version précédente, 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 .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.

# Restrictions d'utilisation

Les sections suivantes décrivent les restrictions d'utilisation de SDK et Runtime Environment pour Linux.

## Limitations applicables à toutes les plateformes Linux, sauf indication contraire

- |Le gestionnaire de fenêtres peut remplacer certains raccourcis-clavier |Java. Si vous devez utiliser un raccourci-clavier remplacé, reportez-vous à la documentation |de votre système d'exploitation et modifiez les raccourcis-clavier du gestionnaire de fenêtres. |

- |Le système X ne peut pas utiliser plus de 255 descripteurs de fichier. Etant donné que la JVM conserve les descripteurs de fichier pour les fichiers jar ouverts, X peut |ne pas disposer de suffisamment de descripteurs de fichier. Pour éviter cette situation, vous |devez définir la variable d'environnement JAVA_HIGH_ZIPFDS de telle sorte que la machine JVM utilise un plus grand nombre de descripteurs de |fichier pour les fichiers jar. |

  Pour utiliser la variable d'environnement JAVA_HIGH_ZIPFDS, attribuez-lui une valeur comprise entre 0 et 512. La JVM ouvre alors les premiers fichiers JAR |en utilisant des descripteurs de fichier, au maximum 1024. Par exemple, si votre programme |a la capacité de charger 300 fichiers jar :

  `export JAVA_HIGH_ZIPFDS=300` |

  Les 300 premiers fichiers jar sont alors chargés à l'aide des descripteurs de fichier |724 à 1023. Tous les fichiers jar ouverts après seront ouverts dans la plage normale.

- Si vous utilisez KDE (K Desktop Environment), vous ne pourrez peut-être pas utiliser le presse-papiers du système avec DBCS pour copier les informations entre les applications Linux et Java.

- Sous RHEL3, SLES9, et les distributions plus récentes, la bibliothèque d'unités d'exécution par défaut est NPTL. Cette dernière implémente les unités d'exécution Java en tant qu'unités d'exécution natives. Dans les distributions antérieures, la bibliothèque d'unités d'exécution par défaut est LinuxThreads qui implémente les unités d'exécution en tant que nouveaux processus. Si le nombre d'unités d'exécution Java dépasse le nombre maximal de processus autorisés, le programme peut se bloquer.

  Le nombre maximal d'unités d'exécution disponibles est déterminé au minimum par les éléments suivants :

  - le nombre de processus utilisateur (ulimit -u) dans /etc/security/limits.conf,
  - la limite définie dans /proc/sys/kernel/threads_max,
  - la limite PTHREAD_THREADS_MAX définie dans libpthreads.so (la modification de cette valeur implique une nouvelle compilation de glibc)

  Toutefois, il se peut que vous n'ayez plus assez de mémoire de stockage avant d'atteindre le nombre maximal d'unités d'exécution.

- Si vous avez mis fin à une application Java avec Ctrl-C, plusieurs processus peuvent rester orphelins.

- Les résultats KeyEvents qui impliquent l'utilisation de la touche ALT diffèrent selon le gestionnaire de fenêtres utilisé dans Linux. Ils diffèrent également en fonction du système d'exploitation. Avec le gestionnaire de fenêtres Enlightenment, Alt+A et Maj+Alt+A produisent des modificateurs différents, alors que Ctrl+Alt+A ne produit aucun événement de touche. Par contre, avec le gestionnaire de fenêtres WindowMaker, Ctrl+Alt+A produit un événement de touche.

- Avec Linux X Window System, les codes clavier sont définis comme suit: 64 0xffe9 (Alt_L) 0xffe7 (Meta_L) et 113 0xffea (Alt_R) 0xffe8 (Meta_R). Pour vérifier ces touches, entrez la commande suivante à l'invite du shell :

      xmodmap -pk

  Ceci explique pourquoi les touches Meta et Alt sont activées ensemble dans le SDK. Comme solution palliative, vous pouvez supprimer la définition Meta_x en entrant la commande suivante à l'invite du shell:

      xmodmap -e "keysym Alt_L = Alt_L" -e "keysym Alt_R = Alt_R"

  Remarque :
  Cette solution peut affecter d'autres applications X-Window exécutées sur le même écran si elles utilisent la touche Meta que vous avez supprimée.

- La création de paires de clés DSA de longueur différente risque de prendre beaucoup de temps sur des machines lentes. Ce délai ne doit pas être interprété comme un arrêt et le processus ira à son terme si on lui laisse le temps. L'algorithme de génération des clés DSA a été optimisé pour générer des longueurs de clé standard (par exemple, 512, 1024) plus rapidement que les autres longueurs.

- Les programmes natifs ne peuvent pas créer de machine virtuelle sans interface JNI_VERSION_1_1(0x00010001). Il est impossible d'appeler JNI_CreateJavaVM() et de lui transmettre une version de JNI_VERSION_1_1(0x00010001). Les versions pouvant être transmises sont les suivantes :
  - JNI_VERSION_1_2(0x00010002)
  - JNI_VERSION_1_4(0x00010004)

  La machine virtuelle créée est déterminée par les bibliothèques Java présentes (soit 1.2.2, 1.3.x, 1.4.x, 5.x), et non par celle impliquée par la version de l'interface JNI transmise.

  La version de l'interface n'a aucune influence sur le comportement de la machine virtuelle si ce n'est sur les fonctions disponibles pour le code natif.

- L'appel de JNI_CreateJavaVM() à partir d'une application JNI peut entraîner un échec de segmentation (signal SIGSEGV). Pour éviter ce problème, recompilez votre programme JNI en spécifiant l'option -lpthread.

- Dans la version en chinois traditionnel, les touches de fonction Entrée, Espace, Retour arrière et Echap ne fonctionnent pas comme prévu lorsque vous utilisez les éditeurs IME LinYi ZhuYin, YiTian ZhuYin et Bosham pour saisir les caractères TCH. La touche Entrée permet d'insérer une ligne, la touche Echap permet d'annuler les chaînes de pré-édition ou la fenêtre candidate, et la barre d'espacement permet d'insérer des espaces. La fenêtre candidate doit disparaître une fois que vous avez appuyé sur la touche de validation, et ne doit pas réapparaître lorsque vous appuyez sur la touche Retour en arrière pendant que vous utilisez les éditeurs IME LinYi ZhuYin, YiTian ZhuYin et Bosham pour saisir les caractères en chinois traditionnel.

- Si vous exécutez de nombreuses unités d'exécution concurrentes, le message suivant peut s'afficher : `java.lang.OutOfMemoryError`. Il indique que votre machine commence à manquer de ressources et les messages peuvent avoir les raisons suivantes :
  1. Aucune nouvelle unité d'exécution ne peut être créée car :
     - Le nombre maximal de processus créés a été atteint. (Si votre installation Linux utilise LinuxThreads et non NPTL.)
     - Les ressources système sont insuffisantes pour créer de nouvelles unités d'exécution. Dans ce cas, d'autres exceptions Java peuvent s'afficher, selon le système sur lequel s'exécute votre application.
  2. La mémoire du noyau est insuffisante ou fragmentée. Les messages noyau correspondants et dont l'ID processus a été arrêté à l'aide de la commande kill sont consignés dans le fichier /var/log/messages.
  Essayez d'optimiser votre système pour augmenter les ressources système correspondantes.

- Pendant l'installation, si vous avez déjà installé une version antérieure de ce produit distribué par Red Hat, le gestionnaire RPM (Red Hat Package Manager) signalera que la version du module IBM est antérieure à toute version du produit distribué par Red Hat. Cette condition est due au fait que Red Hat ajoute un "numéro de série" au module RPM, ce qui remplace le schéma de contrôle des versions pour le module et, par défaut, RPM refuse d'installer un module qui apparaît être antérieur à celui déjà installé. Vous pouvez installer le nouveau module IBM à l'aide de l'option --oldpackage de la commande rpm.

- Lorsque vous exécutez une application Java AWT/Swing sur une machine Linux et que vous en exportez l'affichage sur une seconde machine, certaines boîtes de dialogue risquent de ne pas s'afficher si le jeu de polices chargé sur la machine client X est différent de celui chargé sur la machine serveur X. Cet incident est plus particulièrement constaté sur SLES8 avec des environnements locaux chinois, lorsque l'installation par défaut de la version serveur installe des polices arphic, mais que l'installation par défaut du client ne les installe pas. Pour éviter cet incident, installez les mêmes polices sur les deux machines.

- Si l'environnement local de votre système utilise un codage UTF-8, certains outils SDK peuvent générer une exception sun.io.MalformedInputException. Pour savoir si votre système utilise un codage UTF-8, vérifiez que les variables d'environnement spécifiques à l'environnement local, telles que LANG et LC_ALL, se terminent par le suffixe ".UTF-8". Si l'exception sun.io.MalformedInputException est générée, changez les caractères qui ne se trouvent pas dans la plage des caractères ASCII sur 7 bits (0x00 - 0x7f) et qui ne sont pas représentés comme littéraux de caractère Java Unicode (par exemple : '\u0080'). Vous pouvez également résoudre cet incident en supprimant le suffixe ".UTF-8" des variables d'environnement spécifiques à l'environnement local ; par exemple, si l'environnement local par défaut de votre machine est "en_US.UTF-8", affectez la valeur "en_US" à la variable LANG.
  Remarque :
  Certaines distributions de Red Hat, y compris Red Hat 9 et RHEL3, utilisent le codage UTF-8 par défaut.

- Si vous utilisez AMI et xcin dans un environnement multiplateforme (par exemple, si vous essayez d'exporter l'affichage entre un système 32 bits et un système 64 bits ou entre un système big-endian et un système little-endian), certains incidents peuvent survenir. Dans ce cas, adressez-vous à votre distributeur Linux.

- Sur Red Hat Enterprise Linux 3, les caractères chinois risquent de ne pas s'afficher dans les composants de texte AWT, excepté pour les caractères GB2312 de l'environnement local chinois GB18030.

- |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. A la place, utilisez |l'onglet Remote dans JConsole pour vous connecter à la machine virtuelle à contrôler. Lorsque vous |lancez l'application à contrôler, définissez les options de ligne de commande : |
  |
  - -Dcom.sun.management.jmxremote.port=<valeur> pour définir le port sur lequel l'agent de gestion doit écouter.
  |
  - -Dcom.sun.management.jmxremote.authenticate=false pour désactiver l'authentification sauf si vous avez créé |un fichier de noms d'utilisateur.
  |
  - -Dcom.sun.management.jmxremote.ssl=false pour désactiver le chiffrement SSL.
  |

- |Utilisateurs de la version en chinois, coréen et japonais de Red Hat |Enterprise Linux 4 uniquement : Si vous utilisez la méthode IIIMF (Internet/Intranet Input Method |Framework), utilisez les composants IIIMF inclus dans Red Hat Enterprise |Linux 4 Update 2 ou version ultérieure. Prenez également en compte l'incident décrit ci-dessous. Si cet incident |survient, contactez Red Hat à l'adresse http://www.redhat.com. |
  |
  - Sous Linux zSeries 64 bits, des erreurs IIIMF peuvent survenir ou le démarrage |peut ne pas abouti. Utilisateurs de la version japonaise uniquement : reportez-vous au numéro Bugzilla Red Hat RIT73533.
  |

- |Utilisateurs de la version en chinois simplifié de Red Hat Enterprise |Linux 4 uniquement L'environnement local zh_CN.GB18030 n'est pas pris en charge par xlib dans RHEL4. |xterm ne peut pas activer la méthode d'entrée pour entrer des caractères GB18030. Utilisez à la place |l'environnement local zh_CN.UTF8. Si vous disposez de programmes ou de données codés à l'aide de GB2312, GBK |ou GB18030 et que vous souhaitez les migrer vers RHEL4, vous devez auparavant les traiter à l'aide d'iconv |pour les convertir à l'aide d'utf-8 afin que les programmes puissent s'exécuter et que les données |puissent s'afficher correctement dans RHEL4 avec l'environnement local zh_CN.UTF8. |

- |Sur RHEL 3 avec miniChinput (serveur XIM chinois simplifié) |dans des environnements 64 bits (tels que des plateformes AMD64 ou zSeries 64 bits), Java peut |se comporter de manière imprévue. Contactez Red Hat à l'adresse http://www.redhat.com. Reportez-vous au numéro Bugzilla |Red Hat RIT75701. |

- |Sur RHEL 3 avec ami (serveur XIM coréen), Java peut se comporter de |manière imprévue sur des environnements 64 bits (tels que des plateformes AMD64 ou zSeries |64 bits). Contactez Red Hat à l'adresse http://www.redhat.com. |Reportez-vous aux numéros Bugzilla Red Hat RIT73605 et RIT75708. |

- |Sur RHEL 4 avec xcin (serveur XIM chinois traditionnel), Java peut |se comporter de manière imprévue. Par exemple, une erreur de segmentation peut survenir |lors de l'utilisation de Java sur des environnements 64 bits (tels des plateformes AMD64 ou zSeries 64 bits). Contactez |Red Hat à l'adresse http://www.redhat.com. Reportez-vous au numéro Bugzilla Red Hat RIT78430. |

- |Utilisateurs de la version |japonaise, chinoise et coréenne : Vous ne pouvez pas utiliser XIM pour entrer vos propres caractères dans des composants |de texte sur une applet Java dans un navigateur Web. |Cette limitation existe car XEmbed requiert un correctif pour le fichier de bibliothèque X11. |Pour éviter cette situation, indiquez le paramètre système -Dsun.awt.noxembed=true afin de désactiver XEmbed. Vous pouvez définir cette option à l'aide du panneau de configuration : |
  |
  1. Ouvrez le panneau de configuration du plug-in Java et accédez à l'onglet Java.
  |
  2. Cliquez sur le bouton Afficher de la section Paramètres de l'applet Java Runtime.
  |
  3. Entrez -Dsun.awt.noxembed=true dans Paramètres Java Runtime |et cliquez sur OK.
  |
  4. Cliquez sur Appliquer
  |
  5. Démarrez un navigateur.
  |

## Limitations de Linux IA 32 bits

- Pour les utilisateurs de texte arabe, si Linux est utilisé avec une carte vidéo Matrox et que l'accélération est activée, les caractères sont déformés à l'écran lorsque drawString est utilisé pour afficher de grandes polices. Cet incident provient du pilote de ces cartes. La solution recommandée consiste à désactiver l'accélération pour la carte.

- Sous SLES 9 NPTL, le pilote de port parallèle provoque une panne du noyau et arrête une unité d'exécution Java. La machine virtuelle Java détecte cette panne lorsqu'elle tente d'interrompre l'unité d'exécution pour la récupération de place, ce qui provoque l'arrêt de la JVM. Un fichier de vidage est généré et le message "JVMLH030: threads are disappearing when trying to suspend all threads" s'affiche.

  Le rapport 47947 SUSE Bugzilla signale cet incident. Ce bogue est résolu dans SLES 9 Service Pack 1.

## Limitations Linux AMD64

| |
- Remarque importante sur les paramètres BIOS sur |des systèmes AMD64 SMP : |

  Le paramètre BIOS Node |memory interleaving doit avoir la valeur `DISABLED`. Sinon, |des résultats imprévisibles peuvent se produire, dont des |pannes et blocages Java. Cette instruction respecte la recommandation |d'AMD.

## Limitations de Linux PPC 32 bits et 64 bits

- Si le code Java utilise des appels JNI et qu'un de ces appels contient plus de huit paramètres float ou double, le code C doit être compilé à l'aide du GNU C Compiler (GCC) gcc-2.95.3 niveau Free Software Foundation (FSF).

- Si vous utilisez XFree86 version 3.x, vous recevrez peut-être une erreur SIGSEGV. Nous vous conseillons donc d'utiliser XFree86 version 4.x.

- Si la date définie est antérieure à 1970, vous recevez une erreur de type exception lorsque vous tentez de démarrer Java. Pour éviter cette situation, mettez le poste à la date du jour manuellement.

- Le package JavaComm ne prend pas en charge les opérations de port parallèle sur les noyaux SLES 9 GA et SP1. Cette restriction n'existe plus dans le noyau SP2. Le numéro SUSE Bugzilla est 50028.

- Suite à une fonction IOCTL non implémentée dans le mode 32 bits du noyau 64 bits, JavaComm ne prend pas en charge les opérations de ports série sous SLES 9 et RHEL 4. Cette restriction n'existe plus dans SLES 9 SP2 (Numéro Bugzilla 49787) et RHEL 4 mise à jour 1 (numéro Bugzilla 144904).

## Limitations de Linux PPC 64 bits

- Le compilateur croisé gcc par défaut (version 3.2-49) génère plusieurs erreurs. Pour générer la bibliothèque partagée libFileStat.so, exécutez la commande `/opt/cross/bin/powerpc64-linux-gcc -shared -o libFileStat.so -I<CHEMIN_SDK>/include FileStat.c`, `<CHEMIN_SDK>` correspondant au chemin d'installation de SDK.

## Limitations de Linux zSeries 64 bits

Les limitations suivantes s'appliquent aux utilisateurs chinois et taïwanais sur Linux zSeries 64 bits :

- Les serveurs IMS (input method server) chinois et taïwanais (xcin) n'ont pas été testés avec la version 5.0.

## Limitations Linux zSeries 31 et 64 bits

- Si vous utilisez des composants audio sur une machine sans carte son, il est possible qu'un message d'erreur s'affiche pour signaler que la mémoire est insuffisante lorsque Java tente de diffuser un son. Ce message s'affiche dans la console mais n'a aucune incidence sur l'application Java.

- Bien que le noyau Linux fourni dans les distributions Linux courantes prenne en charge le protocole Internet version 6 (IP6), il se peut que vous ayez des difficultés à l'utiliser. Le support d'IP6 à partir de Java est inclus dans cette version, mais il est conseillé de le désactiver à l'aide de l'option -Djava.net.preferIPv4Stack=true de la commande Java. Si vous installez un noyau assurant le support intégral d'IP6, vous n'avez pas besoin de cette option.

- |Si vous utilisez Java pour zSeries 31 ou 64 bits avec un serveur |X à l'aide d'un paramètre haute résolution, les glyphes de police d'un composant AWT |Choice avec Motif AWT peuvent être découpés. Pour éviter cette situation, réduisez le |paramètre de résolution ou utilisez XAWT à la place de Motif AWT. |

# Commentaires sur le guide utilisateur

Vos commentaires sur ce guide utilisateur nous sont très utiles. Si vous avez des remarques ou des suggestions à formuler sur notre documentation, veuillez nous les transmettre. 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 ;
  - <code international>44 1962 842327, à partir d'un autre pays.
- 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.

# 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 EMEA Director of Licensing
  IBM Europe Middle-East Africa
  Tour Descartes
  92066 Paris-La Défense Cedex 50 France. Pour le Canada, veuillez adresser votre courrier à : IBM Director of Commercial Relations IBM Canada Ltd 3600 Steeles Avenue East Markham, Ontario L3R 9Z7 Canada

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 programmes et les logiciels qu'il décrit.

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 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 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, iSeries, pSeries 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 d'Intel Corporation aux Etats-Unis et/ou dans d'autres pays.

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

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

D'autres sociétés sont propriétaires des autres marques, noms de produits ou logos qui pourraient apparaître dans ce document.

Le présent produit est également partiellement basé sur le logiciel FreeType Project. Pour plus d'informations sur FreeType, consultez le site suivant : http://www.freetype.org.

Le présent produit comprend des logiciels développés par la société Apache Software Foundation (http://www.apache.org/).