Mac OS'nin / usr / libexec / java_home'dan döndürülen varsayılan Java sanal makinesini nasıl değiştirebilirim

(Bunun SU'ya devam edip etmeyeceğinden emin değildim ... geçiş kesinlikle bir seçenektir, ancak daha fazla programcı burada soruları okur, işte burada devam eder).

Mac OS X 10.8.4 çalıştırıyorum ve Apple'ın JDK 1.6.0_51'i ve Oracle JDK 1.7.0_25'i kurdum. Yakın zamanda Oracle'ın 1.8 ön izleme JDK'sını, onu gerektiren bazı ön sürüm yazılımları için kurdum. Şimdi, / usr / libexec / java_home komutunu çalıştırdığımda şunu alıyorum:

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

Harika.

Ancak, koşuyor:

$ java -version

İadeler:

java version "1.8.0-ea"

Bu, Java'nın varsayılan sürümünün şu anda bazı "normal" paketleri (benim durumumda, VisualVM) bozan ön sürüm olduğu anlamına gelir.

Ayarlayamıyorum JAVA_HOMEçünkü uygulamaları başlatmak komut satırından başlatılırken bile ortam değişkenlerini yok sayıyor (örn. $ open /Applications/VisualVM.app).

Peki, genel olarak JVM sipariş tercihlerimi ayarlayabileceğim bir dosya var mı?

(Lütfen bana Java Tercihler Panelini başlatmamı söylemeyin çünkü bu işe yaramıyor: yararlı hiçbir şey içermiyor ve yalnızca yüklediğim 4 JVM'den birini listeliyor.)

Güncelleme :

Oracle JVM'ler yaşıyor /Library/Java/JavaVirtualMachines. JDK 1.8 dizininin olarak yeniden adlandırılması jdk1.8.0.jvm.xyzhiçbir şeyi değiştirmez: java_homeyine de doğru yerde bulur ve / usr / bin / java çalıştırmak 1.8 JVM'yi çalıştırmaya devam eder. Bu, senkronizasyon bağlantıları vb. İle ilgili bir sorun değildir.

Benzer Soruların Cevapları

İken bu cevap JAVA_HOME tarafından yakalandı olmaktan Java sürümlerini kaldırmak bir hack ne miktarda teklifler, hala bu soruya cevap vermez nasıl java_home onun varsayılan seçer ve kullanıcıların olup olmadığını olmayan yıkıcı ayarlayın .

Bence JAVA_HOMEyapabileceğinin en iyisi bu. Komut satırı araçları , bu ortam değişkenini sever javave javacbunlara saygı duyar, komut satırı araçlarının Java 7 kullanmasını /usr/libexec/java_home -v '1.7*'sağlamak için size koyabileceğiniz uygun bir değer vermek JAVA_HOMEiçin kullanabilirsiniz.

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

Ancak standart çift tıklanabilir uygulama paketleri, altında kurulu JDK'leri hiç kullanmaz /Library/Java. .appApple'ın kullanıldığı eski tarz paketler JavaApplicationStubApple Java 6'yı kullanacak /System/Library/Frameworksve AppBundler ile oluşturulmuş yeni stiller , paketlenmiş bir JRE olmadan "genel" JRE girişini kullanacaktır /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home- bu, saplama kodunda sabit kodlanmıştır ve değiştirilemez ve aynı anda iki farklı genel JRE'ye sahip olamazsınız.

Düzenleme: İndirme sayfasından "uygulama paketi" sürümünü kullandığınızı varsayarak ve bu belirli uygulamanın bir AppBundler uygulaması olmadığını, bunun yerine ana yürütülebilir dosyasının bir numara çağıran bir kabuk komut dosyası olduğunu varsayarak, özellikle VisualVM'ye bir göz attım diğer kabuk betikleri ve çeşitli yapılandırma dosyalarını okur. Varsayılan /Library/Javaolarak, 7u10 veya daha sonraki bir sürüm olduğu sürece en yeni JDK'yı seçer veya Java 7 yüklemeniz 9 veya daha önceki bir güncelleme ise Java 6'yı kullanır. Ancak kabuk komut dosyalarındaki mantığı çözmek bana, bir yapılandırma dosyası kullanarak belirli bir JDK belirtebileceğiniz gibi görünüyor.

~/Library/Application Support/VisualVM/1.3.6/etc/visualvm.confSatırı içeren bir metin dosyası oluşturun (1.3.6'yı kullandığınız VisualVM sürümüyle değiştirin)

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

ve bu onu 8 yerine Java 7'yi seçmeye zorlayacaktır.

Ben de orada bulundum ve nasıl /usr/libexec/java_homeçalıştığını her yerde araştırdım, ancak listelediği mevcut Java Sanal Makinelerini nasıl belirlediğine dair herhangi bir bilgi bulamadım.

Biraz deney yaptım ve sanırım basitçe a'yı çalıştırıyor ls /Library/Java/JavaVirtualMachinesve ./<version>/Contents/Info.plistorada bulduğu tüm çalışma zamanlarını inceliyor .

Daha sonra bunları Info.plist'te bulunan anahtara göre azalan sıralar JVMVersionve varsayılan olarak ilk girişi varsayılan JVM olarak kullanır.

Sanırım yapabileceğimiz tek şey sudo vi /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Info.plistplist'i değiştirmek : ve sonra JVMVersion'ı 1.8.0başka bir şeyden değiştirerek onu yukarıdan aşağıya doğru sıralayacak şekilde, örneğin !1.8.0.

Gibi bir şey:

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

ve sonra sihirli bir şekilde listenin başından kaybolur:

/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

Şimdi oturumu kapatmanız / oturum açmanız ve ardından:

java -version
java version "1.7.0_45"

:-)

Elbette şimdi başka bir şeyin bozulup bozulmadığını veya java'nın 1.8.0-ea sürümünün hala düzgün çalışıp çalışmadığını bilmiyorum.

Muhtemelen bunların hiçbirini yapmamalısınız, bunun yerine 1.8.0'ı kaldırın.

Ancak şimdiye kadar bu benim için çalıştı.

Aslında oldukça kolay. Diyelim ki JavaVirtualMachines klasörümüzde bu var:

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

Varsayılanımızın 1.8 olduğunu hayal edin, o zaman yeni bir klasör (örneğin 'eski') ekleyip varsayılan jdk klasörünü bu yeni klasöre taşıdık. Do java -version, ve işte yine 1.7!

Kollarınızı sıvamak için sakıncası yoksa oldukça basit ... / Library / Java / Home , JAVA_HOME için varsayılandır ve yalnızca şunlardan birine işaret eden bir bağlantıdır:

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

Ben JVM / JDK sürümünü benim varsayılan değiştirmek istedim Yani olmadan JAVA_HOME içeriğini değiştirerek ... / bana öyle geliyor ... Kütüphane / Java / Ev akımı JVM / JDK için standart konum olduğuna ve korumak istiyordum en az yan etkiyle işleri değiştirmenin en kolay yolu olmak.

Aslında gerçekten çok basit. Java -version ile gördüğünüz java sürümünü değiştirmek için tek yapmanız gereken bunun bir sürümü:

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

Zaman ayırmadım, ancak / usr / libexec / java_home ve ln'yi kullanarak yukarıdaki sembolik bağlantıyı yeniden oluşturmak için çok basit bir kabuk betiği oluşturmak aptalca olmalı ...

/ Library / Java / Home'un gösterildiği yeri değiştirdikten sonra ... doğru sonucu alırsınız:

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)

Oracle'ın Java 7 için kaldırma talimatları benim için çalıştı.

Alıntı:

JDK'yı Kaldırma JDK'yı kaldırmak için Yönetici ayrıcalıklarına sahip olmanız ve kaldırma komutunu kök olarak veya sudo (8) aracını kullanarak yürütmeniz gerekir.

/ Library / Java / JavaVirtualMachines'e gidin ve adı aşağıdaki formatla eşleşen dizini kaldırın: *

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

Örneğin, 7u6'yı kaldırmak için:

% rm -rf jdk1.7.0_06.jdk

Biraz geç ama bu Mac OSX ile devam eden bir sorun olduğu için ...

Bulduğum en basit çözüm, Apple'ın yüklediği OpenJDK öğelerini kaldırmaktı. Bir Mac OSX güncellemesi geldiğinde, yüklenir ve yeniden kaldırmanız gerekir.

Mac'inizde Java kullanarak Google App Engine için uygulamalar geliştirirseniz, bu gerçekten işe yarar. OpenJDK iyi çalışmıyor ve Mac OSX Yosemite yükseltmesiyle birlikte gelen Java sürümü, her dağıtımda App Engine için Eclipse Eklentisinin çökmesine neden olacak ve şu yararlı bir hata verecektir: "Okuma zaman aşımına uğradı".

"Jenv" i ve "JAVA_HOME" u ayarlamak gibi diğer şeyleri başarılı olmadan test ettim. Şimdi ben ve aşağıdaki çözümü ile bitiriyorum

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
}

