Java Runtime.Version 如何比较运行时版本：feature、interim、update 与预览版本边界

服务启动时只允许 Java 21 及以上版本，最容易踩的坑不是读取版本，而是拿 "21.0.10"、"21.0.9" 做字符串比较。真正可靠的做法是让 Runtime.Version.parse 负责解析，再用数值字段和比较方法判断；预览版还要单独读取 pre()，不能把它混进普通更新号。

把版本当成 Runtime.Version 比较：先检查 feature() 这类数值字段，再按是否接受预览版选择 compareTo 或 compareToIgnoreOptional。

线上误判从哪里开始：把版本号当成普通字符串

一个插件加载器曾把配置项 minimumJava 读成字符串，再用 compareTo 做门禁。结果是 "21.0.10" 被排在 "21.0.9" 前面，低版本反而可能通过检查。这个错误很隐蔽，因为大多数开发机只覆盖了个位数更新号。

第二个误区是把 21-ea 和正式版当成同一种版本。预览版适合测试环境，不一定满足生产运行时的发布策略；比较前必须先明确“只要 feature 足够”还是“必须是正式版”。

Runtime.Version 的字段如何对应 JDK 版本字符串

JDK 10 之后的版本字符串采用 feature.interim.update.patch 结构。现实中的字符串可以省略末尾零段，例如 25.0.1 没有把 patch 再写出来。不要把字段名称和旧版 Java 的 major、minor 习惯混用。

这些方法返回的是可直接比较的数值。version() 返回不含可选信息的版本号列表；build() 返回可选的构建号。做最低版本判断时，优先用公开方法组合表达意图，不要解析 Runtime.version().toString() 的显示文本。

用 parse 和 compareTo 修复最低版本门禁

下面的代码把配置文字转换为 Runtime.Version，并用当前 JVM 版本和目标版本做比较。parse 抛出 IllegalArgumentException 时，应该把配置视为无效，而不是悄悄回退到当前版本。

import java.lang.Runtime;

public final class JavaVersionGate {
    public static boolean atLeast(String configured, Runtime.Version actual) {
        Runtime.Version minimum = Runtime.Version.parse(configured);
        return actual.compareTo(minimum) >= 0;
    }

    public static void main(String[] args) {
        Runtime.Version actual = Runtime.version();
        System.out.println(actual.feature());
        System.out.println(atLeast("21.0.10", actual));
    }
}

这里的控制流很短，但边界要说清楚：parse 负责输入格式，compareTo 负责顺序，调用方负责把非法配置转成启动失败或明确告警。不要把 feature() 相等当作全部条件，否则更新号更低的运行时也会被放行。

预览版要先分流，再决定比较规则

如果生产环境拒绝预览版，可以把版本门禁拆成两层：先看 pre() 是否存在，再做完整版本比较。这样业务规则比比较字符串后再猜后缀更清楚。

public static boolean accepts(Runtime.Version actual,
                               Runtime.Version minimum,
                               boolean allowPreview) {
    if (!allowPreview && actual.pre().isPresent()) {
        return false;
    }
    return actual.compareTo(minimum) >= 0;
}

有些工具只关心数值版本，不关心可选的预览、内部构建信息，这时可以评估 compareToIgnoreOptional 是否符合策略。它不是“更宽松的字符串比较”，而是明确忽略可选版本信息；团队应把这个选择写进配置说明和测试用例。

把异常输入和升级回归纳入验收

版本门禁至少要覆盖四组样例：同一 feature 的不同 update、带 patch 的完整版本、预览版以及非法文本。测试不要只断言 true/false，还要验证错误输入确实在边界处停止。

import static org.junit.jupiter.api.Assertions.*;
import java.lang.Runtime;
import org.junit.jupiter.api.Test;

class JavaVersionGateTest {
    @Test
    void comparesNumericUpdate() {
        var actual = Runtime.Version.parse("21.0.10");
        var minimum = Runtime.Version.parse("21.0.9");
        assertTrue(actual.compareTo(minimum) > 0);
    }

    @Test
    void rejectsMalformedInput() {
        assertThrows(IllegalArgumentException.class,
            () -> Runtime.Version.parse("jdk-latest"));
    }
}

如果应用同时支持多个 JDK 发行线，建议把版本判断封装在一个小类里，日志记录原始配置和解析后的 toString()，但不要依赖该显示文本的排列规则。升级时只需要回归这个类，插件加载、任务调度和数据库连接等业务代码不必各自实现一套解析逻辑。

相关问题

只判断 Runtime.version().feature() 够不够？

只做主版本兼容性检查时够用；涉及安全修复、JDK 更新号或补丁号时必须做完整的 Runtime.Version 比较。

parse 遇到非法版本应该怎么处理？

把它当成配置错误并给出字段名和示例格式。静默使用默认版本会让门禁失去意义。

预览版一定比正式版低吗？

不能只凭字符串顺序判断。是否接受预览版是运行环境策略，应先检查 pre()，再选择比较方法。

小结：让版本策略保持可读和可回归

Runtime.Version 解决的是版本结构和比较语义，不替业务决定“哪个版本可以上线”。把解析、预览分流、数值比较和非法配置处理分开，版本升级时才不会被一个看似普通的字符串排序拖进故障。