简介本资源为 Java 14 的 OpenJDK JRE 运行环境安装包面向需要在 Windows 平台运行 Java 14 应用的开发者与运维人员尤其适合 Red Hat 系环境下的部署与测试场景。压缩包共 358 个文件约 59.57MB以 82 个 dll 动态链接库、25 个 exe 可执行程序及大量 license、assembly_exception 许可与异常说明文件为主另含 policy 安全策略、properties 配置、cacerts 证书库、modules 模块定义与 release 版本信息等构成完整的 JRE 运行时目录结构。已有 622 人学习下载可作为搭建 Java 14 运行环境的直接来源省去自行编译或跨平台适配的麻烦。包内保留完整的许可与异常说明便于合规审查cacerts 与 policy 文件可直接用于安全通信与权限控制modules 与 release 信息则方便确认版本与模块化配置适合快速部署、版本核对及运行环境排错参考。1. 别被文件名骗了java-14-openjdk-jre-14.0.1.7-1.windows.redhat.x86_64.zip 到底是什么java-14-openjdk-jre-14.0.1.7-1.windows.redhat.x86_64.zip这个文件名第一眼看过去像是一堆版本号堆出来的乱码但它其实是一条完整的“身份信息链”。拆开看java-14是大版本openjdk是上游实现jre说明它只含运行时不含编译器14.0.1.7-1是发行方自己的补丁号windows是目标系统redhat是打包方x86_64是架构。很多人第一次拿到它是在一台不能联网的内网 Windows 机器上需要跑一个只认 Java 14 的老服务而机器上既没有包管理器也没有外网。这时候这个 zip 就是唯一的救命稻草。它解决的不是“学 Java”的问题而是“在一台干净、隔离、架构确定的 Windows 机器上把 Java 14 运行时精确地铺进去”的问题。适合谁适合做离线部署、内网运维、老系统维护以及需要固定 JDK 版本做构建验证的工程师。如果你只是本地写代码装个新版 JDK 更省事但如果你面对的是“版本必须锁死、网络必须隔离、架构必须匹配”的场景这个文件名的每一个字段都不能错。2. 拆解文件名每个字段决定了你能不能跑起来2.1 为什么是 JRE 而不是 JDKjre这三个字母决定了这个包能做什么、不能做什么。JRE 只包含 Java 虚拟机、核心类库和运行时需要的配置文件不包含javac、jar、jdb这些开发工具。如果你的目标机器只是运行一个已经打好的.jar或.warJRE 足够而且体积更小、攻击面更窄。但如果你需要在目标机器上编译代码、执行jarsigner或者用jcmd做诊断JRE 会让你在第一步就卡住。常见做法是部署环境用 JRE构建环境用 JDK。我一般会在内网维护两份包一份 JRE 用于生产节点一份 JDK 用于跳板机上的构建。判断标准很简单——目标机器上有没有javac的需求。没有就坚决用 JRE少一个工具就少一个被扫描到的入口。2.2 版本号 14.0.1.7-1 里的发行方逻辑14.0.1是 OpenJDK 的官方版本7-1是 Red Hat 自己的构建号和发行号。这里最容易翻车的地方是很多人以为14.0.1就是全部忽略了后面的7-1。不同发行方对同一个上游版本会打不同的补丁尤其是安全修复和 Windows 平台相关的兼容性修复。7通常表示 Red Hat 的第 7 次构建-1是发行修订号。这意味着如果你在 A 机器上用官方 OpenJDK 14.0.1 验证通过换到 B 机器上用这个 Red Hat 构建理论上 API 行为一致但底层库链接、证书库路径、甚至默认字符集都可能不同。我遇到过最隐蔽的一次是java.security文件里默认禁用的算法列表不一样导致一个老 TLS 握手在官方包上能过、在发行版包上直接拒绝。所以版本号必须完整记录不能只写14.0.1。2.3 windows.redhat.x86_64 三个字段的硬约束windows说明这是 Windows 平台专用里面的可执行文件是.exe和.dll不是 Linux 的.so。x86_64说明它是 64 位能在 64 位 Windows 上跑但不能在 32 位系统上跑也不能在 ARM 架构的 Windows 上直接跑。redhat说明打包方是 Red Hat这通常意味着它来自 Red Hat 的构建流水线可能带有 Red Hat 自己的元数据和目录结构。这三个字段是硬约束错一个就完全不能用。我见过有人把x86_64的包解压到 32 位 Windows 上然后困惑为什么java.exe双击没反应——其实是 PE 头架构不匹配系统直接拒绝加载。也见过把 Windows 包解压到 Linux 上然后试图执行java.exe结果当然是Exec format error。文件名就是契约不要试图绕过。2.4 zip 格式在离线部署中的实际意义为什么是zip而不是msi或exe安装包因为 zip 是“绿色”的解压即用不写注册表不往Program Files里塞东西不需要管理员权限。这在离线、隔离、多版本共存的环境里是巨大优势。你可以把不同版本的 JRE 解压到不同目录用绝对路径调用互不干扰。但 zip 也意味着没有自动配置。JAVA_HOME要自己设PATH要自己加文件关联要自己建。很多人解压完发现java -version还是系统里旧版本就是因为PATH里旧路径排在前面。zip 包给你的是完全控制权代价是你要自己承担配置责任。3. 在 Windows 上把 JRE 14 铺进内网机器从解压到验证3.1 解压位置的选择与目录结构确认不要解压到C:\Program Files下面除非你有管理员权限并且确定不会有多版本冲突。我一般会选C:\java\作为根下面按版本建目录比如C:\java\jre-14.0.1.7。这样路径短、无空格、权限简单后续脚本引用也方便。解压后先看目录结构。典型的 JRE 包解压出来应该有一个bin目录里面有java.exe、javaw.exe、keytool.exe等一个lib目录里面有modules、rt.jarJava 14 其实已经模块化了但发行版可能保留一些兼容文件一个conf目录里面有security和net.properties。如果解压出来只有一层空目录或者文件散落说明解压工具没有保留目录结构需要换工具重新解压。# 在 Windows 上可以用 PowerShell 解压保留目录结构 Expand-Archive -Path java-14-openjdk-jre-14.0.1.7-1.windows.redhat.x86_64.zip -DestinationPath C:\java\jre-14.0.1.7Expand-Archive是 PowerShell 内置命令不需要额外安装。-DestinationPath指定的目录如果不存在会自动创建。注意如果 zip 包里有很长的路径或者特殊字符老版本 PowerShell 可能报错这时候用 7-Zip 的命令行版本更稳。3.2 设置 JAVA_HOME 和 PATH 的正确顺序解压完只是第一步环境变量才是让系统找到它的关键。JAVA_HOME指向 JRE 根目录PATH里加上%JAVA_HOME%\bin。顺序很重要如果系统里已经有其他 Java必须把新路径放在最前面否则java -version会显示旧版本。# 以管理员身份运行 PowerShell设置系统级环境变量 [Environment]::SetEnvironmentVariable(JAVA_HOME, C:\java\jre-14.0.1.7, Machine) $oldPath [Environment]::GetEnvironmentVariable(PATH, Machine) $newPath C:\java\jre-14.0.1.7\bin; $oldPath [Environment]::SetEnvironmentVariable(PATH, $newPath, Machine)这里用Machine级别而不是User级别是因为内网服务经常以系统账户运行用户级变量对它不可见。$oldPath先读出来再拼接避免覆盖掉原有 PATH。改完之后必须新开一个终端窗口旧窗口的环境变量是启动时快照不会自动刷新。3.3 验证安装java -version 之外的三个检查java -version只能告诉你版本号不能告诉你这个 JRE 是否完整、证书库是否可用、模块是否齐全。我一般会做三个额外检查。第一个检查java -XshowSettings:properties -version它会打印出java.home、java.version、os.arch等关键属性。确认java.home指向你解压的目录os.arch是amd64。第二个检查keytool -list -cacerts确认证书库能打开。如果这一步报错说明conf\security\cacerts文件缺失或损坏后续任何 HTTPS 请求都会失败。第三个检查用一个最小 Java 程序验证运行时。写一个Hello.java用另一台机器上的 JDK 编译成 class然后拷到目标机器上用这个 JRE 运行。这一步能验证类加载、字节码版本兼容性。# 在目标机器上运行已编译的 class C:\java\jre-14.0.1.7\bin\java -cp . Hello # 输出 Hello, Java 14 说明运行时正常如果java -version正常但运行 class 报UnsupportedClassVersionError说明编译用的 JDK 版本高于 14需要降级编译或者换 JDK。3.4 用脚本批量部署到多台机器内网机器往往不止一台手动解压设变量效率太低。我一般会写一个批处理脚本放在共享目录里每台机器执行一次。echo off setlocal set SRC\\fileserver\share\java-14-openjdk-jre-14.0.1.7-1.windows.redhat.x86_64.zip set DSTC:\java\jre-14.0.1.7 if exist %DST% ( echo Already exists, skipping extract. ) else ( mkdir %DST% powershell -Command Expand-Archive -Path %SRC% -DestinationPath %DST% -Force ) setx JAVA_HOME %DST% /M setx PATH %DST%\bin;%PATH% /M echo Done. Open a new terminal to verify. endlocalsetx是 Windows 自带的设置环境变量命令/M表示系统级。注意setx有长度限制如果 PATH 已经很长可能会截断所以更稳的做法还是用 PowerShell 的SetEnvironmentVariable。脚本里先判断目录是否存在避免重复解压覆盖配置。4. 避坑指南JRE 14 离线部署里最容易翻车的五件事4.1 解压后 java.exe 双击闪退现象解压完进bin目录双击java.exe窗口一闪而过什么都没看到。原因java.exe是控制台程序双击时如果没有参数它会打印用法然后立即退出。这不是故障是正常行为。真正的故障是双击后连窗口都不出现那可能是 PE 架构不匹配或者依赖的 DLL 缺失。解决不要双击用cmd打开命令行cd到bin目录执行java.exe -version。如果报“不是有效的 Win32 应用程序”说明架构错了检查是不是 32 位系统装了 64 位包。如果报缺少msvcp140.dll说明需要装 VC 运行库。4.2 PATH 改了但 java -version 还是旧版本现象环境变量里明明加了新路径新开终端执行java -version还是显示 Java 8 或 11。原因PATH 里旧 Java 的路径排在新路径前面或者系统里存在C:\Windows\System32\java.exe这个“幽灵”文件。Windows 的搜索顺序是当前目录 → PATH 从左到右System32 往往在 PATH 很靠前的位置。解决用where java命令列出所有匹配的java.exe看第一个是哪个。如果是 System32 下的直接删掉或者重命名需要管理员权限。如果是旧版本路径在前调整 PATH 顺序把新路径移到最前面。4.3 证书库报错导致 HTTPS 全部失败现象Java 程序启动时报PKIX path building failed或者unable to find valid certification path。原因JRE 自带的cacerts文件不包含目标服务用的根证书或者cacerts文件在解压过程中损坏。内网服务经常用自签名证书默认证书库当然不认。解决用keytool -importcert把内网根证书导入cacerts。导入前先备份原文件。命令是keytool -importcert -alias internal-ca -file ca.crt -keystore cacerts -storepass changeit。默认密码是changeit如果发行版改过需要查发行方文档。4.4 模块化之后反射报 IllegalAccessError现象老代码在 Java 8 上跑得好好的换到 Java 14 的 JRE 上启动时报IllegalAccessError或者InaccessibleObjectException。原因Java 9 引入模块系统后JDK 内部 API 被封装了。很多老框架用反射访问sun.misc.Unsafe或者java.lang的内部字段在 Java 14 上默认被拒绝。解决临时方案是加--add-opens参数比如--add-opens java.base/java.langALL-UNNAMED。但这不是长久之计每个需要开放的包都要加参数会越来越长。根本方案是升级框架版本或者联系框架维护方适配新版本。我一般会先用--add-opens让服务跑起来然后排期做框架升级。4.5 多版本共存时 JAVA_HOME 被覆盖现象机器上同时有 Java 8 和 Java 14装完 14 之后某个依赖 Java 8 的服务启动失败。原因JAVA_HOME是全局的改成 14 之后所有读这个变量的服务都受影响。有些服务在启动脚本里硬编码了JAVA_HOME有些则依赖系统变量。解决不要改全局JAVA_HOME而是在每个服务的启动脚本里显式指定。比如set JAVA_HOMEC:\java\jre-8放在脚本开头只对当前进程生效。这样多版本可以和平共处互不干扰。全局变量只保留一个“默认”版本给交互式命令行用。5. 进阶技巧把 JRE 14 做成可复用的内网基线5.1 用 jlink 裁剪出更小的运行时JRE 14 完整包解压后大概 200MB 左右如果目标机器磁盘紧张或者要分发给很多节点可以用jlink裁剪。jlink在 JDK 里不在 JRE 里所以需要在一台有 JDK 14 的机器上操作。# 在 JDK 14 环境下裁剪一个只含 java.base 和 java.logging 的运行时 jlink --module-path C:\java\jdk-14\jmods --add-modules java.base,java.logging --output C:\java\jre-min-14 --strip-debug --compress2 --no-header-files --no-man-pages--add-modules指定保留的模块只保留程序真正用到的。--strip-debug去掉调试信息--compress2启用压缩--no-header-files和--no-man-pages去掉 C 头文件和手册页。裁剪完可能只有 40-50MB。但要注意如果程序用了未列出的模块运行时会报ModuleNotFoundException所以裁剪前要用jdeps分析依赖。5.2 用 jdeps 分析程序真正依赖哪些模块jdeps也是 JDK 工具能扫描 class 文件或 jar 包列出它依赖的模块和包。# 分析一个 jar 包的模块依赖 jdeps --multi-release 14 --print-module-deps --ignore-missing-deps myapp.jar # 输出类似java.base,java.logging,java.sql--print-module-deps直接输出模块列表可以喂给jlink的--add-modules。--ignore-missing-deps忽略找不到的依赖避免因为缺少可选依赖而中断分析。这一步是裁剪的前提不分析就裁剪大概率会漏模块。5.3 把配置固化成脚本模板内网部署最怕“每台机器手工配一遍”。我习惯把解压、设变量、验证三步写成一个模板脚本放在共享目录新机器执行一次就完成基线配置。脚本里用变量控制版本号和路径换版本时只改变量。echo off setlocal set JRE_VERSION14.0.1.7 set JRE_ROOTC:\java\jre-%JRE_VERSION% set ZIP_NAMEjava-14-openjdk-jre-%JRE_VERSION%-1.windows.redhat.x86_64.zip set SHARE\\fileserver\share if not exist %JRE_ROOT% ( mkdir %JRE_ROOT% powershell -Command Expand-Archive -Path %SHARE%\%ZIP_NAME% -DestinationPath %JRE_ROOT% -Force ) powershell -Command [Environment]::SetEnvironmentVariable(JAVA_HOME, %JRE_ROOT%, Machine) powershell -Command $p[Environment]::GetEnvironmentVariable(PATH,Machine); if($p -notlike *%JRE_ROOT%\bin*){[Environment]::SetEnvironmentVariable(PATH,%JRE_ROOT%\bin;$p,Machine)} %JRE_ROOT%\bin\java.exe -version endlocal这个脚本的关键点是幂等重复执行不会重复解压也不会重复往 PATH 里塞路径。if not exist判断目录-notlike判断 PATH 里是否已包含。这样即使误操作跑了两次也不会把 PATH 撑爆。5.4 验证基线是否生效的检查清单部署完不是跑一下java -version就完事。我一般会做一个检查清单每项都过了才算基线可用。检查项命令预期结果版本正确java -version输出包含 14.0.1.7架构正确java -XshowSettings:properties -versionos.arch amd64证书库可用keytool -list -cacerts -storepass changeit列出证书条目无报错类加载正常运行一个已编译的 Hello.class输出预期文本模块完整java --list-modules包含程序需要的模块环境变量echo %JAVA_HOME%指向解压目录这张表可以贴在部署文档里每台机器部署完逐项打勾。看起来繁琐但比服务上线后半夜被叫起来排查要划算得多。5.5 一个我踩过的坑别在 PATH 里留尾部反斜杠最后说一个血泪教训。有一次我在脚本里写set PATH%JRE_ROOT%\bin\;%PATH%注意bin后面多了一个反斜杠。大部分时候没问题但某些老程序的启动脚本会拼接路径多一个反斜杠导致C:\java\jre-14.0.1.7\bin\\java.exe这种双反斜杠路径Windows 有时能解析有时直接报“系统找不到指定的路径”。排查了半天才发现是尾部反斜杠。从那以后我所有 PATH 拼接都严格检查结尾不加多余分隔符。这个坑很小但很耗时间希望帮到你。本文还有配套的精品资源点击获取