Làm cách nào để thay đổi máy ảo Java mặc định của Mac OS được trả về từ / usr / libexec / java_home

(Không chắc liệu điều này có nên tiếp tục SU ... di chuyển chắc chắn là một lựa chọn, nhưng nhiều lập trình viên đọc câu hỏi ở đây, vì vậy hãy tiếp tục).

Tôi đang chạy Mac OS X 10.8.4 và tôi đã cài đặt JDK 1.6.0_51 của Apple cũng như JDK 1.7.0_25 của Oracle. Gần đây tôi đã cài đặt JDK bản xem trước 1.8 của Oracle cho một số phần mềm phát hành trước yêu cầu nó. Bây giờ, khi tôi chạy / usr / libexec / java_home, tôi nhận được:

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

Tuyệt quá.

Tuy nhiên, đang chạy:

$ java -version

Lợi nhuận:

java version "1.8.0-ea"

Điều đó có nghĩa là phiên bản mặc định của Java hiện là phiên bản phát hành trước, phiên bản này phá vỡ một số gói "bình thường" (trong trường hợp của tôi là VisualVM).

Tôi không thể đặt JAVA_HOMEvì khởi chạy ứng dụng bỏ qua các biến môi trường, ngay cả khi khởi chạy từ dòng lệnh (ví dụ $ open /Applications/VisualVM.app:).

Vì vậy, có tệp nào tôi có thể chỉnh sửa để đặt tùy chọn đặt hàng JVM trên toàn cầu không?

(Vui lòng không yêu cầu tôi khởi chạy Java Preferences Panel vì điều đó đơn giản là không hoạt động: nó không chứa bất kỳ thứ gì hữu ích và chỉ liệt kê một trong 4 JVM mà tôi đã cài đặt.)

Cập nhật :

Oracle JVM hiện có /Library/Java/JavaVirtualMachines. Đặt lại tên thư mục JDK 1.8 để jdk1.8.0.jvm.xyzkhông thay đổi bất cứ điều gì: java_homevẫn tìm thấy nó ở đúng vị trí và chạy / usr / bin / java vẫn thực hiện 1.8 JVM. Đây không phải là vấn đề với các liên kết đồng bộ, v.v.

Câu trả lời cho các câu hỏi tương tự

Mặc dù câu trả lời này đưa ra số tiền mà một cuộc tấn công sẽ loại bỏ các phiên bản Java khỏi java_home, nhưng nó vẫn không trả lời câu hỏi này về cách java_home chọn mặc định của nó và liệu người dùng có thể thiết lập nó không phá hủy hay không .

Tôi nghĩ đó JAVA_HOMElà điều tốt nhất bạn có thể làm. Các công cụ dòng lệnh thích javavà javacsẽ tôn trọng biến môi trường đó, bạn có thể sử dụng /usr/libexec/java_home -v '1.7*'để cung cấp cho mình một giá trị phù hợp để đưa vào JAVA_HOMEđể làm cho các công cụ dòng lệnh sử dụng Java 7.

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

Nhưng các gói ứng dụng có thể nhấp đúp tiêu chuẩn hoàn toàn không sử dụng JDK được cài đặt bên dưới /Library/Java. Các .appgói kiểu cũ sử dụng Apple JavaApplicationStubsẽ sử dụng Apple Java 6 /System/Library/Frameworksvà các gói kiểu mới được xây dựng với AppBundler mà không có JRE đi kèm sẽ sử dụng JRE "công khai" /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home- được mã hóa cứng trong mã sơ khai và không thể thay đổi được, và bạn không thể cài đặt hai JRE công khai khác nhau cùng một lúc.

