Jak mogę zmienić domyślną maszynę wirtualną Java w systemie Mac OS zwróconą z / usr / libexec / java_home

108

(Nie byłem pewien, czy to powinno trwać SU ... migracja jest z pewnością opcją, ale więcej programistów czyta tutaj pytania, więc tutaj idzie).

Używam systemu Mac OS X 10.8.4 i mam zainstalowany JDK 1.6.0_51 firmy Apple oraz JDK 1.7.0_25 firmy Oracle. Niedawno zainstalowałem JDK w wersji zapoznawczej Oracle 1.8 dla niektórych programów w wersji wstępnej, które tego wymagają. Teraz, kiedy uruchamiam / usr / libexec / java_home, otrzymuję to:

$ /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

Wspaniały.

Jednak bieganie:

$ java -version

Zwroty:

java version "1.8.0-ea"

Oznacza to, że domyślną wersją Javy jest obecnie wersja przedpremierowa, która psuje niektóre „normalne” pakiety (w moim przypadku VisualVM).

Nie mogę ustawić, JAVA_HOMEponieważ uruchamianie aplikacji ignoruje zmienne środowiskowe, nawet podczas uruchamiania z wiersza poleceń (np $ open /Applications/VisualVM.app.).

Czy jest więc plik, który mogę edytować, w którym mogę globalnie ustawić preferencje porządkowania maszyny JVM ?

(Proszę nie mówić mi, żebym uruchamiał panel preferencji Java, ponieważ to po prostu nie działa: nie zawiera niczego przydatnego i zawiera tylko jedną z 4 maszyn JVM, które zainstalowałem).

Aktualizacja :

Maszyny JVM firmy Oracle mieszkają w /Library/Java/JavaVirtualMachines. jdk1.8.0.jvm.xyzZmiana nazwy katalogu JDK 1.8 na niczego nie zmienia: java_homenadal znajduje go we właściwym miejscu, a uruchomienie / usr / bin / java nadal wykonuje JVM 1.8. Nie jest to problem z linkami synchronizacyjnymi itp.

Odpowiedzi na podobne pytania

Chociaż ta odpowiedź jest równoznaczna z włamaniem, które usunie wersje Javy z przechwytywania przez java_home, nadal nie odpowiada na pytanie, w jaki sposób java_home wybiera swoje domyślne ustawienie i czy użytkownicy mogą je ustawić w sposób nieniszczący .

Christopher Schultz
źródło
Wpisz „which java” i postępuj zgodnie z menu nawigacyjnym. /usr/bin/javato tylko symboliczne łącze
Brian Roach
11
Byłem tam, zrobiłem to. /usr/bin/javawskazuje na /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java. VersionsKatalog nie zawiera dowiązania do 1.8.0 JDK. Zamiast tego zawiera katalog o użytecznej nazwie, Aktóry Currentwskazuje na. Anie jest "JAVA_HOME. Ma podkatalog o nazwie, Commandsktóry ma javapolecenie, ale jest to nieprzezroczysty uniwersalny plik binarny, który robi, kto-wie-co. Podejrzewam, że używa java_homeitp., aby zdecydować, którego JVM użyć."
Christopher Schultz
2
Jeśli to nie jest na temat, przeprowadź migrację zamiast zamykania. FWIW, chodzi o „narzędzia programowe powszechnie używane przez programistów”, więc zamknięcie „nie na temat” jest nieszczere.
Christopher Schultz
Tak, to frustrujące! Chcę tylko jednego JDK dla wszystkich, a może dwóch, które mogę łatwo przełączać między 1.7 a 1.8.
Brian
1
Znalazłem tę odpowiedź SO przydatną w przypadku tego pytania: stackoverflow.com/a/44169445/2987755
dkb

Odpowiedzi:

89

Myślę, że JAVA_HOMEto najlepsze, co możesz zrobić. Narzędzia wiersza poleceń, takie jak javai javacbędą respektować tę zmienną środowiskową, możesz użyć /usr/libexec/java_home -v '1.7*'do podania odpowiedniej wartości do wprowadzenia JAVA_HOME, aby narzędzia wiersza poleceń używały języka Java 7.

export JAVA_HOME="`/usr/libexec/java_home -v '1.7*'`"

