簡(jiǎn)介面向 Windows x86_64 平臺(tái)的 Red Hat 構(gòu)建版 OpenJDK JRE 14.0.1.7 壓縮包適合在離線環(huán)境、服務(wù)器或本機(jī)快速搭建 Java 14 運(yùn)行時(shí)環(huán)境尤其適合開發(fā)、測(cè)試與運(yùn)維人員在無外網(wǎng)場(chǎng)景下完成環(huán)境初始化。包內(nèi)共 358 個(gè)文件總體積約 59.57MB包含 82 個(gè) DLL 動(dòng)態(tài)鏈接庫(kù)、25 個(gè) EXE 可執(zhí)行程序、JAR 包、modules 模塊文件及 cacerts 證書庫(kù)等核心組件同時(shí)附有 license、additional_license_info、assembly_exception 等許可說明和 Markdown 文檔既能支撐標(biāo)準(zhǔn) JRE 啟動(dòng)也便于核對(duì)模塊化配置、安全策略與證書信任關(guān)系此外還包含時(shí)區(qū)映射、安全策略、類加載輔助等細(xì)節(jié)文件便于處理更精細(xì)的運(yùn)行配置。已有 620 人學(xué)習(xí)下載說明該包在實(shí)際部署中具備一定通用性。使用此壓縮包無需聯(lián)網(wǎng)即可獲得完整的 Red Hat 版 Java 運(yùn)行時(shí)可統(tǒng)一項(xiàng)目基礎(chǔ)環(huán)境、復(fù)現(xiàn)運(yùn)行問題或作為容器與服務(wù)器部署的基線解壓后的目錄結(jié)構(gòu)清晰各類文件用途明確便于開發(fā)者按需引用與定位問題。 下午收到一個(gè)壓縮包名字特別長(zhǎng)java-14-openjdk-jre-14.0.1.7-1.windows.redhat.x86_64.zip。第一眼掃過去很多人會(huì)以為這是某個(gè)開源項(xiàng)目源碼或者某個(gè)安裝包的附件其實(shí)它就是一個(gè)非常典型的 OpenJDK 運(yùn)行時(shí)環(huán)境包專門給 Windows x86_64 平臺(tái)用的 Red Hat 構(gòu)建版 JRE 14。如果你手里正好有一個(gè)這樣的 zip 包或者正在折騰 Java 環(huán)境的安裝部署那這篇內(nèi)容就是給你寫的。這個(gè)包能解決的問題很直接讓一臺(tái) Windows 機(jī)器具備運(yùn)行 Java 程序的能力。它不需要安裝器解壓即用非常適合內(nèi)網(wǎng)離線部署、整機(jī)鏡像打包、臨時(shí)跑 Java 工具等場(chǎng)景。我也看到很多朋友把 JRE、JDK、JVM 這幾個(gè)概念混在一起面試時(shí)被問到JRE 和 JVM 之間的關(guān)系就卡殼這次順便一起講透。1. 文件名拆解這個(gè)壓縮包到底裝了什么1.1 一個(gè)文件名包含的所有關(guān)鍵信息先把這個(gè)長(zhǎng)名字拆開看信息量其實(shí)很大java-14Java 主版本號(hào)是 14也就是 2020 年 3 月發(fā)布的版本。openjdk這是 OpenJDK 項(xiàng)目構(gòu)建的產(chǎn)物不是 Oracle 商業(yè)版。jreJava Runtime EnvironmentJava 運(yùn)行時(shí)環(huán)境只負(fù)責(zé)運(yùn)行不包含編譯器等開發(fā)工具。14.0.1.7-1完整版本號(hào)對(duì)應(yīng) OpenJDK 14.0.1 的第 7 個(gè)構(gòu)建版本后面的-1是 Red Hat 自己的打包修訂號(hào)。windows目標(biāo)操作系統(tǒng)是 Windows。redhat這個(gè)構(gòu)建來自 Red Hat不是 Oracle 也不是 Eclipse Adoptium。x86_6464 位 Intel/AMD 架構(gòu)。把這些拼起來意思就是Red Hat 編譯的 OpenJDK 14.0.1 運(yùn)行時(shí)環(huán)境Windows 64 位版本以 zip 形式分發(fā)。很多人看到redhat就以為只能在紅帽系統(tǒng)上裝這是個(gè)誤解redhat只代表構(gòu)建方最終產(chǎn)物是純 Windows 可執(zhí)行的程序跟開發(fā)機(jī)器裝沒裝紅帽系統(tǒng)毫無關(guān)系。那為什么會(huì)出現(xiàn)Red Hat 構(gòu)建的 Windows JRE這種組合其實(shí)在企業(yè)市場(chǎng)很常見。很多公司在采購(gòu)了 RHEL 之后開發(fā)人員的 Windows 筆記本也需要與服務(wù)器端保持一致的 Java 運(yùn)行時(shí)環(huán)境。紅帽在維護(hù) OpenJDK 時(shí)會(huì)同步產(chǎn)出 Windows 版二進(jìn)制包方便統(tǒng)一技術(shù)棧。這也是為什么你會(huì)搜到很多 OpenJDK 部署教程里反復(fù)提到redhat這個(gè)后綴。1.2 JRE、JVM、JDK 到底什么關(guān)系這也是 Java 面試題里出現(xiàn)頻率最高的基礎(chǔ)題我用類比講清楚。JVM 是 Java Virtual Machine負(fù)責(zé)把字節(jié)碼翻譯成當(dāng)前操作系統(tǒng)能識(shí)別的機(jī)器指令。它就像一個(gè)發(fā)動(dòng)機(jī)本身不能單獨(dú)跑必須裝進(jìn)車?yán)锊庞幸饬x。JRE 就是這個(gè)裝好發(fā)動(dòng)機(jī)的車除了 JVM 這臺(tái)發(fā)動(dòng)機(jī)還有方向盤、油箱、儀表盤——對(duì)應(yīng) Java 核心類庫(kù)和基礎(chǔ)運(yùn)行文件比如java.lang、java.util、java.io這些包以及java.exe這個(gè)啟動(dòng)入口。用戶把車開走就完事不需要關(guān)心發(fā)動(dòng)機(jī)怎么造。JDK 則是整車制造車間里面不僅有一輛能開的車JRE還有造車用的全套工具——javac編譯器、javadoc文檔生成器、jar打包工具等。所以開發(fā) Java 程序需要 JDK運(yùn)行編譯好的.class或.jar包只需要 JRE。這個(gè) zip 包就是只給了你車沒給車間因此里面不會(huì)有javac這個(gè)命令。放到實(shí)際場(chǎng)景里你在一臺(tái) Windows 服務(wù)器上部署一個(gè)打包好的 Spring Boot 應(yīng)用只要 JRE 就夠了你想在這臺(tái)機(jī)器上重新修改代碼并編譯就必須裝 JDK。我之前在給團(tuán)隊(duì)搭 CI 構(gòu)建機(jī)的時(shí)候就見過有人為了省磁盤空間只裝了 JRE結(jié)果流水線在mvn compile階段直接報(bào)錯(cuò)折騰了半天才發(fā)現(xiàn)是缺javac。1.3 為什么這個(gè)包里沒有 applet 插件老一批 Java 開發(fā)者可能還記得Java 8 及更早的 JRE 安裝包里自帶一個(gè)瀏覽器插件叫 Java Plug-in用來在網(wǎng)頁(yè)里跑 Applet 小程序。這個(gè) zip 包解壓后你翻遍整個(gè)目錄也找不到這玩意兒因?yàn)閺?JDK 9 開始 Applet API 就被標(biāo)記為廢棄到了 JDK 11 干脆默認(rèn)禁用JDK 14 更是直接不給編譯了。所以如果你搜索jre applet 插件是為了在 Chrome 或 Edge 里跑老系統(tǒng)別指望這個(gè) OpenJDK 14 能幫你。這類遺留需求通常得回到 JRE 8 的 32 位版本或者用專門的兼容方案這個(gè)話題我放在后面章節(jié)細(xì)說。2. 實(shí)操部署從 zip 包到能跑 Java 程序2.1 解壓與目錄檢查拿到 zip 包后不需要運(yùn)行任何安裝向?qū)е苯咏鈮?。我個(gè)人習(xí)慣把它放到一個(gè)不含中文和空格的路徑下比如C:\Java\jre-14.0.1這樣能避免很多工具因路徑解析問題踩坑。解壓后打開目錄你應(yīng)該能看到下面幾個(gè)關(guān)鍵目錄和文件bin\java.exeJava 程序的啟動(dòng)器幾乎所有 Java 程序都是通過它拉起的。bin\keytool.exe密鑰和證書管理工具做 HTTPS 配置、JWT 簽名驗(yàn)證時(shí)會(huì)用到。conf\運(yùn)行時(shí)配置文件比如security\java.security可以調(diào)整加密策略。legal\各模塊的開源協(xié)議聲明。lib\核心類庫(kù)和平臺(tái)庫(kù)文件。這里要特別注意一點(diǎn)第一次操作時(shí)建議先把 zip 的文件大小和官方發(fā)布的 SHA-256 校驗(yàn)值比對(duì)一下。內(nèi)網(wǎng)傳包經(jīng)常出現(xiàn)文件損壞的情況如果 zip 包本身不完整解壓時(shí)可能不報(bào)錯(cuò)但運(yùn)行起來各種莫名其妙的 ClassNotFoundException。校驗(yàn)通過后再解壓能省掉后面一大半排查時(shí)間。2.2 環(huán)境變量配置JAVA_HOME 與 Path解壓完還不能直接用需要告訴 Windows 操作系統(tǒng) Java 裝在哪里。右鍵此電腦→屬性→高級(jí)系統(tǒng)設(shè)置→環(huán)境變量在系統(tǒng)變量里新建變量名: JAVA_HOME 變量值: C:\Java\jre-14.0.1然后找到Path變量點(diǎn)擊編輯新增一行%JAVA_HOME%\bin配置完務(wù)必點(diǎn)擊確定關(guān)閉所有設(shè)置窗口這樣環(huán)境變量的修改才會(huì)真正寫入注冊(cè)表。為什么JAVA_HOME這么重要很多軟件不直接讀Path而是去系統(tǒng)變量里找JAVA_HOME。比如 Elasticsearch、Maven、Gradle、Tomcat 這些工具啟動(dòng)腳本里都寫了$JAVA_HOME/bin/java這種引用。你只配Path的話命令行能敲java -version但啟動(dòng) Elasticsearch 時(shí)照樣報(bào)找不到 Java這就是為什么Windows 啟動(dòng) Elasticsearch和JAVA_HOME 配置總被一起搜索的原因。補(bǔ)充一個(gè)老版本項(xiàng)目相關(guān)的小細(xì)節(jié)有些公司內(nèi)部遺留系統(tǒng)的啟動(dòng)腳本還會(huì)主動(dòng)讀取CLASSPATH環(huán)境變量來定位第三方依賴。Java 5 之后大部分場(chǎng)景已經(jīng)不需要手動(dòng)配置CLASSPATH了如果你遇到的是這種老古董項(xiàng)目可以在系統(tǒng)變量里再補(bǔ)一個(gè)CLASSPATH值設(shè)置為.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar注意開頭的.;表示當(dāng)前目錄別漏。2.3 驗(yàn)證運(yùn)行與一個(gè)簡(jiǎn)單測(cè)試配置完成后重新打開一個(gè)命令行窗口注意必須新開舊窗口讀不到新環(huán)境變量輸入java -version正常輸出類似這樣openjdk version 14.0.1 2020-04-14 OpenJDK Runtime Environment (build 14.0.17-1) OpenJDK 64-Bit Server VM (build 14.0.17-1, mixed mode, sharing)能看到這三行就說明 JRE 已經(jīng)正常工作了。注意第二行的OpenJDK Runtime Environment以及第三行末尾的Server VM這些標(biāo)記說明你用的是 OpenJDK 的 HotSpot 虛擬機(jī)64 位模式。再順手寫一個(gè)測(cè)試類驗(yàn)證運(yùn)行鏈路雖然 JRE 沒有javac但你可以提前在 JDK 機(jī)器上編譯好或者直接用一個(gè)現(xiàn)成的 jar 包測(cè)試java -jar MyApp.jar如果程序能正常輸出日志說明 JRE 的類加載、核心庫(kù)、JVM 參數(shù)解析全鏈路都是通的。3. 使用中的問題排查與坑位提醒3.1 命令找不到、版本對(duì)不上怎么辦我整理了一個(gè)高頻問題速查表基本覆蓋了新手在 Windows 上部署 OpenJDK JRE 時(shí)會(huì)遇到的絕大多數(shù)情況現(xiàn)象常見原因解決辦法java提示不是內(nèi)部或外部命令環(huán)境變量未配置或者 Path 里沒加%JAVA_HOME%\bin重新檢查 JAVA_HOME 和 Path配置后務(wù)必重開命令行java -version顯示的版本和預(yù)期不符系統(tǒng)里裝了多個(gè) JavaPath 順序?qū)е孪绕ヅ涞脚f版本在 Path 里把%JAVA_HOME%\bin移到最前面或者刪除舊 Java 的路徑解壓后 bin 目錄里沒有 java.exezip 下載不完整或者下成了源碼包而不是二進(jìn)制包對(duì)比文件大小與 SHA-256確認(rèn)是jre-14.0.1_windows-x64_bin類二進(jìn)制包32 位 Windows 上運(yùn)行 64 位 JRE 直接報(bào)錯(cuò)架構(gòu)不匹配去下載x86版本文件名里會(huì)標(biāo)注 i586 而不是 x86_64雙擊 java.exe 一閃而過JRE 本身沒有圖形界面命令窗口被執(zhí)行完后自動(dòng)關(guān)閉在 cmd 里運(yùn)行java -version驗(yàn)證雙擊不是正常用法有一個(gè)坑我提過很多次就是安裝過 Oracle JDK 又裝 OpenJDK導(dǎo)致的版本混亂。Windows 的 Path 里可能同時(shí)存在C:\Program Files\Java\jdk-11和C:\Java\jre-14.0.1到底哪個(gè)生效取決于它們?cè)?Path 里的排列順序。排查時(shí)不要只看環(huán)境變量窗口直接在命令行執(zhí)行where java這個(gè)命令會(huì)列出所有被 Path 命中的 java.exe 路徑從上到下第一個(gè)就是當(dāng)前實(shí)際生效的版本比反復(fù)改環(huán)境變量快得多。3.2 程序運(yùn)行期問題內(nèi)存、工具鏈與老項(xiàng)目兼容JRE 裝好、環(huán)境變量配好只是萬里長(zhǎng)征第一步運(yùn)行期的問題更磨人。最常見的一個(gè)是java.lang.OutOfMemoryError: Insufficient memory。字面上像是物理內(nèi)存不夠其實(shí)多半是 JVM 啟動(dòng)參數(shù)里的堆內(nèi)存設(shè)置不合理。比如你在一臺(tái) 8G 內(nèi)存的 Windows 機(jī)器上跑 Elasticsearch如果 ES 的jvm.options里設(shè)了-Xms4g -Xmx4g同時(shí)系統(tǒng)還要給其他程序留內(nèi)存就有可能在分配時(shí)直接被操作系統(tǒng)拒絕。排查方法是先看任務(wù)管理器里的物理內(nèi)存剩余量再用命令行顯式指定小一點(diǎn)的堆啟動(dòng)測(cè)試java -Xms256m -Xmx512m -jar MyApp.jar如果這個(gè)小堆配置下程序能正常跑說明問題出在啟動(dòng)參數(shù)而不是 JRE 包本身。要注意 JRE 14 的 G1 垃圾回收器默認(rèn)會(huì)占用一定比例的堆外內(nèi)存遇到內(nèi)存吃緊時(shí)除了調(diào)-Xmx還可以加上-XX:MaxRAMPercentage50這類比例參數(shù)讓 JVM 根據(jù)機(jī)器實(shí)際物理內(nèi)存自適應(yīng)分配。第二個(gè)常見問題是老項(xiàng)目跑不起來典型報(bào)錯(cuò)是UnsupportedClassVersionError后面跟著一個(gè)版本號(hào)。比如報(bào)錯(cuò)信息里寫class file version 55.0代表這個(gè) class 是 Java 11 編譯的而你當(dāng)前用的是 Java 8 或 JRE 14 去加載低版本編譯的代碼也會(huì)出現(xiàn)奇怪的不兼容。JRE 14 默認(rèn)的字節(jié)碼版本是 58.0如果你的 jar 包是用更高版本 JDK比如 17編譯的那用這個(gè) JRE 14 是跑不了的只能換 JDK 17 的 JRE 或者用兼容模式重新編譯。第三個(gè)坑是工具有問題。這個(gè)包里沒有javac但很多人會(huì)習(xí)慣性地敲javac想編譯文件結(jié)果返回不是內(nèi)部或外部命令這其實(shí)是正?，F(xiàn)象。還有做簽名、證書操作時(shí)會(huì)用到keytool它在bin目錄下在 JRE 里是存在的別因?yàn)檎也坏絡(luò)avac就以為整個(gè) bin 目錄都被精簡(jiǎn)了。3.3 版本選擇策略14 不是 LTS生產(chǎn)環(huán)境別硬上OpenJDK 的版本發(fā)布節(jié)奏是每六個(gè)月一個(gè)大版本但真正面向長(zhǎng)期維護(hù)的只有 LTSLong-Term Support版本比如 Java 8、11、17、21。Java 14 屬于短期過渡版本發(fā)表于 2020 年 3 月到 2020 年 9 月 Java 15 發(fā)布后就基本停止公開更新了。這就帶來一個(gè)現(xiàn)實(shí)問題你手里這個(gè)java-14-openjdk-jre-14.0.1.7-1只是在某一時(shí)間點(diǎn)修復(fù)了當(dāng)時(shí)已知的安全漏洞但后續(xù)發(fā)現(xiàn)的 CVE 不會(huì)有官方補(bǔ)丁。如果你是要把外部服務(wù)暴露在公網(wǎng)上我強(qiáng)烈不建議直接用這個(gè)版本跑關(guān)鍵業(yè)務(wù)更穩(wěn)妥的做法是部署 OpenJDK 17 或 21 的 JRE它們才是當(dāng)前的主流選擇。那 JRE 14 在 2026 年的今天還有沒有價(jià)值有但集中在兩類場(chǎng)景一類是內(nèi)網(wǎng)離線環(huán)境里的遺留系統(tǒng)當(dāng)初就是用 Java 14 編譯發(fā)布的系統(tǒng)文檔明確要求運(yùn)行時(shí)版本不能高于 14另一類是做技術(shù)考古、復(fù)現(xiàn)老問題用的測(cè)試環(huán)境。遇到這類情況別手賤去升到 17嚴(yán)格按應(yīng)用要求的版本部署反而最安全。4. 這個(gè) JRE 包該用在哪什么時(shí)候不該用它4.1 適合的場(chǎng)景離線部署、瘦客戶端與自動(dòng)化任務(wù)這個(gè) zip 版的 JRE 最大的優(yōu)勢(shì)是綠色免安裝。我在給某制造企業(yè)做產(chǎn)線數(shù)據(jù)采集時(shí)現(xiàn)場(chǎng)設(shè)備是一批 Windows 10 工控機(jī)不允許隨便裝軟件更不可能每臺(tái)都跑一遍 Oracle 的在線安裝程序。當(dāng)時(shí)我直接把解壓好的 JRE 目錄復(fù)制到每臺(tái)機(jī)器的D:\runtime\jre寫一個(gè) bat 腳本自動(dòng)配置環(huán)境變量再配合計(jì)劃任務(wù)啟動(dòng)采集程序幾十臺(tái)機(jī)器一下午就搞定了。整個(gè)過程不需要管理員反復(fù)點(diǎn)下一步也不用面對(duì)jre 安裝出現(xiàn)腳本錯(cuò)誤這類在線安裝器才有的問題。具體地說以下幾個(gè)場(chǎng)景非常適合這個(gè)包內(nèi)網(wǎng)離線環(huán)境沒有外網(wǎng)下載條件一個(gè) zip 包拷貝過去解壓即用。整機(jī)鏡像與 Windows 自動(dòng)化部署把 JRE 目錄打進(jìn)鏡像或通過批處理腳本批量設(shè)置環(huán)境變量和自啟動(dòng)任務(wù)。瘦客戶端與終端機(jī)只跑固定 Java 應(yīng)用比如掃碼、打印、刷卡程序不需要 JDK 的開發(fā)功能。CI/CD 從機(jī)Windows 構(gòu)建節(jié)點(diǎn)上跑測(cè)試任務(wù)、啟動(dòng)測(cè)試服務(wù)JRE 足夠用。一個(gè)小技巧如果你需要批量部署可以在解壓目錄下放一個(gè)setup_jre.batecho off setx JAVA_HOME C:\Java\jre-14.0.1 /M setx Path %Path%;C:\Java\jre-14.0.1\bin /M echo JRE environment configured. pause注意setx /M需要管理員權(quán)限而且setx默認(rèn)會(huì)把Path截?cái)嗟?1024 字符這里只是演示真實(shí)環(huán)境建議用 PowerShell 或組策略部署避免覆蓋已有路徑。4.2 不適合的場(chǎng)景與遷移建議如果你打算在 Windows 上跑 Docker、Redis、Elasticsearch 這類現(xiàn)代中間件或者用 Maven、Gradle 構(gòu)建項(xiàng)目那我建議你直接放棄這個(gè) JRE 14 包。原因很簡(jiǎn)單這些工具對(duì) Java 版本的要求通常寫著Java 17 或 21JRE 14 一上來就被判定為不滿足要求。特別是 Elasticsearch 8.x 版本強(qiáng)制要求 JDK 17你給它配一個(gè) JRE 14 的JAVA_HOME啟動(dòng)時(shí)會(huì)得到一個(gè)很直白的版本錯(cuò)誤。還有朋友問能不能用這個(gè) JRE 包代替 JDK 來開發(fā)答案是絕對(duì)不能。沒有javac你就無法編譯源代碼沒有jar你就無法打包而jshell這個(gè)交互式工具也是 JDK 的一部分JRE 里同樣找不到。開發(fā)機(jī)老老實(shí)實(shí)裝 JDK運(yùn)行環(huán)境才考慮 JRE。如果你手里正好有老項(xiàng)目必須從 Java 11 遷到 Java 17我的經(jīng)驗(yàn)是不要只換 JRE 版本就跑先檢查這幾項(xiàng)第三方依賴?yán)镉袥]有用到了 Java 14 之后被移除的內(nèi)部 API比如sun.misc.Unsafe相關(guān)調(diào)用。配置文件里有沒有寫死堆內(nèi)存參數(shù)G1 收集器在 17 里的默認(rèn)行為跟 14 差異較大。如果項(xiàng)目用了 Lombok注意 Lombo 版本是否支持新 JDK否則會(huì)冒出 You arent using a compiler supported by lombok 這類讓人摸不著頭腦的提示。4.3 冷門但實(shí)用的配套技巧最后分享幾個(gè)我多次踩坑后總結(jié)的冷門用法。跑 Windows 計(jì)劃任務(wù)執(zhí)行 Java 程序時(shí)很多人直接寫java -jar xxx.jar一旦程序報(bào)了異常日志一閃而過根本看不到原因。正確的做法是寫一個(gè)包裝腳本把標(biāo)準(zhǔn)輸出和錯(cuò)誤輸出重定向到日志文件echo off cd /d D:\apps\myapp C:\Java\jre-14.0.1\bin\java.exe -jar myapp.jar app.log 21這樣哪怕程序崩潰了堆棧信息也會(huì)記錄在app.log里排查起來非常方便。如果你遇到老掉牙的 Web 應(yīng)用必須在瀏覽器里運(yùn)行 Applet而當(dāng)前 JRE 14 又完全不支持插件我的建議是直接考慮虛擬化方案把裝有 Java 8 32 位 Firefox 的舊系統(tǒng)封裝成虛擬機(jī)比在老系統(tǒng)上硬塞插件安全得多。這是我在處理政府單位遺留辦公系統(tǒng)時(shí)驗(yàn)證過的最有效解法。再補(bǔ)充一點(diǎn)在開發(fā)環(huán)境里做 Java 面試題練習(xí)時(shí)比如手寫 Lambda 表達(dá)式、冒泡排序、觀察jstack輸出用這個(gè) JRE 14 完全夠用。Java 14 支持了instanceof模式匹配預(yù)覽功能、Records預(yù)覽功能以及文本塊應(yīng)付基礎(chǔ)語(yǔ)法練習(xí)和研究 JVM 行為是綽綽有余的。我自己平時(shí)處理 Windows 服務(wù)器上的 Java 應(yīng)用絕大多數(shù)情況都只裝 JRE不裝 JDK一方面省一點(diǎn)磁盤空間另一方面也減少了安全暴露面。你要是第一次在公司內(nèi)網(wǎng)部署這個(gè) zip 包記住一個(gè)原則先用where java看當(dāng)前環(huán)境再改JAVA_HOME最后用java -version驗(yàn)證三步走完這臺(tái)機(jī)器的 Java 環(huán)境基本就穩(wěn)了。至于這個(gè)包本身把它當(dāng)做一個(gè)運(yùn)行 Java 程序的底座就好不該指望它帶給你編譯能力更不該在追求新特性的項(xiàng)目里強(qiáng)行續(xù)命。本文還有配套的精品資源點(diǎn)擊獲取