Remarque : Avant d'utiliser le présent document et le produit associé, prenez connaissance des informations générales figurant à la section Remarques.
Cette édition du guide utilisateur s'applique à IBM 32-bit SDK et Runtime Environment pour Windows, Java 2 Technology Edition, Version 5.0 et à toutes les versions, modifications et actualisations de service suivantes, sauf indication contraire dans les nouvelles éditions.
(c) Copyright Sun Microsystems, Inc. 1997, 2004, 901 San Antonio Rd., Palo Alto, CA 94303 USA. Tous droits réservés.
(c) Copyright International Business Machines Corporation, 1999, 2005. Tous droits réservés.
U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Ce guide utilisateur fournit des informations générales sur IBM 32-bit SDK et Runtime Environment pour Windows, Java 2 Technology Edition, Version 5.0 et d'autres spécifiques sur les différences entre les implémentations IBM et Sun. Consultez-le en complément de la documentation plus détaillée disponible sur le site Web de Sun : http://java.sun.com.
Le document Diagnostics Guide fournit des informations détaillées sur IBM Virtual Machine for Java.
Les modifications techniques apportées à ce guide pour Version 5.0, autres que les changements mineurs ou importants tels que la mise à jour de "1.4.2" à "5.0", sont signalées en rouge au format HTML ou dans une impression en couleur et par des barres verticales à leur gauche.
Les termes "Runtime Environment" et "machine virtuelle Java" sont utilisés indifféremment dans ce guide.
Le SDK IBM est un environnement de développement permettant d'écrire et d'exécuter des applets et des applications conformes à l'API IBM Java 5.0 Core Application Program Interface.
Il inclut Runtime Environment for Windows, qui permet d'exécuter uniquement des applications Java. Si vous avez installé SDK, IBM Runtime Environment est inclus.
L'environnement d'exécution contient la machine virtuelle Java ainsi que les fichiers de prise en charge incluant les fichiers de classe. L'environnement d'exécution contient seulement un sous-ensemble des classes se trouvant dans le SDK. Il permet de prendre en charge un programme Java lors de l'exécution mais ne permet pas de compiler les programmes Java. Runtime Environment for Windows 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, le module de l'API Java Communications est fourni pour une utilisation avec Runtime Environment for Windows. Vous pouvez trouver des informations à ce sujet dans Utilisation de l'API Java Communications (JavaComm).
En général, toute applet ou application ayant déjà été exécutée avec une version antérieure du SDK doit fonctionner correctement avec IBM 32-bit SDK pour Windows, v5.0. Il n'est pas garanti que les classes compilées avec cette version fonctionnent sur des versions antérieures.
Pour en savoir plus sur la compatibilité, consultez la documentation de Sun sur le site Web http://java.sun.com.
Si vous effectuez une mise à niveau du SDK à partir d'une version précédente, sauvegardez tous les fichiers de configuration et ceux de règles de sécurité avant de procéder.
Une fois la mise à niveau effectuée, il peut être nécessaire de restaurer ou de reconfigurer ces fichiers car ils peuvent avoir été modifiés lors du processus de mise à niveau. Vérifiez la syntaxe des nouveaux fichiers avant de restaurer les fichiers d'origine car le format ou les options des fichiers peuvent avoir été modifiés.
Pour la Version , IBM Runtime Environment for Windows contient les nouvelles versions de d'IBM Java Virtual Machine et du compilateur JIT (Just-In-Time). Si vous effectuez une migration à partir d'une version d'IBM Runtime Environment plus ancienne, notez que :
Le SDK contient plusieurs outils de développement et un Java Runtime Environment (JRE). Cette section décrit le contenu des outils du SDK et de l'environnement d'exécution.
Les applications entièrement écrites en Java ne doivent pas du tout être dépendantes de l'arborescence des répertoires du SDK IBM (ou des fichiers contenus dans ces répertoires). Toute dépendance de cette arborescence (ou de ces fichiers) peut compromettre la portabilité de l'application.
Remarque : les guides utilisateur, la documentation utilisateur ainsi que la licence, les fichiers de droit d'auteur et le répertoire demo qui les accompagnent constituent la seule documentation comprise dans ce SDK pour Windows. Vous pouvez consulter ou télécharger la documentation des logiciels Sun sur le site Web de Sun à l'adresse http://java.sun.com.
Pour installer SDK ou Runtime Environment, téléchargez le package d'installation correspondant. Veillez bien à télécharger tous les packages dans le même répertoire. Les packages et les noms de fichiers sont répertoriés dans Installation sous surveillance (interactive) ; ne les modifiez pas.
Avant d'entamer l'installation, assurez-vous que l'espace est suffisant dans le répertoire C:\WINDOWS\TEMP. La quantité d'espace temporaire dans le répertoire TEMP doit être comme suit :
Si vous n'avez pas assez d'espace temporaire, le programme d'installation émet une erreur et interrompt l'installation. Si l'espace temporaire est suffisant mais qu'un message d'erreur est émis, vérifiez que les packages ont été totalement téléchargés. Pour ce faire, comparez les tailles des fichiers de vos packages à celles affichées dans les pages Web d'où vous les avez téléchargés.
Les packages installables sont :
Autres packages fournis dans des fichiers zip :
Runtime Environment est installé par défaut dans le répertoire C:\Program Files\IBM\Java50\jre.
Si vous avez téléchargé le package d'installation de SDK, vous pouvez choisir d'installer ce qui suit :
Vous pouvez installer les composants de façon individuelle ou combinée.
Dans l'assistant d'installation, vous disposez des options suivantes :
Lorsque vous installez Runtime Environment (comme élément du package d'installation de SDK ou à partir d'un package d'installation propre), vous devez préciser s'il doit être installé comme machine virtuelle Java système. Dans l'affirmative, le programme d'installation copie les fichiers java.exe et javaw.exe dans le répertoire système Windows. Si une version de java.exe ou javaw.exe existe déjà dans le répertoire système Windows, vous devez l'écraser avec celle en cours. L'installation de ces fichiers dans le répertoire système Windows fait de Runtime Environment la machine virtuelle Java par défaut pour le système. Par ailleurs, la clé de registre "Version" est définie de façon à correspondre à cette installation.
Pour une installation automatisée, vous devez d'abord effectuer une installation sous surveillance et créer un fichier de réponses (setup.iss) enregistrant les choix réalisés. Ce fichier de réponses doit être adapté aux ordinateurs sur lesquels vous pensez l'utiliser. Si besoin est, créez plusieurs fichiers de réponses pour installer les packages sur des ordinateurs de configuration distincte.
Pour créer un fichier de réponses pendant l'installation, entrez à une invite de commande :
ibm-java2-sdk-50-win-i386 /r
ou
ibm-java2-jre-50-win-i386 /r
En fonction du produit Windows, un fichier de réponses (setup.iss) est créé dans le répertoire C:\Windows ou C:\Winnt, où C: correspond à l'unité d'amorçage.
Le message suivant peut apparaître lors d'une installation interactive :
Another Java Runtime Environment is currently installed as the System JVM. Select Yes to overwrite this version or No to exit this installation.
Si ce message s'affiche, cliquez sur No et quittez l'installation. Accédez au répertoire système Windows et supprimez les deux fichiers suivants :
Après cela, relancez l'installation interactive à l'aide de la commande indiquée en début de section.
Sur le système où vous effectuerez l'installation automatisée, copiez le fichier de réponses setup.iss dans le répertoire C:\Windows. Après la copie, entrez à une invite de commande :
ibm-java2-sdk-50-win-i386 /s /f1c:\Windows\setup.iss /f2c:\setup.log ibm-java2-jre-50-win-i386 /s /f1c:\Windows\setup.iss /f2c:\setup.log
Si l'installation aboutit, le fichier journal contient la chaîne ResultCode=0.
Si vous modifiez la variable d'environnement PATH de la façon décrite ci-dessous, cela remplacera tous les fichiers exécutables Java présents dans le chemin.
Après avoir installé le SDK, vous pouvez exécuter un outil en entrant son nom à l'invite shell avec un nom de fichier comme argument.
Vous pouvez définir le chemin d'accès à un outil en l'entrant à chaque fois avant le nom de l'outil. Par exemple, si le SDK pour Windows est installé dans C:\Program Files\IBM\Java50\bin, vous pouvez compiler un fichier nommé myfile.java en entrant la commande suivante à l'invite shell :
C:\Program Files\IBM\Java50\bin/javac monfichier.java
Pour modifier la variable d'environnement PATH :
export PATH=C:\Program Files\IBM\Java50\bin:C:\Program Files\IBM\Java50\jre/bin:$PATH
Le CLASSPATH indique aux outils SDK, tels que java, javac et javadoc, l'emplacement des bibliothèques de classes Java.
Vous ne devez définir le CLASSPATH de manière explicite que dans les cas suivants :
Pour afficher la valeur actuelle du CLASSPATH, entrez ce qui suit à l'invite shell :
echo $CLASSPATH
Si vous prévoyez de développer et d'exécuter des applications qui utilisent différents environnements d'exécution, y compris d'autres versions que vous avez installées séparément, vous devez définir le CLASSPATH (et PATH) explicitement pour chaque application. Si vous prévoyez d'exécuter plusieurs applications simultanément et d'utiliser des environnements d'exécution différents, chaque application doit être exécutée dans le shell qui lui est propre.
Si vous souhaitez exécuter une seule version de Java à la fois, vous pouvez utiliser un script shell pour passer d'un environnement d'exécution à l'autre.
L'outil java lance une application Java en démarrant Java Runtime Environment et en chargeant une classe déterminée.
La machine virtuelle recherche la classe initiale (et d'autres classes utilisées) à trois emplacements : le chemin d'accès à la classe d'amorce, les extensions installées et le chemin d'accès à la classe utilisateur. Les arguments ajoutés après le nom de la classe ou du fichier JAR sont transmis à la fonction main.
La commande javaw est identique à java, sauf qu'elle n'est associée à aucune fenêtre de console. Utilisez la commande javaw lorsque vous ne souhaitez pas qu'une fenêtre d'invite s'affiche. Si le lancement échoue, le programme de lancement de javaw affiche une boîte de dialogue contenant un message d'erreur.
Les commandes java et javaw obéissent à la syntaxe suivante :
java [ options ] class [ arguments ... ] java [ options ] -jar file.jar [ arguments ... ] javaw [ options ] class [ arguments ... ] javaw [ options ] -jar file.jar [ arguments ... ]
Les éléments placés entre crochets sont facultatifs.
Si l'option -jar est indiquée, le fichier JAR nommé contient des fichiers de classes et de ressources pour l'application, la classe d'amorce étant signalée par l'en-tête de manifeste de classe principale.
Le programme de lancement contient un jeu d'options standard qui sont prises en charge dans l'environnement d'exécution courant et qui le seront également dans les prochaines éditions. Il contient également un jeu d'options non standard. Les options par défaut ont été choisies pour une utilisation d'ordre général optimale. Vous devez être vigilant lorsque vous décidez d'apporter des modifications à ces options.
Vous pouvez indiquer des options Java et des propriétés systèmes de trois différentes manières : Voici ces différents méthodes classées par ordre de préférence :
Les options les plus à droite à la ligne de commande ont priorité sur celles à gauche : par exemple, si vous entrez les options -Xint -Xjit myClass, -Xjit est prioritaire.
Les options -X ci-après ne sont pas standard et peuvent être modifiées sans préavis.
Pour celles employant le paramètre <taille>, vous devez ajouter "k" ou "K" au nombre pour indiquer qu'il s'agit de kilo-octets, "m" ou "M" de mégaoctets ou bien "g" ou "G" de gigaoctets.
Pour obtenir le numéro de compilation et de version IBM, entrez la commande suivante à l'invite de :
java -version
La commande java et les autres commandes du programme de lancement java (telles que javaw) permettent d'indiquer un nom de classe avec n'importe quel caractère contenu dans le jeu de caractères de l'environnement local courant.
Vous pouvez également utiliser des séquences d'échappement Java pour spécifier n'importe quel caractère Unicode dans le nom de classe et les arguments. Pour ce faire, vous devez entrer -Xargencoding. Pour indiquer un caractère Unicode, utilisez les séquences d'échappement au format \u####, où # est un caractère hexadécimal (de 0 à 9, de A à F).
De la même façon, pour indiquer que le nom de classe et les arguments de la commande sont de codage UTF8, voir -Xargencoding:utf8 ; s'ils sont de codage ISO8859_1, voir -Xargencoding:latin.
Par exemple, pour indiquer une classe nommée "HelloWorld" en codage Unicode pour les deux majuscules, utilisez cette commande :
java -Xargencoding '\u0048ello\u0057orld'
Les commandes java et javaw offrent des messages de sortie traduits. Ces messages varient selon l'environnement local dans lequel s'exécute Java. Les descriptions détaillées des erreurs et autres informations de débogage renvoyées par java sont en anglais.
Le compilateur IBM JIT (Just-In-Time) génère dynamiquement le code machine pour les séquences de code intermédiaire fréquemment utilisées dans les applications Java et les applets en phase d'exécution.| Le compilateur |JIT V5.0 propose de nouvelles optimisations suite à la recherche du compilateur, améliore les optimisations |implémentées dans les versions précédentes du compilateur JIT et fournit une meilleure exploitation matérielle.
IBM SDK et Runtime Environment incluent le JIT, qui est activé par défaut dans les applications utilisateur ainsi que les outils SDK. Il n'est généralement pas nécessaire d'appeler explicitement le compilateur JIT. La compilation du code intermédiaire Java en code machine se produit de manière transparente. Toutefois, si un incident survient dans l'environnement d'exécution lors de l'exécution d'une application Java ou d'une applet, vous pouvez désactiver le compilateur JIT afin d'isoler plus facilement l'incident. La désactivation du compilateur JIT doit être uniquement une mesure temporaire, sa présence étant requise pour des performances appropriées.
Il existe trois méthodes de désactivation du compilateur JIT :
A l'invite de commande, entrez ce qui suit :
export JAVA_COMPILER=NONE
(Les commandes d'interpréteur Korn sont utilisées dans tout le reste de ce guide utilisateur.)
JAVA_COMPILER=NONE
export JAVA_COMPILER
setenv JAVA_COMPILER NONE
java -Djava.compiler=NONE MyApp
java -Xint MonApp
Les options de ligne de commande remplacent la variable d'environnement JAVA_COMPILER.
Pour activer le JIT de manière exemplaire, attribuez la valeur "jitc" à la variable d'environnement JAVA_COMPILER ou utilisez l'option -D pour attribuer la valeur "jitc" à la propriété java.compiler. Vous pouvez également utiliser l'option -Xjit (et omettre l'option -Xint) sur la ligne de commande de la JVM pour activer le JIT.
Si la valeur "" (chaîne vide) est attribuée à la variable d'environnement JAVA_COMPILER ou à la propriété java.compiler, le JIT reste désactivé. Pour annuler la définition de la variable d'environnement correctement, entrez entrez unset JAVA_COMPILER au niveau de l'invite shell.
Pour savoir si le JIT est activé, entrez la commande suivante :
java -version
Si le compilateur JIT est inactif, le message qui s'affiche contient ce qui suit :
(JIT disabled)
Si le compilateur JIT est actif, le message qui s'affiche contient ce qui suit :
(JIT enabled)
Pour plus d'informations sur le JIT, voir document Diagnostics Guide.
Le récupérateur de place gère la mémoire utilisée par Java et par les applications exécutées dans la machine virtuelle.
Lorsque le récupérateur de place reçoit une demande de stockage, la mémoire inutilisée dans le segment de mémoire est mise de côté (on parle alors d'"allocation"). Le récupérateur de place vérifie également les zones de mémoire qui ne sont plus utilisées et les libère pour qu'elles puissent être réutilisées (il s'agit de la "récupération").
La phase de récupération peut être déclenchée par un défaut d'allocation de mémoire, ce qui peut se produire lorsqu'il ne reste plus d'espace pour une demande de stockage ou par un appel System.gc() explicite.
La récupération de place peut avoir un impact considérable sur les performances des applications. Pour cette raison, la machine virtuelle IBM fournit différentes méthodes d'optimisation de la façon dont cette récupération est effectuée afin de limiter l'incidence sur votre application.
Pour plus d'informations sur la récupération de place, voir document .
L'option -Xgcpolicy indique les règle de récupération de place.
-Xgcpolicy accepte les valeurs optthruput (valeur par défaut et recommandée), optavgpause ou gencon. Cette option contrôle le comportement du récupérateur en établissant des compromis entre le débit de l'application et l'ensemble du système et les délais d'interruption nécessités par la récupération de place.
Le format et les valeurs de cette option sont les suivants :
-Xgcpolicy:optthruput
-Xgcpolicy:optavgpause
-Xgcpolicy:gencon
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 Java utilise les deux techniques suivantes pour réduire le délai d'interruption :
L'option de ligne de commande -Xgcpolicy:optavgpause spécifie l'utilisation d'une récupération de place simultanée pour réduire de façon significative le temps passé à la récupération de place. La récupération de place simultanée réduit les délais d'interruption en effectuant des opérations de récupération simultanément avec l'exécution normale du programme afin de minimiser les perturbations provoquées par la collecte du segment de mémoire. L'option -Xgcpolicy:optavgpause réduit également l'impact de l'augmentation de la taille du segment sur la durée des interruptions pour récupération de place. L'option -Xgcpolicy:optavgpause est particulièrement utile pour les configurations présentant de grandes tailles de segment. Ainsi, vous noterez une certaine baisse du débit de vos applications.
Lors de la récupération de place simultanée, un laps de temps considérable est perdu à identifier les objets relativement longs qui ne peuvent alors pas être récupérés. Si la fonction de récupération de place se concentre uniquement sur les objets susceptibles d'être recyclables, vous pouvez réduire encore davantage les délais d'interruption de certaines applications. La récupération de place de génération parvient à cela en divisant le segment en deux "générations", les zones "nursery" (nouvelle génération) et "tenure" (génération titulaire). Les objets sont placés dans l'une ou l'autre de ces zones suivant leur ancienneté. La zone "nursery" est la plus petite des deux et contient les objets les plus récents alors que la zone "tenure" est plus importante et contient les objets plus anciens. Les objets sont d'abord alloués à la zone "nursery". S'ils survivent assez longtemps, ils finissent par passer dans la zone "tenure".
La récupération de place de génération dépend d'une courte durée de la plupart des objets. Cette technique réduit les délais d'interruption en s'efforçant de récupérer en priorité de l'espace disque dans la zone "nursery" car c'est dans cette dernière que l'espace est le plus facilement recyclable. Alors que la récupération intégrale du segment est plus occasionnelle mais plus lente, la récupération des éléments de la zone "nursery" est plus fréquente et, si la taille de cette zone est assez petite, les délais d'interruption sont comparativement plus courts. Il existe toutefois un inconvénient à cette technique qui est, qu'avec le temps, la zone "tenure" peut être saturée si trop d'objets durent trop longtemps. Pour minimiser le délai d'interruption lorsque ce cas survient, ayez recours à une combinaison des deux techniques. L'option -Xgcpolicy:gencon spécifie l'utilisation combinée de la récupération de place simultanée et de la récupération de place de génération pour limiter au minimum les temps d'interruption pour récupération de place.
Si le segment Java est proche de la saturation et que la place à récupérer est très limitée, les demandes de nouveaux objets ne sont pas satisfaites rapidement car aucun espace n'est disponible immédiatement. Si le segment est utilisé au maximum de sa capacité ou presque, une baisse de performances se produit au niveau des applications, indépendamment du réglage des options définies ci-dessus. Si des demandes d'espace supplémentaire sont effectuées, l'application reçoit une exception OutofMemory qui entraîne l'arrêt de la JVM si cette dernière n'est pas interceptée et traitée. A ce stade, la machine JVM génère un fichier de diagnostic "javadump". Dans ces cas de figure, il est recommandé d'augmenter la taille du segment à l'aide de l'option -Xmx ou de réduire le nombre d'objets d'application utilisés. Pour plus d'informations, voir document Diagnostics Guide.
En cas de signal pertinent pour la JVM, un gestionnaire de signaux est appelé. Il détermine s'il a été appelé pour une unité d'exécution Java ou non Java.
Si le signal concerne une unité d'exécution Java, la JVM prend le contrôle du traitement du signal. Si un gestionnaire d'application pour ce signal est installé et que vous ne définissez pas l'option de ligne de commande -Xnosigchain, une fois que la machine JVM a terminé le traitement, le gestionnaire d'application pour ce signal est appelé.
Si le signal concerne une unité d'exécution non Java et que l'application qui a installé la JVM a déjà installé un gestionnaire spécifique pour ce signal, le contrôle est passé à ce gestionnaire. Sinon, si le signal est demandé par la machine JVM ou l'application Java, il est ignoré ou l'action par défaut est effectuée.
En cas de signaux d'exception ou d'erreur, la JVM effectue l'une des opérations suivantes :
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.
Le tableau tableau 1 ci-dessous indique les signaux utilisés par la JVM. Ces signaux sont regroupés par type ou par utilisation, de la façon suivante :
| Nom du signal | Type de signal | Description | Désactivé par -Xrs |
|---|---|---|---|
| SIGBUS | Exception | Accès incorrect à la mémoire (données non alignées) | Oui |
| SIGSEGV | Exception | Accès incorrect à la mémoire (écriture dans une mémoire inaccessible) | Oui |
| SIGILL | Exception | Instruction non conforme (tentative d'appel d'une instruction machine inconnue) | Oui |
| SIGFPE | Exception | Exception en virgule flottante (division par zéro) | Oui |
| SIGABRT | Erreur | Arrêt anormal. La JVM déclenche ce signal si elle détecte un incident JVM. | Oui |
| SIGINT | Interruption | Attention interactive (Ctrl-C). JVM s'arrête normalement. | Oui |
| SIGTERM | Interruption | Demande d'arrêt. JVM s'arrête normalement. | Oui |
| SIGHUP | Interruption | Arrêt de l'exécution. JVM s'arrête normalement. | Oui |
| SIGQUIT | Contrôle | Utilisé par la machine JVM pour les vidages Java. | Oui |
| |SIGRECONFIG (58) | |Contrôle | |Réservé à la détection des modifications apportées au nombre d'UC, à la capacité de traitement |ou à la mémoire physique. | |Oui |
| |SIGTRAP (5) | |Contrôle | |Utilisé par le JIT. | |Oui |
| |SIGCHLD | |Contrôle | |Utilisé par le SDK pour le contrôle interne. | |Non |
Utilisez l'option -Xrs (réduction de l'utilisation des signaux) pour empêcher la JVM de traiter la plupart des signaux. Pour plus d'informations, reportez-vous à la page du programme de lancement d'applications Java, à l'adresse http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html.
Les signaux 1 (SIGHUP), 2 (SIGINT), 4 (SIGILL), 7 (SIGBUS), 8 (SIGFPE), 11 (SIGSEGV) et 15 (SIGTERM) sur unités d'exécution JVM provoquent l'arrêt de la machine JVM. Par conséquent, le gestionnaire de signaux d'application ne doit tenter aucune récupération à partir de ces signaux à moins qu'il n'ait plus besoin de la JVM.
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 et de la charger avant les bibliothèques système. La bibliothèque 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.
IBM SDK contient le processeur XSLT4J et l'analyseur XML4J respectant la spécification JAXP 1.3. Ces outils vous permettent d'analyser et de transformer des documents XML indépendamment de toute implémentation de traitement XML donnée. Grâce aux localisateurs de fabrique recherchant les implémentations SAXParserFactory, DocumentBuilderFactory et TransformerFactory, votre application peut passer de l'une à l'autre sans devoir modifier le code.
|La technologie XML incluse avec le SDK IBM est similaire à |Apache Xerces Java et Apache Xalan Java. Pour plus d'informations, voir http://xml.apache.org/xerces2-j/ et http://xml.apache.org/xalan-j/.
Le processeur XSLT4J vous permet de choisir entre le processeur d'interprétation XSLT d'origine ou le nouveau processeur de compilation XSLT. Le processeur d'interprétation est conçu pour manipuler et déboguer des environnements. Il prend en charge les fonctions d'extension XSLT non prises en charge par le processeur de compilation XSLT. Ce dernier est conçu pour des environnements d'exécution hautes performances ; il génère un moteur de transformation, ou translet, à partir d'une feuille de style XSL. Cette approche distingue l'interprétation des instructions de la feuille de style de leur application à des données XML.
Le processeur d'interprétation XSLT est le processeur par défaut. Pour sélectionner le processeur de compilation XSLT, vous pouvez :
Pour implémenter des propriétés dans le fichier jaxp.properties file, copiez jaxp.properties.sample dans jaxp.properties, dans C:\Program Files\IBM\Java50\. Ce fichier contient également tous les détails sur la procédure à suivre pour identifier les implémentations à utiliser pour TransformerFactory, SAXParserFactory et DocumentBuilderFactory.
Pour améliorer les performances lorsque vous transformez un objet StreamSource à l'aide du processeur de compilation XSLT, indiquez la classe com.ibm.xslt4j.b2b2dtm.XSLTCB2BDTMManager comme fournisseur du service org.apache.xalan.xsltc.dom.XSLTCDTMManager. Pour identifier le fournisseur de services, essayez chaque étape jusqu'à org.apache.xalan.xsltc.dom.XSLTCDTMManager :
Le processeur de compilation XSLT détecte le fournisseur de services pour le service org.apache.xalan.xsltc.dom.XSLTCDTMManager lorsqu'un objet javax.xml.transform.TransformerFactory est créé. Les objets javax.xml.transform.Transformer et javax.xml.transform.sax.TransformerHandler créés à l'aide de l'objet TransformerFactory utilisent le même fournisseur de services. Vous pouvez uniquement changer le fournisseur de services en modifiant l'un des paramètres décrits ci-dessus et en créant un nouvel objet TransformerFactory.
Si vous utilisez une ancienne version de Tomcat, cette limitation peut vous concerner.
Si vous utilisez une ancienne version de Xerces (antérieure à 2.0) ou de Xalan (antérieure à 2.3) dans la substitution approuvée, il se peut qu'une exception de pointeur nul soit émise lorsque vous lancez votre application. Cette exception se produit car les anciennes versions ne gèrent pas le fichier jaxp.properties correctement.
Pour éviter cette situation, utilisez l'une des solutions suivantes :
export IBM_JAVA_OPTIONS=-Djavax.xml.parsers.SAXParserFactory= org.apache.xerces.jaxp.SAXParserFactoryImplou
export IBM_JAVA_OPTIONS=-Djavax.xml.parsers.DocumentBuilderFactory= org.apache.xerces.jaxp.DocumentBuilderFactoryImplou
export IBM_JAVA_OPTIONS=-Djavax.xml.transform.TransformerFactory= org.apache.xalan.processor.TransformerFactoryImpl
Les sections qui suivent offrent des informations sur l'utilisation de SDK for Windows pour développer des applications Java. Voir Outils SDK pour en savoir plus sur les outils disponibles.
Pour déboguer les programmes Java, vous devez utiliser l'application Java Debugger (JDB) ou d'autres débogueurs communiquant à l'aide de l'architecture JPDA (Java Platform Debugger Architecture) fournie par le SDK pour Windows.
Le débogueur Java (JDB) est inclus dans le SDK de Windows. Il est appelé par la commande jdb et s'"attache" à la machine virtuelle Java à l'aide de JPDA. Pour déboguer une application Java, procédez comme suit :
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=<port>
MonApp <MonApp args>jdb -attach <numéro de port>Le débogueur se rattache à la machine JVM, ce qui vous permet à présent d'émettre une série de commandes pour examiner et contrôler l' application Java. Par exemple, entrez run pour permettre l'exécution de l'application Java.
Pour obtenir des informations sur les options JDB, entrez :
jdb -help
Pour obtenir des informations sur les commandes JDB :
Vous pouvez également utiliser JDB pour déboguer les applications Java en cours d'exécution sur les machines distantes JPDA utilise une socket TCP/IP pour la connexion à la machine JVM distante.
jdb -attach <nom de machine ou adresse ip>:<numéro de port>
Lorsque vous lancez une session de débogage à l'aide du transport dt_socket, assurez-vous que les ports indiqués sont libres.
|Cette version ne prend pas en charge l'interface JVMDI (Java Virtual Machine Debugging Interface). Elle a été |remplacée par l'interface JVMTI (Java Virtual Machine Tool Interface).
Pour plus d'informations sur l'utilisation de JDB et JPDA, consultez les sites Web suivants :
Certaines applications Java doivent pouvoir déterminer si elles s'exécutent sur une machine virtuelle Java 32 bit ou 64 bit. Par exemple, si votre application possède une bibliothèque de code native, celle-ci doit être compilée séparément en 32 et 64 bit pour des plateformes prenant en charge ces deux modes d'opération 32 et 64 bit. Dans ce cas, votre application doit charger la bibliothèque correcte lors de l'exécution car il est impossible de mélanger du code 32 et 64 bit.
La propriété système com.ibm.vm.bitmode permet aux applications d'identifier le mode dans lequel votre machine virtuelle Java fonctionne. Elle renvoie les valeurs suivantes :
Vous pouvez observez la propriété com.ibm.vm.bitmode depuis le code de votre application à l'aide de l'appel :
System.getProperty("com.ibm.vm.bitmode");
Les numéros de versions JNI que des programmes natifs peuvent indiquer dans l'appel de l'API JNI_CreateJavaVM() sont :
Le numéro de version détermine uniquement le niveau de l'interface native JNI à utiliser. Le niveau de la machine virtuelle créée est précisé par les bibliothèques J2SE (à savoir, 5.0). L'API de l'interface JNI n'affecte pas la spécification de langue implémentée avec la machine virtuelle, les API de bibliothèque de classe ou tout autre aspect du comportement de la machine virtuelle. Pour plus d'informations, voir http://java.sun.com/j2se/1.5.0/docs/guide/jni.
Si votre application a besoin de deux bibliothèques JNI, l'une pour 32 bit et l'autre pour 64 bit, employez la propriété système com.ibm.vm.bitmode afin de déterminer si vous travaillez avec une machine virtuelle 32 ou 64 bit et choisissez la bibliothèque en conséquence.
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 |propre classe d'extension de java.lang.Thread pour utiliser ces nouvelles classes.
|La documentation Java de ces classes est fournie avec le kit SDK dans le fichier docs/apidoc.zip.
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.
Pour exécuter une applet à l'aide d'Applet Viewer, entrez la commande suivante à l'invite :
appletviewer nom
où nom correspond à l'un des éléments suivants :
Par exemple, pour appeler Applet Viewer sur un fichier HTML qui appelle une applet, entrez la commande suivante à l'invite :
appletviewer $HOME/nomfichier.html
où nomfichier correspond au nom du fichier HTML.
Par exemple, http://java.sun.com/applets/NervousText/example1.html est l'URL d'une page Web qui appelle une applet. Pour appeler Applet Viewer sur cette page Web, entrez la commande suivante à l'invite shell :
appletviewer http://java.sun.com/applets/NervousText/exemple1.html
Applet Viewer ne reconnaît pas l'option charset de la balise <META>. Si le fichier chargé par appletviewer n'est pas encodé comme valeur par défaut du système, une exception E-S peut se produire. Pour éviter cette exception, utilisez l'option -encoding lorsque vous exécutez appletviewer. Par exemple :
appletviewer -encoding JISAutoDetect sample.html
L'option -debug d'Applet Viewer permet de déboguer les applets. Lors du débogage d'applets, il est conseillé d'appeler Applet Viewer à partir du répertoire contenant le fichier HTML qui appelle l'applet. Par exemple :
cd demo/applets/TicTacToe ../../bin/appletviewer -debug exemple1.html
Vous trouverez de la documentation sur le débogage d'applets à l'aide d'Applet Viewer sur le site Web de Sun à l'adresse http://java.sun.com.
Java 2 Platform, Standard Edition (J2SE) prend au minimum en charge les spécifications définies dans les spécifications officielles de prise en charge de CORBA dans J2SE (V1.5). Dans certains cas, la fonction ORB J2SE IBM prend en charge des versions plus récentes des spécifications.
Ce SDK prend en charge toutes les versions de GIOP, telles qu'elles sont définies dans les chapitres 13 et 15 de la spécification CORBA 2.3.1, document formal/99-10-07 du groupe OMG, accessible sur le site Web suivant :
http://www.omg.org/cgi-bin/doc?formal/99-10-07
Le protocole GIOP bidirectionnel n'est pas pris en charge.
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 service annuaire transitoire (commande tnameserv), lorsqu'aucun paramètre ORBInitialPort n'est fourni, est passé de 900 à 2809, c'est-à-dire au numéro de port enregistré auprès de l'IANA (Internet Assigned Number Authority) pour un service annuaire CORBA. Les programmes qui dépendent de cette valeur par défaut peuvent nécessiter une mise à jour pour fonctionner avec cette version.
Le contexte initial renvoyé par le serveur de noms transitoire est à présent un org.omg.CosNaming.NamingContextExt. Les programmes existants qui réduisent la référence à un contexte org.omg.CosNaming.NamingContext fonctionnent toujours et n'ont pas besoin d'être recompilés.
La fonction ORB prend en charge les paramètres -ORBInitRef et -ORBDefaultInitRef définis par la spécification INS et l'opération ORB::string_to_object prend désormais en charge les formats de chaîne ObjectURL (corbaloc: et corbaname:) définis par la spécification INS.
La fonction OMG définit une méthode ORB::register_initial_reference pour enregistrer un service auprès de l'INS. Toutefois, cette méthode n'est pas disponible dans l'API Sun Java centrale Version 5.0. Les programmes ayant besoin d'enregistrer un service dans la version actuelle doivent appeler cette méthode sur la classe d'implémentation ORB interne IBM. Par exemple, pour enregistrer un service "MonService" :
((com.ibm.CORBA.iiop.ORB)orb).register_initial_reference("MonService",
serviceRef);
où orb correspond à une instance d'org.omg.CORBA.ORB, renvoyée par ORB.init(), et serviceRef correspond à un objet CORBA, connecté à la fonction ORB. Ce mécanisme est temporaire et n'est pas compatible avec les future versions, ni portable sur les ORB non IBM.
Une fonction de débogage d'exécution améliore la maintenabilité. Elle peut être utile pour la procédure de diagnostic ou être demandée par le service de maintenance IBM. Le traçage est géré à l'aide de trois propriétés système.
Par exemple, pour tracer les événements et les messages GIOP mis en forme, entrez :
java -Dcom.ibm.CORBA.Debug=true -Dcom.ibm.CORBA.CommTrace=true monApp
N'activez pas le traçage pour le fonctionnement normal car cela pourrait réduire les performances. Même si vous avez désactivé le traçage, l'outil de diagnostic de premier niveau fonctionne toujours, de sorte que seules les erreurs graves sont signalées. Si un fichier de sortie de débogage est généré, examinez-le pour identifier le problème. Par exemple, il se peut que le serveur se soit arrêté sans effectuer de ORB.shutdown().
Le contenu et le format du fichier de sortie de trace varie d'une version à l'autre.
Vous pouvez optimiser l'ORB à l'aide des propriétés suivantes :
Par exemple, pour définir une taille de fragment de 4096 octets :
java -Dcom.ibm.CORBA.FragmentSize=4096 monApp
La taille de fragment par défaut est de 1024 octets. Vous pouvez désactiver la fragmentation en définissant une taille de fragment égale à 0.
java -Dcom.ibm.CORBA.RequestTimeout=30
-Dcom.ibm.CORBA.LocateRequestTimeout=30 monApp
Par défaut, l'ORB attend une réponse indéfiniment. Ne définissez pas un délai d'attente trop court pour ne pas risquer de mettre fin aux connexions inutilement.
Par exemple, pour forcer l'ORB à utiliser le port 1050, entrez :
java -Dcom.ibm.CORBA.ListenerPort=1050 monApp
Si cette propriété est définie, l'ORB se met en mode écoute dès qu'il est initialisé. Sinon, il commence l'écoute seulement lorsque cela est requis.
Lors de l'exécution avec un gestionnaire de sécurité Java 2, l'appel de certaines méthodes des classes API CORBA peut donner lieu à des vérifications de droits et, par conséquent, générer une exception de sécurité. Les méthodes concernées sont les suivantes :
| Classe/Interface | Méthode | Droit requis |
|---|---|---|
|
org.omg.CORBA.ORB |
init |
java.net.SocketPermission resolve |
|
org.omg.CORBA.ORB |
connect |
java.net.SocketPermission listen |
|
org.omg.CORBA.ORB |
resolve_initial_references |
java.net.SocketPermission connect |
|
org.omg.CORBA. portable.ObjectImpl |
_is_a |
java.net.SocketPermission connect |
|
org.omg.CORBA. portable.ObjectImpl |
_non_existent |
java.net.SocketPermission connect |
|
org.omg.CORBA. portable.ObjectImpl |
OutputStream _request (chaîne, booléen) |
java.net.SocketPermission connect |
|
org.omg.CORBA. portable.ObjectImpl |
_get_interface_def |
java.net.SocketPermission connect |
|
org.omg.CORBA. Request |
invoke |
java.net.SocketPermission connect |
|
org.omg.CORBA. Request |
send_deferred |
java.net.SocketPermission connect |
|
org.omg.CORBA. Request |
send_oneway |
java.net.SocketPermission connect |
|
javax.rmi. PortableRemoteObject |
narrow |
java.net.SocketPermission connect |
Si votre programme utilise l'une de ces méthodes, assurez-vous qu'il bénéficie des droits nécessaires.
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 mise 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, définissez l'option
-Dsun.rmi.transport.tcp.connectionPool=true (ou toute valeur non NULL)
Cette version de Runtime Environment ne contient pas de paramètre permettant de restreindre le nombre d'unités d'exécution du pool de connexions.
Pour plus d'informations, reportez-vous au site de Sun Java, à l'adresse suivante : http://java.sun.com.
Le SDK IBM inclut une meilleure prise en charge des données bidirectionnelles. Pour plus d'informations, consultez le site http://www-106.ibm.com/developerworks/java/jdk/bidirectional/index.html. La documentation Java du package bidirectionnel est fournie avec le kit SDK dans le fichier docs/apidoc.zip.
Depuis Java 5.0, la classe Big Decimal IBM est adoptée par Sun en tant que java.math.BigDecimal. | IBM n'assure plus la gestion de com.ibm.math.BigDecimal, désormais obsolète. | Il est recommandé de migrer le code Java existant pour utiliser java.math.BigDecimal.
|La nouvelle classe java.math.BigDecimal utilise les mêmes méthodes |que les précédentes |java.math.BigDecimal et com.ibm.math.BigDecimal. Le code existant qui utilise java.math.BigDecimal |continue à fonctionner correctement.
|Pour faire migrer le code Java existant afin d'utiliser la classe java.math.BigDecimal, modifiez l'instruction |d'importation au début du fichier java en remplaçant import com.ibm.math.*; par import java.math,*;.
Le SDK et le Runtime Environment IBM définissentl'euro comme devise par défaut pour les pays de l'Union Monétaire Européenne (UME) pour les dates ultérieures au 31 décembre 2001.
Pour utiliser l'ancienne devise nationale, entrez -Duser.variant=PREEURO sur la ligne de commande Java.
Si vous utilisez les paramètres nationaux du Royaume-Uni, du Danemark ou de la Suède et souhaitez utiliser l'euro, entrez -Duser.variant=EURO sur la ligne de commande Java.
L'interface de programmation d'application Java Communications (JavaComm) est un module fourni en option à utiliser avec Runtime Environment for Windows. JavaComm doit être installé indépendamment du SDK ou de l'environnement d'exécution.
L'API JavaComm permet aux applications Java sur toute plateforme d'effectuer des communications de port série et parallèles pour les technologies telles que la messagerie vocale, la télécopie et les cartes à puce. Après avoir écrit les communications de port série et parallèle pour votre application, vous pouvez inclure ces fichiers avec votre application.
L'API Java Communications prend en charge les ports série Electronic Industries Association (EIA)-232 (RS232) et les ports parallèles Institute of Electrical and Electronics Engineers (IEEE) 1284. Elle fonctionne sur les systèmes utilisant IBM Runtime Environment Version 5.0.
L'API Java Communications vous permet d'effectuer les opérations suivantes :
Les fichiers de l'API Java Communications sont installés comme suit :
Si vous avez choisi d'effectuer l'installation dans le répertoire par défaut, le fichier comm.jar se trouve dans C:\Program Files\IBM\Java50\jre/lib/ext.
Si vous avez installé le module dans un autre répertoire, les fichiers se trouvent dans la même arborescence mais C:\Program Files\IBM\Java50\ est remplacé par le répertoire où vous avez installé l'API Java Communications.
Une fois que vous avez installé l'API Java Communications, vous devez :
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.
Vous trouverez de la documentation et des exemples de l'API Java Communications sur le site Web à l'adresse http://java.sun.com.
Java Plug-in est un plug-in de navigateur Web. Si vous l'employez, vous pouvez désactiver la machine virtuelle Java par défaut de votre navigateur Web et utiliser à la place un environnement d'exécution de votre choix pour exécuter des applets ou des beans dans le navigateur.
Vous devez laisser les applets se charger complètement pour éviter le blocage du navigateur. Par exemple, si vous cliquez sur le bouton Précédente puis Suivante alors qu'une applet est en cours de chargement, les pages HTML peuvent ne pas s'afficher.
Java Plug-in est expliqué par Sun à l'adresse : http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/.
En raison des limitations de certains navigateurs, vous ne pourrez peut-être pas implémenter toutes les fonctions du module org.w3c.dom.html.
Le plug-in Java prend en charge les caractères double octet (par exemple, le chinois traditionnel BIG-5, le coréen et le japonais) en tant que paramètres pour les balises <APPLET>, <OBJECT> et <EMBED>. Vous devez sélectionner le codage des caractères correct pour le document HTML de sorte que Java Plug-in puisse analyser le paramètre. Indiquez le codage des caractères pour le document HTML à l'aide de la balise <META> dans la section <HEAD> comme suit :
<meta http-equiv="Content-Type" content="text/html; charset=big5">
Cet exemple demande au navigateur d'analyser le fichier HTML à l'aide de l'encodage de caractères Chinese BIG-5. Tous les paramètres sont transmis correctement au plug-in Java. Cependant, il est possible que certaines des versions plus anciennes des navigateurs ne comprennent pas correctement cet indicateur. Dans ce cas, vous pouvez obliger le navigateur à ignorer cet indicateur, mais vous devrez peut-être modifier le codage manuellement.
Vous pouvez indiquer le codage à utiliser pour analyser le fichier HTML :
Vous pouvez utiliser Java Web Start pour déployer des applications Java. Web Start permet à l'utilisateur de lancer et de gérer des applications directement à partir du Web. Avec Java Web Start, vous pouvez démarrer facilement les applications à partir du Web, en ayant la garantie d'exécuter la dernière version en date, ce qui élimine les procédures d'installation ou de mise à jour. Java Web Start évite le temps passé à télécharger et à installer des logiciels.
|Outre les java-vm-args décrits sur le site Web http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/syntax.html#resources, Web Start prend en charge -Xgcpolicy pour définir la règle de récupération de place.
Pour plus d'informations sur les navigateurs prenant en charge Web Start, voir Navigateurs pris en charge.
Pour plus d'informations sur Web Start, consultez les sites Web http://java.sun.com/products/javawebstart et http://java.sun.com/j2se/1.5.0/docs/guide/javaws/index.html. Pour plus d'informations sur le déploiement d'applications, consultez le site Web http://java.sun.com/j2se/1.5.0/docs/guide/deployment/index.html.
Vous pouvez lancez Web Start de l'une des trois manières suivantes :
Une fois l'application téléchargée, elle est stockée dans le cache Java. Si vous accédez à nouveau à l'application, Java Web Start télécharge une version plus récente de l'application si elle est disponible ou emploie la version en cache dans le cas contraire.
Si une erreur se produit dans un fichier .jnlp (telle qu'un nom de balise erroné), Web Start s'interrompt sans afficher de message d'erreur.
Contrairement à une applet Java, une application Java ne peut reposer sur un navigateur Web pour les services d'installation et d'exécution. Lorsque vous livrez une application Java, le package se compose probablement de ce qui suit :
Pour exécuter votre application, les utilisateurs ont besoin de Runtime Environment for Windows. SDK for Windows inclut un Runtime Environment. Toutefois, vous ne pouvez pas supposer que SDK for Windows est installé pour les utilisateurs.
Votre licence de SDK for Windows ne vous permet pas de redistribuer les fichiers du SDK avec votre application. Assurez-vous qu'une version sous licence de SDK for Windows est installée sur la machine cible.
| | |La machine virtuelle d'IBM (VM) vous permet de partager avec |d'autres machines virtuelles |des classes d'amorce et d'application en les stockant dans le cache |d'une mémoire partagée. Le partage de classes réduit la |consommation globale de mémoire virtuelle lorsque plusieurs |machines virtuelles partagent un cache. Il diminue également le |temps de démarrage d'une machine virtuelle après création du |cache. Le cache de classes partagées est indépendant de toute machine |virtuelle active et demeure au-delà de la durée de vie de celle l'ayant |lancé.
| |IBM SDK permet un partage de classes illimité qui semble transparent pour l'utilisateur.
| |Le cache de classes partagées contient des données et des |métadonnées descriptives de classes statiques en lecture seule. Toute |machine virtuelle peut lire et mettre à jour ce cache. Les machines |virtuelles le partageant doivent être de la même édition. Soyez vigilant si une modification de code intermédiaire |d'exécution est appliquée. (Voir Modification du code intermédiaire d'exécution.)
| |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.
| |Activez le partage de classes à l'aide de l'option |-Xshareclasses au démarrage de la machine |virtuelle, afin que celle-ci se connecte à un cache existant ou en |crée un. Toutes les classes d'amorce et d'application chargées par |la machine virtuelle sont par défaut partagées. Les chargeurs de |classes personnalisés effectuent automatiquement un partage s'ils |étendent le chargeur de classes de l'application ; sinon, |ils doivent utiliser l'API Java Helper fournie avec la machine |virtuelle pour accéder au cache. (Voir Adaptation de chargeurs de classes personnalisés pour partager |des classes.)
| |L'accès au cache des classes est limitée par les droits Java et du système d'exploitation. Le cache de classes partagées est créé avec l'accès utilisateur par défaut sauf si la sous-option de ligne de commande groupAccess est utilisée. Seul un chargeur de classe qui est enregistré pour partager des classes peut en ajouter |à ce cache. Si un gestionnaire de sécurité Java est installé, les chargeurs de classe à l'exception des chargeurs de classe d'extension, d'application et d'amorce, doivent disposer de droits permettant de partager des classes par l'ajout de SharedClassPermissions au fichier java.policy. (Voir Utilisation de SharedClassPermissions.) |Le droit RuntimePermission "createClassLoader" restreint la création de chargeurs de classe et restreint donc l'accès au cache.
| |Plusieurs caches peuvent se trouver sur un même système ; ils sont |alors désignés par leur nom, comme sous-option de la commande -Xshareclasses. Une machine virtuelle ne peut se connecter qu'à un seul cache à la fois. Vous |indiquez la taille du cache au démarrage via -Xscmx<n>[k|m|g], mais cette taille est ensuite déterminée |par rapport à la durée de vie du cache. Les caches existent |jusqu'à destruction explicite avec une sous-option de la |commande -Xshareclasses ou redémarrage du |système.
| |Tous les utilitaires du cache sont des sous-options de la |commande -Xshareclasses. Utilisez |-Xshareclasses:help pour obtenir la liste des |sous-options disponibles.
| |Le partage de classes est activé et configuré à l'aide des options de ligne de commande -Xshareclasses et -Xscmx.
|Pour activer le partage de classes, ajoutez |-Xshareclasses[:name=<nom>] à la ligne de |commande de votre application. La machine virtuelle se connecte alors |à un cache existant du nom indiqué ou en crée un de ce nom. Si un |nouveau cache est créé, il est rempli avec toutes les classes |d'amorce et d'application chargées jusqu'à ce qu'il soit saturé. Si deux machines virtuelles ou |plus sont démarrées en même temps, elles remplissent en parallèle le |cache.
|Pour vérifier que le cache a bien été créé, exécutez java -Xshareclasses:listAllCaches. Pour savoir |combien de classes et quelle quantité de données sont partagées, |exécutez java -Xshareclasses:[name=<nom>],printStats. (Ces |utilitaires peuvent être exécutés au terme de la machine virtuelle |de l'application ou dans une autre fenêtre de commande.)
|Pour voir les classes chargées depuis le cache ou stockées à l'intérieur, |ajoutez -Xshareclasses:[name=<nom>],verbose à la ligne |de commande de votre application.
|Pour supprimer le cache créé, exécutez java |-Xshareclasses:[name=<nom>],delete. Vous devez uniquement |supprimer des caches s'ils contiennent de nombreuses classes |périmées ou s'ils sont pleins et que vous souhaitez en créer un |plus important.
|Il est recommandé de régler la taille du cache pour votre application |spécifique car il est peu probable que la valeur par défaut corresponde à la |taille optimale. La meilleure méthode de détermination de 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 arrêtée. Toutefois, un cache saturé n'a aucune répercussion négative sur les performances |ou la capacité des machines virtuelles qui y sont connectées. Il peut donc être légitime de définir une taille |de cache plus petite que nécessaire.
|Si un cache arrive à saturation, un message est émis sur la ligne de commande |de toutes les machines virtuelles utilisant le cache. Ces dernières ne chargeront |plus aucune classe dans leur propre mémoire de processus. Les classes d'un cache |saturé peuvent toujours être partagées mais ce dernier est en lecture seule et ne |peut plus être mis à jour avec de nouvelles classes.
| |Le partage de classes s'avère particulièrement utile sur des |systèmes recourant à plusieurs machines virtuelles qui exécutent un |même code. Le système profite ainsi de la consommation réduite de mémoire |virtuelle. | Il est également bienvenu sur des systèmes |démarrant et arrêtant souvent des machines virtuelles, profitant du |meilleur temps de démarrage.
|Le temps système pour créer et remplir un nouveau cache est minimal. Le |coût du temps de démarrage des machines virtuelles est généralement |compris entre 0 et 5 % pour une seule machine virtuelle, en fonction du nombre de classes chargées. |L'amélioration de ce temps avec un cache rempli oscille entre 10 et |40 %, selon le système d'exploitation et le nombre de classes |chargées. Plusieurs machines virtuelles exécutées de manière simultanée |tirent un plus grand parti du temps de démarrage général.
|Lorsque vous exécutez votre application avec le partage de |classes, vous pouvez employer les outils du système |d'exploitation pour constater la baisse de consommation de |mémoire virtuelle.
| |Le cache du partage des classes est alloué à l'aide du mécanisme de mémoire partagée System |V IPC.
|La taille de cache théorique maximale est 2 Go. La taille du cache indiquée est limitée |par la quantité d'espace physique et de pagination disponible sur le système.
|Etant donné que l'espace d'adresse virtuelle d'un |processus |est partagé entre le cache de classes partagées et le segment Java, l'augmentation de la taille |maximale du segment Java réduit la taille du cache de classes partagées que vous pouvez créer.
| |Toute machine virtuelle utilisant un agent JVMTI capable de |modifier du code intermédiaire ne peut partager des classes tant que |la sous-option modified=<contexte modifié> est utilisée à la ligne |de commande (voir ci-dessus). Le contexte modifié est un descripteur |spécifique à l'utilisateur désignant le type de modification |effectuée. Toutes les machines virtuelles utilisant un contexte |modifié doivent modifier le code intermédiaire de façon prévisible |et réitérable ; ainsi, les classes modifiées stockées dans le cache |intègrent les modifications attendues lorsqu'elles sont chargées par |une autre machine virtuelle. Toute modification doit être prévisible |afin que les classes chargées depuis le cache ne puissent être à |nouveau modifiées par l'agent. Le code intermédiaire modifié et |inchangé peut être stocké dans le même cache. Voir le document |Diagnostics Guide pour en savoir |plus à ce sujet.
| |Pour les systèmes d'exploitation pouvant exécuter |des applications tant 32 que 64 bit, le partage de classes n'est pas |autorisé entre des machines virtuelles 32 et 64 bit. |La sous-option |listAllCaches répertorie les caches de 32 et |64 bit, en fonction du mode d'adressage de la machine virtuelle |utilisée.
|Le cache de classes partagées requiert de l'espace disque |pour stocker des informations d'identification sur les caches |figurant sur le système. Si le |répertoire contenant les informations d'identification est supprimé, |la machine virtuelle ne peut identifier les classes partagées sur le |système et doit créer à nouveau le cache.
|Les droits permettant d'accéder à un cache de classes partagées sont appliqués par |le système d'exploitation. Si aucun nom de cache n'est précisé, le nom d'utilisateur est ajouté |au nom par défaut afin que plusieurs utilisateurs sur le même système |créent leurs propres caches par défaut.
| |Si un gestionnaire de sécurité est utilisé conjointement au partage de classes et que l'application |en cours d'exécution utilise ses propres chargeurs de classes, ces derniers doivent disposer du droit |SharedClassPermissions pour pouvoir partager des classes. Vous ajoutez SharedClassPermissions |au fichier java.policy en indiquant le nom de classe ClassLoader (les caractères génériques sont admis) |et "read", "write" ou "read,write" pour déterminer l'accès accordé. |Par exemple :
|permission com.ibm.oti.shared.SharedClassPermission "com.abc.customclassloaders.*", "read,write";
Si un chargeur de classe ne dispose pas du droit SharedClassPermission correct et que |des tentatives de partage de classe sont effectuées, une exception AccessControlException est émise. Vous ne pouvez pas |modifier ou réduire les droits des chargeurs de classe d'amorçage, d'application ou d'extension par défaut.
| |La plupart des applications Java utilisent les chargeurs de |classes des machines virtuelles ou disposent de chargeurs |personnalisés étendant java/net/URLClassLoader. Les applications |utilisant ces chargeurs peuvent automatiquement partager des classes d'amorce |et d'application. Les chargeurs de classes n'étendant pas |java/net/URLClassLoader requièrent des modifications afin de réaliser |un partage de classes. Le droit SharedClassPermissions doit être accordé |à tous les chargeurs de classes personnalisés si un gestionnaire est utilisé, voir Utilisation de SharedClassPermissions. IBM fournit plusieurs interfaces Java pour différents types de chargeurs de classes personnalisés, ce qui permet à |ceux-ci de rechercher et de stocker des classes dans leur cache de |classes partagées. Ces classes se trouvent dans le package com.ibm.oti.shared. La documentation Java |de ce package est fournie avec le SDK dans le fichier docs/apidoc.zip. Voir le |document Diagnostics Guide pour en savoir |plus sur le mode d'utilisation de ces interfaces.
Si vous avez droit à des services pour le code de programme appartenant à IBM Solutions Developer Program, contactez l'équipe de ce dernier en accédant au site Web à l'adresse :http://www-1.ibm.com/partnerworld/.
Si vous avez établi un contrat de service (tel qu'IBM Personal Systems Support Line ou équivalent selon le pays), les termes et conditions déterminent les services, le cas échéant, que vous avez le droit de recevoir par rapport au programme.
Les guides utilisateur fournis avec ce SDK et le Runtime Environment ont été testés à l'aide de lecteurs d'écran. Les lecteurs d'écran tels que Home Page Reader ou JAWS peuvent être utilisés avec ces guides.
Pour modifier la taille des polices des guides utilisateur, utilisez la fonction fournie par votre navigateur, habituellement située dans le menu Affichage.
Pour les utilisateurs nécessitant une navigation par clavier, une description des touches utiles pour les applications Swing est disponible dans la section "Swing Key Bindings" sur le site http://www-128.ibm.com/developerworks/java/jdk/additional/
|En plus de l'interface graphique, l'outil iKeyman fournit l'outil |de ligne de commande IKEYCMD, qui a les mêmes fonctions que l'interface |graphique iKeyman. IKEYCMD permet de gérer les clés, certificats et demandes de certificats. Vous pouvez appeler IKEYCMD à partir des scripts de shell natifs et à partir des programmes destinés à être utilisés lorsque les applications requièrent des interfaces personnalisées pour les tâches de gestion de certificats et de clés. IKEYCMD peut créer des fichiers de base de données de clés pour tous les |types actuellement pris en charge par iKeyman. IKEYCMD peut également créer des demandes de certificats, importer des certificats signés par CA et gérer les certificats auto-signés.
Pour exécuter une commande IKEYCMD, entrez :
java [-Dikeycmd.properties=<properties file>]com.ibm.gsk.ikeyman.ikeycmd <object> <action> [options]
où :
Pour plus d'informations, consultez le guide utilisateur d'iKeyman accessible à l'adresse : http://www.ibm.com/developerworks/java/jdk/security/index.html.
Si vous passez la boîte à liste déroulante d'un composant JComboBox avec les touches fléchées, le bouton ou le champ éditable de la zone de liste déroulante ne change pas de valeur tant qu'un élément n'est pas sélectionné. Ce comportement est voulu pour cette version. Il améliore l'accessibilité et augmente la facilité d'utilisation en garantissant que le comportement de passage par clavier soit identique à celui du passage par souris.
IBM Java Web Start Version 5.0 comporte plusieurs améliorations de l'accessibilité et de la facilité d'utilisation par rapport à la version précédente, qui incluent notamment une meilleure prise en charge des lecteurs d'écran et une navigation par clavier améliorée.
La ligne de commande peut uniquement être utilisée pour lancer une application Java activée pour Web Start. Pour modifier les options des préférences, vous devez éditer le fichier de configuration .java/.deployment/.deployment.properties situé dans le répertoire initial de l'utilisateur. Pensez à effectuer une sauvegarde avant de modifier ce fichier. Toutes les préférences pouvant être définies dans l'afficheur de cache de l'application Java ne sont pas disponibles dans le fichier de configuration.
Vous pouvez obtenir des fichiers de règles de compétence illimitée JCE à l'adresse http://www.ibm.com/developerworks/java/jdk/security/index.html. La documentation sur les packages de sécurité IBM JCE, JCEFIPS, JSSE2, JSSEFIPS, JGSS, JAAS et la cryptographie du matériel est également disponible sur ce site Web.
Prenez en compte ces restrictions dans IBM 32-bit SDK pour Windows, v5.0 :
Vos commentaires sur ce guide utilisateur nous sont très utiles. Si vous avez des remarques ou des suggestions à formuler sur notre documentation, veuillez nous les transmettre. Vous pouvez nous envoyer vos questions "non techniques" ou tout commentaire relatif à notre documentation. Veuillez nous envoyer vos commentaires :
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.
Le présent document peut contenir des informations ou des références concernant certains produits, logiciels ou services IBM non annoncés dans ce pays. Pour plus de détails, référez-vous aux documents d'annonce disponibles dans votre pays, ou adressez-vous à votre partenaire commercial IBM. Toute référence à un produit, logiciel ou service IBM n'implique pas que seul ce produit, logiciel ou service puisse être utilisé. Tout autre élément fonctionnellement équivalent peut être utilisé, s'il n'enfreint aucun droit d'IBM. Il est de la responsabilité de l'utilisateur d'évaluer et de vérifier lui-même les installations et applications réalisées avec des produits, logiciels ou services non expressément référencés par IBM.
IBM peut détenir des brevets ou des demandes de brevet couvrant les produits mentionnés dans le présent document. La remise de ce document ne vous donne aucun droit de licence sur ces brevets ou demandes de brevet. Vous pouvez envoyer, par écrit, vos demandes de renseignements relatives aux licences au :
IBM EMEA Director of Licensing IBM Europe Middle-East Africa Tour Descartes La Défense 5 2, avenue Gambetta 92066 - Paris-La Défense CEDEX France
Pour le Canada, veuillez adresser votre courrier à :
IBM Director of Commercial Relations IBM Canada Ltd. 3600 Steeles Avenue East Markham, Ontario L3R 9Z7 Canada
Les informations sur les licences concernant les produits utilisant un jeu de caractères double octet peuvent être obtenues par écrit à l'adresse suivante :
Le paragraphe suivant ne s'applique ni au Royaume-Uni, ni dans aucun autre pays dans lequel il serait contraire aux lois locales.
LE PRESENT DOCUMENT EST LIVRE EN L'ETAT. IBM DECLINE TOUTE RESPONSABILITE, EXPLICITE OU IMPLICITE, RELATIVE AUX INFORMATIONS QUI Y SONT CONTENUES, Y COMPRIS EN CE QUI CONCERNE LES GARANTIES DE VALEUR MARCHANDE OU D'ADAPTATION A VOS BESOINS. Certaines juridictions n'autorisent pas l'exclusion des garanties implicites, auquel cas l'exclusion ci-dessus ne vous sera pas applicable.
Le présent document peut contenir des inexactitudes ou des coquilles. Il est mis à jour périodiquement. Chaque nouvelle édition inclut les mises à jour. IBM peut modifier sans préavis les programmes et les logiciels qu'il décrit.
Les références à des sites Web non IBM sont fournies à titre d'information uniquement et n'impliquent en aucun cas une adhésion aux données qu'ils contiennent. Les éléments figurant sur ces sites Web ne font pas partie des éléments du présent produit IBM et l'utilisation de ces sites relève de votre seule responsabilité.
IBM pourra utiliser ou diffuser, de toute manière qu'elle jugera appropriée et sans aucune obligation de sa part, tout ou partie des informations qui lui seront fournies.
Les licenciés souhaitant obtenir des informations permettant : (i) l'échange des données entre des logiciels créés de façon indépendante et d'autres logiciels (dont celui-ci), et (ii) l'utilisation mutuelle des données ainsi échangées, doivent adresser leur demande à :
Ces informations peuvent être soumises à des conditions particulières, prévoyant notamment le paiement d'une redevance.
Le logiciel sous licence décrit dans ce document et tous les éléments sous licence disponibles s'y rapportant sont fournis par IBM conformément aux termes du Contrat sur les produits et services IBM, des Conditions internationales d'utilisation des logiciels IBM ou de tout autre accord équivalent.
Les données de performance indiquées dans ce document ont été déterminées dans un environnement contrôlé. Par conséquent, les résultats peuvent varier de manière significative selon l'environnement d'exploitation utilisé. Certaines mesures évaluées sur des systèmes en cours de développement ne sont pas garanties sur tous les systèmes disponibles. En outre, elles peuvent résulter d'extrapolations. Les résultats peuvent donc varier. Il incombe aux utilisateurs de ce document de vérifier si ces données sont applicables à leur environnement d'exploitation.
Les informations concernant des produits non IBM ont été obtenues auprès des fournisseurs de ces produits, par l'intermédiaire d'annonces publiques ou via d'autres sources disponibles. IBM n'a pas testé ces produits et ne peut confirmer l'exactitude de leurs performances ni leur compatibilité. Elle ne peut recevoir aucune réclamation concernant des produits non IBM. Toute question concernant les performances de produits non IBM doit être adressée aux fournisseurs de ces produits.
Java, ainsi que tous les marques et logos incluant Java, sont des marques de Sun Microsystems, Inc. aux Etats-Unis et/dans certains autres pays.
D'autres sociétés sont propriétaires des autres marques, noms de produits ou logos qui pourraient apparaître dans ce document.
Le présent produit est également partiellement basé sur le logiciel FreeType Project. Pour plus d'informations sur FreeType, consultez le site suivant : http://www.freetype.org.
Le présent produit comprend des logiciels développés par la société Apache Software Foundation (http://www.apache.org/).