Java 27 发布:后量子密码能力、预览特性与生态升级如何落地

2026-09-16 15 预计阅读时间: 1 分钟
来源: infoq.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间:10 分钟

Java 27 是继 JDK 25 之后的第二个非 LTS 版本。此次发布包含 9 项 JEP,其中 5 项仍处于预览或孵化阶段。它的重点并不只是增加语言语法,而是同时推进后量子密码安全、未来语言能力,以及 Helidon、JavaFX 等 Java Verified Portfolio 项目的演进。

对生产团队来说,这类非 LTS 版本的价值主要有两个:提前验证未来会进入 LTS 的能力,以及尽早发现安全、工具链和依赖兼容性问题。它更适合作为技术验证基线,而不是在没有评估的情况下直接替换现有 LTS 运行时。

后量子密码不是“换一个算法名”

Java 27 对后量子密码能力的强化,回应的是一个长期迁移问题:一旦足够强的量子计算机出现,传统公钥算法可能无法继续提供预期的安全性。真正的工程挑战并非调用一次新的密码 API,而是梳理算法在整个系统中的传播路径:

  • TLS 终止发生在 JDK、反向代理、服务网格还是云负载均衡器;
  • 证书、密钥库、签名令牌和归档数据使用了哪些算法;
  • 上下游系统及硬件安全模块是否支持相同能力;
  • 是否需要在迁移期间保留经典算法与后量子算法的组合方案;
  • 已加密并长期保存的数据是否存在“现在收集、未来解密”的风险。

升级 JDK 并不等于应用自动获得端到端的后量子安全。协议协商、证书体系、密码提供者和对端实现都必须兼容,具体可用算法也应以 Java 27 实际安装的安全提供者文档为准。

可以先用下面的小程序盘点当前运行时公开的密码服务。它不会修改系统配置,也不能替代合规测试,但适合放进升级验证流水线。

cat > CryptoInventory.java <<'JAVA'
import java.security.Provider;
import java.security.Security;
import java.util.List;
import java.util.Locale;
import java.util.TreeSet;

public class CryptoInventory {
    private static final List<String> SERVICES = List.of(
        "KEM", "KeyPairGenerator", "Signature", "Cipher"
    );

    private static final List<String> PQC_MARKERS = List.of(
        "ML-KEM", "ML-DSA", "SLH-DSA"
    );

    public static void main(String[] args) {
        System.out.println("Runtime: " + System.getProperty("java.runtime.version"));

        System.out.println("\nInstalled security providers:");
        for (Provider provider : Security.getProviders()) {
            System.out.printf("- %s %s%n", provider.getName(), provider.getVersionStr());
        }

        System.out.println("\nAlgorithms matching common PQC names:");
        boolean found = false;

        for (String service : SERVICES) {
            TreeSet<String> matches = new TreeSet<>();
            for (String algorithm : Security.getAlgorithms(service)) {
                String upper = algorithm.toUpperCase(Locale.ROOT);
                if (PQC_MARKERS.stream().anyMatch(upper::contains)) {
                    matches.add(algorithm);
                }
            }

            if (!matches.isEmpty()) {
                found = true;
                System.out.println(service + ": " + matches);
            }
        }

        if (!found) {
            System.out.println("No matching names found; inspect provider documentation and aliases.");
        }
    }
}
JAVA

javac --release 27 CryptoInventory.java
java CryptoInventory

如果程序没有匹配到算法,不能直接得出“Java 27 不支持后量子密码”的结论。提供者可能使用别名,某些能力也可能需要额外模块、配置或第三方 provider。这个程序的作用是建立可重复的运行时清单,而不是给出安全认证结果。

9 项 JEP 中有 5 项仍未定型,启用方式必须显式化

超过一半的 JEP 仍处于预览或孵化阶段,这是 Java 27 最值得注意的发布信号之一。预览特性允许开发者验证未来语言或虚拟机设计,但它们并不承诺跨版本保持源代码、字节码或 API 兼容。