Chỉnh sửa: Tôi đã xem xét cụ thể VisualVM, giả sử bạn đang sử dụng phiên bản "gói ứng dụng" từ trang tải xuống và ứng dụng cụ thể này không phải là ứng dụng AppBundler, thay vào đó tệp thực thi chính của nó là một tập lệnh shell gọi một số của các tập lệnh shell khác và đọc các tệp cấu hình khác nhau. Nó mặc định chọn JDK mới nhất /Library/Javamiễn là 7u10 trở lên hoặc sử dụng Java 6 nếu cài đặt Java 7 của bạn là bản cập nhật 9 trở lên. Nhưng làm sáng tỏ logic trong các tập lệnh shell đối với tôi, tôi thấy giống như bạn có thể chỉ định một JDK cụ thể bằng cách sử dụng tệp cấu hình.

Tạo một tệp văn bản ~/Library/Application Support/VisualVM/1.3.6/etc/visualvm.conf(thay thế 1.3.6 bằng bất kỳ phiên bản VisualVM nào bạn đang sử dụng) có chứa dòng

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

và điều này sẽ buộc nó phải chọn Java 7 thay vì 8.

Tôi cũng đã ở đó và tìm kiếm khắp nơi về cách thức /usr/libexec/java_homehoạt động nhưng tôi không thể tìm thấy bất kỳ thông tin nào về cách nó xác định Máy ảo Java có sẵn mà nó liệt kê.

Tôi đã thử nghiệm một chút và tôi nghĩ rằng nó chỉ đơn giản thực hiện một ls /Library/Java/JavaVirtualMachinesvà sau đó kiểm tra ./<version>/Contents/Info.plisttất cả các thời gian chạy mà nó tìm thấy ở đó.

Sau đó, nó sắp xếp chúng giảm dần theo khóa JVMVersioncó trong Info.plist và theo mặc định, nó sử dụng mục nhập đầu tiên làm JVM mặc định của nó.

Tôi nghĩ điều duy nhất chúng ta có thể làm là thay đổi plist: sudo vi /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Info.plistvà sau đó sửa đổi JVMVersion từ 1.8.0thành một thứ khác khiến nó sắp xếp nó xuống dưới cùng thay vì trên cùng, chẳng hạn như !1.8.0.

Cái gì đó như:

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

và sau đó nó biến mất khỏi đầu danh sách một cách kỳ diệu:

/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

Bây giờ bạn sẽ cần đăng xuất / đăng nhập và sau đó:

java -version
java version "1.7.0_45"

:-)

Tất nhiên tôi không biết liệu có thứ gì khác bị hỏng bây giờ hay không hoặc phiên bản 1.8.0-ea của java vẫn hoạt động bình thường.

Bạn có thể không nên làm bất kỳ điều gì trong số này mà thay vào đó chỉ cần gỡ cài đặt 1.8.0.

Tuy nhiên cho đến nay điều này đã làm việc cho tôi.

Nó thực sự khá dễ dàng. Giả sử chúng ta có cái này trong thư mục JavaVirtualMachines:

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

Hãy tưởng tượng rằng 1.8 là mặc định của chúng tôi, sau đó chúng tôi chỉ cần thêm một thư mục mới (ví dụ: 'cũ') và di chuyển thư mục jdk mặc định sang thư mục mới đó. Làm java -versionlại et thì đấy, 1.7!

Nó khá đơn giản, nếu bạn không ngại xắn tay áo của mình lên ... / Library / Java / Home là mặc định cho JAVA_HOME và nó chỉ là một liên kết trỏ đến một trong số:

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

Vì vậy, tôi muốn thay đổi phiên bản JVM / JDK mặc định của mình mà không thay đổi nội dung của JAVA_HOME ... / Library / Java / Home là vị trí chuẩn cho JVM / JDK hiện tại và đó là những gì tôi muốn giữ lại ... đối với tôi thì có vẻ như vậy. là cách dễ dàng nhất để thay đổi mọi thứ với ít tác dụng phụ nhất.

Nó thực sự đơn giản. Để thay đổi phiên bản java mà bạn thấy với java -version, tất cả những gì bạn phải làm là một số phiên bản sau:

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

Tôi đã không dành thời gian nhưng một tập lệnh shell rất đơn giản sử dụng / usr / libexec / java_home và ln để đặt lại liên kết biểu tượng ở trên sẽ rất dễ tạo ...