Ale standardowe pakiety aplikacji, które można kliknąć dwukrotnie, w ogóle nie używają pakietów JDK zainstalowanych poniżej /Library/Java. .appPakiety w starym stylu korzystające z Apple JavaApplicationStubbędą używać Java 6 firmy Apple /System/Library/Frameworks, a pakiety w nowym stylu utworzone za pomocą AppBundler bez dołączonego środowiska JRE będą używać „publicznego” środowiska JRE /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home- jest to na stałe zakodowane w kodzie pośredniczącym i nie można go zmienić, oraz nie można mieć zainstalowanych dwóch różnych publicznych środowisk JRE w tym samym czasie.


Edycja: przyjrzałem się konkretnie VisualVM, zakładając, że używasz wersji „pakietu aplikacji” ze strony pobierania , a ta konkretna aplikacja nie jest aplikacją AppBundler, zamiast tego jej głównym plikiem wykonywalnym jest skrypt powłoki, który wywołuje numer innych skryptów powłoki i odczytuje różne pliki konfiguracyjne. Domyślnie wybiera najnowszy JDK z/Library/Java pakiet o ile jest to wersja 7u10 lub nowsza, lub używa języka Java 6, jeśli instalacja oprogramowania Java 7 to aktualizacja 9 lub starsza. Ale po rozwikłaniu logiki w skryptach powłoki wydaje mi się, że można określić konkretny JDK za pomocą pliku konfiguracyjnego.

Utwórz plik tekstowy ~/Library/Application Support/VisualVM/1.3.6/etc/visualvm.conf(zastąp 1.3.6 dowolną wersją programu VisualVM, którego używasz) zawierający wiersz

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

a to zmusi go do wybrania Java 7 zamiast 8.

Ian Roberts
źródło
Wydaje się, że nie ma to miejsca w moim systemie. Uruchomienie VisualVM przed zainstalowaniem JDK 1.8 działało. Po JDK1.8 VisualVM pokazuje ekran powitalny, a następnie umiera. Przeniesienie katalogu JDK1.8 z / Library / Java przywraca jego zdolność do działania.
Christopher Schultz
@ChristopherSchultz Zajrzałem do pakietu VisualVM i okazało się, że nie jest to zwykła aplikacja Appbundler. Zobacz moją zmianę, aby poznać możliwe obejście.
Ian Roberts
Przepraszam, napisałem mój poprzedni komentarz przed twoją edycją. Sprawdzę, czy VisualVM działa przy użyciu tej techniki, ale jest mało prawdopodobne, aby miał uniwersalne zastosowanie. Mam kilka innych programów opartych na Javie, które uruchamiam, jak również Eclipse, JasperReports iReport itp., Na które może to wpłynąć. Myślę, że wolałbym po prostu przenieść katalog JDK1.8 w inne miejsce i użyć tego jawnie z JAVA_HOME przez (kilka) razy, kiedy go faktycznie potrzebuję.
Christopher Schultz
1
Tak, masz rację, JAVA_HOMEto najlepszy sposób i ogólnie najlepiej jest określić wersję pomocniczą, której potrzebujesz w innych przypadkach. Opierając się na demontaż, okaże się to możliwe export JAVA_VERSION=1.7, aby java_homedomyślnie wyświetlał JKD7 zamiast JDK8, ale przerwy java_home -v 1.6ponieważ java-homeinterpretuje ją jako dodatkowe ograniczenia i rezygnuje z powodu wzajemnie unsatisfiable ograniczeń, a potem po prostu idzie z domyślnego 1.8 nawet z --failfastopcją.
andrewdotn
2
Nie mogę zrozumieć, dlaczego Panel sterowania Java w Preferencjach systemowych nie tylko przedstawia listę do wyboru, zamiast uciekać się do skryptów / poleceń powłoki. Podejrzewam, że to tylko dla apletów, które działają w przeglądarce ...
JGFMK
51

Ja też tam byłem i wszędzie szukałem sposobu /usr/libexec/java_home szukałem działa, ale nie mogłem znaleźć żadnych informacji o tym, jak określa dostępne wirtualne maszyny Java, które wyświetla.

