简介：本资源为 Java 14 的 OpenJDK JRE 运行环境安装包，面向需要在 Windows 平台部署 Java 运行时的开发者、测试人员及运维人员，尤其适合 Red Hat 系 Windows 环境下的应用调试与兼容性验证。压缩包共 358 个文件，约 59.57MB，以 82 个 dll 动态链接库、25 个 exe 可执行程序、63 组 license 与 additional_license_info 授权说明为主，另含 policy 安全策略、properties 配置、cacerts 证书库、modules 模块描述及 release 版本信息等，完整覆盖 JRE 运行所需的二进制、授权与配置组件。目前已有 622 人学习下载，可作为搭建 Java 14 运行环境的可靠来源。包内目录结构规范，便于快速定位运行时库、安全策略与证书配置，适合用于本地开发调试、依赖 Java 14 的应用部署及版本兼容性排查，帮助读者省去自行编译或四处搜集组件的麻烦。
1. 从一个压缩包名说起：Java 14 的 Windows 构建到底装了什么
java-14-openjdk-jre-14.0.1.7-1.windows.redhat.x86_64.zip这个文件名，第一眼看过去像是一串随机字符的堆叠，但它其实是一份完整的“身份证”。拆开来看：java-14是大版本，openjdk是上游实现，jre说明这是运行时环境而非完整 JDK，14.0.1.7-1是补丁版本与构建号，windows是目标平台，redhat是构建方，x86_64是架构。很多做 Java 桌面工具、内网服务或者嵌入式 Windows 设备的同行，都会在某个时刻遇到这种由第三方厂商重新打包的 JRE 压缩包——它不来自 Oracle 官网，也不走常规安装器，而是一个解压即用的绿色目录。
这篇文章要解决的，就是当你手里只有这样一个 zip 时，怎么把它变成可复现、可维护、可排错的运行时环境。适合谁看？适合需要在 Windows 机器上批量部署 Java 14 应用、又不想装完整 JDK 的运维和开发；也适合想搞清楚 OpenJDK 各发行版差异、避免踩到“版本号看着一样、行为却不同”这个坑的工程师。我不会假设你手里有源码包或者官方文档，所有步骤都基于这个压缩包本身能提供的东西来推演。
2. 解压之后先别急着配环境变量：目录结构与版本核对
拿到压缩包，很多人第一反应是解压到C:\Program Files\Java然后配JAVA_HOME。这个习惯本身没错，但在 Java 14 这个时间点上，第三方构建的目录布局和 Oracle 老版本有明显差异，先看清楚再动手能省掉后面很多返工。
2.1 解压后的标准目录树与关键文件
把 zip 解压到一个临时路径，比如D:\tmp\jre14，你会看到类似下面的结构。不同构建方可能略有出入，但核心目录是一致的：
jre14/ ├── bin/ │ ├── java.exe │ ├── javaw.exe │ ├── keytool.exe │ └── server/ │ └── jvm.dll ├── conf/ │ ├── net.properties │ ├── security/ │ │ └── java.security │ └── logging.properties ├── lib/ │ ├── modules │ ├── jrt-fs.jar │ └── server/ ├── legal/ └── release这里有几个文件值得单独说。release是一个纯文本文件，里面记录了JAVA_VERSION、IMPLEMENTOR、OS_NAME、OS_ARCH等键值对，它是核对构建来源最可靠的东西，比文件名更可信。conf/security/java.security控制着加密策略和证书信任链，Java 14 已经默认禁用了 TLS 1.0 和 1.1，如果你的老系统还在用这两个协议，这里就是第一个翻车点。lib/modules是 jlink 之后的模块化运行时镜像，Java 9 以后 JRE 不再是一个大 rt.jar，而是这个文件承载了所有标准模块。
提示：不要用文件管理器直接双击
java.exe来验证安装，那样只会弹出一个空窗口然后消失。正确做法是开命令行。
2.2 用 release 文件和 java -version 交叉验证
先进入bin目录，执行下面两条命令。第一条读release文件，第二条让 JVM 自报家门：
# 进入解压后的 bin 目录 cd /d D:\tmp\jre14\bin # 查看构建元数据 type ..\release # 查看运行时版本 java.exe -versionrelease文件里你会看到类似JAVA_VERSION="14.0.1"和IMPLEMENTOR="Red Hat"这样的行。java -version的输出则类似：
openjdk version "14.0.1" 2020-04-14 OpenJDK Runtime Environment 18.9 (build 14.0.1+7) OpenJDK 64-Bit Server VM 18.9 (build 14.0.1+7, mixed mode, sharing)注意括号里的build 14.0.1+7，这个+7就是构建号，对应文件名里的.7-1中的7。如果release文件里的版本和java -version对不上，说明压缩包在传输或解压过程中被污染了，别犹豫，重新下载。这一步看起来多余，但我见过至少三次因为压缩包损坏导致ClassNotFoundException却查了半天的案例。
2.3 为什么 JRE 14 不再需要单独装 jre 目录
从 Java 11 开始，Oracle 和 OpenJDK 都取消了独立的 JRE 分发，你下载的 JDK 里通过 jlink 可以生成自定义运行时。而这个压缩包本身就是别人已经 jlink 好的产物，所以它没有jmods目录，也没有javac.exe。这意味着你不能用它编译 Java 代码，只能运行已经编译好的.class或.jar。如果你的场景里需要动态编译，比如某些脚本引擎或者 JSP 容器，这个包是不够的，必须换完整 JDK。这一点在选型阶段就要确认清楚，否则部署到一半才发现缺编译器，那就只能走回头路。
3. 在 Windows 上把 JRE 14 跑起来：环境变量与最小验证
目录看明白了，接下来就是让它能被系统和其他程序找到。Windows 上配置 Java 环境有两个层面：一是给当前用户或系统加JAVA_HOME和PATH，二是让依赖 Java 的应用程序能通过注册表或配置文件定位到运行时。第三方构建的 JRE 通常不写注册表，所以显式配置是必须的。
3.1 设置 JAVA_HOME 与 PATH 的正确姿势
假设你把解压后的目录移动到了C:\Tools\jre-14.0.1。用管理员权限打开 PowerShell，执行以下命令。这里用setx而不是临时set，是为了让配置持久化：
# 设置 JAVA_HOME，注意路径不要带尾部反斜杠 setx JAVA_HOME "C:\Tools\jre-14.0.1" /M # 把 bin 目录追加到系统 PATH $oldPath = [Environment]::GetEnvironmentVariable("Path", "Machine") $newPath = $oldPath + ";%JAVA_HOME%\bin" [Environment]::SetEnvironmentVariable("Path", $newPath, "Machine")/M表示写入系统级变量，需要管理员权限。如果你只想给当前用户配，去掉/M并把"Machine"换成"User"。这里有个血泪经验：JAVA_HOME的值不要带结尾的反斜杠，也不要带bin，很多构建工具（比如某些版本的 Gradle 和 Maven 插件）会自己拼接\bin\java.exe，你多写一个斜杠就会变成C:\Tools\jre-14.0.1\\bin\java.exe，虽然 Windows 通常能容忍，但个别脚本会直接报路径无效。
配置完成后，必须新开一个命令行窗口，旧窗口的环境变量不会刷新。然后执行：
echo %JAVA_HOME% java -version如果echo输出的路径正确，java -version也能打印出 14.0.1，说明环境变量生效了。
3.2 用最小 Java 程序验证运行时完整性
光看版本号还不够，得实际跑一个类加载和标准库调用的流程。写一个最简单的测试类，编译工作可以在别的机器上用完整 JDK 完成，这里只验证运行：
// MiniCheck.java public class MiniCheck { public static void main(String[] args) { // 打印运行时版本 System.out.println("Runtime: " + Runtime.version()); // 触发标准库中的加密模块，验证 modules 文件完整 try { javax.crypto.Cipher c = javax.crypto.Cipher.getInstance("AES/GCM/NoPadding"); System.out.println("Crypto OK: " + c.getAlgorithm()); } catch (Exception e) { System.out.println("Crypto FAIL: " + e.getMessage()); } // 触发网络模块，验证 conf 目录可读 System.out.println("HTTP Client: " + java.net.http.HttpClient.newHttpClient().version()); } }用完整 JDK 编译成MiniCheck.class，然后拷贝到目标机器上，执行：
java -cp . MiniCheck预期输出里应该包含Runtime: 14.0.1+7、Crypto OK: AES/GCM/NoPadding和HTTP Client: HTTP_2。如果加密模块报NoSuchAlgorithmException，大概率是lib/modules被裁剪过，这个 JRE 包不完整；如果 HTTP 客户端报错，检查conf/net.properties是否存在。这个最小验证能覆盖模块系统、加密库和网络配置三个最容易出问题的区域，比单纯跑-version有意义得多。
3.3 让 Windows 服务或计划任务找到这个 JRE
很多内网工具是以 Windows 服务方式运行的，服务账户通常是LocalSystem，它的环境变量和当前登录用户不一样。如果你在用户级配了JAVA_HOME，服务是读不到的。稳妥做法是在服务的启动脚本里硬编码完整路径，或者用setx /M写系统级变量。另外，Java 14 在 Windows 上默认使用%TEMP%作为临时目录，服务账户的临时目录可能是C:\Windows\Temp，权限不足时会导致java.io.IOException: Unable to create temporary file。可以在启动参数里显式指定：
java -Djava.io.tmpdir=C:\Tools\jre-14.0.1\tmp -jar app.jar提前建好tmp目录并给服务账户写权限，能避免一类很隐蔽的启动失败。
4. 避坑与排查：JRE 14 在 Windows 上的五个高频翻车点
即使版本核对无误、环境变量也配了，实际跑起来还是会遇到一些和旧版本不一样的行为。下面这五条是我在多个项目里反复踩过的，按“现象 → 原因 → 解决”整理，你可以直接对照排查。
4.1 现象：启动报 “Unrecognized VM option 'UseConcMarkSweepGC'”
原因很直接：CMS 垃圾回收器在 Java 14 里已经被彻底移除，Java 9 标记废弃，14 正式删除。很多老应用的启动脚本里还带着-XX:+UseConcMarkSweepGC，在 Java 8 上跑得好好的，换到 14 直接启动失败。
解决：把启动参数里的 CMS 相关选项删掉，换成 G1 或 ZGC。Java 14 默认就是 G1，通常不需要显式指定。如果确实需要低延迟，可以加-XX:+UseZGC，但注意 ZGC 在 Windows 上的支持是实验性的，需要额外加-XX:+UnlockExperimentalVMOptions。更稳妥的做法是先用默认 G1 跑起来，观察 GC 日志再决定要不要换。
4.2 现象：TLS 握手失败，日志显示 “No appropriate protocol”
原因：Java 14 的java.security里默认禁用了 TLS 1.0 和 TLS 1.1，很多内网老服务只支持这两个协议。这不是 bug，是安全策略的收紧。
解决：优先推动服务端升级到 TLS 1.2。如果短期内改不了，可以临时在conf/security/java.security里找到jdk.tls.disabledAlgorithms这一行，把TLSv1, TLSv1.1删掉，然后重启应用。但这样做会降低安全性，只建议在隔离内网里作为过渡。另一个更干净的办法是在启动参数里指定-Djdk.tls.client.protocols=TLSv1.2，强制客户端只用 1.2，如果服务端不支持就直接失败，避免降级到不安全的协议。
4.3 现象：java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter
原因：JAXB 和 JAX-WS 这些 Java EE 模块在 Java 11 里就被移出了标准库，Java 14 自然也没有。很多老代码直接 import 了javax.xml.bind包，编译时用的是旧 JDK，运行时换到 14 就炸了。
解决：如果应用是你自己维护的，加 Maven 依赖jakarta.xml.bind:jakarta.xml.bind-api和org.glassfish.jaxb:jaxb-runtime。如果是第三方 jar 没法改代码，可以把这两个 jar 放到lib/ext目录下——但 Java 14 已经不支持扩展目录机制了，正确做法是用-cp或-classpath把 jar 加进去，或者用-Xbootclasspath/a:追加。后者在 Java 14 上仍然可用，但属于内部 API，未来版本可能移除，能改代码就改代码。
4.4 现象：中文乱码，控制台输出变成问号或方块
原因：Windows 控制台默认代码页是 GBK（936），而 Java 14 在启动时如果没指定file.encoding，会跟随系统区域设置。但很多第三方构建的 JRE 在conf里没有正确设置，导致System.out的编码和实际控制台不匹配。
解决：启动时显式指定编码。Java 14 推荐用-Dfile.encoding=UTF-8，同时把控制台代码页切到 65001：
chcp 65001 java -Dfile.encoding=UTF-8 -jar app.jar注意chcp只影响当前窗口，服务里跑的话需要在脚本开头执行。另外，-Dfile.encoding在 Java 18 之后行为有变化，但 14 上这个参数是有效的。
4.5 现象：解压后java.exe被杀毒软件直接隔离
原因：第三方构建的 JRE 压缩包里，bin/server/jvm.dll和java.exe没有数字签名，或者签名不被国内杀软信任。这不是 Java 本身的问题，是分发渠道的问题。
解决：把解压目录加入杀毒软件的白名单，或者用完整 JDK 自己 jlink 一个运行时。如果必须用这个包，建议在部署前先在一台干净机器上做全量扫描，确认没有捆绑其他东西。另外，解压时用命令行tar -xf或 7-Zip，不要用 Windows 自带的解压向导，后者有时会丢失文件属性导致java.exe无法执行。
5. 进阶：用 jlink 和 jpackage 把这个 JRE 变成可分发产物
如果你不只是想在一台机器上跑，而是要把 Java 14 应用分发给没有 Java 环境的 Windows 用户，那这个 JRE 压缩包可以作为一个起点。Java 14 自带了jpackage工具（孵化阶段），配合jlink可以做出自带运行时的安装包。不过注意，jpackage在完整 JDK 里才有，这个 JRE 包里没有，所以你需要另外准备一个同版本的完整 JDK 来做构建，构建产物再分发。
5.1 用 jlink 裁剪出更小的运行时
假设你的应用只用到java.base、java.sql和java.logging三个模块，可以用完整 JDK 里的jlink生成一个精简运行时：
jlink --module-path "C:\Tools\jdk-14.0.1\jmods" ^ --add-modules java.base,java.sql,java.logging ^ --output "C:\build\mini-jre" ^ --strip-debug ^ --no-header-files ^ --no-man-pages ^ --compress=2--strip-debug去掉调试符号，--compress=2启用压缩，--no-header-files和--no-man-pages去掉 C 头文件和手册页。这样生成的mini-jre通常只有 40MB 左右，比完整 JRE 小一半以上。参数里的--module-path必须指向完整 JDK 的jmods目录，不能用 JRE 的lib/modules代替，因为jmods里包含模块的完整元数据。
5.2 用 jpackage 打成 exe 安装包
jpackage可以把应用 jar 和运行时一起打成一个.exe或.msi。下面是一个最小命令：
jpackage --type exe ^ --name MyApp ^ --input "C:\build\app" ^ --main-jar app.jar ^ --main-class com.example.Main ^ --runtime-image "C:\build\mini-jre" ^ --win-console ^ --win-dir-chooser--input是存放应用 jar 的目录，--runtime-image指向上一步 jlink 生成的运行时，--win-console表示保留控制台窗口（调试时有用，正式发布可以去掉），--win-dir-chooser允许用户选择安装目录。生成的安装包会自带运行时，用户机器上不需要预装 Java。这里有个坑：jpackage在 Java 14 上需要 WiX Toolset 3.x 才能生成 exe，如果没装会报错，提前在构建机上装好。
5.3 验证分发产物是否真的独立
打包完成后，在一台没有 Java 环境的 Windows 虚拟机上安装，然后检查两件事：一是应用能否正常启动，二是安装目录下是否存在runtime子目录。用where java确认系统 PATH 里没有其他 Java，再运行应用。如果启动失败，查看安装目录下的app\MyApp.cfg文件，里面记录了运行时路径和 JVM 参数，可以手动调整。我一般会在这个阶段故意把系统里的 Java 全部卸载，确保测试环境干净，否则很容易出现“在我机器上能跑”的玄学问题。
最后说一个我自己的习惯：每次拿到这种第三方构建的 JRE 压缩包，我都会先算一遍 SHA256，和分发方提供的校验值比对，然后把这个哈希值记在部署文档里。后面如果出现运行时行为异常，第一件事就是重新校验文件完整性。这个动作花不了两分钟，但能排除掉一大类“莫名其妙”的故障。希望帮到你。
本文还有配套的精品资源，点击获取
