Avant d'utiliser le présent document et le produit associé, prenez connaissance des informations générales figurant à la section Remarques.
LE PRESENT DOCUMENT EST LIVRE EN L'ETAT SANS AUCUNE GARANTIE EXPLICITE OU IMPLICITE. IBM DECLINE NOTAMMENT TOUTE RESPONSABILITE RELATIVE A CES INFORMATIONS EN CAS DE CONTREFACON AINSI QU'EN CAS DE DEFAUT D'APTITUDE A L'EXECUTION D'UN TRAVAIL DONNE.
Ce document est mis à jour périodiquement. Chaque nouvelle édition inclut les mises à jour. Les informations qui y sont fournies sont susceptibles d'être modifiées avant que les produits décrits ne deviennent eux-mêmes disponibles. En outre, il peut contenir des informations ou des références concernant certains produits, logiciels ou services non annoncés dans ce pays. Cela ne signifie cependant pas qu'ils y seront annoncés.
Pour plus de détails, pour toute demande d'ordre technique, ou pour obtenir des exemplaires de documents IBM, référez-vous aux documents d'annonce disponibles dans votre pays, ou adressez-vous à votre partenaire commercial.
Vous pouvez également consulter les serveurs Internet suivants :
Compagnie IBM France Direction Qualité Tour Descartes 92066 Paris-La Défense Cedex 50
(C) Copyright IBM France 2007. Tous droits réservés.
Ce guide d'utilisation fournit des informations générales sur IBM SDK et Runtime Environment pour Linux, Java Technology Edition, Version 6 et d'autres informations spécifiques sur les différences entre les implémentations IBM et Sun.
Consultez-le en complément de la documentation plus détaillée disponible sur le site Web de Sun à l'adresse http://java.sun.com.
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.
(plateformes Intel 32 bits uniquement) Ces environnements virtuels sont pris en charge :
Le document Diagnostics Guide fournit des informations détaillées sur IBM Virtual Machine for Java.
Ce guide d'utilisation fait partie intégrante d'une édition et s'applique uniquement à cette édition spécifique. Assurez-vous d'être en possession du guide d'utilisation approprié pour l'édition utilisée.
Les termes "Runtime Environment" et "Java Virtual Machine" sont utilisés indifféremment dans ce guide d'utilisation.
|Les modifications techniques apportées à cette version du guide d'utilisation, autres que les modifications mineures ou importantes, sont indiquées par des chevrons bleus lors de l'affichage dans un centre de documentation, en rouge avec des barres verticales placées à leur gauche lors de l'affichage au format HTML ou sur une impression en couleurs ou par des barres verticales placées à leur gauche lors de l'affichage au format PDF.
Le code de programme n'est pas conçu pour ou destiné à une utilisation dans des applications en temps réel telles que (mais de façon non limitative) le contrôle en ligne des avions, du trafic aérien, de la navigation aérienne ou des communications aériennes ; ou la conception, construction, l'opération ou l'entretien de toute installation nucléaire.
Le SDK IBM est un environnement de développement permettant d'écrire et d'exécuter des applets et des applications conformes à Java 6 Core Application Program Interface (API).
Le SDK inclut Runtime Environment for 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ébogables et les fichiers de classe. L'environnement d'exécution contient seulement un sous-ensemble des classes se trouvant dans le SDK. Il permet de prendre en charge un programme Java lors de l'exécution mais ne permet pas de compiler les programmes Java. Le Runtime Environment for 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/PPC64 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, où xx est une abréviation représentant la langue. Pour afficher ou imprimer le contrat de licence, ouvrez ce fichier dans un navigateur Web.
Dans ce guide utilisateur, le répertoire d'installation par défaut de SDK est désigné par /opt/ibm/java-i386-60/. Si vous n'utilisez pas Linux IA 32 bits, votre répertoire d'installation par défaut sera différent.
Les plateformes ci-après ont des répertoires d'installation par défaut différents ; remplacez-les pour la plateforme utilisée lorsque vous voyez /opt/ibm/java-i386-60/ :
Les commandes d'interpréteur Korn sont utilisées à titre d'exemple dans tout le reste de ce guide utilisateur.
En général, les applets ou les applications ayant déjà été exécutées avec une version antérieure du SDK doivent fonctionner correctement avec IBM SDK pour Linux, v6. Il n'est pas garanti que les classes compilées avec cette version fonctionnent sur les versions antérieures.
Pour plus d'informations sur les problèmes de compatibilité entre les différentes éditions, reportez-vous aux pages Web Sun suivantes :
|http://java.sun.com/javase/6/webnotes/compatibility.html
http://java.sun.com/j2se/5.0/compatibility.html
http://java.sun.com/j2se/1.4/compatibility.html
http://java.sun.com/j2se/1.3/compatibility.html
Si vous utilisez le SDK comme faisant partie d'un autre produit (par exemple, IBM WebSphere Application Server) et que vous effectuez une mise à niveau depuis une version antérieure du SDK, par exemple v5.0, il se peut que les classes sérialisées ne soient pas compatibles. Ces dernières sont toutefois compatibles entre les diverses actualisations de service.
A partir de la version 5.0, IBM Runtime Environment for Linux contient les nouvelles versions d'IBM Virtual Machine for Java et du compilateur JIT (Just-In-Time).
Si vous effectuez une migration à partir d'une version d'IBM Runtime Environment plus ancienne, notez que :
Les SDK System z 31 et 64 bits et Runtime Environment s'exécutent sur les machines System z9 et zSeries.
Les SDK et Runtime Environment s'exécutent sur les serveurs ou équivalents suivants :
Le SDK contient plusieurs outils de développement ainsi qu'un Java Runtime Environment (JRE). Cette section décrit le contenu des outils du SDK et de l'environnement d'exécution.
Les applications entièrement écrites en Java ne doivent pas être dépendantes de l'arborescence des répertoires du SDK d'IBM (ou des fichiers contenus dans ces répertoires). Toute dépendance de cette arborescence (ou de ces fichiers) peut compromettre la portabilité de l'application.
Les guides d'utilisation, la documentation utilisateur ainsi que la licence, les fichiers de droit d'auteur, la documentation utilisateur et le répertoire demo qui les accompagnent constituent la seule documentation comprise dans ce SDK pour 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.
Liste des classes et des outils que vous pouvez utiliser avec l'environnement d'exécution standard.
Une liste des outils et des informations de référence inclus dans le SDK standard.
Le fichier de licence, /opt/ibm/java-i386-60/docs/content/<locale>/LA_<locale>, contient le contrat de licence SDK du logiciel Linux (où <locale> correspond au nom de votre environnement, par exemple Fr_FR). Pour afficher ou imprimer le contrat de licence, ouvrez ce fichier dans un navigateur Web.
Vous pouvez installer IBM Java SDK et 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/java-i386-60/. Les exemples de ce guide supposent que vous avez déjà installé Java dans ce répertoire.
Si vous effectuez une mise à niveau du SDK à partir d'une version précédente, sauvegardez tous les fichiers de configuration et 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.
Le SDK dépend de bibliothèques partagées qui ne sont pas installées par défaut pour Red Hat Enterprise Linux (RHEL).
Sous RHEL 4, les fichiers RPM contenant ces bibliothèques sont les suivants :
Pour inclure ces bibliothèques lors de l'installation RHEL 4, procédez comme suit :
Le SDK dépend de bibliothèques partagées qui ne sont pas installées par défaut pour Red Hat Enterprise Linux (RHEL).
Sous RHEL 5, les fichiers RPM contenant ces bibliothèques sont les suivants :
Pour inclure ces bibliothèques lors de l'installation RHEL 5, procédez comme suit :
Pour exécuter le SDK IBM for Java sur Red Hat Enterprise Linux Version 5 avec SELinux activé, Java doit être déjà installé dans le répertoire par défaut ou une commande doit être entrée.
Si Java n'est pas installé dans le répertoire par défaut, entrez :
chcon -R -t texrel_shlib_t <chemin_sdk>
où <chemin_sdk> correspond au chemin d'accès à Java.
Pour plus d'informations sur SELinux, voir Introduction to SELinux dans la documentation Red Hat.
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
Procédure d'installation à partir d'un fichier RPM.
Pour mettre à niveau votre machine virtuelle à l'aide d'un outil RPM, vous devez d'abord désinstaller toutes les versions précédentes. Pour installer deux versions de la machine virtuelle dans des emplacements différents, utilisez l'option rpm --force afin d'ignorer le conflit de version ou installez la machine virtuelle à partir du fichier .tgz.
rpm -ivh ibm-java2-<arch>-sdk-6.0-0.0.<arch>.rpmou
rpm -ivh ibm-java2-<arch>-jre-6.0-0.0.<arch>.rpm
où <arch> représente votre architecture : i386, x86_64, ppc, ppc64, s390 ou s390x.
Procédure d'installation à partir d'un fichier .tgz.
tar -zxvf ibm-java2-sdk-60-linux-<arch>.tgzou
tar -zxvf ibm-java2-jre-60-linux-<arch>.tgz
où <arch> représente votre architecture : i386, x86_64, ppc, ppc64, s390 ou s390x.
chcon -R -t texrel_shlib_t /opt/ibm/java2-i386-60/jre chcon -R -t texrel_shlib_t /opt/ibm/java2-i386-60/bin chcon -R -t texrel_shlib_t /opt/ibm/java2-i386-60/lib
IBM Java est également disponible dans un format compatible avec JPackage.
Afin de simplifier la gestion du SDK, plusieurs de ses composants sont maintenant disponibles en tant que fichiers RPM distincts, par exemple : l'environnement JRE (Java Runtime Environment) de base, le kit de développement, le plug-in, l'exemple de démonstration, le son, la source et les polices. Le fichier RPM "jpackage-utils" (téléchargeable à partir de http://jpackage.org), qui autorise la gestion de plusieurs fichiers RPM Java sur un système, est également un élément prérequis pour les SDK IBM. Pour plus d'informations sur la spécification JPackage, voir http://jpackage.org.
Incohérences des codages de police sur Red Hat Advanced Server
Si vous modifiez la variable d'environnement PATH, tous les programmes de lancement Java du chemin seront remplacés.
La variable d'environnement PATH permet à Linux de localiser les programmes et utilitaires tels que javac, java et javadoc, à partir du répertoire de travail. Pour afficher la valeur actuelle de PATH, entrez ce qui suit à l'invite de commande :
echo $PATH
Pour ajouter les programmes de lancement Java au chemin d'accès :
export PATH=/opt/ibm/java-i386-60/bin:/opt/ibm/java-i386-60/jre/bin:$PATH
Une fois le chemin défini, vous pouvez exécuter un outil en entrant son nom à l'invite de commande à partir de n'importe quel répertoire. Par exemple, pour compiler le fichier Myfile.Java, entrez ce qui suit à l'invite de commande :
javac Myfile.Java
Le chemin d'accès aux classes indique aux outils SDK, tels que java, javac et javadoc, l'emplacement des bibliothèques de classes Java.
Vous devez définir le chemin d'accès aux classes de manière explicite uniquement dans les cas suivants :
Pour afficher la valeur actuelle de la variable d'environnement CLASSPATH, entrez la commande suivante à l'invite shell :
echo $CLASSPATH
Si vous développez et exécutez des applications qui utilisent différents environnements d'exécution, y compris d'autres versions que vous avez installées séparément, vous devez définir CLASSPATH et PATH explicitement pour chaque application. Si vous exécutez plusieurs applications simultanément et utilisez des environnements d'exécution différents, chaque application doit être exécutée dans l'invite shell qui lui est propre.
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é.
Procédure de désinstallation du package RPM (Red Hat Package Manager).
Pour désinstaller le SDK ou Runtime Environment pour Linux si le package RPM installable est déjà installé, procédez comme suit :
Une liste des packages Java IBM installés s'affiche, par exemple :
ibm-java2-<arch>-jre-6.0-0.0.<arch> ibm-java2-<arch>-sdk-6.0-0.0.<arch>
Cette sortie indique les packages que vous pouvez désinstaller, à l'aide de la commande rpm -e, par exemple :
rpm -e ibm-java2-<arch>-jre-6.0-0.0.<arch> rpm -e ibm-java2-<arch>-sdk-6.0-0.0.<arch>
Vous pouvez également utiliser un outil graphique tel que kpackage ou yast2
Procédure de suppression du IBM SDK pour Linux, v6 ayant été extrait du module condensé.
Les applications Java peuvent être démarrées à l'aide du programme de lancement java ou via l'interface JNI. Les paramètres sont transmis à une application Java à l'aide des arguments de ligne de commande, des variables d'environnement et des fichiers de propriétés.
Brève description des commandes java et javaw.
Les outils java et javaw lancent une application Java en démarrant Java Runtime Environment et en chargeant une classe déterminée.
La commande javaw est identique à java, sauf qu'elle n'est associée à aucune fenêtre de console. Utilisez la commande javaw lorsque vous ne souhaitez pas qu'une fenêtre d'invite de commande s'affiche. Si le lancement échoue, le programme de lancement de javaw affiche une boîte de dialogue contenant un message d'erreur.
La machine virtuelle recherche la classe initiale (ainsi que les autres classes utilisées) à trois emplacements : le chemin d'accès à la classe d'amorce, les extensions installées et le chemin d'accès à la classe utilisateur. Les arguments ajoutés après le nom de classe ou le nom de fichier jar sont transmis à la fonction main.
Les commandes java et javaw ont la syntaxe suivante :
java [ options ] <classe> [ arguments ... ] java [ options ] -jar <fichier.jar> [ arguments ... ] javaw [ options ] <classe> [ arguments ... ] javaw [ options ] -jar <fichier.jar> [ arguments ... ]
Vous pouvez obtenir le numéro de compilation et de version IBM de votre installation Java à l'aide de l'option -version. |Vous pouvez également obtenir les informations de version de tous les fichiers jar figurant dans le chemin d'accès aux classes à l'aide de l'option -Xjarversion.
java -versionLes informations suivantes s'affichent :
java version "1.6.0-internal" Java(TM) SE Runtime Environment (build 20070329_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260-20070326_12091 (JIT enabled) J9VM - 20070326_12091_lHdSMR JIT - dev_20070326_1800 GC - 20070319_AA)Les dates de création ainsi que les versions exactes seront modifiées.
Vous pouvez également afficher les informations de version relatives à tous les fichiers jar figurant dans le chemin d'accès, le chemin d'accès de l'initialisation et le répertoire d'extensions en entrant la commande suivante :
java -Xjarversion
Les informations suivantes s'affichent :
... /opt/ibm/java-i386-60/jre/lib/ext/ibmpkcs11impl.jar VERSION: 1.0 build_20070125 /opt/ibm/java-i386-60/jre/lib/ext/dtfjview.jar /opt/ibm/java-i386-60/jre/lib/ext/xmlencfw.jar VERSION: 1.00, 20061011 LEVEL: -20061011 ...
Les informations disponibles varient selon les fichiers jar et sont obtenues à partir des propriétés Implementation-Version et Build-Level du manifeste du fichier jar.
Vous pouvez indiquer les options Java et les propriétés système sur la ligne de commande à l'aide d'un fichier d'options ou d'une variable d'environnement.
Ces méthodes d'indication des options Java sont répertoriées par ordre de priorité :
java -Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump MyJavaClass
export IBM_JAVA_OPTIONS="-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump"
Les options les plus à droite sur la ligne de commande ont priorité sur celles de gauche ; par exemple, si vous indiquez :
java -Xint -Xjit myClass
l'option -Xjit est prioritaire.
Définitions des options standard.
Les programmes de lancement java et javaw acceptent les arguments et les noms de classes avec n'importe quel caractère contenu dans le jeu de caractères de l'environnement local courant. Vous pouvez également utiliser des séquences d'échappement Java pour spécifier n'importe quel caractère Unicode dans le nom de classe et les arguments.
Pour ce faire, utilisez l'option de ligne de commande -Xargencoding.
Par exemple, pour indiquer une classe nommée HelloWorld en codage Unicode pour les deux majuscules, utilisez cette commande :
java -Xargencoding '\u0048ello\u0057orld'
Les commandes java et javaw fournissent des messages traduits. Ces messages diffèrent suivant l'environnement local dans lequel Java est exécuté. Les descriptions détaillées des erreurs et les autres informations de débogage renvoyées par la commande java sont en anglais.
Le compilateur IBM JIT (Just-In-Time) génère dynamiquement le code machine pour les séquences de code intermédiaire fréquemment utilisées dans les applications Java et les applets en phase d'exécution. Le compilateur JIT v6 propose de nouvelles optimisations suite à la recherche du compilateur, améliore les optimisations implémentées dans les versions précédentes du compilateur JIT et fournit une meilleure exploitation matérielle.
IBM SDK et Runtime Environment incluent le JIT, qui est activé par défaut dans les applications utilisateur ainsi que les outils SDK. Il n'est généralement pas nécessaire d'appeler explicitement le compilateur JIT. La compilation du code intermédiaire Java en code machine se produit de manière transparente. Vous pouvez désactiver le JIT pour isoler un incident. Si un incident survient lors de l'exécution d'une application Java ou d'une applet, vous pouvez désactiver le JIT afin d'isoler l'incident. La désactivation du compilateur JIT est uniquement une mesure temporaire, sa présence étant requise pour optimiser les performances.
Pour plus d'informations sur le JIT, voir document Diagnostics Guide.
Le JIT peut être désactivé de différentes manières. Les options de ligne de commande remplacent la variable d'environnement JAVA_COMPILER.
La désactivation du compilateur JIT est une mesure temporaire permettant d'isoler des incidents lors du débogage des applications Java.
export JAVA_COMPILER=NONE
java -Djava.compiler=NONE <classe>
java -Xint < classe>
Le JIT est activé par défaut. Vous pouvez activer explicitement le JIT de plusieurs façons. Les options de ligne de commande remplacent la variable d'environnement JAVA_COMPILER.
export JAVA_COMPILER=jitcSi la valeur chaîne vide est attribuée à la variable d'environnement JAVA_COMPILER, le JIT reste désactivé. Pour désactiver la variable d'environnement, à l'invite shell, entrez :
unset JAVA_COMPILER
java -Djava.compiler=jitc <classe>
java -Xjit <classe>
Vous pouvez déterminer l'état du JIT à l'aide de l'option -version.
Exécutez le programme de lancement java à l'aide de l'option -version. A l'invite shell, entrez :
java -version
Si le compilateur JIT est inactif, le message qui s'affiche contient ce qui suit :
(JIT disabled)
Si le compilateur JIT est actif, le message qui s'affiche contient ce qui suit :
(JIT enabled)
Pour plus d'informations sur le JIT, voir les documents Diagnostics Guide.
Le récupérateur de place gère la mémoire utilisée par Java et par les applications exécutées dans la machine virtuelle.
Lorsque le récupérateur de place reçoit une demande de stockage, la mémoire inutilisée dans le segment de mémoire est mise de côté (on parle alors d'"allocation"). Le récupérateur de place vérifie également les zones de mémoire qui ne sont plus utilisées et les libère pour qu'elles puissent être réutilisées. Il s'agit de la "récupération".
La phase de récupération peut être déclenchée par un défaut d'allocation de mémoire, ce qui peut se produire lorsqu'il ne reste plus d'espace pour une demande de stockage ou par un appel System.gc() explicite.
La récupération de place peut avoir un impact considérable sur les performances des applications. Pour cette raison, la machine virtuelle IBM fournit différentes méthodes d'optimisation de la façon dont cette récupération est effectuée afin de limiter potentiellement l'incidence sur votre application.
Pour plus d'informations sur la récupération de place, reportez-vous au document Diagnostics Guide.
L'option -Xgcpolicy contrôle le comportement du récupérateur de place. Elle établit des compromis entre le débit de l'application et l'ensemble du système et les délais d'interruption nécessités par la récupération de place.
Le format et les valeurs de cette option sont les suivants :
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.
La machine virtuelle JVM utilise deux techniques pour réduire les délais d'interruption : la récupération de place simultanée et la récupération de place de génération.
L'option de ligne de commande -Xgcpolicy:optavgpause spécifie l'utilisation d'une récupération de place simultanée pour réduire de façon significative le temps passé à la récupération de place. La récupération de place simultanée réduit les délais d'interruption en effectuant des opérations de récupération simultanément avec l'exécution normale du programme afin de minimiser les perturbations provoquées par la collecte du segment de mémoire. L'option -Xgcpolicy:optavgpause réduit également l'impact de l'augmentation de la taille du segment sur la durée des interruptions pour récupération de place. L'option -Xgcpolicy:optavgpause est particulièrement utile pour les configurations présentant de grandes tailles de segment. Ainsi, vous noterez une certaine baisse du débit de vos applications.
Lors de la récupération de place simultanée, un laps de temps considérable est perdu à identifier les objets de longue durée qui ne peuvent alors pas être collectés. Si la récupération de place ne se concentre que sur les objets susceptibles d'être recyclables, vous pouvez réduire encore davantage les délais d'interruption de certaines applications. La récupération de place de génération parvient à cela en divisant le segment en deux "générations" : les zones "nursery" (nouvelle génération) et "tenure" (génération titulaire). Les objets sont placés dans l'une ou l'autre de ces zones suivant leur ancienneté. La zone "nursery" est la plus petite des deux et contient les objets les plus récents alors que la zone "tenure" est plus importante et contient les objets plus anciens. Les objets sont d'abord affectés à la zone "nursery" ; s'ils survivent assez longtemps, ils finissent par passer dans la zone "tenure".
La récupération de place de génération dépend d'une courte durée de la plupart des objets. Cette technique réduit les délais d'interruption en s'efforçant de récupérer en priorité de l'espace disque dans la zone "nursery" car c'est dans cette dernière que l'espace est le plus facilement recyclable. Alors que la récupération intégrale du segment est plus occasionnelle mais plus lente, la récupération des éléments de la zone "nursery" est plus fréquente et, si la taille de cette zone est assez petite, les délais d'interruption sont comparativement plus courts. Il existe toutefois un inconvénient à cette technique qui est, qu'avec le temps, la zone "tenure" peut être saturée si trop d'objets durent trop longtemps. Pour minimiser le délai d'interruption lorsque ce cas survient, ayez recours à une combinaison des deux techniques. L'option -Xgcpolicy:gencon spécifie l'utilisation combinée de la récupération de place simultanée et de la récupération de place de génération pour limiter au minimum les temps d'interruption pour récupération de place.
Si le segment Java est proche de la saturation et que la place à récupérer est très limitée, les demandes de nouveaux objets ne sont pas satisfaites rapidement car aucun espace n'est disponible immédiatement.
Si le segment est utilisé au maximum de sa capacité ou presque, une baisse de performance se produit au niveau des applications, indépendamment des options de récupération de place utilisées. Si des demandes d'espace supplémentaire sont effectuées, il se peut que l'application reçoive une exception OutOfMemoryError, qui entraîne l'arrêt de la JVM si cette dernière n'est pas interceptée et traitée. A ce stade, la machine virtuelle génère un fichier Javadump utilisé pendant les diagnostics. Dans ces cas de figure, il est recommandé d'augmenter la taille du segment à l'aide de l'option -Xmx ou de réduire le nombre d'objets utilisés.
Pour en savoir plus, voir le document Diagnostics Guide.
IBM SDK et Runtime Environment définissent l'euro comme devise par défaut pour les pays de l'Union Monétaire Européenne (UME) pour les dates ultérieures au 31 décembre 2001. A partir du 1 janvier 2008, Chypre et Malte utiliseront également l'euro comme devise par défaut.
Pour utiliser l'ancienne devise nationale, entrez -Duser.variant=PREEURO sur la ligne de commande Java.
Si vous utilisez les paramètres nationaux du Royaume-Uni, du Danemark ou de la Suède et souhaitez utiliser l'euro, entrez -Duser.variant=EURO sur la ligne de commande Java.
Les fichiers de configuration relatifs aux caractères de reprise de Linux (fontconfig.RedHat.bfc et fontconfig.SuSE.bfc) sont installés afin de fournir des paramètres de police appropriés pour les nouvelles distributions Linux .
Ces fichiers sont fournis à titre d'information uniquement. Leur existence n'implique en aucun cas que la nouvelle distribution Linux est une plateforme prise en charge pour le IBM SDK et Runtime Environment pour Linux, Java Technology Edition, Version 6.
| | |A partir de la version 6, les méthodes de saisie indiennes et thaïs ne sont pas disponibles par défaut. Vous devez inclure manuellement les fichiers jar de la méthode de saisie dans le chemin d'accès aux extensions Java pour pouvoir utiliser les méthodes de saisie indiennes et thaïs.
Dans la version 5.0, les fichiers jar de la méthode de saisie sont inclus dans le répertoire jre/lib/ext et sont automatiquement chargés par la machine virtuelle. Dans la version 6, les fichiers jar de la méthode de saisie sont inclus dans le répertoire jre/lib/im et doivent être ajoutés manuellement au chemin d'accès aux extensions Java pour permettre l'utilisation des méthodes de saisie indiennes et thaïs. Pour ce faire, utilisez l'une des méthodes suivantes :
|java -Djava.ext.dirs=/opt/ibm/java-i386-60/jre/lib/ext:/opt/ibm/java-i386-60/jre/lib/im <classe>
|
Si vous avez installé le SDK ouRuntime Environment dans un répertoire différent, |remplacez /opt/ibm/java-i386-60/ par le répertoire dans lequel vous avez installé le SDK ou Runtime Environment.
Le SDK pour Linux contient plusieurs bibliothèques et outils requis pour le développement d'applications Java.
Voir Outils SDK et informations de référence pour en savoir plus sur les outils disponibles.
| | |IBM SDK contient les analyseurs syntaxiques XML4J et |XL XP-J, le compilateur XL TXE-J 1.0 XSLT ainsi que l'interpréteur XSLT4J XSLT. |Ces outils vous permettent d'analyser, de valider, transformer et sérialiser des documents XML indépendamment de toute implémentation de traitement XML donnée.
|
Utilisez les localisateurs de fabrique pour rechercher les implémentations de classes Factory abstraites, comme décrit dans la section Sélection d'un processeur XML. |A l'aide des localisateurs de fabrique, vous pouvez sélectionner une bibliothèque XML différente sans modifier le code Java.
|IBM SDK for Java comporte les bibliothèques XML répertoriées ci-dessous.
|XML4J est un analyseur syntaxique prenant en charge les normes suivantes : |
|XML4J 4.5 est basé sur Apache Xerces-J 2.9.0. Voir http://xerces.apache.org/xerces2-j/ pour plus d'informations.
|XL XP-J 1.1 est un analyseur syntaxique non-validant haute performance prenant en charge StAX 1.0 (JSR 173) ; une API bidirectionnelle utilisée pour l'analyse d'extraction et la sérialisation du flux des documents XML 1.0 et XML 1.1. Voir la section Informations de référence relatives à XL XP-J pour plus d'informations sur les éléments pris en charge par XL XP-J 1.1.
|La version 5.0 de IBM SDK for Java contenait l'interpréteur et le compilateur XSLT4J. |L'interpréteur XSLT4J était utilisé par défaut.
| |La version 6 deIBM SDK for Java comporte XL TXE-J. XL TXE-J contient l'interpréteur XSLT4J version 2.7.8 ainsi qu'un nouveau compilateur XSLT. |Le nouveau compilateur est utilisé par défaut. Le compilateur XSLT4J n'est plus compris dans IBM SDK |for Java, voir Migration vers le compilateur XL-TXE-J pour plus d'informations sur la migration vers XL TXE-J.
| |XL TXE-J prend en charge les normes suivantes : |
|La sélection d'un processeur XML est effectuée à l'aide de fournisseurs de services. Lors de l'utilisation d'un localisateur de fabrique, Java examine les éléments suivants afin de déterminer le fournisseur de services à utiliser : |
|Les fournisseurs de services suivants contrôlent les bibliothèques de traitement XML utilisées par Java : |
|L'interpréteur XSLT4J est à présent remplacé par le compilateur XL TXE-J comme processeur XSLT par défaut. Procédez comme suit afin que votre application puisse utiliser la nouvelle bibliothèque.
|
Le compilateur XL TXE-J est plus rapide que l'interpréteur XSLT4J lorsqu'une seule transformation est appliquée plusieurs fois. Si vous exécutez une transformation plusieurs fois, la vitesse d'exécution du compilateur XL TXE-J est inférieure à celle de l'interpréteur XSLT4J en raison du temps système de compilation et d'optimisation.
|Pour continuer à utiliser l'interpréteur XSLT4J comme processeur XSLT, attribuez la valeur org.apache.xalan.processor.TransformerFactoryImpl au fournisseur de services javax.xml.transform.TransformerFactory.
|Procédez comme suit pour migrer vers le compilateur XL-TXE-J :
|Attribut du compilateur XSL4J | |Attribut du compilateur XL TXE-J | |
---|---|
translet-name | |http://www.ibm.com/xmlns/prod/xltxe-j/translet-name | |
destination-directory | |http://www.ibm.com/xmlns/prod/xltxe-j/destination-directory | |
package-name | |http://www.ibm.com/xmlns/prod/xltxe-j/package-name | |
jar-name | |http://www.ibm.com/xmlns/prod/xltxe-j/jar-name | |
generate-translet | |http://www.ibm.com/xmlns/prod/xltxe-j/generate-translet | |
auto-translet | |http://www.ibm.com/xmlns/prod/xltxe-j/auto-translet | |
use-classpath | |http://www.ibm.com/xmlns/prod/xltxe-j/use-classpath | |
debug | |http://www.ibm.com/xmlns/prod/xltxe-j/debug | |
indent-number | |http://www.ibm.com/xmlns/prod/xltxe-j/indent-number | |
enable-inlining | |Obsolète dans le nouveau compilateur | |
Les bibliothèques XL XP-J et XL TXE-J XML sont de nouvelles options de la version 6 du SDK. Ces informations de référence décrivent les fonctions prises en charge par ces bibliothèques.
XL XP-J 1.1 est un analyseur syntaxique non-validant haute performance prenant en charge StAX 1.0 (JSR 173) ; une API bidirectionnelle utilisée pour l'analyse d'extraction et la sérialisation du flux des documents XML 1.0 et XML 1.1.
Les options StAX facultatives ci-après ne sont pas prises en charge par XL XP-J : |
|Les propriétés suivantes sont prises en charge par l'implémentation javax.xml.stream.XMLInputFactory, comme décrit dans la documentation Java |XMLInputFactory .
| |Nom de la propriété | |Pris en charge | |
---|---|
javax.xml.stream.isValidating | |Non. Le scanner XL XP-J ne prend pas en charge la validation. | |
javax.xml.stream.isNamespaceAware | |Oui (prend en charge les valeurs true et false). Pour les propriétés XMLStreamReader créées à partir de DOMSource, le traitement des espaces de nom dépend des méthodes utilisées pour créer l'arborescence DOM. De plus, cette valeur n'a aucune incidence. | |
javax.xml.stream.isCoalescing | |Oui | |
javax.xml.stream.is |ReplacingEntityReferences | |Oui. Pour les propriétés XMLStreamReader créées à partir de DOMSource, la définition de ce paramètre n'a aucune incidence si des entités ont déjà été remplacées dans l'arborescence DOM. | |
javax.xml.stream.is |SupportingExternalEntities | |Oui | |
javax.xml.stream.supportDTD | |Non. Les paramètres DTD sont toujours pris en charge. L'attribution de la valeur false n'a aucune incidence. | |
javax.xml.stream.reporter | |Oui | |
javax.xml.stream.resolver | |Oui | |
XL XP-J prend également en charge la méthode facultative createXMLStreamReader(javax.xml.transform.Source), |permettant ainsi la création de programmes de lecture StAX à partir de sources DOM et SAX.
|Les propriétés suivantes sont prises en charge par l'implémentation javax.xml.stream.XMLStreamReader, |comme décrit dans la documentation Java XMLStreamReader.
| |Nom de la propriété | |Pris en charge | |
---|---|
javax.xml.stream.entities | |Oui | |
javax.xml.stream.notations | |Oui | |
XL XP-J prend également en charge la propriété javax.xml.stream.isInterning, qui renvoie une valeur booléenne indiquant si les noms XML et les URI espace de nom renvoyés par les appels d'API ont été pris en considération par l'analyseur syntaxique.
|Les propriétés suivantes sont prises en charge par l'implémentation javax.xml.stream.XMLOutputFactory, |comme décrit dans la documentation Java XMLOutputFactory.
| |Nom de la propriété | |Pris en charge | |
---|---|
javax.xml.stream.isRepairingNamespaces | |Oui | |
Les propriétés suivantes sont prises en charge par l'implémentation javax.xml.stream.XMLStreamWriter, |comme décrit dans la documentation Java XMLStreamWriter.
| |Nom de la propriété | |Pris en charge | |
---|---|
javax.xml.stream.isRepairingNamespaces | |Oui | |
Les propriétés des objets XMLStreamWriter sont en lecture seule.
| | |XL TXE-J est une bibliothèque XSLT contenant l'interpréteur XSLT4J 2.7.8 et un compilateur XSLT.
Fonction | |Interpréteur XSLT4J (inclus) | |Compilateur XSLT4J (non inclus) | |Compilateur XL TXE-J (inclus) | |
---|---|---|---|
Fonction http://javax.xml.transform.stream. |StreamSource/feature | |Oui | |Oui | |Oui | |
Fonction http://javax.xml.transform.stream. |StreamResult/feature | |Oui | |Oui | |Oui | |
Fonction http://javax.xml.transform.dom.DOMSource/feature | |Oui | |Oui | |Oui | |
Fonction http://javax.xml.transform.dom.DOMResult/feature | |Oui | |Oui | |Oui | |
Fonction http://javax.xml.transform.sax.SAXSource/feature | |Oui | |Oui | |Oui | |
Fonction http://javax.xml.transform.sax.SAXResult/feature | |Oui | |Oui | |Oui | |
Fonction http://javax.xml.transform.stax.StAXSource/feature | |Oui | |Non | |Oui | |
Fonction http://javax.xml.transform.stax.StAXResult/feature | |Oui | |Non | |Oui | |
Fonction http://javax.xml.transform.sax. |SAXTransformerFactory/feature | |Oui | |Oui | |Oui | |
Fonction http://javax.xml.transform.sax. |SAXTransformerFactory/feature/xmlfilter | |Oui | |Oui | |Oui | |
Fonction http://javax.xml.XMLConstants/feature/secure-processing | |Oui | |Oui | |Oui | |
Attribut http://xml.apache.org/xalan/features/incremental | |Oui | |Non | |Non | |
Attribut http://xml.apache.org/xalan/features/optimize | |Oui | |Non | |Non | |
Attribut http://xml.apache.org/xalan/properties/source-location | |Oui | |Non | |Non | |
Attribut translet-name | |N/A | |Oui | |Oui (avec un nom nouveau) | |
Attribut destination-directory | |N/A | |Oui | |Oui (avec un nom nouveau) | |
Attribut package-name | |N/A | |Oui | |Oui (avec un nom nouveau) | |
Attribut jar-name | |N/A | |Oui | |Oui (avec un nom nouveau) | |
Attribut generate-translet | |N/A | |Oui | |Oui (avec un nom nouveau) | |
Attribut auto-translet | |N/A | |Oui | |Oui (avec un nom nouveau) | |
Attribut use-classpath | |N/A | |Oui | |Oui (avec un nom nouveau) | |
Attribut enable-inlining | |Non | |Oui | |Non (obsolète pour TL TXE-J) | |
Attribut indent-number | |Non | |Oui | |Oui (avec un nom nouveau) | |
Attribut debug | |Non | |Oui | |Oui (avec un nom nouveau) | |
Extensions Java | |Oui | |Oui (syntaxe abrégée uniquement, les constructions xalan:component/xalan:script |ne sont pas prises en charge) | ||
Extensions JavaScript | |Oui | |Non | |Non | |
Eléments d'extension | |Oui | |Non | |Non | |
Fonctions d'extension EXSLT | |Oui | |Oui (excluant les extensions dynamiques) | |Oui (excluant les extensions dynamiques) | |
Extension Redirect | |Oui | |Oui (redirect:open et redirect:close sont exclus) | |Oui | |
Extension output | |Non | |Oui | |Oui | |
Extension nodeset | |Oui | |Oui | |Oui | |
Fonctions d'extension NodeInfo | |Oui | |Non | |Non | |
Extension de bibliothèque SQL | |Oui | |Non | |Non | |
Extension pipeDocument | |Oui | |Non | |Non | |
Extension evaluate | |Oui | |Non | |Non | |
Extension tokenize | |Oui | |Non | |Non | |
XML 1.1 | |Oui | |Oui | |Oui | |
Avec la commande Process, utilisez -FLAVOR |sr2sw pour une transformation à l'aide du traitement du flux StAX et-FLAVOR |er2ew pour un traitement d'événement StAX.
|Le nouveau compilateur ne recherche pas |le fournisseur de services org.apache.xalan.xsltc.dom.XSLTCDTMManager. A la place, si StreamSource est utilisé, le compilateur bascule vers un analyseur syntaxique XML de haute performance.
|La mise en ligne est obsolète dans XL |TXE-J. |
|La classe org.apache.xalan.xsltc.trax.SmartTransformerFactoryImpl n'est plus prise en charge.
| |Si vous utilisez une ancienne version de Xerces (antérieure à 2.0) ou de Xalan (antérieure à 2.3) dans la substitution approuvée, il se peut qu'une variante NullPointerException soit émise lorsque vous lancez votre application. Cette exception se produit car les anciennes versions ne gèrent pas le fichier jaxp.properties correctement.
|
Pour éviter cette situation, utilisez l'une des solutions suivantes : |
|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
Pour déboguer les programmes Java, vous pouvez utiliser l'application Java Debugger (JDB) ou d'autres débogueurs communiquant à l'aide de l'architecture JPDA (Java Platform Debugger Architecture) fournie par le SDK pour Linux.
Pour plus d'informations sur la procédure de diagnostic à l'aide de Java, reportez-vous au document Diagnostics Guide.
Le débogueur Java (JDB) est inclus dans le SDK de Linux. Il est appelé par la commande jdb et se connecte à la machine virtuelle à l'aide de JPDA.
Pour déboguer une applicationJava, procédez comme suit :
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=<port> <classe>La machine virtuelle démarre mais interrompt l'exécution avant de démarrer l'application Java.
jdb -attach <port>Le débogueur se connecte à la machine virtuelle, ce qui vous permet à présent d'émettre une série de commandes pour examiner et contrôler l'application Java. Par exemple, entrez run pour permettre l'exécution de l'application Java.
Pour plus d'informations sur les options JDB, entrez :
jdb -help
Pour plus d'informations sur les commandes JDB, entrez :
Vous pouvez également utiliser JDB pour déboguer les applications Java en cours d'exécution sur les machines distantes. JPDA utilise une socket TCP/IP pour la connexion à la machine virtuelle distante.
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=<port> <classe>La machine virtuelle démarre mais interrompt l'exécution avant de démarrer l'application Java.
jdb -attach <hôte>:<port>
Cette version ne prend pas en charge l'interface JVMDI (Java Virtual Machine Debugging Interface). Elle a été remplacée par l'interface JVMTI (Java Virtual Machine Tool Interface).
Pour plus d'informations sur l'utilisation de JDB et JPDA, consultez les sites Web suivants :
Certaines applications Java doivent pouvoir déterminer si elles s'exécutent sur une machine virtuelle Java 32 ou 64 bits. Par exemple, si votre application possède une bibliothèque de code native, celle-ci doit être compilée séparément en 32 et 64 bits pour des plateformes prenant en charge ces deux modes d'opération 32 et 64 bits. Dans ce cas, votre application doit charger la bibliothèque correcte lors de l'exécution car il est impossible de mélanger du code 32 et 64 bits.
La propriété système com.ibm.vm.bitmode permet aux applications d'identifier le mode dans lequel votre machine virtuelle Java fonctionne. Elle renvoie les valeurs suivantes :
Vous pouvez observer la propriété com.ibm.vm.bitmode depuis le code de votre application à l'aide de l'appel :
System.getProperty("com.ibm.vm.bitmode");
En cas de signal pertinent pour la JVM, un gestionnaire de signaux est appelé. Il détermine s'il a été appelé pour une unité d'exécution Java ou non Java.
Si le signal concerne une unité d'exécution Java, la JVM prend contrôle du traitement du signal. Si un gestionnaire d'applications pour ce signal est installé et que vous n'avez pas spécifié l'option de ligne de commande-Xnosigchain, le gestionnaire d'applications pour ce signal est appelé une fois le traitement de la machine virtuelle terminé.
Si le signal concerne une unité d'exécution non Java et que l'application qui a installé la JVM a déjà installé un gestionnaire spécifique pour ce signal, le contrôle est passé à ce gestionnaire. Sinon, si le signal est demandé par la JVM ou l'application Java, il est ignoré ou l'action par défaut est effectuée.
En cas de signaux d'exception ou d'erreur, la JVM effectue l'une des opérations suivantes :
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 :
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.
Les types de signaux sont Exceptions, Erreurs, Interruptions et Contrôles.
Le tableau 7 ci-dessous indique les signaux utilisés par la JVM. Ces signaux sont regroupés par type ou par utilisation, de la façon suivante :
Nom du signal | Type de signal | Description | Désactivé par -Xrs |
---|---|---|---|
SIGBUS (7) | Exception | Accès incorrect à la mémoire (données non alignées) | Oui |
SIGSEGV (11) | Exception | Accès incorrect à la mémoire (écriture dans une mémoire inaccessible) | Oui |
SIGILL (4) | Exception | Instruction non conforme (tentative d'appel d'une instruction machine inconnue) | Non |
SIGFPE (8) | Exception | Exception en virgule flottante (division par zéro) | Oui |
SIGABRT (6) | Erreur | Arrêt anormal. La JVM déclenche ce signal si elle détecte un incident JVM. | Oui |
SIGINT (2) | Interruption | Attention interactive (Ctrl-C). JVM s'arrête normalement. | Oui |
SIGTERM (15) | Interruption | Demande d'arrêt. JVM s'arrête normalement. | Oui |
SIGHUP (1) | Interruption | Arrêt de l'exécution. JVM s'arrête normalement. | Oui |
SIGQUIT (3) | Contrôle | Signal d'arrêt pour un terminal. Un vidage Javadump est déclenché par défaut. | Oui |
SIGTRAP (5) | Contrôle | Utilisé par le JIT. | Oui |
__SIGRTMAX - 2 | Contrôle | Utilisé par le SDK. | Non |
SIGCHLD (17) | 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, voir la page de lancement du programme d'applications Java de Sun.
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.
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.
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 :
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.
Pour utiliser libjsig.so :
gcc -L$JAVA_HOME/bin -ljsig -L$JAVA_HOME/bin/j9vm -ljvm java_application.cou
export LD_PRELOAD=$JAVA_HOME/bin/libjsig.so; java_application (bash et ksh) setenv LD_PRELOAD=$JAVA_HOME/bin/libjsig.so; java_application (csh)
La variable d'environnement JAVA_HOME doit être définie à l'emplacement du SDK, par exemple, /opt/ibm/java-i386-60/.
Pour utiliser une bibliothèque libjsig.a :
cc_r -q64 <other compile/link parameter> -L/opt/ibm/java-i386-60/jre/bin -ljsig -L/opt/ibm/java-i386-60/jre/bin/j9vm -ljvm java_application.c
Les numéros de versions JNI que des programmes natifs peuvent indiquer dans l'appel de l'API JNI_CreateJavaVM() sont : JNI_VERSION_1_2(0x00010002) et JNI_VERSION_1_4(0x00010004).
Le numéro de version détermine uniquement le niveau de l'interface native JNI à utiliser. Le niveau de la machine virtuelle créée est précisé par les bibliothèques JSE (à savoir, v6). L'API de l'interface JNI n'affecte pas la spécification de langue implémentée avec la machine virtuelle, les API de bibliothèque de classe ou tout autre aspect du comportement de la machine virtuelle. Pour plus d'informations, voir http://java.sun.com/javase/6/docs/technotes/guides/jni/.
Si votre application a besoin de deux bibliothèques JNI, l'une pour 32 bits et l'autre pour 64 bits, employez la propriété système com.ibm.vm.bitmode afin de déterminer si vous travaillez avec une machine virtuelle 32 ou 64 bits et choisissez la bibliothèque en conséquence.
Pour compiler et relier une application native à SDK, utilisez la commande suivante :
gcc -I/opt/ibm/java-i386-60/include -L/opt/ibm/java-i386-60/jre/lib/<arch>/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.
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és 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 :
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 classe d'extension de java.lang.Thread pour utiliser ces nouvelles classes.
La documentation Java de ces classes est fournie avec le SDK dans le répertoire docs/content/apidoc.
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 bit suid du programme de lancement Java.
Java Platform, Standard Edition (JSE), prend au minimum en charge les spécifications définies dans la documentation relative à la conformité de Sun. Dans certains cas, la fonction ORB JSE IBM prend en charge les versions les plus récentes des spécifications.
Les spécifications prises au minimum en charge sont définies dans les spécifications officielles de prise en charge de CORBA dans Java SE 6.
Ce SDK prend en charge toutes les versions de GIOP, telles qu'elles sont définies dans les chapitres 13 et 15 de la spécification CORBA 2.3.1, document OMG formal/99-10-07.
http://www.omg.org/cgi-bin/doc?formal/99-10-07
Le protocole GIOP bidirectionnel n'est pas pris en charge.
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.
Ce SDK prend en charge INS (Interoperable Naming Service), tel que défini par le groupe OMG dans le document ptc/00-08-07, accessible sur le site Web suivant :
http://www.omg.org/cgi-bin/doc?ptc/00-08-07
Le port par défaut utilisé par le serveur de noms transitoire (commande tnameserv), lorsqu'aucun paramètre ORBInitialPort n'est fourni, est passé de 900 à 2809, c'est-à-dire au numéro de port enregistré auprès de l'IANA (Internet Assigned Number Authority) pour un service annuaire CORBA. Les programmes qui dépendent de cette valeur par défaut peuvent nécessiter une mise à jour pour fonctionner avec cette version.
Le contexte initial renvoyé par le serveur de noms transitoire est à présent un org.omg.CosNaming.NamingContextExt. Les programmes existants qui réduisent la référence à un contexte org.omg.CosNaming.NamingContext fonctionnent toujours et n'ont pas besoin d'être recompilés.
La fonction ORB prend en charge les paramètres -ORBInitRef et -ORBDefaultInitRef définis par la spécification INS (Interoperable Naming Service) et l'opération ORB::string_to_object prend désormais en charge les formats de chaîne ObjectURL (corbaloc: et corbaname:) définis par la spécification INS.
La fonction OMG définit une méthode ORB::register_initial_reference pour enregistrer un service auprès de l'INS. Toutefois, cette méthode n'est pas disponible dans l'API Sun Java centrale Version 6. Les programmes ayant besoin d'enregistrer un service dans la version actuelle doivent appeler cette méthode sur la classe d'implémentation ORB interne IBM. Par exemple, pour enregistrer un service «MonService» :
((com.ibm.CORBA.iiop.ORB)orb).register_initial_reference("MonService", serviceRef);
Où orb correspond à une instance d'org.omg.CORBA.ORB, renvoyée par ORB.init(), et serviceRef correspond à un objet CORBA, connecté à la fonction ORB. Ce mécanisme est temporaire et n'est pas compatible avec les versions ultérieures, ni portable sur les ORB non IBM.
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.
Par exemple, pour tracer les événements et les messages GIOP mis en forme à partir de la ligne de commande, entrez :
java -Dcom.ibm.CORBA.Debug=true -Dcom.ibm.CORBA.CommTrace=true <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 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.
La fonction ORB peut être ajustée afin d'être compatible avec votre réseau. Les propriétés requises pour ajuster l'ORB sont décrites dans cette section.
Pour désactiver la fragmentation, définissez une taille de fragmentation de 0 octets :
java -Dcom.ibm.CORBA.FragmentSize=0 <monApp>
Lors de l'exécution avec un gestionnaire de sécurité Java, l'appel de certaines méthodes des classes API CORBA peut donner lieu à des vérifications de droits et, par conséquent, générer une exception de sécurité. Si votre programme utilise l'une de ces méthodes, assurez-vous qu'il bénéficie des droits nécessaires.
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 |
Liste des classes d'implémentation ORB.
Les classes d'implémentation ORB de cette version sont les suivantes :
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.
L'invocation RMI Java fournit un mécanisme simple de programmation Java distribuée. RMI sur IIOP (RMI-IIOP) utilise le protocole IIOP (Internet Inter-ORB Protocol) standard CORBA (Common Object Request Broker Architecture) pour étendre le RMI Java de base pour la communication. Une interaction directe est ainsi permise avec tout autre ORB CORBA, qu'il soit mis en oeuvre en Java ou dans un autre langage de programmation.
La documentation suivante est disponible :
Le regroupement d'unités d'exécution pour les gestionnaires de connexions RMI n'est pas activé par défaut.
Pour activer le regroupement de connexions implémenté au niveau du transport TCP du RMI, set définissez l'option
-Dsun.rmi.transport.tcp.connectionPool=true
Cette version de Runtime Environment ne contient pas de paramètre permettant de restreindre le nombre d'unités d'exécution du pool de connexions.
Depuis Java 5.0, la classe Big Decimal IBM est adoptée par Sun en tant que java.math.BigDecimal. La classe com.ibm.math.BigDecimal est réservée pour une utilisation ultérieure probable par IBM et est actuellement obsolète. Migrez le code Java existant pour utiliser java.math.BigDecimal.
La nouvelle classe java.math.BigDecimal utilise les mêmes méthodes que les classes java.math.BigDecimal et com.ibm.math.BigDecimal précédentes. Le code existant qui utilise java.math.BigDecimal continue à fonctionner correctement. Les deux classes ne peuvent pas être sérialisées.
Pour faire migrer le code Java existant afin d'utiliser la classe java.math.BigDecimal, modifiez l'instruction d'importation au début du fichier .java en remplaçant import com.ibm.math.*; par import java.math.*;.
Le plug-in Java peut-être utilisé pour exécuter les applications Java dans le navigateur. Applet Viewer est utilisé pour tester les applications devant être exécutées dans un navigateur. Java Web Start est utilisé pour déployer les applications Java sur un réseau et fournit un mécanisme permettant de les conserver à jour.
Le plug-in Java est un plug-in de navigateur Web. Le plug-inJava peut être utilisé pour exécuter des applets dans le navigateur.
Vous devez laisser les applets se charger complètement pour éviter le blocage du navigateur. Par exemple, si vous cliquez sur le bouton Précédente puis Suivante alors qu'une applet est en cours de chargement, les pages HTML peuvent ne pas s'afficher.
Vous trouverez plus d'informations sur le plug-in Java sur le site de Sun à l'adresse http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/.
Le plug-in Java prend en charge SeaMonkey, Mozilla, ainsi que Mozilla Firefox.
Navigateur | Versions prises en charge |
---|---|
Mozilla | 1.7.12, 1.8 |
Firefox | 1.5, 2.0 |
Navigateur | Versions prises en charge |
---|---|
Mozilla | 1.6 |
|SeaMonkey | |1.0.8 |
Les navigateurs de versions secondaires ultérieures sont également pris en charge.
Pour installer le plug-in Java, créez un lien symbolique vers le répertoire de plug-in de votre navigateur.
Le plug-in Java se fonde sur l'initiative Open JVM Integration de Mozilla, utilisée avec la plupart des produits Mozilla, y compris Firefox.
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.
Seules les versions 1.4 et versions ultérieures de Mozilla sont prises en charge.
cd /usr/local/mozilla/plugins/
cd $HOME/.mozilla/plugins
ln -s /opt/ibm/java-i386-60/jre/plugin/<arch>/ns7/libjavaplugin_oji.so .où <arch> correspond à l'architecture de votre système.
Pour vérifier que le plug-in Java est disponible et activé, sélectionnez Aide -> A propos des plug-ins sous Mozilla.
Vous devez créer un lien symbolique vers le plug-in et non le copier. De cette manière, vous pouvez localiser la JVM.
Procédez comme suit pour mettre le plug-in Java à la disposition de tous les utilisateurs :
cd /usr/local/mozilla-firefox/plugins/
ln -s /opt/ibm/java-i386-60/jre/plugin/<arch>/ns7/libjavaplugin_oji.so .où <arch> correspond à l'architecture de votre système.
Vous devez créer un lien symbolique vers le plug-in et non le copier. De cette manière, vous pouvez localiser la JVM.
En raison des limitations de certains navigateurs, vous ne pourrez peut-être pas implémenter toutes les fonctions du module org.w3c.dom.html.
Une des erreurs suivantes se produit :
Le plug-in Java prend en charge les caractères double octet (par exemple, le chinois traditionnel BIG-5, le coréen et le japonais) en tant que paramètres pour les balises <APPLET>, <OBJECT>, et <EMBED>. Vous devez sélectionner le codage des caractères correct pour le document HTML de sorte que le plug-in Java puisse analyser le paramètre.
Indiquez le codage des caractères pour le document HTML à l'aide de la balise <META> dans la section <HEAD>, comme suit :
<meta http-equiv="Content-Type" content="text/html; charset=big5">
Cet exemple demande au navigateur d'analyser le fichier HTML à l'aide du codage de caractères Chinese BIG-5.
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.
Utilisez la commande suivante pour exécuter un applet à l'aide d'Applet Viewer.
A partir d'une invite shell, entrez :
appletviewer <nom>
où <nom> correspond à l'un des éléments suivants :
Par exemple, pour appeler Applet Viewer sur un fichier HTML qui appelle un applet, entrez à l'invite shell :
appletviewer $HOME/<nomfichier>.html
où nomfichier correspond au nom du fichier HTML.
Pour appeler Applet Viewer sur une page Web, entrez à 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 Applet Viewer n'est pas codé en tant que valeur par défaut du système, une exception E-S peut se produire. Pour éviter cette exception, utilisez l'option -encoding lorsque vous exécutez appletviewer. Par exemple :
appletviewer -encoding JISAutoDetect sample.html
L'option -debug d'Applet Viewer permet de déboguer les applets.
Par exemple :
cd demo/applets/TicTacToe ../../../bin/appletviewer -debug exemple1.html
Vous trouverez de la documentation sur le débogage d'applets à l'aide d'Applet Viewer sur le site Web de Sun à l'adresse http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/debugger.html.
Java Web Start est utilisé pour le déploiement d'applications Java.
Web Start vous permet de lancer et de gérer des applications directement à partir du Web. Les applications sont mises en cache pour réduire les temps d'installation. Elles sont automatiquement mises à niveau lorsque de nouvelles versions sont disponibles.
Web Start prend en charge ces java-vm-args décrits sur le site Web http://java.sun.com/javase/6/docs/technotes/guides/javaws/developersguide/syntax.html#resources :
IBM Web Start prend également en charge -Xgcpolicy pour définir la règle de récupération de place.
Pour plus d'informations sur les navigateurs prenant en charge Web Start, voir Navigateurs pris en charge.
Pour plus d'informations sur Web Start, voir :
Pour plus d'informations sur le déploiement des applications, voir
Web Start peut être exécuté depuis une page Web ou une ligne de commande. Les applications Web Start sont stockées dans le cache de l'application Java.
Java Web Start Version 6 est installé automatiquement lorsque vous installez 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 appeler Web Start de plusieurs façons.
javaws <URL>où <URL> correspond à l'emplacement d'un fichier .jnlp.
/opt/ibm/java-i386-60/jre/bin/javaws| -viewer
Toutes les applications Java Web Start sont stockées dans le cache de l'application Java. Une application est uniquement téléchargée si la version la plus récente de cette application n'est pas stockée dans le cache.
La gestion des versions statiques autorise les applications Web Start à demander une version JVM particulière sous laquelle s'exécuter. Puisque cette fonctionnalité permet également aux applications d'exploiter les anciennes défaillances relatives à la sécurité sur des systèmes qui ont été mis à niveau vers une nouvelle machine virtuelle, la gestion sécurisée des versions statiques (Secure Static Versioning, SSV) est désormais utilisée par défaut.
Avec SSV, l'utilisateur recevra un avertissement avant l'exécution de toute application Web Start non signée qui requiert l'utilisation d'une machine virtuelle spécifique. Les applications signées et celles qui requièrent la version la plus récente de la machine virtuelle s'exécutent normalement.
Vous pouvez désactiver SSV en attribuant la valeur false à la propriété deployment.javaws.ssv.enabled du fichier deployment.properties.
Les applications Java sont généralement composées de fichiers de classes, de ressources et de données.
Lorsque vous livrez une application Java, le package se compose probablement de ce qui suit :
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.
Le partage de données de classes permet à plusieurs machines JVM de partager le même espace en mémoire.
La machine virtuelle Java (JVM) vous permet de partager des données de classes entre JVM en les stockant dans unfichier cache mappé en mémoire sur disque. Le partage de classes réduit la consommation globale de mémoire virtuelle lorsque plusieurs machines virtuelles partagent un cache. Il diminue également le temps de démarrage d'une machine virtuelle après création du cache. Le cache de classes partagées est indépendant de toute machine virtuelle active et demeure jusqu'à ce qu'il soit détruit .
Un cache partagé peut contenir les éléments suivants :
Le partage de données de classes est une méthode transparente permettant de réduire l'encombrement de la mémoire et d'améliorer le temps de démarrage de la machine virtuelle. |Java 6 |propose de nouvelles fonctions permettant d'améliorer la gestion, l'isolement et la performance du cache.
Activez le partage de données de classes à l'aide de l'option -Xshareclasses au démarrage de la machine virtuelle. La machine virtuelle JVM se connecte à un cache existant ou crée un cache s'il n'en existe pas déjà un.
Toutes les classes d'amorce et d'application chargées par la machine virtuelle sont par défaut partagées. Les chargeurs de classes personnalisés effectuent automatiquement un partage de classes s'ils étendent le chargeur de classes de l'application ; sinon, ils doivent utiliser l'API Java Helper fournie avec la machine virtuelle pour accéder au cache. (Voir Adaptation de chargeurs de classes personnalisés pour partager des classes.)
|La machine virtuelle peut également stocker le code AOT compilé dans le cache pour certaines méthodes afin d'améliorer le temps de démarrage des machines virtuelles suivantes. Le code AOT compilé n'est pas partagé entre plusieurs machines virtuelles, mais est mis en cache pour réduire le temps de compilation lors du démarrage de la machine virtuelle. Le nombre de codes AOT stockés dans le cache est déterminé de manière heuristique. Les méthodes pouvant être stockées dans le cache ne peuvent pas être contrôlées, mais vous pouvez définir des limites supérieures et inférieures pouvant être appliquées à la quantité d'espace de cache requise pour le code AOT. Vous pouvez également désactiver la mise en cache du code AOT complètement. |Voir Activation et configuration du partage de données de classes pour plus d'informations.
|Une machine virtuelle peut accéder à un cache en mode lecture-écriture ou en mode lecture seule. Toutes les machines virtuelles connectées à un cache dotés de droits d'accès en lecture-écriturepeuvent mettre le cache à jour. Plusieurs machines virtuelles peuvent lire en même temps à partir du cache, et ce, même lors de l'écriture dans le cache par une autre machine virtuelle.
Soyez vigilant si une modification de code intermédiaire d'exécution est appliquée. Voir Modification du code intermédiaire d'exécution pour plus d'informations.
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.
L'accès au cache des classes est limité par les autorisations 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 données de classes peut mettre à jour le cache de classes partagées.
|La mémoire cache est protégée contre les corruptions accidentelles ou délibérées à l'aide de la protection de la page de mémoire. Cependant, il ne s'agit pas d'une protection optimale car la machine virtuelle doit désactiver la protection des pages afin d'écrire dans ces pages. Le seul moyen de garantir qu'un cache ne puisse pas être modifié est de l'ouvrir en lecture seule.
Si un gestionnaire de sécuritéJava SecurityManager est installé, les chargeurs de classe, à l'exception des chargeurs de classe d'extension, d'application et d'amorce, doivent disposer des droits permettant de partager des classes par l'ajout de SharedClassPermission au fichier java.policy. (Voir Utilisation de SharedClassPermission.) L'autorisation RuntimePermission «createClassLoader» restreint la création de chargeurs de classe et restreint donc l'accès au cache.
Plusieurs caches peuvent se trouver sur un même système ; ils sont alors désignés par leur nom, comme sous-option de la commande -Xshareclasses. Une machine virtuelle ne peut se connecter qu'à un seul cache à la fois.
Vous pouvez remplacer la taille du cache par défaut au démarrage à l'aide de -Xscmx<n><size>, mais cette taille ne peut ensuite être modifiée pendant la durée de vie du cache. Les caches existent jusqu'à leur destruction explicite avec une sous-option de la commande -Xshareclasses oule fichier cache est supprimé manuellement.
Tous les utilitaires du cache sont des sous-options de la commande -Xshareclasses. Voir Activation et configuration du partage de données de classes, ou utiliser -Xshareclasses:help pour consulter une liste des sous-options disponibles.
Les utilitaires de partage de données de classes et de gestion de cache sont contrôlés à l'aide des options de ligne de commande du programme de lancement java.
Pour les options employant le paramètre <taille>, ajoutez "k" ou "K" au nombre pour indiquer qu'il s'agit de kilo-octets, "m" ou "M" de mégaoctets ou bien "g" ou "G" de gigaoctets.
Certains utilitaires de cache peuvent être utilisés avec des caches des versions Java précédentes ou des caches créés par des machines virtuelles dotées de largeurs de bits différentes. Ces caches sont appelés des caches «incompatibles».
Vous pouvez utiliser les sous-options suivantes avec l'option -Xshareclasses :
Affiche les informations détaillées relatives au cache spécifié par les sous-options name, cacheDir et nonpersistent. Chaque classe apparaît dans l'ordre chronologique, avec une référence à l'emplacement depuis lequel elle a été chargée. Le code AOT des méthodes de classe est également répertorié.
Voir leVoir le document Diagnostics Guide pour plus d'informations.
Cette section présente le cycle de vie d'un cache contenant des données de classe partagée et contient également des exemples d'utilitaires de gestion de cache.
Pour activer le partage de données de classes, ajoutez -Xshareclasses[:name=<name>] à la ligne de commande de votre application.
La machine virtuelle se connecte alors à un cache existant du nom indiqué ou en crée un de ce nom. Si un nouveau cache est créé, il est rempli avec toutes les classes d'amorce et d'application chargées jusqu'à ce qu'il soit saturé. Si deux machines virtuelles ou plus sont démarrées en même temps, elles remplissent en parallèle le cache.
Pour vérifier que le cache a bien été créé, exécutez java -Xshareclasses:listAllCaches. Pour savoir combien de classes et quelle quantité de données sont partagées, exécutez java -Xshareclasses:[name=<name>],printStats. (Ces utilitaires peuvent être exécutés au terme de la machine virtuelle de l'application ou dans une autre fenêtre de commande.)
Pour plus de retour d'informations sur l'utilisation du cache lors de l'exécution de la machine virtuelle, utilisez la sous-option verbose. Par exemple, java -Xshareclasses:[name=<name>],verbose.
Pour voir les classes chargées depuis le cache ou stockées dedans, ajoutez -Xshareclasses:[name=<name>],verboseIO à la ligne de commande de votre application.
Pour supprimer le cache créé, exécutez java -Xshareclasses:[name=<name>],destroy. Vous devez uniquement supprimer des caches s'ils contiennent de nombreuses classes périmées ou s'ils sont pleins et que vous souhaitez en créer un plus important.
Il est recommandé de régler la taille du cache pour votre application spécifique car il est peu probable que la valeur par défaut corresponde à la taille optimale. La meilleure méthode de déterminer la taille de cache optimale consiste à indiquer un cache de grande taille (à l'aide de l'option -Xscmx), d'exécuter l'application puis d'utiliser printStats afin de déterminer le montant de données de classe ayant été stockées. Ajoutez une petite quantité à la valeur affichée dans printStats pour la contingence. Etant donné que des classes peuvent être chargées à tout moment lors du cycle de vie de la machine virtuelle, il est préférable d'effectuer cette analyse une fois l'application terminée. Toutefois, un cache saturé n'a aucune répercussion négative sur les performances ou la capacité des machines virtuelles qui y sont connectées. Il peut donc être légitime de définir une taille de cache plus petite que nécessaire.
Si un cache arrive à saturation, un message est émis sur la ligne de commande de toutes les machines virtuelles utilisant la sous-option verbose. Toutes les machines virtuelles partageant ce cache chargeront alors les classes supplémentaires dans leur propre mémoire de processus. Les classes d'un cache saturé peuvent toujours être partagées mais ce dernier est en lecture seule et ne peut plus être mis à jour avec de nouvelles classes.
Le partage de données de classes s'avère particulièrement utile sur des systèmes recourant à plusieurs machines virtuelles JVM qui exécutent un même code. Le système profite ainsi de la consommation réduite de mémoire virtuelle. Il est également bienvenu sur des systèmes démarrant et arrêtant souvent des machines virtuelles, profitant du meilleur temps de démarrage.
Le temps système pour créer et remplir un nouveau cache est minimal. Le temps de démarrage des machines virtuelles est généralement de 0 à 5 % supérieur à celui d'un système n'utilisant pas le partage de données de classes, en fonction du nombre de classes chargées. La réduction de ce temps avec un cache rempli oscille entre 10 et 40 % en comparaison avec un système n'utilisant pas le partage de données de classes, selon le système d'exploitation et le nombre de classes chargées. Plusieurs machines virtuelles exécutées de manière simultanée tirent un plus grand parti du temps de démarrage général.
Les classes en double sont consolidées dans le cache de classes partagées. Par exemple, une classe A chargée à partir de myClasses.jar et une classe A chargée à partir de myOtherClasses.jar (au contenu identique) sont stockées une seule fois dans le cache. L'utilitaire printAllStats affiche plusieurs entrées pour les classes en double, chaque entrée pointant vers la même classe.
Lorsque vous exécutez votre application avec le partage de données de classes, vous pouvez employer les outils du système d'exploitation pour constater la baisse de consommation de mémoire virtuelle.
Facteurs à prendre en compte lorsque vous déployez le partage de données de classes dans un produit et utilisez cette option dans un environnement de développement.
La taille de cache théorique maximale est 2 Go. La taille de mémoire cache que vous pouvez spécifier est limitée par la quantité d'espace physique et d'espace de permutation disponible sur le système.
Le cache du partage des classes est alloué à l'aide du mécanisme de mémoire partagée System V IPC.
Etant donné que l'espace d'adresse virtuelle d'un processus est partagé entre le cache de classes partagées et le segment Java, l'augmentation de la taille maximale du segment Java peut entraîner la réduction de 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.
Toute machine virtuelle utilisant un agent JVMTI (JVM Tool Interface) capable de modifier des données de code intermédiaire doit utiliser la sous-option modified=<modified_context> afin de partager les classes modifiées avec une autre machine virtuelle.
Le contexte modifié est un descripteur spécifique à l'utilisateur désignant le type de modification effectuée. Le contexte modifié partitionne le cache de sorte à ce que toutes les machines virtuelles exécutées avec le même contexte partagent une partition.
Ce partitionnement permet aux machines virtuelles n'utilisant pas des codes intermédiaires modifiés de partager un cache de manière sécurisée avec celles utilisant des codes intermédiaires modifiés. Toutes les machines virtuelles utilisant un contexte modifié doivent modifier le code intermédiaire de façon prévisible et réitérable ; ainsi, les classes modifiées stockées dans le cache intègrent les modifications attendues lorsqu'elles sont chargées par une autre machine virtuelle. Toute modification doit être prévisible car les classes chargées depuis le cache de classes partagées ne peuvent être à nouveau modifiées par l'agent.
Si un agent JVMTI est utilisé sans contexte de modification, les classes sont toujours partagées de manière sécurisée par la machine virtuelle, mais il y a une petite incidence sur la performance. L'utilisation d'un contexte de modification avec un agent JVMTI rend inutile des vérifications supplémentaires et donc, n'a aucune incidence sur la performance. Un chargeur de classes personnalisé qui étend java.net.URLClassLoader et modifie des codes intermédiaires lors du chargement sans utiliser JVMTI stocke les codes intermédiaires modifiés automatiquement dans le cache, mais celui-ci ne les traite pas comme des codes modifiés. Toute autre machine virtuelle partageant ce cache charge les classes modifiées. La sous-option modified=<contexte_modification> peut être utilisée de la même manière qu'avec les agents JVMTI pour partitionner les codes intermédiaires modifiés dans le cache. Si un chargeur de classes personnalisé doit procéder à des modifications de classes imprévues lors du chargement, ce chargeur de classes ne doit pas utiliser le partage de données de classes.
Voir le document Diagnostics Guide pour en savoir plus à ce sujet.
Vous ne pouvez pas partager de classes entre des machines virtuelles 32 et 64 bits. Un espace disque temporaire doit être disponible pour conserver les informations du cache. Les droits d'accès au cache sont appliqués par le système d'exploitation.
Pour les systèmes d'exploitation pouvant exécuter à la fois des applications de 32 et 64 bits, le partage de données de classe n'est pas autorisé entre des machines virtuelles 32 et 64 bits. La sous-option listAllCaches répertorie les caches de 32 et 64 bits, en fonction du mode d'adressage de la machine virtuelle utilisée.
Le cache de classes partagées requiert de l'espace disque pour stocker des informations d'identification sur les caches figurant sur le système. Ces informations se trouvent dans /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 le cache à nouveau. Utilisez la commande ipcs pour afficher les segments de mémoire utilisé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 classe partagée sont appliqués par le système d'exploitation. Si aucun nom de cache n'est précisé, le nom d'utilisateur est ajouté au nom par défaut afin que plusieurs utilisateurs sur le même système créent leurs propres caches par défaut.
Si un gestionnaire SecurityManager est utilisé avec le partage de données de classes et que l'application en cours utilise ses propres chargeurs de classes, ces derniers doivent dispenser d'autorisations de classes partagés pour pouvoir partager des classes.
Vous ajoutez des autorisations de classes partagées au fichier java.policy en indiquant le nom de classe ClassLoader (les caractères génériques sont admis) et «read», «write» ou «read,write» pour déterminer l'accès accordé. Par exemple :
permission com.ibm.oti.shared.SharedClassPermission "com.abc.customclassloaders.*", "read,write";
Si ClassLoader ne dispose pas des autorisations correctes, il ne peut partager les classes. Vous ne pouvez pas modifier les autorisations des chargeurs de classes d'extension, d'application ou d'amorçage par défaut.
Les chargeurs de classes qui étendent java.net.URLClassLoader peuvent partager des classes sans être modifiés. Les chargeurs de classes n'étendant pas java.net.URLClassLoader doivent être adaptés afin de partager les données de classes.
Le droit SharedClassPermissions doit être accordé à tous les chargeurs de classes personnalisés si un gestionnaire de sécurité est utilisé, voir Utilisation de SharedClassPermission. IBM fournit plusieurs interfaces Java pour différents types de chargeurs de classes personnalisés, permettant ainsi à ces derniers de rechercher et stocker des classes dans leur cache de classes partagées. Ces classes se trouvent dans le package com.ibm.oti.shared.
La documentation Java de ce package est fournie avec le SDK dans le répertoire docs/content/apidoc.
Voir le document Diagnostics Guide pour en savoir plus sur le mode d'utilisation de ces interfaces.
Le package de l'API Java Communications (JavaComm) est fourni en option et doit être utilisé 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 API permet aux applications Java sur toute plateforme d'effectuer des communications de port série et parallèles pour les technologies telles que la messagerie vocale, la télécopie et les cartes à puce.
L'API Java Communications prend en charge les ports série Electronic Industries Association (EIA)-232 (RS232) et les ports parallèles Institute of Electrical and Electronics Engineers (IEEE) 1284. Elle fonctionne sur les systèmes utilisant IBM Version 6 Runtime Environment.
L'API Java Communications vous permet d'effectuer les opérations suivantes :
Assurez-vous 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 installerJava à l'origine, installez l'API Java Communications à partir du fichier RPM. Pour installer l'API Java Communications à partir d'un module RPM, voir Installation de l'API Java Communications à partir d'un fichier RPM.
Pour installer l'API Java Communications à partir d'un fichier compressé, procédez comme suit :
tar -xvzf ibm-java-javacomm-3.0-0.0-<plat>-<arch>.tar.gz
où <arch> représente votre architecture : i386, x86_64, ppc ou ppc64.
Assurez-vous 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 installerJava à l'origine, installez l'API Java Communications à partir du fichier RPM.
rpm -ivh ibm-javacomm-3.0-0.0.<arch>.rpmL'API Java Communications est installée dans l'arborescence des répertoires /opt/ibm/java-i386-60/.
Par défaut, les fichiers de l'API Java Communications sont installés dans le répertoire /opt/ibm/java-i386-60/. Les fichiers ainsi que leur structure sont les suivants :
Afin d'utiliser l'API Java Communications, vous devez modifier le mode d'accès des ports série et parallèle et définir le PATH si vous ne l'avait pas déjà fait lors de l'installation de Java.
Voir Définition du PATH.
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 660 /dev/ttyS0 (également appelé port série COM1) chmod 660 /dev/lp0 (également appelé port parallèle LPT1) chmod 660 /dev/ttyS1 (également appelé port série COM2) chmod 660 /dev/ttyS2 (également appelé port série COM3) chmod 660 /dev/ttyS3 (également appelé port série COM4)
Ajoutez 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.
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 en série. Les numéros de port sont attribués de manière séquentielle à tous les périphériques.
Par exemple, si vous définissez /dev/ttyS=PORT_SERIAL alors que les périphériques /dev/ttyS0 et /dev/ttyS1 existent, les ports COM1 et COM2 leur seront attribués.
Pour utiliser les connecteurs USB-série, supprimez la mise en commentaire de la ligne /dev/ttyUSB=PORT_SERIAL dans le fichier javax.comm.properties. Si les périphériques /dev/ttyUSB0 et /dev/ttyUSB1 existent alors que COM1 et COM2 ont déjà été définis, les ports suivants, COM3 et COM4, sont attribués aux périphériques USB-série.
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, vous devez utiliser la version DOS de l'utilitaire de configuration ThinkPad disponible sur le site de téléchargement 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 le système sous Linux, les ports ne seront pas activés.
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.
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 de l'API Java Communications à l'aide du package RPM.
rpm -e ibm-javacomm-3.0-0.0Vous pouvez également utiliser un outil graphique tel que kpackage ou yast2
Désinstallation de l'API Java Communications si vous avez installé le module TAR condensé.
Supprimez les fichiers suivants du répertoire dans lequel vous les avez installés :
Vous trouverez de la documentation et des exemples de l'API Java Communications sur le site Web de Sun.
http://java.sun.com/products/javacomm/.
Points de service :
Si vous avez droit à des services pour le code de programme appartenant à IBM Solutions Developer Program, contactez l'équipe de ce dernier en accédant au site Web à l'adresse :http://www.ibm.com/partnerworld/.
Si vous avez établi un contrat de service (tel qu'IBM Personal Systems Support Line ou équivalent selon le pays), les termes et conditions déterminent les services, le cas échéant, que vous avez le droit de recevoir par rapport au programme.
Les guides d'utilisation fournis avec ce SDK et Runtime Environment ont été testés à l'aide de lecteurs d'écran.
Pour modifier la taille des polices des guides d'utilisation, utilisez la fonction fournie par votre navigateur, habituellement située dans le menu Affichage.
Pour les utilisateurs nécessitant une navigation par clavier, une description des touches utiles pour les applications Swing est disponible dans la section Swing Key Bindings sur le site http://www.ibm.com/developerworks/java/jdk/additional/.
Si vous parcourez la liste déroulante d'un composant JComboBox avec les touches fléchées, le bouton ou la zone modifiable du composant JComboBox ne change pas de valeur tant qu'un élément n'est pas sélectionné. Il s'agit du comportement correct de cette version. Il améliore l'accessibilité et augmente la facilité d'utilisation en garantissant que le comportement de passage par clavier soit identique à celui du passage par souris.
A partir de la version 5.0, Java Web Start comporte plusieurs améliorations de l'accessibilité et de la facilité d'utilisation, qui incluent notamment une meilleure prise en charge des lecteurs d'écran et une navigation par clavier améliorée.
La ligne de commande peut uniquement être utilisée pour lancer une application Java activée pour Web Start. Pour modifier les options des préférences, vous devez éditer le fichier de configuration .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.
Si vous avez des commentaires sur ce guide d'utilisation, contactez-nous via l'une des voies suivantes. Vous pouvez nous envoyer vos questions "non techniques" ou tout commentaire relatif à notre documentation.
Veuillez nous envoyer vos commentaires :
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.
Les options -X ci-après ne sont pas standard et peuvent être modifiées sans préavis.
Pour les options employant le paramètre <taille>, ajoutez "k" ou "K" au nombre pour indiquer qu'il s'agit de kilo-octets, "m" ou "M" de mégaoctets ou bien "g" ou "G" de gigaoctets.
En ce qu'il s'agit des options employant le paramètre <percentage>, vous devez utiliser un nombre compris entre 0 et 1. Par exemple, 50 % correspond à 0,5.
Force l'écriture de la sortie de récupération de place en mode prolixe dans le fichier spécifié. Si ce fichier existe, la sortie remplace son contenu. Si ce fichier existe mais qu'il ne peut pas être ouvert ou s'il est impossible de créer un nouveau fichier, la sortie est redirigée sur l'erreur standard. Si vous définissez les arguments entiers X et Y, la sortie de la récupération de place en mode prolixe est redirigée vers un nombre X de fichiers, chaque fichier contenant un nombre Y de cycles gc pouvant générer une sortie verbose. Ces fichiers sont nommés nomfichier1, nomfichier2, etc. Par défaut, aucune consignation de la récupération de place en mode prolixe n'a lieu.
Voir le document Diagnostics Guide pour en savoir plus sur la sortie de la récupération de place en mode prolixe.
Restrictions d'utilisation de SDK et Runtime Environment pour Linux.
Pour plus d'informations sur la procédure de diagnostic, reportez-vous au document Diagnostics Guide à l'adresse http://www.ibm.com/developerworks/java/jdk/diagnosis/60.html.
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 des blocages Java. Cette instruction respecte la recommandation d'AMD.
Dans l'outil JConsole d'IBM, l'onglet Local qui permet de se connecter à d'autres machines virtuelles sur le même système n'est pas disponible. De plus, l'option pid de la ligne de commande correspondante n'est pas prise en charge. A la place, utilisez l'onglet Remote dans JConsole pour vous connecter à la machine virtuelle à contrôler. Vous pouvez également utiliser l'option de ligne de commande connection, en indiquant un numéro de port et un hôte localhost. Lorsque vous lancez l'application à contrôler, définissez les options de ligne de commande :
Le moteur Mozilla Rhino Javascript n'est pas inclus dans IBM SDK pour Java en raison des problèmes liés aux licences. Pour utiliser le moteur Rhino Javascript avec IBM SDK for Java, téléchargez le moteur de script jsr223 depuishttps://scripting.dev.java.net/ et le moteur Rhino Javascript depuis le site Web Mozilla : http://www.mozilla.org/rhino/.
La création de paires de clés DSA de longueurs inhabituelles peut prendre longtemps sur des machines lentes. L'attente ne doit pas être interprétée comme un blocage ; si vous patientez, vous verrez que le processus aboutit. L'algorithme de génération de clés DSA a été optimisé pour obtenir des longueurs standard (par exemple, 512, 1024) plus rapidement que d'autres.
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 :
La machine virtuelle créée est déterminée par les bibliothèques Java (soit 1.2.2, 1.3.x, 1.4.x, 5.x, 6.x) et non 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.
Le gestionnaire de fenêtres peut remplacer certains raccourcis-clavier Java. Si vous devez utiliser un raccourci-clavier Java 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-Window 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 SLES9 et les distributions les 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 :
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.
Il n'existe aucun moyen de différencier le temps UC en mode utilisateur et le temps UC en mode système de cette plateforme. ThreadMXBean.getThreadUserTime(), ThreadMXBean.getThreadCpuTime(), ThreadMXBean.getCurrentThreadUserTime() et ThreadMXBean.getCurrentThreadCpuTime() renvoient le temps UC total relatif à l'unité d'exécution requise.
Il se peut que les résultats KeyEvent 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. Lorsque les paramètres par défaut sont utilisés, la séquence de touches Ctrl+Alt+A dans le gestionnaire de fenêtres KWin génère un résultat KeyEvent. Cette même séquence de touches (Ctrl+Alt+A) utilisée dans le gestionnaire de fenêtres Metacity ne génère pas de résultat KeyEvent.
Sous 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"
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.
Un 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.
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 :
Essayez d'optimiser votre système pour augmenter les ressources système correspondantes.
Lorsque vous exécutez une application Java AWT ou Swing sur une machine Linux et que vous 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. 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 si les variables d'environnement spécifiques à l'environnement local, telles que LANG ou 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 de 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 cette erreur 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», attribuez la valeur «en_US» à la variable LANG.
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, effectuez une mise à niveau vers la version la plus récente d'AMI et de xcin.
Utilisateurs de la version en chinois, coréen et japonais de RHEL4 uniquement.
Aucun serveur XIM n'est installé par défaut. Pour saisir des caractères DBCS dans une application Java, installez un package de serveur XIM tel que iiimf-x ou kinput2.
Utilisateurs de la version en chinois, coréen et japonais de RHEL4 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. Contactez Red Hat à l'adresse http://www.redhat.com.
(zSeries 64 bits uniquement) Des erreurs IIIMF peuvent se produire ou le démarrage ne peut pas aboutir. Pour remédier à cet incident, effectuez une mise à niveau vers les composants IIIMF les plus récents.
(Version en chinois traditionnel sur PPC, s390 ou s390x uniquement) Il se peut que la méthode IIIMF ne fonctionne pas. Pour remédier à cet incident, utilisez iiimf-le-xcin-0.1.7-13.EL4 ou version ultérieure.
(Version en chinois simplifié sur PPC, s390 ou s390x uniquement) Il se peut que la méthode IIIMF ne fonctionne pas correctement. Pour remédier à cet incident, utilisez les composants IIMF inclus dans RHEL4 Update 5 ou version ultérieure.
Utilisateurs de la version en chinois simplifié de RHEL4 uniquement.
L'environnement local zh_CN.GB18030 n'est pas pris en charge par xlib dans RHEL4. xterm ne peut pas activer le serveur IMS (Input Method Server) 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.
Cette restriction n'existe plus dans RHEL4 U3.
Des blocages risquent de se produire avec xcin sur RHEL4. Pour résoudre le problème, attribuez la valeur YES à ICCHECK_DISABLE dans le fichier /etc/chinese/xcin/xcinrc.
Uniquement les environnements 64 bits
Sous RHEL4 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). Pour remédier à cet incident, effectuez une mise à niveau vers le composant xcin le plus récent.
RHEL4 uniquement.
Lors de l'utilisation de la méthode IIIMF (Internet Intranet Input Method Framework) pour entrer des caractères DBCS, il se peut que des incidents relatifs au changement de mise en évidence se produisent. Ces incidents se produisent lorsque des composants de saisie actifs sont réduits. Une fois les composants restaurés, la méthode de saisie bascule de nouveau sur SBCS. DBCS doit alors être réactivé manuellement.
Les composants suivants sont concernés par cet incident relatif au changement de mise en forme :
RHEL4 etSLES9 uniquement
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 :
Cette limitation n'existe plus dans RHEL4 U3 et SLES9 SP3.
Plateformes Intel 32 bits uniquement
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.
Plateformes Intel 32 bits uniquement
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.
Plateformes PPC uniquement
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).
Plateformes PPC uniquement
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.
Plateformes PPC 64 bits uniquement
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<SDK_PATH>/include FileStat.c
où <SDK_PATH> correspond au chemin d'installation de SDK.
Plateformes zSeries uniquement
Bien que le noyau Linux fourni dans les distributions Linux courantes prenne en charge le protocole Internet version 6 (IPv6), il se peut que vous ayez des difficultés à l'utiliser. Le support d'IPv6 à partir de Java est inclus dans cette version, mais il est recommandé 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'IPv6, vous n'avez pas besoin de cette option.
Plateformes zSeries 64 bits uniquement
Les serveurs IMS (input method server) chinois et taïwanais (xcin) n'ont pas été testés.
Il se peut que l'API Java Desktop ne fonctionne pas car une ou plusieurs bibliothèques GNOME ne sont pas disponibles.
Environnements DBCS uniquement
Si votre application échoue en raison d'une exception NullPointerException avec GTK Look and Feel, désactivez la variable d'environnement GNOME_DESKTOP_SESSION_ID.
Utilisateurs japonais uniquement
L'alias de page de codes Unicode «\u30b7\u30d5\u30c8\u7b26\u53f7\u5316\u8868\u73fe» pour Shift_JIS a été supprimé. Si vous utilisez cette page de codes dans vos applications, remplacez-la par Shift_JIS.
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 :
Les informations sur les licences concernant les produits utilisant un jeu de caractères double octet peuvent être obtenues par écrit à l'adresse suivante :
Le paragraphe suivant ne s'applique ni au Royaume-Uni, ni dans aucun autre pays dans lequel il serait contraire aux lois locales.
LE PRESENT DOCUMENT EST LIVRE EN L'ETAT. IBM DECLINE TOUTE RESPONSABILITE, EXPLICITE OU IMPLICITE, RELATIVE AUX INFORMATIONS QUI Y SONT CONTENUES, Y COMPRIS EN CE QUI CONCERNE LES GARANTIES DE VALEUR MARCHANDE OU D'ADAPTATION A VOS BESOINS. Certaines juridictions n'autorisent pas l'exclusion des garanties implicites, auquel cas l'exclusion ci-dessus ne vous sera pas applicable.
Le présent document peut contenir des inexactitudes ou des coquilles. Il est mis à jour périodiquement. Chaque nouvelle édition inclut les mises à jour. IBM peut modifier sans préavis les produits et logiciels décrits dans ce document.
Les références à des sites Web non IBM sont fournies à titre d'information uniquement et n'impliquent en aucun cas une adhésion aux données qu'ils contiennent. Les éléments figurant sur ces sites Web ne font pas partie des éléments du présent produit IBM et l'utilisation de ces sites relève de votre seule responsabilité.
IBM pourra utiliser ou diffuser, de toute manière qu'elle jugera appropriée et sans aucune obligation de sa part, tout ou une partie des informations qui lui seront fournies.
Les licenciés souhaitant obtenir des informations permettant : (i) l'échange des données entre des logiciels créés de façon indépendante et d'autres logiciels (dont celui-ci), et (ii) l'utilisation mutuelle des données ainsi échangées, doivent adresser leur demande à :
Ces informations peuvent être soumises à des conditions particulières, prévoyant notamment le paiement d'une redevance.
Le logiciel sous licence décrit dans ce document et tous les éléments sous licence disponibles s'y rapportant sont fournis par IBM conformément aux termes du Contrat sur les produits et services IBM, des Conditions internationales d'utilisation des logiciels IBM ou de tout autre accord équivalent.
Les données de performance indiquées dans ce document ont été déterminées dans un environnement contrôlé. Par conséquent, les résultats peuvent varier de manière significative selon l'environnement d'exploitation utilisé. Certaines mesures évaluées sur des systèmes en cours de développement ne sont pas garanties sur tous les systèmes disponibles. En outre, elles peuvent résulter d'extrapolations. Les résultats peuvent donc varier. Il incombe aux utilisateurs de ce document de vérifier si ces données sont applicables à leur environnement d'exploitation.
Les informations concernant des produits non IBM ont été obtenues auprès des fournisseurs de ces produits, par l'intermédiaire d'annonces publiques ou via d'autres sources disponibles. IBM n'a pas testé ces produits et ne peut confirmer l'exactitude de leurs performances ni leur compatibilité. Elle ne peut donc recevoir aucune réclamation concernant des produits non IBM. Toute question concernant les performances de produits non IBM doit être adressée aux fournisseurs de ces produits.
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 de Intel Corporation aux Etats-Unis et/ou dans certains autres pays.
Java ainsi que tous les logos et marques incluant Java, sont des marques déposées de Sun Microsystems, Inc. aux Etats-Unis et/ou dans certains autres pays.
Linux est une marque de Linus Torvalds aux Etats-Unis et/ou dans certains autres pays.
Les autres noms de sociétés, de produits et de services peuvent appartenir à des tiers.