web-dev-qa-db-fra.com

Problème lors du changement de version de Java avec des alternatives

Je ne sais pas trop comment je me suis retrouvé dans ce pétrin, mais pour une raison quelconque, je ne suis pas en mesure de modifier la version actuelle de Java à l'aide d'alternatives. Je peux exécuter des alternatives --config Java et taper ma sélection, mais lorsque le numéro de version de Java ou de javac est répercuté, il revient à la version 1.5 à chaque fois (même si la version actuelle est 1.6). Au fait, le serveur sur lequel je travaille exécute RHEL5.

J'ai vérifié que les chemins utilisés dans les alternatives pointaient vers les bons répertoires. Voici quelques résultats de ma session:

[brilewis @ myserver] $ Sudo/usr/sbin/update-alternatives --config Java

Il y a 3 programmes qui fournissent 'Java'.

Commande de sélection

** 1 /usr/lib/jvm/jre-1.4.2-gcj/bin/Java
+ 2 /usr/Java/jdk1.5.0_10/bin/Java
3 /usr/Java/jdk1.6.0_16/bin/Java

Entrez pour conserver la sélection actuelle [+] ou tapez le numéro de sélection: 3

[brilewis @ myserver] $ Java -version

Version Java "1.5.0_10" Environnement d'exécution Java (TM) 2, Standard Edition (version 1.5.0_10-b03) Serveur Java HotSpot (TM) VM (version 1.5.0_10-b03, mode mixte)

[brilewis @ myserver] $ Sudo/usr/sbin/update-alternatives --config Java

Il y a 3 programmes qui fournissent 'Java'.

Commande de sélection

** 1 /usr/lib/jvm/jre-1.4.2-gcj/bin/Java
2 /usr/Java/jdk1.5.0_10/bin/Java
+ 3 /usr/Java/jdk1.6.0_16/bin/Java

Entrez pour conserver la sélection actuelle [+] ou tapez le numéro de la sélection:

UPDATE: Ce qui suit est la sortie de echo $PATH:

/usr/Java/jdk1.5.0_10/bin:/usr/local/Apache-ant-1.7.1/bin:/usr/local/Apache-Tomcat-6.0.24:/usr/kerberos/bin:/usr/ local/bin:/bin:/usr/bin:/usr/NX/bin:/home/brilewis/bin

UPDATE (26/04/10): J'ai suivi la suggestion de Bert et supprimé Java_HOME de la variable d'environnement PATH dans/etc/profile. Après cela, j’ai pu utiliser des alternatives pour changer la version de Java. Le seul problème est que lorsque j'essaie d'exécuter javac, j'obtiens "-bash: javac: command not found". Cela ne se produit pas lorsque la version est définie sur 1.5.

javarhel5
14
Brian

La seule façon pour moi de résoudre le problème a été de recommencer en supprimant/var/lib/alternatives/Java et en réinstallant chaque JDK. J'ai fait la même chose pour javac et jar. Après cela, j'ai pu passer d'une version à l'autre sans aucun problème.

3
Brian

Pour Oracle Java 6u30, une fois que vous avez installé leurs RPM, vous pouvez configurer des alternatives:

/usr/sbin/alternatives --install "/usr/bin/Java" "Java" "/usr/Java/default/bin/Java" 2 \
--slave /usr/bin/javac javac /usr/Java/default/bin/javac \
--slave /usr/bin/javadoc javadoc /usr/Java/default/bin/javadoc \
--slave /usr/bin/jar jar /usr/Java/default/bin/jar \
--slave /usr/bin/keytool keytool /usr/Java/default/bin/keytool \
--slave /usr/bin/orbd orbd /usr/Java/default/bin/orbd \
--slave /usr/bin/pack200 pack200 /usr/Java/default/bin/pack200 \
--slave /usr/bin/rmid rmid /usr/Java/default/bin/rmid \
--slave /usr/bin/rmiregistry rmiregistry /usr/Java/default/bin/rmiregistry \
--slave /usr/bin/servertool servertool /usr/Java/default/bin/servertool \
--slave /usr/bin/tnameserv tnameserv /usr/Java/default/bin/tnameserv \
--slave /usr/bin/unpack200 unpack200 /usr/Java/default/bin/unpack200 \
--slave /usr/share/man/man1/Java.1.gz Java.1.gz /usr/Java/default/man/man1/Java.1.gz \
--slave /usr/share/man/man1/keytool.1.gz keytool.1.gz /usr/Java/default/man/man1/keytool.1.gz \
--slave /usr/share/man/man1/orbd.1.gz orbd.1.gz /usr/Java/default/man/man1/orbd.1.gz \
--slave /usr/share/man/man1/pack200.1.gz pack200.1.gz /usr/Java/default/man/man1/pack200.1.gz \
--slave /usr/share/man/man1/rmid.1.gz rmid.1.gz /usr/Java/default/man/man1/rmid.1.gz \
--slave /usr/share/man/man1/rmiregistry.1.gz rmiregistry.1.gz /usr/Java/default/man/man1/rmiregistry.1.gz \
--slave /usr/share/man/man1/servertool.1.gz servertool.1.gz /usr/Java/default/man/man1/servertool.1.gz \
--slave /usr/share/man/man1/tnameserv.1.gz tnameserv.1.gz /usr/Java/default/man/man1/tnameserv.1.gz \
--slave /usr/share/man/man1/unpack200.1.gz unpack200.1.gz /usr/Java/default/man/man1/unpack200.1.gz

Activez ensuite la configuration:

/usr/sbin/alternatives --config Java

Et sélectionnez/usr/Java/default/bin/Java dans le menu.

De plus, vous devez gzip les pages de manuel