Trochę eksperymentowałem i myślę, że po prostu wykonuje a, ls /Library/Java/JavaVirtualMachinesa następnie sprawdza./<version>/Contents/Info.plist wszystkie znalezione tam środowiska wykonawcze.

Następnie sortuje je malejąco według kluczaJVMVersion zawartego w Info.plist i domyślnie używa pierwszego wpisu jako domyślnej maszyny JVM.

Myślę, że jedyne, co możemy zrobić, to zmienić plistę: sudo vi /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Info.plista następnie zmodyfikować JVMVersion z 1.8.0na coś innego, co spowoduje, że sortuje ją do dołu zamiast do góry, na przykład !1.8.0.

Coś jak:

<?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' -->`

a potem magicznie znika z góry listy:

/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

Teraz musisz się wylogować / zalogować, a następnie:

java -version
java version "1.7.0_45"

:-)

Oczywiście nie mam pojęcia, czy coś się teraz psuje lub czy wersja Java 1.8.0-ea nadal działa poprawnie.

Prawdopodobnie nie powinieneś tego robić, a zamiast tego po prostu odinstalować 1.8.0.

Jak dotąd jednak to zadziałało.

void256
źródło
To zadziałało dla mnie. Musiałem użyć tej poprawki, aby wtyczka Idea Sbt działała dla mnie na MacOS. Wspominam o tym na moim blogu agilebuild.blogspot.com/2014/02/...
antoine
To działa, ale wydaje się trochę skomplikowane i może nie wyglądać jak standardowa procedura operacyjna. Wędruję, jeśli jest lepsze podejście.
Weibo Li
Nadal chciałbym znaleźć rozwiązanie, ale aby ustawić JDK dla Intellij, dodałem to do mojego zshenv: export IDEA_JDK = /usr/libexec/java_home -v 1.7. Myślę, że zrobię to samo dla JAVA_HOME ...
David Resnick
Udaje mi się użyć tej odpowiedzi, aby uniknąć używania Java 9 do uruchamiania aplikacji z podwójnym kliknięciem (z powodu problemu w eksploratorze Keystore Store). Dzięki!
Nicolas Henneaux
2
Fragment z Instalacji JDK i JRE w systemie macOS : po zainstalowaniu oprogramowania Java dla macOS 2012-006 /usr/bin/javaznajdzie najnowszy zainstalowany pakiet JDK i użyje go do wszystkich narzędzi wiersza poleceń związanych z Javą w programie /usr/bin.
Jeremy Kao
7

To całkiem proste. Powiedzmy, że mamy to w naszym folderze JavaVirtualMachines:

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

Wyobraź sobie, że 1.8 jest naszym domyślnym, po prostu dodajemy nowy folder (na przykład „stary”) i przenosimy domyślny folder jdk do tego nowego folderu. Zrób java -versionponownie et voila, 1.7!

Użytkownik404
źródło
1
Niewiarygodne, ale zadziałało ... Dzięki Mac OS Mojave
Michał Dobi Dobrzański
5

To całkiem proste, jeśli nie masz nic przeciwko zakasaniu rękawów ... / Library / Java / Home jest domyślnym dla JAVA_HOME, a to tylko link wskazujący na jeden z:

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

Chciałem więc zmienić moją domyślną wersję JVM / JDK bez zmiany zawartości JAVA_HOME ... / Library / Java / Home to standardowa lokalizacja dla obecnej JVM / JDK i to właśnie chciałem zachować ... wydaje mi się być najłatwiejszym sposobem zmiany rzeczy przy jak najmniejszych skutkach ubocznych.

To naprawdę proste. Aby zmienić wersję java, którą widzisz za pomocą java -version, wszystko, co musisz zrobić, to jej wersja:

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

Nie poświęciłem czasu, ale bardzo prosty skrypt powłoki, który wykorzystuje / usr / libexec / java_home i ln do zmiany powyższego linku symbolicznego, powinien być głupi łatwy do stworzenia ...