Khi bạn đã thay đổi nơi trỏ / Thư viện / Java / Trang chủ ... bạn sẽ nhận được kết quả chính xác:

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)

Hướng dẫn gỡ cài đặt của Oracle cho Java 7 đã phù hợp với tôi.

Trích:

Gỡ cài đặt JDK Để gỡ cài đặt JDK, bạn phải có đặc quyền của Quản trị viên và thực hiện lệnh loại bỏ với tư cách là người chủ hoặc bằng cách sử dụng công cụ sudo (8).

Điều hướng đến / Library / Java / JavaVirtualMachines và xóa thư mục có tên phù hợp với định dạng sau: *

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

Ví dụ: để gỡ cài đặt 7u6:

% rm -rf jdk1.7.0_06.jdk

Hơi muộn nhưng vì đây là vấn đề đang diễn ra với Mac OSX ...

Giải pháp đơn giản nhất mà tôi tìm thấy là chỉ cần xóa nội dung OpenJDK mà Apple cài đặt. Mỗi khi có bản cập nhật Mac OSX, nó sẽ được cài đặt và bạn sẽ cần phải gỡ bỏ nó một lần nữa.

Điều này thực sự hoạt động tốt nếu bạn phát triển ứng dụng cho Google App Engine trên máy Mac của mình bằng Java. OpenJDK không hoạt động tốt và phiên bản Java đi kèm với bản nâng cấp Mac OSX Yosemite sẽ làm cho Trình cắm Eclipse dành cho Máy ứng dụng gặp sự cố trong mỗi lần triển khai với lỗi hữu ích: "Đã hết thời gian đọc".

Tôi đã thử nghiệm "jenv" và những thứ khác như đặt "JAVA_HOME" mà không thành công. Bây giờ tôi và kết thúc với giải pháp sau

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
}

(được thêm vào ~ / .bashrc hoặc ~ / .bash.profile hoặc ~ / .zshrc)

Và gọi như vậy:

setJava 1.8

java_home sẽ xử lý dữ liệu nhập sai. vì vậy bạn không thể làm sai điều gì đó. Maven và những thứ khác sẽ chọn phiên bản phù hợp ngay bây giờ.

Tôi thực sự đã xem xét điều này một chút trong trình tháo gỡ, vì nguồn không có sẵn.

/ usr / bin / java và / usr / libexec / java_home đều sử dụng JavaLaunching.framework. Biến môi trường JAVA_HOME thực sự được kiểm tra đầu tiên bởi / usr / bin / java và bạn bè (nhưng không phải / usr / libexec / java_home.) Khuôn khổ sử dụng các biến môi trường JAVA_VERSION và JAVA_ARCH để lọc các JVM có sẵn. Vì vậy, theo mặc định:

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

Nhưng cài đặt, giả sử, JAVA_VERSION có thể ghi đè cài đặt mặc định:

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

Bạn cũng có thể đặt JAVA_LAUNCHER_VERBOSE = 1 để xem một số ghi nhật ký gỡ lỗi bổ sung như đường dẫn tìm kiếm, các JVM được tìm thấy, v.v., với cả / usr / bin / java và / usr / libexec / java_home.

Trong quá khứ, JavaLaunching.framework thực sự đã sử dụng hệ thống tùy chọn (trong miền com.apple.java.JavaPreferences) để đặt thứ tự JVM ưa thích, cho phép đặt JVM mặc định bằng PlistBuddy - nhưng tốt nhất tôi có thể nói, rằng mã đã bị xóa trong các phiên bản macOS gần đây. Các biến môi trường dường như là cách duy nhất (ngoài việc chỉnh sửa danh sách Info.plist trong chính các gói JDK.)

Tất nhiên, việc đặt các biến môi trường mặc định có thể được thực hiện thông qua .profile của bạn hoặc thông qua launcherd , nếu bạn cần chúng được đặt ở cấp phiên.

Chỉnh sửa: thông tin này dành riêng cho visualvm, không dành cho bất kỳ ứng dụng java nào khác

