Comment puis-je changer la machine virtuelle Java par défaut de Mac OS renvoyée par / usr / libexec / java_home

(Je ne savais pas si cela devait continuer avec SU ... la migration est certainement une option, mais plus de programmeurs lisent les questions ici, alors voici).

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 en pré-version qui en ont besoin. Maintenant, quand je lance / usr / libexec / java_home, j'obtiens 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

Retour:

java version "1.8.0-ea"

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

Je ne peux pas définir JAVA_HOMEcar 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 modifier dans lequel je peux définir mes préférences de commande JVM globalement ?

(Veuillez ne pas me dire de lancer le panneau de préférences Java car cela ne fonctionne tout simplement pas: il ne contient rien d'utile et ne répertorie qu'une des 4 JVM que j'ai installées.)

Mise à jour :

Les JVM Oracle vivent dans /Library/Java/JavaVirtualMachines. Renommer le répertoire JDK 1.8 en jdk1.8.0.jvm.xyzne change rien: le java_hometrouve 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 de synchronisation, etc.

Réponses à des questions similaires

Bien que cette réponse offre ce qui équivaut à un hack qui supprimera les versions de Java de la capture par java_home, elle ne répond toujours pas à cette question de savoir comment java_home choisit sa valeur par défaut et si les utilisateurs peuvent ou non le définir de manière non destructive .

Je pense que JAVA_HOMEc'est le mieux que vous puissiez faire. Les outils de ligne de commande aiment javaet javacrespecteront cette variable d'environnement, que vous pouvez utiliser /usr/libexec/java_home -v '1.7*'pour vous donner une valeur appropriée à insérer JAVA_HOMEafin que les outils de ligne de commande 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 .appbundles à l' ancienne utilisant Apple JavaApplicationStubutiliseront Apple Java 6 à partir de /System/Library/Frameworks, et ceux de style nouveau construits avec AppBundler sans JRE groupé utiliseront le JRE "public" dans /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home- qui est codé en dur dans le code stub et ne peut pas être modifié, et vous ne pouvez pas installer deux JRE publics différents en même temps.

Edit: J'ai jeté un coup d'œil à VisualVM en particulier, en supposant que vous utilisez la version "application bundle" de la page de téléchargement , et que cette application particulière n'est pas une application AppBundler, à la place son exécutable principal est un script shell qui appelle un numéro d'autres scripts shell et lit divers fichiers de configuration. Par défaut, il sélectionne le JDK le plus récent à partir /Library/Javade 7u10 ou version ultérieure, ou utilise Java 6 si votre installation Java 7 est la mise à jour 9 ou antérieure. Mais pour démêler la logique des scripts 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 la 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.

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

J'ai expérimenté un peu et je pense qu'il exécute simplement un ls /Library/Java/JavaVirtualMachines, puis inspecte ./<version>/Contents/Info.plisttous les runtimes qu'il y trouve.

Il les trie ensuite par ordre décroissant de la clé JVMVersioncontenue 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 pourrions faire est de changer le plist: sudo vi /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Info.plistpuis de modifier la JVMVersion de 1.8.0à quelque chose d'autre qui la fait trier vers le bas au lieu du haut, 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' -->`

puis il disparaît comme par magie 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

Vous devrez maintenant vous déconnecter / vous connecter, puis:

java -version
java version "1.7.0_45"

:-)

Bien sûr, je n'ai aucune idée si quelque chose d'autre casse maintenant ou si la version 1.8.0-ea de java fonctionne toujours correctement.

Vous ne devriez probablement rien faire de cela, mais simplement désinstaller 1.8.0.

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

C'est en fait assez simple. 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, puis 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 -versionnouveau et voila, 1.7!

C'est assez simple, si cela ne vous dérange pas de retrousser vos manches ... / Library / Java / Home est la valeur par défaut pour JAVA_HOME, et c'est juste un lien qui pointe vers l'un des:

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

J'ai donc voulu changer ma version JVM / JDK par défaut 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 être le moyen le plus simple de changer les choses avec le moins d'effets secondaires.

C'est en fait très simple. Pour changer la version de java que vous voyez avec java -version, tout ce que vous avez à faire est 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 rediriger le lien symbolique ci-dessus devrait être stupide et facile à créer ...

Une fois que vous avez changé l'endroit où / Library / Java / Home est pointé ... 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)

Les instructions de désinstallation d'Oracle pour Java 7 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 remove en tant que 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

Un peu tard mais comme il s'agit d'un problème persistant avec Mac OSX ...

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

Cela fonctionne très bien si vous développez des applications pour Google App Engine sur votre Mac à l'aide de Java. L'OpenJDK ne fonctionne pas bien et la version Java fournie avec la mise à niveau de Mac OSX Yosemite fera planter le plug-in Eclipse pour App Engine à chaque déploiement avec l'erreur utile: «Délai de lecture écoulé».

J'ai testé "jenv" et d'autres choses comme la configuration de "JAVA_HOME" sans succès. Maintenant je et 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 choses prendront la bonne version maintenant.

En fait, j'ai un peu regardé cela dans le désassembleur, car la source n'est pas disponible.

/ usr / bin / java et / usr / libexec / java_home utilisent tous deux JavaLaunching.framework. La variable d'environnement JAVA_HOME est en effet vérifiée d'abord par / usr / bin / java et ses amis (mais pas par / usr / libexec / java_home.) Le framework utilise les variables d'environnement JAVA_VERSION et JAVA_ARCH pour filtrer les JVM disponibles. Donc, par défaut:

$ /usr/libexec/java_home -V
Matching Java Virtual Machines (2):
    11.0.5, x86_64: "Amazon Corretto 11"    /Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home
    1.8.0_232, x86_64:  "Amazon Corretto 8" /Library/Java/JavaVirtualMachines/amazon-corretto-8.jdk/Contents/Home

/Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home

Mais la configuration, disons, JAVA_VERSION peut remplacer la valeur par défaut:

$ JAVA_VERSION=1.8 /usr/libexec/java_home
/Library/Java/JavaVirtualMachines/amazon-corretto-8.jdk/Contents/Home

Vous pouvez également définir JAVA_LAUNCHER_VERBOSE = 1 pour afficher une journalisation de débogage supplémentaire en ce qui concerne les chemins de recherche, les JVM trouvées, etc., avec à la fois / usr / bin / java et / usr / libexec / java_home.

Dans le passé, JavaLaunching.framework utilisait en fait le système de préférences (sous le domaine com.apple.java.JavaPreferences) pour définir l'ordre JVM préféré, permettant à la JVM par défaut d'être définie avec PlistBuddy - mais pour autant que je sache , cela le code a été supprimé dans les versions récentes de macOS. Les variables d'environnement semblent être le seul moyen (mis à part la modification du fichier Info.plist dans les ensembles JDK eux-mêmes).

La définition des variables d'environnement par défaut peut bien sûr être effectuée via votre .profile ou via launchd , si vous avez besoin qu'elles soient définies au niveau de la session.

Edit: ces informations sont pour visualvm spécifiquement, pas pour toute autre application java

Comme mentionné par d'autres, vous devez modifier le visualvm.conf

Pour la dernière version de JvisualVM 1.3.6 sur Mac, les répertoires d'installation ont changé.

Il se trouve actuellement dans /Applications/VisualVM.app/Contents/Resources/visualvm/etc/visualvm.conf .

Cependant, cela peut dépendre de l'endroit où vous avez installé VisualVM. Le moyen le plus simple de trouver où votre VisualVM est de le démarrer, puis d'examiner le processus en utilisant:

ps -ef | grep VisualVM

Vous verrez quelque chose comme:

... -Dnetbeans.dirs = / Applications / VisualVM.app / Contenu / Ressources / visualvm / visualvm ...

Vous voulez prendre la propriété netbeans.dir et rechercher un répertoire et vous trouverez le dossier etc.

Décommentez cette ligne dans le visualvm.conf et modifiez le chemin vers le jdk

visualvm_jdkhome="/path/to/jdk"

De plus, si vous avez de la lenteur avec votre visualvm et que vous avez beaucoup de mémoire, je suggère d'augmenter considérablement la quantité de mémoire disponible et de l'exécuter en mode serveur:

visualvm_default_options="-J-XX:MaxPermSize=96m -J-Xmx2048m -J-Xms2048m -J-server -J-XX:+UseCompressedOops -J-XX:+UseConcMarkSweepGC -J-XX:+UseParNewGC -J-XX:NewRatio=2 -J-Dnetbeans.accept_license_class=com.sun.tools.visualvm.modules.startup.AcceptLicense -J-Dsun.jvmstat.perdata.syncWaitMs=10000 -J-Dsun.java2d.noddraw=true -J-Dsun.java2d.d3d=false"

J'ai eu une situation similaire et le processus suivant a fonctionné pour moi:

1. Dans le terminal, tapez

   vi ~/.profile

2. Ajoutez ensuite cette ligne dans le fichier et enregistrez

   export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk<version>.jdk/Contents/Home

   où la version est celle de votre ordinateur, par exemple 1.7.0_25

3. Quittez l'éditeur, puis tapez la commande suivante pour qu'elle devienne effective

   source ~/.profile 

Tapez ensuite java -version pour vérifier le résultat

    java -version 

Qu'est-ce que .profile? De: http://computers.tutsplus.com/tutorials/speed-up-your-terminal-workflow-with-command-aliases-and-profile--mac-30515

Le fichier .profile est un fichier caché. C'est un fichier facultatif qui indique au système les commandes à exécuter lorsque l'utilisateur dont il est le fichier de profil se connecte. Par exemple, si mon nom d'utilisateur est bruno et qu'il y a un fichier .profile dans / Users / bruno /, tout son contenu sera exécuté pendant la procédure de connexion.

MacOS utilise / usr / libexec / java_home pour trouver la version Java actuelle. Une façon de contourner est de changer le fichier plist comme expliqué par @ void256 ci-dessus. Une autre façon est de prendre la sauvegarde de java_home et de le remplacer par votre propre script java_home ayant le code
echo $ JAVA_HOME

Exportez maintenant le JAVA_HOME vers la version souhaitée du SDK en ajoutant les commandes suivantes au ~ / .bash_profile. export JAVA_HOME = "/ System / Library / Java / JavaVirtualMachines / 1.6.0.jdk / Contents / Home" launchctl setenv JAVA_HOME $ JAVA_HOME /// Rendre la variable d'environnement globale

Exécutez la commande source ~ / .bash_profile pour exécuter les commandes ci-dessus.

Chaque fois que l'on a besoin de changer JAVA_HOME, il peut réinitialiser la valeur JAVA_HOME dans le fichier ~ / .bash_profile.

Je voulais changer le formulaire de version Java par défaut 1.6 * en 1.7 *. J'ai essayé les étapes suivantes et cela a fonctionné pour moi:

• Suppression du lien «java» sous / usr / bin
• Créé à nouveau, pointant vers le nouvel emplacement:

ln -s /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/bin/java java

• vérifié avec "java -version"

Java version "1.7.0_51"
Java (TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot (TM) 64 bits Server VM (build 24.51-b03, mode mixte)