web-dev-qa-db-fra.com

Comment puis-je modifier la valeur par défaut de Java VM de Mac OS renvoyée par / usr / libexec / Java_home

(Je ne savais pas si cela devrait continuer avec le SU ... la migration est certainement une option, mais davantage de programmeurs lisent les questions ici, alors c'est comme ça).

J'utilise Mac OS X 10.8.4 et le JDK 1.6.0_51 d'Apple est installé, ainsi que le JDK 1.7.0_25 d'Oracle. J'ai récemment installé le JDK d'aperçu 1.8 d'Oracle pour certains logiciels de pré-version le nécessitant. Maintenant, quand je lance/usr/libexec/Java_home, je reçois ceci:

$ /usr/libexec/Java_home -V
Matching Java Virtual Machines (4):
    1.8.0, x86_64:  "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
    1.7.0_25, x86_64:   "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home
    1.6.0_51-b11-457, x86_64:   "Java SE 6" /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
    1.6.0_51-b11-457, i386: "Java SE 6" /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home

Génial.

Cependant, en cours d'exécution:

$ Java -version

Résultats:

Java version "1.8.0-ea"

Cela signifie que la version par défaut de Java est actuellement la version préliminaire qui rompt certains packages "normaux" (dans mon cas, VisualVM).

Je ne peux pas définir Java_HOME parce que le lancement d'applications ignore les variables d'environnement, même lors du lancement à partir de la ligne de commande (par exemple $ open /Applications/VisualVM.app).

Alors, y a-t-il un fichier que je peux éditer et où je peux définir mes préférences de commande JVM globalement ?

(Ne me dites pas de lancer le panneau de préférences Java parce que cela ne fonctionne tout simplement pas: il ne contient rien d’utile et ne répertorie que l’un des 4 ordinateurs JVM que j’ai installés.)

Mise à jour :

Les JVM Oracle résident dans /Library/Java/JavaVirtualMachines. Renommer le répertoire JDK 1.8 en jdk1.8.0.jvm.xyz ne change rien: Java_home le trouve toujours au bon endroit et l'exécution de/usr/bin/Java exécute toujours la JVM 1.8. Ce n'est pas un problème avec les liens, etc.

Réponses à des questions similaires

Bien que cette réponse propose ce qui revient à un hack qui empêchera les versions de Java d'être captées par Java_home, il ne répond toujours pas à cette question de Comment Java_home choisit sa valeur par défaut et indique si les utilisateurs peuvent ou non la définir de manière non destructive .

javamacosjava-home
100
Christopher Schultz

Je pense que Java_HOME est ce que vous pouvez faire de mieux. Les outils de ligne de commande tels que Java et javac respecteront cette variable d’environnement. Vous pouvez utiliser /usr/libexec/Java_home -v '1.7*' pour vous donner une valeur appropriée à mettre dans Java_HOME afin de créer une commande. les outils en ligne utilisent Java 7.

export Java_HOME="`/usr/libexec/Java_home -v '1.7*'`"

Mais les bundles d'applications standard double-cliquables n'utilisent pas du tout les JDK installés sous /Library/Java. Les ensembles .app à l'ancienne utilisant JavaApplicationStub d'Apple utiliseront Apple Java 6 de /System/Library/Frameworks, et les nouveaux styles construits avec AppBundler sans un JRE fourni utilisera le JRE "public" dans /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home - codé en dur dans le code de raccord et ne peut pas être modifié, et vous ne pouvez pas installer deux JRE publics différents installés à le même temps.

Edit: j’ai jeté un œil à VisualVM en particulier, en supposant que vous utilisiez la version "application bundle" de la page de téléchargement , et que cette application particulière ne soit pas une application AppBundler, mais que son exécutable principal est un script Shell qui appelle plusieurs autres scripts Shell et lit divers fichiers de configuration. Il choisit par défaut le dernier JDK dans /Library/Java tant qu'il s'agit de 7u10 ou plus, ou utilise Java 6 si votre installation Java 7 est mise à jour 9 ou antérieure. Mais si je décrypte la logique dans les scripts du shell, il me semble que vous pouvez spécifier un JDK particulier à l’aide d’un fichier de configuration.

Créez un fichier texte ~/Library/Application Support/VisualVM/1.3.6/etc/visualvm.conf (remplacez 1.3.6 par la version de VisualVM que vous utilisez) contenant la ligne

visualvm_jdkhome="`/usr/libexec/Java_home -v '1.7*'`"

et cela le forcera à choisir Java 7 au lieu de 8.

85
Ian Roberts

J'y suis allé aussi et j'ai cherché partout comment /usr/libexec/Java_home fonctionne, mais je n'ai trouvé aucune information sur la façon dont il détermine les Java machines virtuelles disponibles répertoriées.

J'ai un peu expérimenté et je pense qu'il exécute simplement un ls /Library/Java/JavaVirtualMachines puis inspecte le ./<version>/Contents/Info.plist de tous les temps d'exécution qu'il trouve là-bas.

Il les trie ensuite décroissant à l'aide de la clé JVMVersion contenue dans Info.plist et utilise par défaut la première entrée comme JVM par défaut.

Je pense que la seule chose que nous puissions faire est de changer le plist: Sudo vi /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Info.plist puis de modifier la version JVMVersion de 1.8.0 en un autre élément qui le fait trier vers le bas au lieu de la partie supérieure, comme !1.8.0.

Quelque chose comme:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.Apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    ...
    <dict>
            ...
            <key>JVMVersion</key>
            <string>!1.8.0</string>   <!-- changed from '1.8.0' to '!1.8.0' -->`

et puis, comme par magie, il disparaît du haut de la liste:

/usr/libexec/Java_home -verbose
Matching Java Virtual Machines (3):
    1.7.0_45, x86_64:   "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home
    1.7.0_09, x86_64:   "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home
    !1.8.0, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home

Maintenant, vous devrez vous déconnecter/vous connecter, puis:

Java -version
Java version "1.7.0_45"

:-)

Bien entendu, je ne sais pas si quelque chose d'autre se casse maintenant ou si la version 1.8.0-ea de Java fonctionne toujours correctement.

Vous ne devriez probablement pas faire cela, mais simplement désinstaller la 1.8.0.

Cependant, jusqu'à présent, cela a fonctionné pour moi.

49
void256

C'est en fait assez facile. Disons que nous avons ceci dans notre dossier JavaVirtualMachines:

  • jdk1.7.0_51.jdk
  • jdk1.8.0.jdk

Imaginez que 1.8 soit notre valeur par défaut, alors nous ajoutons simplement un nouveau dossier (par exemple 'ancien') et déplaçons le dossier jdk par défaut vers ce nouveau dossier. Faites Java -version encore et voila, 1.7!

6
User404

Les les instructions de désinstallation pour Java 7 d’Oracle ont fonctionné pour moi.

Extrait:

Désinstallation du JDK Pour désinstaller le JDK, vous devez disposer des privilèges d'administrateur et exécuter la commande de suppression en tant qu'utilisateur root ou à l'aide de l'outil Sudo (8).

Accédez à/Library/Java/JavaVirtualMachines et supprimez le répertoire dont le nom correspond au format suivant: *

/Library/Java/JavaVirtualMachines/jdk<major>.<minor>.<macro[_update]>.jdk

Par exemple, pour désinstaller 7u6:

% rm -rf jdk1.7.0_06.jdk

5
duma

C'est assez simple, si cela ne vous dérange pas de vous retrousser les manches ... / Library/Java/Home est la valeur par défaut pour Java_HOME, et il ne s'agit que d'un lien pointant vers l'un des éléments suivants:

  • /System/Library/Java/JavaVirtualMachines/1.?.?.jdk/Contents/Home
  • /Library/Java/JavaVirtualMachines/jdk1.?.?_??.jdk/Contents/Home

Je voulais donc changer ma version par défaut de JVM/JDK sans changer le contenu de Java_HOME .../Library/Java/Home est l'emplacement standard de la JVM/JDK actuelle et c'est ce que je voulais préserver. ... il me semble que c'est le moyen le plus facile de changer les choses avec le moins d'effets secondaires.

C'est vraiment très simple. Afin de changer la version de Java que vous voyez avec la version Java, il vous suffit de faire une version de ceci:

cd /Library/Java
Sudo rm Home
Sudo ln -s /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home ./Home

Je n'ai pas pris le temps, mais un script Shell très simple qui utilise/usr/libexec/Java_home et ln pour republier le lien symbolique ci-dessus devrait être stupide facile à créer ...

Une fois que vous avez changé l'emplacement de/Library/Java/Home, vous obtenez le résultat correct:

cerebro:~ magneto$ Java -version
Java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27) Java HotSpot(TM)
64-Bit Server VM (build 25.60-b23, mixed mode)
5
jrypkahauer

Un peu tard, mais comme c'est un problème récurrent avec Mac OSX ...

La solution la plus simple que j'ai trouvée consistait simplement à supprimer le logiciel OpenJDK installé par Apple. Chaque fois qu'une mise à jour de Mac OSX arrive, elle est installée et vous devrez la supprimer à nouveau.

Cela fonctionne vraiment bien si vous développez des applications pour Google App Engine sur votre Mac en utilisant Java. OpenJDK ne fonctionne pas bien et la version Java fournie avec la mise à niveau Mac OSX Yosemite provoquera le blocage du plug-in Eclipse pour App Engine sur chaque déploiement avec l'erreur utile: "Lecture expirée".

4
Mo'in Creemers

J'ai testé "jenv" et d'autres choses telles que la définition de "Java_HOME" sans succès. Maintenant, je finis avec la solution suivante

function setJava {
    export Java_HOME="$(/usr/libexec/Java_home -v $1)"
    launchctl setenv Java_HOME $Java_HOME
    Sudo ln -nsf "$(dirname ${Java_HOME})/MacOS" /Library/Java/MacOS 
    Java -version
}

(ajouté à ~/.bashrc ou ~/.bash.profile ou ~/.zshrc)

Et en appelant comme ça:

setJava 1.8

Java_home gérera la mauvaise entrée. donc vous ne pouvez pas faire quelque chose de mal. Maven et d'autres trucs vont chercher la bonne version maintenant.

1
Yuna Braska