团队应把三类代码分开管理:

  1. 生产代码只使用正式特性;
  2. 实验模块可以启用预览特性,但不能无意间成为公共依赖;
  3. 孵化 API 应隔离在适配层后面,避免业务代码直接扩散对实验模块的引用。

下面的命令展示了 Java 27 项目启用预览能力时必须保持一致的编译和运行参数。示例程序本身只使用稳定语法,你可以把类体替换为正在评估的 Java 27 预览特性。

cat > PreviewProbe.java <<'JAVA'
public class PreviewProbe {
    public static void main(String[] args) {
        System.out.println("Preview test on " + Runtime.version());
    }
}
JAVA

javac --release 27 --enable-preview PreviewProbe.java
java --enable-preview PreviewProbe

使用 Maven 时,可以显式固定编译参数,并确保测试进程同样开启预览支持:

<properties>
  <maven.compiler.release>27</maven.compiler.release>
</properties>

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-compiler-plugin</artifactId>
      <version>3.13.0</version>
      <configuration>
        <enablePreview>true</enablePreview>
      </configuration>
    </plugin>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-plugin</artifactId>
      <version>3.5.2</version>
      <configuration>
        <argLine>--enable-preview</argLine>
      </configuration>
    </plugin>
  </plugins>
</build>

运行前需要确认插件版本符合组织的制品仓库策略。构建、单元测试、集成测试、IDE 和部署启动命令都应使用相同的预览设置;否则常见结果是本地编译成功,CI 或生产启动时却拒绝加载相应 class 文件。

Helidon 与 JavaFX 应独立做兼容性验证

此次发布脉络还涉及 Helidon 27 和 JavaFX 27。服务端框架、桌面 UI 工具包与 JDK 虽然属于同一 Java 生态,但版本号接近并不意味着可以不经测试地同步升级。

服务端团队应重点检查:

  • Helidon 应用的启动、配置解析、HTTP 客户端和服务器行为;
  • TLS、证书库及安全提供者在新 JDK 上的差异;
  • 容器基础镜像、GC 参数、可观测性代理和原生库;
  • 反射、字节码增强与模块边界相关警告。

JavaFX 应用则需要覆盖:

  • JavaFX 模块与 JDK 的打包组合;
  • Windows、macOS 和 Linux 上的图形及原生依赖;
  • CSS、字体、媒体、WebView 和辅助功能;
  • 使用 jlink 或安装包工具生成的运行时镜像。

更稳妥的做法是维护一张明确的验证矩阵,而不是只测试开发者电脑上的一种组合:

层级 当前基线 Java 27 候选组合 验证内容
JDK 现有 LTS JDK 27 编译、测试、GC、启动参数
服务端 当前 Helidon 版本 Helidon 27 候选 HTTP、TLS、配置、监控
桌面端 当前 JavaFX 版本 JavaFX 27 UI、媒体、原生打包
安全 当前 provider Java 27 provider 组合 算法、密钥、互操作性

推荐的采用节奏

Java 27 更适合以“观察—验证—隔离—决策”的方式引入:

  • 在 CI 中增加 Java 27 构建任务,但暂时保留现有 LTS 作为发布基线;
  • 对 9 项 JEP 分类记录,只让明确批准的实验模块使用预览或孵化能力;
  • 生成密码算法、provider、TLS 和证书依赖清单,避免把后量子安全简化为 JDK 版本升级;
  • 分别测试 Helidon、JavaFX、代理、插件和原生依赖,不假设版本号相同就代表兼容;
  • 为实验代码设置退出条件:特性变化、性能不达标或下一版本移除时能够快速回退。

Java 27 的意义在于让团队更早接触下一阶段的安全模型和语言设计。稳健的采用方式不是追逐每个新特性,而是把非 LTS 版本变成持续兼容性测试的一部分,在未来 LTS 到来前消化迁移风险。


相关推荐