Po zmianie miejsca / Library / Java / Home ... otrzymasz poprawny wynik:

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)
jrypkahauer
źródło
1
To nie tak działa: /Library/Java/Homejest rzeczywiście dowiązaniem symbolicznym, ale wskazuje na to, /System/Library/Frameworks/JavaVM.framework/Homektóre samo w sobie znajduje się w dużej mieszaninie dowiązań symbolicznych, które w końcu prowadzą do ... magicznego polecenia, które określa właściwe środowisko JRE do uruchomienia. Zauważ, że /usr/libexec/java_homerównież łączy się z tą magią. Możesz więc przerwać wszystko, zastępując dowiązania symboliczne i wskazując pojedyncze środowisko JRE, ale za każdym razem będziesz musiał to aktualizować. Najwyraźniej nie ma takiego polecenia set_preferred_jvm_versionani czegoś podobnego.
Christopher Schultz
1
Zaletą tej techniki jest jednak to, że nie wymaga ona JAVA_HOMEnigdzie ustawiania . Bawię się tą techniką, aby sprawdzić, czy spowoduje to uruchomienie programów opartych na języku Java z „preferowaną” maszyną wirtualną Java. Podejrzewam, że tak, ale jest dość delikatny.
Christopher Schultz
Cóż, w dzisiejszych czasach mam to w .bash_profile:export JAVA_HOME=`/usr/libexec/java_home -v 12`
jrypkahauer
Nie działa to w przypadku dwukrotnego kliknięcia ikony, o co w pewnym sensie chodziło. Rozwiązania, które działają tylko z wiersza poleceń, nie są ... rozwiązaniami.
Christopher Schultz
3

U mnie zadziałały instrukcje dotyczące odinstalowywania oprogramowania Oracle dla oprogramowania Java 7 .

Fragment:

Odinstalowanie JDK Aby odinstalować pakiet JDK, musisz mieć uprawnienia administratora i wykonać polecenie usuwania jako root lub za pomocą narzędzia sudo (8).

Przejdź do / Library / Java / JavaVirtualMachines i usuń katalog, którego nazwa pasuje do następującego formatu: *

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

Na przykład, aby odinstalować 7u6:

% rm -rf jdk1.7.0_06.jdk

duma
źródło
2
To pytanie nie dotyczyło odinstalowania ... chodziło o wybranie "podstawowej" maszyny JVM z zainstalowanych ...
Christopher Schultz
3

Trochę późno, ale ponieważ jest to ciągły problem w systemie Mac OSX ...

Najprostszym rozwiązaniem, jakie znalazłem, było po prostu usunięcie elementów OpenJDK, które instaluje Apple. Za każdym razem, gdy pojawia się aktualizacja systemu Mac OSX, jest ona instalowana i należy ją ponownie usunąć.

Działa to naprawdę dobrze, jeśli tworzysz aplikacje dla Google App Engine na komputerze Mac przy użyciu języka Java. OpenJDK nie działa dobrze, a wersja Java, która jest dostarczana z uaktualnieniem Mac OSX Yosemite, spowoduje awarię wtyczki Eclipse dla App Engine przy każdym wdrożeniu z pomocnym błędem: „Przekroczono limit czasu odczytu”.

Mo'in Creemers
źródło
1
Zabawne ... Myślałem, że w tym momencie Apple całkowicie usunęło Javę. Nie pamiętam ręcznego usuwania JVM Java 1.6 firmy Apple i na pewno już jej tu nie ma. W każdym razie nie rozwiązuje to tak naprawdę pierwotnego problemu, jakim było określenie preferowanej maszyny JVM, biorąc pod uwagę wybór, który został zainstalowany.
Christopher Schultz,
Masz rację. Nie odpowiada na pytanie. Odpowiada na to: jeśli usuniesz używaną maszynę JVM, zostanie użyta następna z listy. Może to pomoże.
Mo'in Creemers
czy to wyjaśnia, dlaczego po uruchomieniu instalacji jdk 8 nie pojawia się ona w folderze JavaVirtualMachines? Wszystko co widzę to „1.6.0.jdk” bez względu na zainstalowaną wersję.
whyoz
@whyoz Właśnie zainstalowałem jdk-8u31-macosx-x64 na osx 10.10.2, a maszyna wirtualna została zainstalowana w folderze JavaVirtualMachines zgodnie z oczekiwaniami.
Mo'in Creemers
Czy prowadzisz Parallels przez przypadek? Zainstalowałem go po stronie Windows Parallels i 8u31 zainstalowałem zgodnie z oczekiwaniami ... tylko nie po stronie Maca ..
Whyoz
3

