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


108

(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 .


Tapez 'which java' et suivez le fil d'Ariane. /usr/bin/javaest juste un lien symbolique
Brian Roach

11
J'y suis allé, j'ai fait ça. /usr/bin/javapointe vers /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java. Le Versionsrépertoire ne contient pas de lien symbolique vers le JDK 1.8.0. Au lieu de cela, il contient un répertoire appelé utilement Aqui Currentpointe vers. An'est pas un "JAVA_HOME. Il a un sous-répertoire appelé Commandsqui a une javacommande, mais c'est un binaire universel opaque qui fait qui-sait-quoi. Je soupçonne qu'il utilise java_home, etc. pour décider quelle JVM utiliser.
Christopher Schultz

2
Si cela est hors sujet, veuillez migrer au lieu de fermer. FWIW, il s'agit des "outils logiciels couramment utilisés par les programmeurs", donc fermer "hors sujet" est malhonnête.
Christopher Schultz

Oui, c'est frustrant! Je veux juste un JDK pour tous, ou peut-être 2 que je peux facilement basculer entre 1.7 et 1.8.
Brian

1
J'ai trouvé cette réponse SO utile pour cette question: stackoverflow.com/a/44169445/2987755
dkb

Réponses:


89

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.


Cela ne semble pas être le cas sur mon système. Le lancement de VisualVM avant l'installation de JDK 1.8 fonctionnait. Après JDK1.8, VisualVM affiche l'écran de démarrage, puis meurt. Le déplacement du répertoire JDK1.8 hors de / Library / Java restaure sa capacité à s'exécuter.
Christopher Schultz

@ChristopherSchultz J'ai jeté un coup d'œil à l'intérieur du bundle VisualVM et il s'avère que ce n'est pas une application appbundler normale. Voir ma modification pour une solution de contournement possible.
Ian Roberts du

Désolé, j'ai écrit mon commentaire précédent avant votre modification. Je vais vérifier que VisualVM s'exécute en utilisant cette technique, mais il est peu probable qu'il soit universellement applicable. J'ai un tas d'autres logiciels basés sur Java que je lance aussi comme Eclipse, JasperReports iReport, etc. qui sont tous susceptibles d'être affectés par cela. Je pense que je préfère simplement déplacer le répertoire JDK1.8 ailleurs et l'utiliser explicitement avec JAVA_HOME pour les (quelques) fois où j'en ai réellement besoin.
Christopher Schultz

1
Oui, vous avez raison, JAVA_HOMEc'est la voie à suivre et en général, votre meilleur pari est de spécifier la version mineure dont vous avez besoin dans les autres cas. Sur la base du désassemblage, il s'avère que vous pouvez export JAVA_VERSION=1.7utiliser java_homepar défaut JKD7 au lieu de JDK8, mais cela se rompt java_home -v 1.6car l' java-homeinterprète comme une contrainte supplémentaire et abandonne en raison de contraintes mutuellement insatisfaisables, puis va simplement avec la valeur par défaut 1.8 même avec l' --failfastoption.
andrewdotn

2
Je ne peux pas comprendre pourquoi le panneau de configuration Java des préférences système ne présente pas seulement une liste de sélection, plutôt que de devoir recourir à des scripts / commandes shell. Je soupçonne que ce n'est que pour les applets qui fonctionnent dans le navigateur ...
JGFMK

51

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.


Cela a fonctionné pour moi. J'ai dû utiliser ce réglage pour que le plugin Idea Sbt fonctionne pour moi sur MacOS. Je le mentionne sur mon blog agilebuild.blogspot.com/2014/02/…
antoine

Cela fonctionne mais cela semble un peu délicat et peut ne pas ressembler à une procédure d'opération standard. J'erre s'il y a une meilleure approche.
Weibo Li

J'aimerais toujours une solution pour cela, mais pour configurer le JDK pour Intellij à utiliser, j'ai ajouté ceci à mon zshenv: export IDEA_JDK = /usr/libexec/java_home -v 1.7. Je pense que je vais faire de même pour JAVA_HOME ...
David Resnick

J'arrive à utiliser cette réponse pour éviter d'utiliser Java 9 en lançant des applications double-clic (en raison d'un problème dans l'explorateur Keystore Store). Merci!
Nicolas Henneaux

2
Un extrait de l' installation du JDK et du JRE sur macOS : après avoir installé Java pour macOS 2012-006, /usr/bin/javatrouvera le dernier JDK installé et l'utilisera pour tous les outils de ligne de commande liés à Java dans /usr/bin.
Jeremy Kao

7

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!


1
Incroyable, mais cela a fonctionné ... Merci Mac OS Mojave
Michał Dobi Dobrzański

5

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)