Như những người khác đã đề cập, bạn cần sửa đổi visualvm.conf

Đối với phiên bản mới nhất của JvisualVM 1.3.6 trên Mac, các thư mục cài đặt đã thay đổi.

Nó hiện đang ở trong /Application/VisualVM.app/Contents/Resources/visualvm/etc/visualvm.conf .

Tuy nhiên, điều này có thể phụ thuộc vào nơi bạn đã cài đặt VisualVM. Cách dễ nhất để tìm nơi bắt đầu VisualVM của bạn và sau đó xem xét quá trình bằng cách sử dụng:

ps -ef | grep VisualVM

Bạn sẽ thấy một cái gì đó như:

... -Dnetbeans.dirs = / Ứng dụng / VisualVM.app / Nội dung / Tài nguyên / visualvm / visualvm ...

Bạn muốn lấy thuộc tính netbeans.dir và tìm kiếm một thư mục và bạn sẽ tìm thấy thư mục etc.

Bỏ ghi chú dòng này trong visualvm.conf và thay đổi đường dẫn đến jdk

visualvm_jdkhome="/path/to/jdk"

Ngoài ra, nếu bạn gặp vấn đề với visualvm của mình chậm và bạn có nhiều bộ nhớ, tôi khuyên bạn nên tăng đáng kể dung lượng bộ nhớ có sẵn và chạy nó ở chế độ máy chủ:

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"

Tôi đã gặp trường hợp tương tự và quy trình sau đây đã hiệu quả với tôi:

1. Trong thiết bị đầu cuối, nhập

   vi ~/.profile

2. Sau đó, thêm dòng này vào tệp và lưu

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

   trong đó phiên bản là phiên bản trên máy tính của bạn, chẳng hạn như 1.7.0_25

3. Thoát khỏi trình chỉnh sửa, sau đó nhập lệnh sau để làm cho nó trở nên hiệu quả

   source ~/.profile 

Sau đó gõ java -version để kiểm tra kết quả

    java -version 

.Profile là gì? Từ: http://computers.tutsplus.com/tutorials/speed-up-your-terminal-workflow-with-command-aliases-and-profile--mac-30515

Tệp .profile là một tệp ẩn. Đây là một tệp tùy chọn cho hệ thống biết lệnh nào sẽ chạy khi người dùng có tệp hồ sơ đăng nhập. Ví dụ: nếu tên người dùng của tôi là bruno và có tệp .profile trong / Users / bruno /, tất cả nội dung của nó sẽ được thực hiện trong quá trình đăng nhập.

MacOS sử dụng / usr / libexec / java_home để tìm Phiên bản Java hiện tại. Một cách để bỏ qua là thay đổi tệp plist như được giải thích bởi @ void256 ở trên. Các cách khác là sao lưu java_home và thay thế nó bằng tập lệnh java_home của riêng bạn có mã
echo $ JAVA_HOME

Bây giờ xuất JAVA_HOME sang phiên bản SDK mong muốn bằng cách thêm các lệnh sau vào ~ / .bash_profile. export JAVA_HOME = "/ System / Library / Java / JavaVirtualMachines / 1.6.0.jdk / Contents / Home" Launcctl setenv JAVA_HOME $ JAVA_HOME /// Tạo biến môi trường toàn cục

Chạy mã nguồn lệnh ~ / .bash_profile để chạy các lệnh trên.

Bất cứ lúc nào cần thay đổi JAVA_HOME, anh ta có thể đặt lại giá trị JAVA_HOME trong tệp ~ / .bash_profile.

Tôi muốn thay đổi phiên bản java mặc định dạng 1.6 * thành 1.7 *. Tôi đã thử các bước sau và nó hiệu quả với tôi:

• Đã xóa liên kết "java" khỏi / usr / bin
• Đã tạo lại nó, trỏ đến vị trí mới:

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

• được xác minh bằng "java -version"

phiên bản java "1.7.0_51"
Java (TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot (TM) 64-Bit Server VM (build 24.51-b03, hỗn hợp)