Testowałem "jenv" i inne rzeczy, takie jak ustawienie "JAVA_HOME" bez powodzenia. Teraz ja i kończę na następującym rozwiązaniu

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
}

(dodane do ~ / .bashrc lub ~ / .bash.profile lub ~ / .zshrc)

I tak dzwonię:

setJava 1.8

java_home obsłuży błędne dane wejściowe. więc nie możesz zrobić czegoś złego. Maven i inne rzeczy wybiorą teraz właściwą wersję.

Yuna Braska
źródło
1

Właściwie przyjrzałem się temu trochę w deasemblerze, ponieważ źródło nie jest dostępne.

/ usr / bin / java i / usr / libexec / java_home korzystają z JavaLaunching.framework. Zmienna środowiskowa JAVA_HOME jest rzeczywiście najpierw sprawdzana przez / usr / bin / java i znajomych (ale nie przez / usr / libexec / java_home). Framework wykorzystuje zmienne środowiskowe JAVA_VERSION i JAVA_ARCH do filtrowania dostępnych maszyn JVM. Tak więc domyślnie:

$ /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

Ale ustawienie, powiedzmy, JAVA_VERSION może zastąpić ustawienie domyślne:

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

Możesz również ustawić JAVA_LAUNCHER_VERBOSE = 1, aby wyświetlić dodatkowe rejestrowanie debugowania, takie jak ścieżki wyszukiwania, znalezione maszyny JVM itp., Zarówno z / usr / bin / java, jak i / usr / libexec / java_home.

W przeszłości JavaLaunching.framework faktycznie używał systemu preferencji (w domenie com.apple.java.JavaPreferences), aby ustawić preferowaną kolejność JVM, umożliwiając ustawienie domyślnej maszyny JVM za pomocą PlistBuddy - ale najlepiej, jak mogę powiedzieć, że kod został usunięty w najnowszych wersjach systemu macOS. Zmienne środowiskowe wydają się być jedynym sposobem (poza edytowaniem Info.plist w samych pakietach JDK).

Ustawienie domyślnych zmiennych środowiskowych można oczywiście wykonać poprzez plik .profile lub przez launchd , jeśli trzeba, ustawić je na poziomie sesji.

Dan Walters
źródło
To świetna informacja, Dan. Używanie .profilenie jest przydatne w moim przypadku użycia (uruchamianie aplikacji np. Z launchpada), ale wskazówka launchdjest dobra. Będę musiał spróbować, ponieważ niedawne szaleństwo w zakresie wersjonowania Javy oznacza, że ​​mam kilka generacji Javy zainstalowanych jednocześnie, z różnymi poziomami (osobistego) zaufania.
Christopher Schultz
-2

Edycja: ta informacja jest przeznaczona specjalnie dla VisualVM, a nie dla żadnej innej aplikacji Java

Jak wspominali inni, musisz zmodyfikować plik visualvm.conf

W najnowszej wersji JvisualVM 1.3.6 na komputerach Mac katalogi instalacyjne uległy zmianie.

Obecnie znajduje się w /Applications/VisualVM.app/Contents/Resources/visualvm/etc/visualvm.conf .

Jednak może to zależeć od tego, gdzie zainstalowano VisualVM. Najłatwiejszym sposobem znalezienia miejsca, w którym znajduje się Twój VisualVM, jest uruchomienie go, a następnie przyjrzenie się temu procesowi za pomocą:

ps -ef | grep VisualVM

Zobaczysz coś takiego:

... -Dnetbeans.dirs = / Applications / VisualVM.app / Contents / Resources / visualvm / visualvm ...

Chcesz wziąć właściwość netbeans.dir i poszukać katalogu, a znajdziesz folder etc.

Odkomentuj ten wiersz w pliku visualvm.conf i zmień ścieżkę do jdk

visualvm_jdkhome="/path/to/jdk"

