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