Les versions récentes de libc corrigent un bogue qui en cachait un autre dans la version GNU de make (le symptôme en est que make ne cherche plus les règles dans les Makefile). Un patch corrigeant ce problème est inclus dans la distribution 5.2.8 de libc.
dirname: too many arguments
Votre variable d'environnement CLASSPATH n'est pas initialisée correctement. Dans le fichier .java_wrapper, on trouve quelques lignes ressemblant à :
PRG=`which $0`
J_HOME=`dirname $PRG`/..
Malheureusement, la commande which généralement fournie avec Linux est horriblement défectueuse et certains shells risquent d'affecter à $0 le chemin complet. Selon Randy Chapman, la solution est d'utiliser soit~:
J_HOME=`dirname $0`/..
soit, de façon plus sûre~:
J_HOME=/usr/local/java
Un autre correctif, proposé par Dave Dittrich, est :
PRG=`csh -c "which $0"`
Quant à Tim Farnum, il propose de changer la ligne PRG=`which $0` en~:
PRG=$0
Lutz Behnke, enfin, suggère~:
PRG=`type -path $0` >/dev/null 2>&1
Une modification similaire doit être appliquée au script d'appletviewer.
cannot find class java/lang/Thread
Votre variable d'environnement CLASSPATH n'est pas initialisée correctement. Voir plus haut.
Passez root et faites un chmod 666 /dev/zero
.
Il peut arriver que votre écran se remplisse de messages d'erreurs, que le système remplisse joyeusement votre mémoire virtuelle, puis se bloque.
Dans ce cas, il vous manque probablement une bibliothèque quelque part. Lancez ldconfig -v et regardez ce qu'il manque. Il est également possible que les variables d'environnement LD_LIBRARY_PATH ou CLASSPATH ne soient pas positionnées. Enfin, il se trouve que certaines applets sont boguées et bloquent le JDK Linux (il y a d'ailleurs un moyen d'éviter le blocage en ayant un autre xterm dans lequel tourne top. Il suffit alors d'utiliser top pour tuer le processus java AVANT qu'il remplisse la mémoire virtuelle et bloque le système).
Java semble nécessiter d'importantes ressources. Il est donc conseillé de restreindre au maximum le nombre d'applications ouvertes ou qui s'exécutent. Il parvient à se charger sur un 486DX-2-75 avec 8 Mo de RAM et 16 Mo de swap (cela prend tout de même une minute). L'auteur a ainsi réussi à faire tourner deux applets animées simultanément (ou à peu près) avant que le système se retrouve à court de mémoire virtuelle et se bloque.
Vous avez oublié des paramètres de la ligne de commande.
Une erreur classique ayant cette conséquence est d'associer aux applets un type MIME incorrect. Votre serveur doit renvoyer
avec l'applet un en-tête indiquant qu'elle est du type MIME text/plain
, application/octet-stream
ou tout autre type
pour lequel le client ne dispose pas d'un module de traitement spécial. La manière de remédier à cela
dépend du serveur que vous utilisez.
(John Franks)
Il semble également que tinyhttpd
, un serveur HTTP écrit en Perl, renvoie un content type
incorrect.
Apache, en revanche, semble fonctionner relativement correctement.
Selon Joey Oravec, HotJava conserve un fichier de traces des actions qu'il accomplit et des éventuels problèmes qu'il rencontre. Si vous devez établir un diagnostic par vous-même, examinez le fichier $HOME/.hotjava/weblog, dans le répertoire racine de l'utilisateur. Ce fichier vous permettra de repérer plus aisément s'il vous manque une bibliothèque ou s'il s'agit d'un problème similaire.
Chapitre suivant, Chapitre Précédent
Table des matières de ce chapitre, Table des matières générale
Début du document, Début de ce chapitre