(~ / .bashrc veya ~ / .bash.profile veya ~ / .zshrc'ye eklendi)

Ve böyle sesleniyor:

setJava 1.8

java_home yanlış girişi halledecektir. yani yanlış bir şey yapamazsınız. Maven ve diğer şeyler şimdi doğru sürümü alacak.

Aslında kaynak mevcut olmadığı için demonte makinesinde buna biraz baktım.

/ usr / bin / java ve / usr / libexec / java_home, JavaLaunching.framework kullanır. JAVA_HOME ortam değişkeni gerçekten ilk olarak / usr / bin / java ve arkadaşları tarafından kontrol edilir (ancak / usr / libexec / java_home değil.) Çerçeve, mevcut JVM'leri filtrelemek için JAVA_VERSION ve JAVA_ARCH ortam değişkenlerini kullanır. Yani, varsayılan olarak:

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

Ancak, diyelim ki JAVA_VERSION ayarı varsayılanı geçersiz kılabilir:

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

Ayrıca hem / usr / bin / java hem de / usr / libexec / java_home ile arama yolları, bulunan JVM'ler vb. Gibi bazı ek hata ayıklama günlüğünü görmek için JAVA_LAUNCHER_VERBOSE = 1'i ayarlayabilirsiniz.

Geçmişte JavaLaunching.framework, tercih edilen JVM sırasını ayarlamak için tercihler sistemini (com.apple.java.JavaPreferences etki alanı altında) kullandı ve varsayılan JVM'nin PlistBuddy ile ayarlanmasına izin verdi - ancak söyleyebileceğim en iyi şekilde, macOS'in son sürümlerinde kod kaldırılmıştır. Ortam değişkenleri tek yol gibi görünüyor (JDK paketlerindeki Info.plist'i düzenlemenin dışında).

Varsayılan ortam değişkenlerini ayarlamak, tabii ki .profiliniz aracılığıyla veya bir oturum düzeyinde ayarlanmaları gerekiyorsa launchd aracılığıyla yapılabilir .

Düzenleme: Bu bilgiler, başka herhangi bir java uygulaması için değil, özellikle visualvm içindir

Başkalarının da bahsettiği gibi, visualvm.conf'u değiştirmeniz gerekir

Mac'te JvisualVM 1.3.6'nın en son sürümü için yükleme dizinleri değişmiştir.

Şu anda /Applications/VisualVM.app/Contents/Resources/visualvm/etc/visualvm.conf içindedir. .

Ancak bu, VisualVM'yi nereye kurduğunuza bağlı olabilir. VisualVM'nizin nerede başlatıldığını bulmanın en kolay yolu ve ardından aşağıdakileri kullanarak işleme bakın:

ps -ef | grep VisualVM

Şöyle bir şey göreceksiniz:

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

Netbeans.dir özelliğini alıp bir dizine bakmak istiyorsunuz ve etc klasörünü bulacaksınız.

Visualvm.conf dosyasındaki bu satırın açıklamasını kaldırın ve jdk'ye giden yolu değiştirin

visualvm_jdkhome="/path/to/jdk"

Ek olarak, görsel sanal makinenizde yavaşlık yaşıyorsanız ve çok fazla belleğiniz varsa, mevcut bellek miktarını büyük ölçüde artırmanızı ve sunucu modunda çalıştırmanızı öneririm:

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"

Benzer bir durum yaşadım ve aşağıdaki süreç benim için çalıştı:

1. Terminalde yazın

   vi ~/.profile

2. Sonra bu satırı dosyaya ekleyin ve kaydedin

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

   1.7.0_25 gibi, bilgisayarınızda bulunan sürüm

3. Düzenleyiciden çıkın, ardından aşağıdaki komutu yazın ve etkili olmasını sağlayın

   source ~/.profile 

Ardından sonucu kontrol etmek için java -version yazın

    java -version 

.Profile nedir? From: http://computers.tutsplus.com/tutorials/speed-up-your-terminal-workflow-with-command-aliases-and-profile--mac-30515

.profile dosyası gizli bir dosyadır. Profil dosyası olan kullanıcı giriş yaptığında sisteme hangi komutların çalıştırılacağını söyleyen isteğe bağlı bir dosyadır. Örneğin kullanıcı adım bruno ise ve / Users / bruno / içinde bir .profile dosyası varsa, tüm içeriği oturum açma prosedürü sırasında yürütülecektir.

MacOS, mevcut Java Sürümünü bulmak için / usr / libexec / java_home kullanır. Atlamanın bir yolu, yukarıda @ void256 tarafından açıklandığı gibi plist dosyasını değiştirmektir. Diğer yollar, java_home'un yedeğini almak ve onu,
echo $ JAVA_HOME koduna sahip kendi java_home betiğinizle değiştirmektir.

Şimdi aşağıdaki komutları ~ / .bash_profile dosyasına ekleyerek JAVA_HOME'u istenen SDK sürümüne aktarın. dışa aktar JAVA_HOME = "/ Sistem / Kitaplık / Java / JavaVirtualMachines / 1.6.0.jdk / İçindekiler / Ana Sayfa" launchctl setenv JAVA_HOME $ JAVA_HOME /// Ortam değişkenini global yap

Yukarıdaki komutları çalıştırmak için ~ / .bash_profile komutunu çalıştırın.

JAVA_HOME'un değiştirilmesi gerektiğinde, ~ / .bash_profile dosyasındaki JAVA_HOME değerini sıfırlayabilir.

Varsayılan java sürüm formunu 1.6 * ile 1.7 * olarak değiştirmek istedim. Aşağıdaki adımları denedim ve benim için çalıştı:

• / Usr / bin altından "java" bağlantısı kaldırıldı
• Yeniden oluşturuldu ve yeni konuma işaret edildi:

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

• "java sürümü" ile doğrulandı

java "1.7.0_51" sürümü
Java (TM) SE Runtime Environment (derleme 1.7.0_51-b13)
Java HotSpot (TM) 64-Bit Sunucu VM (derleme 24.51-b03, karma mod)