Dodatkowo, jeśli masz powolne działanie swojego visualvm i masz dużo pamięci, sugerowałbym znaczne zwiększenie ilości dostępnej pamięci i uruchomienie jej w trybie serwera:

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"
Celandro
źródło
Zła rada: modyfikacja skryptu startowego dla określonej aplikacji prawdopodobnie zepsuje aplikację i nie rozwiąże pierwotnego problemu zmiany domyślnej maszyny JVM dla systemu operacyjnego.
Christopher Schultz
Niestety, jak wspominali inni, jvisualvm nie używa standardowych metod wyboru jvm. To jedyne rozwiązanie dla tej aplikacji.
Celandro,
Jak stwierdzam w mojej odpowiedzi , nie musisz niczego modyfikować w samym pakiecie aplikacji, aplikacja może załadować swoją konfigurację z pliku ~/Library/Application Support/VisualVM/1.3.6/etc/visualvm.conf.
Ian Roberts,
-2

Miałem podobną sytuację i następujący proces zadziałał dla mnie:

  1. W terminalu wpisz

    vi ~/.profile
  2. Następnie dodaj tę linię do pliku i zapisz

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

    gdzie wersja to ta na komputerze, na przykład 1.7.0_25

  3. Wyjdź z edytora, a następnie wpisz następujące polecenie, aby stało się skuteczne

    source ~/.profile 

Następnie wpisz java -version, aby sprawdzić wynik

    java -version 

Co to jest .profile? Od: http://computers.tutsplus.com/tutorials/speed-up-your-terminal-workflow-with-command-aliases-and-profile--mac-30515

Plik .profile jest plikiem ukrytym. Jest to opcjonalny plik, który informuje system, które polecenia mają zostać uruchomione, gdy zaloguje się użytkownik, którego plik profilu to jest. Na przykład, jeśli moja nazwa użytkownika to bruno, aw katalogu / Users / bruno / znajduje się plik .profile, cała jego zawartość zostanie wykonana podczas logowania.

Tony
źródło
To nie zadziała podczas uruchamiania VisualVM z Launchpada. Uruchamianie z wiersza poleceń nigdy nie stanowi problemu, ponieważ można ustawić zmienną środowiskową JAVA_HOME.
Christopher Schultz,
-2

MacOS używa / usr / libexec / java_home do znalezienia aktualnej wersji Java. Jednym ze sposobów na ominięcie jest zmiana pliku plist, jak wyjaśniono powyżej w @ void256. Innym sposobem jest wykonanie kopii zapasowej java_home i zastąpienie jej własnym skryptem java_home z kodem
echo $ JAVA_HOME

Teraz wyeksportuj JAVA_HOME do żądanej wersji SDK, dodając następujące polecenia do ~ / .bash_profile. export JAVA_HOME = "/ System / Library / Java / JavaVirtualMachines / 1.6.0.jdk / Contents / Home" launchctl setenv JAVA_HOME $ JAVA_HOME /// Ustaw zmienną środowiskową na globalną

Uruchom polecenie source ~ / .bash_profile, aby uruchomić powyższe polecenia.

Za każdym razem, gdy trzeba zmienić JAVA_HOME, można zresetować wartość JAVA_HOME w pliku ~ / .bash_profile.

Rajat
źródło
Wszystko, co opiera się na zmiennych środowiskowych, nie zadziała. Chodzi o to, że aplikacje uruchamiane przez LaunchPad itp. Nie będą miały takiej konfiguracji środowiska. Powyższy hack plist wydaje się być „najlepszym”, ponieważ faktycznie zapewnia pożądany rezultat. Nie jestem jeszcze pewien żadnych wad. Zobacz odpowiedź od @Tony, która ma ten sam problem.
Christopher Schultz
-3

Chciałem zmienić domyślną wersję java z 1.6 * na 1.7 *. Wypróbowałem następujące kroki i zadziałało:

  • Usunięto link „java” z katalogu / usr / bin
  • Utworzono go ponownie, wskazując nową lokalizację:

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

  • zweryfikowano za pomocą „wersji java”

wersja java „1.7.0_51”
Java (TM) SE Runtime Environment (kompilacja 1.7.0_51-b13)
Java HotSpot (TM) 64-bitowa maszyna wirtualna serwera (wersja 24.51-b03, tryb mieszany)

user2756423
źródło
Nie odpowiada na pytanie: nie wpłynie to na zachowanie /usr/libexec/java_home.
Christopher Schultz,