1
Ce n'est pas comme ça que ça fonctionne: /Library/Java/Homec'est en effet un lien symbolique, mais il pointe vers /System/Library/Frameworks/JavaVM.framework/Homelequel se trouve un gros fouillis de liens symboliques qui vous amène finalement à ... une commande magique qui détermine le bon JRE à lancer. Notez que cela est /usr/libexec/java_homeégalement lié à cette magie. Ainsi, vous pouvez tout interrompre en remplaçant simplement les liens symboliques et en pointant vers un seul JRE, mais vous devrez le mettre à jour à chaque fois. Il n'y a évidemment pas de commande similaire set_preferred_jvm_versionou quelque chose de similaire.
Christopher Schultz

1
L'avantage de cette technique, cependant, est qu'elle ne vous oblige pas à définir JAVA_HOMEn'importe où. Je vais jouer avec cette technique pour voir si elle aboutira au lancement de programmes basés sur Java avec la machine virtuelle Java "préférée". Je soupçonne que ce sera le cas, mais c'est assez fragile.
Christopher Schultz

Eh bien, ces jours-ci, j'ai juste ceci dans .bash_profile:export JAVA_HOME=`/usr/libexec/java_home -v 12`
jrypkahauer

Cela ne fonctionne pas pour un double-clic sur une icône, ce qui était un peu le point. Les solutions qui ne fonctionnent qu'à partir de la ligne de commande ne sont ... pas des solutions.
Christopher Schultz le

3

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


2
Cette question ne concernait pas la désinstallation ... il s'agissait de choisir la JVM "principale" parmi celles que l'on a installées ...
Christopher Schultz

3

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é».


1
Drôle ... Je pensais qu'Apple avait complètement supprimé Java à ce stade. Je ne me souviens pas avoir supprimé manuellement la JVM Java 1.6 d'Apple, et ce n'est définitivement plus là. En tout cas, cela ne résout pas vraiment le problème d'origine qui était de spécifier la JVM préférée étant donné une sélection qui a été installée.
Christopher Schultz

Vous avez raison. Cela ne répond pas à la question. Il répond à ceci: Si vous supprimez la JVM utilisée, la «suivante» de la liste est utilisée. Peut-être que cela aide.
Mo'in Creemers

cela explique-t-il pourquoi après avoir exécuté une installation de jdk 8, il n'apparaît pas dans le dossier JavaVirtualMachines? Tout ce que je vois est "1.6.0.jdk" quelle que soit la version que j'installe.
whyoz

@whyoz Je viens d'installer jdk-8u31-macosx-x64 sur osx 10.10.2 et la VM a été installée dans le dossier JavaVirtualMachines comme prévu.
Mo'in Creemers le

Utilisez-vous Parallels par hasard? Je l'ai installé du côté Windows de Parallels et 8u31 installé comme prévu..juste pas du côté Mac ..
whyoz

3

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.


1

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.


C'est une excellente information, Dan. L'utilisation .profilen'est pas utile pour mon cas d'utilisation (lancer une application à partir, par exemple, du tableau de bord), mais le conseil launchdest bon. Je vais devoir essayer, car la folie récente de la gestion des versions de Java signifie que plusieurs générations de Java sont installées simultanément, avec différents niveaux de confiance (personnelle).
Christopher Schultz

-2

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"

Mauvais conseil: la modification du script de démarrage pour une application particulière cassera probablement l'application et ne résoudra pas le problème d'origine de la modification de la JVM par défaut pour le système d'exploitation.
Christopher Schultz

Malheureusement, comme mentionné par d'autres, jvisualvm n'utilise pas de méthodes standard pour choisir un jvm. C'est la seule solution pour cette application.
Celandro

Comme je le dis dans ma réponse, vous n'avez pas besoin de modifier quoi que ce soit à l'intérieur du bundle d'applications lui-même, l'application peut charger sa configuration à partir de ~/Library/Application Support/VisualVM/1.3.6/etc/visualvm.conf.
Ian Roberts

-2

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.


Cela ne fonctionnera pas lors du lancement de VisualVM à partir du Launchpad. Le lancement à partir de la ligne de commande n'est jamais un problème, car vous pouvez définir la variable d'environnement JAVA_HOME.
Christopher Schultz

-2

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.


Tout ce qui repose sur des variables d'environnement ne fonctionnera pas. Le fait est que les applications lancées via LaunchPad, etc. n'auront pas cette configuration environnementale. Le hack plist ci-dessus semble être le "meilleur" en ce sens qu'il atteint réellement le résultat souhaité. Je ne suis pas encore sûr des inconvénients. Voir la réponse de @Tony qui a le même problème.
Christopher Schultz

-3

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)


Ne répond pas à la question: cela n'affectera pas le comportement de /usr/libexec/java_home.
Christopher Schultz
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.