gzip /usr/Java/default/man/man1/*.1

De plus, les RPM Oracle Java peuvent avoir masqué votre lien symbolique alternatif, alors forcez-le à devenir normal.

ln -sf /etc/alternatives/Java /usr/bin/Java
32
user783522

Je peux modifier le code Java par défaut sur CentOS en procédant comme suit:

  1. Ajoutez le JDK IBM:

    alternatives --install /usr/bin/Java java /opt/WebSphere/AppServer/Java/bin/Java 3

  2. Définissez le nouveau JDK IBM par défaut:

    alternatives --config Java   (then select #3 in the list)

  3. Tapez Java -version à l'invite pour voir le résultat.

6
djangofan

alternatives fonctionne en modifiant un lien symbolique dans le répertoire /usr/bin. Toutefois, si votre chemin contient un exécutable valide précédemment, il sera utilisé à la place.

Dans ce cas, à en juger par vos commentaires précédents, il semble que /usr/Java/jdk1.5.0_10/bin se trouve quelque part dans le chemin et devrait être supprimé.

Pour un shell BASH, le chemin est généralement défini dans ~/.bashrc ou (moins probable?) ~/.bash_profile

3
Powerlord

Mis à jour avec plus d'explications

  1. Vérifiez quel exécutable Java est réellement en cours d'exécution, par exemple.

    $ type Java

    Si cela montre autre chose que /usr/bin/Java, alors vous avez probablement un JRE/JDK spécifique codé en dur dans votre chemin. Cela convient, mais vous ne pourrez pas utiliser les versions Java modifiées en utilisant des alternatives RH pour tout compte qui codera en dur un JRE/JDK spécifique dans sa PATH de cette manière. Toutefois, les autres packages/comptes (processus système, par exemple) qui ne codent pas dans le chemin une version spécifique du JDK utilisent le JRE alternatives-spécifié.

  2. Vérifiez votre variable d'environnement Java_HOME, par exemple.

    $ echo $Java_HOME

    Si cette option est définie, le fichier exécutable Java sera parfois dirigé vers un JRE/JDK différent, quel que soit l'emplacement de l'exécutable Java. Là encore, il n'est pas inhabituel de définir cela, mais vous ne pourrez pas utiliser les versions Java modifiées à l'aide d'alternatives RH pour les comptes codant en dur un Java_HOME différent.

Cela dit, pour le développement de mon compte, je règle normalement un JDK spécifique dans mon chemin et java_HOME pour qu'il pointe vers un JDK spécifique, plutôt que de me fier aux paramètres système. RH alternatives convient parfaitement pour contrôler la version Java utilisée par d’autres packages, mais pour mon propre développement, j’aime cibler explicitement le Java que je souhaite utiliser.

1
Bert F

Lorsque vous utilisez la méthode alternatives, si vous souhaitez utiliser une alternative, vous devez d'abord l'installer. Je crois que les RPM incluraient cela dans le cadre de l'installation, mais dans le cas où des installations manuelles sont effectuées, vous pouvez toujours les installer manuellement. Par exemple, avec Java,

alternatives --install "/usr/bin/Java" "Java" "/usr/Java/example/bin/Java" \
 --slave /usr/bin/javac javac /usr/Java/example/bin/javac \
 ...

Ce que cela fait est d'installer une alternative pour le lien symbolique Java. Pour chaque esclave, il crée/met également à jour le lien symbolique avec une autre valeur spécifiée dans une autre alternative, lorsque vous le basculez. Donc, si vous deviez passer à une version différente de Java à l'aide d'alternatives, et que l'alternative spécifie un esclave pour javac, javac se référera également à la nouvelle version.

Ma liste complète est la suivante:

alternatives --install /usr/bin/Java java /usr/Java/<version>/bin/Java 1500 \
  --slave /usr/bin/ControlPanel ControlPanel /usr/Java/<version>/jre/bin/ControlPanel \
   --slave /usr/bin/jar jar /usr/Java/<version>/bin/jar \
   --slave /usr/bin/javac javac /usr/Java/<version>/bin/javac \
   --slave /usr/bin/javaws javaws /usr/Java/<version>/bin/javaws \
   --slave /usr/bin/jcontrol jcontrol /usr/Java/<version>/bin/jcontrol \
   --slave /usr/bin/keytool keytool /usr/Java/<version>/bin/keytool \
   --slave /usr/bin/orbd orbd /usr/Java/<version>/bin/orbd \
   --slave /usr/bin/pack200 pack200 /usr/Java/<version>/bin/pack200 \
   --slave /usr/bin/policytool policytool /usr/Java/<version>/bin/policytool \
   --slave /usr/bin/rmid rmid /usr/Java/<version>/bin/rmid \
   --slave /usr/bin/rmiregistry rmiregistry /usr/Java/<version>/bin/rmiregistry \
   --slave /usr/bin/servertool servertool /usr/Java/<version>/bin/servertool \
   --slave /usr/bin/tnameserv tnameserv /usr/Java/<version>/bin/tnameserv \
   --slave /usr/bin/unpack200 unpack200 /usr/Java/<version>/bin/unpack200 \
   --slave /usr/share/man/man1/Java.1 Java.1 /usr/Java/<version>/man/man1/Java.1  \ 
   --slave /usr/share/man/man1/javac.1 javac.1 /usr/Java/<version>/man/man1/javac.1  \ 
   --slave /usr/share/man/man1/javaws.1 javaws.1 /usr/Java/<version>/man/man1/javaws.1  \ 
   --slave /usr/share/man/man1/keytool.1 keytool.1 /usr/Java/<version>/man/man1/keytool.1  \ 
   --slave /usr/share/man/man1/orbd.1 orbd.1 /usr/Java/<version>/man/man1/orbd.1  \ 
   --slave /usr/share/man/man1/pack200.1 pack200.1 /usr/Java/<version>/man/man1/pack200.1  \ 
   --slave /usr/share/man/man1/policytool.1 policytool.1 /usr/Java/<version>/man/man1/policytool.1  \ 
   --slave /usr/share/man/man1/rmid.1 rmid.1 /usr/Java/<version>/man/man1/rmid.1  \ 
   --slave /usr/share/man/man1/rmiregistry.1 rmiregistry.1 /usr/Java/<version>/man/man1/rmiregistry.1  \ 
   --slave /usr/share/man/man1/servertool.1 servertool.1 /usr/Java/<version>/man/man1/servertool.1  \ 
   --slave /usr/share/man/man1/tnameserv.1 tnameserv.1 /usr/Java/<version>/man/man1/tnameserv.1  \ 
   --slave /usr/share/man/man1/unpack200.1 unpack200.1 /usr/Java/<version>/man/man1/unpack200.1

J'espère que cela t'aides.

0
WingsOfPain