Java不再是那个"稳妥的选择"了

提到Java，很多人脑子里蹦出来的第一个词是"稳"。稳到什么程度？稳到"选Java不会丢饭碗"成了业界共识。稳到几十年来，新语言们在前台抢尽风头，Java在后台默默干活。

但2026年2月，风向变了。

这不是什么大张旗鼓的发布会，没有炫酷的demo视频，甚至连头条都算不上。但如果你仔细看这周的Java生态动态，会发现一个现象：我们正在见证的，不是修修补补的小更新，而是一系列能从根本上改变Java运行方式的基础设施升级。

从OpenJDK的延迟常量，到Chicory让WebAssembly跑在JVM上，Java正在悄悄搭建下一个十年的技术底座。

延迟常量：省钱的智慧

问题在哪

假设你家开了一家餐厅。每天早上，你都会提前准备好所有食材，不管今天有没有客人来。结果呢？有些食材放坏了都没用上，白白浪费了成本。

Java的传统常量初始化就是这么干的：

// 不管用不用，先初始化再说
public static final ExpensiveObject INSTANCE = new ExpensiveObject();

这种"提前准备"的策略，在大型应用里会带来一个头疼的问题：启动时间越来越长。微服务、容器化部署，每个毫秒都算数。你的应用可能只用了10%的功能，却要为100%的初始化买单。

新的思路

JEP 531（延迟常量）的思路很简单：用到再准备，准备完就记住。

// 用到才初始化，初始化一次后永久缓存
private static final LazyConstant<ExpensiveObject> LAZY_INSTANCE = 
    LazyConstant.of(ExpensiveObject::new);

public static ExpensiveObject getInstance() {
    return LAZY_INSTANCE.get(); // 第一次调用时才计算
}

这就像你改成"有客人点菜再备料"的模式。备料完成后记下来，下次同样的菜直接用。

这次的更新

JEP 531从草案升级到了候选状态，这是第三次预览。两个重要变化：

一是移除了isInitialized()和orElse()方法。为什么？因为这两个方法违背了设计初衷。延迟常量的核心价值是"你只管用，不用操心它有没有准备好"，而不是让你去检查状态。

二是新增了ofLazy()工厂方法，可以创建延迟初始化的集合：

List.ofLazy(...)
Set.ofLazy(...)
Map.ofLazy(...)

这些集合有个特点：初始化前是延迟的，初始化后是不可变的。线程安全、内存高效，从零扩展到生产环境，不会在堆空间上浪费。

谁最受益

如果你在搞微服务、云原生应用，或者任何有大类路径的项目，这个特性直接解决启动时间膨胀的问题。在容器环境里，把初始化推迟到第一次请求，可能就是你达标和超标SLA的区别。

TornadoVM 3.0：Java终于能借GPU的力了

从研究项目到生产可用

TornadoVM 3.0.0正式发布了。这不是简单的版本号升级，而是一个信号：这个项目从"有意思的研究"毕业了，现在是"生产可用的加速层"。

简单说，TornadoVM让你用Java写代码，然后自动在GPU上并行执行。不需要学CUDA，不需要换语言。

写法长什么样

TaskGraph taskGraph = new TaskGraph("saxpy")
    .transferToDevice(DataTransferMode.FIRST_EXECUTION, x, y)
    .task("t0", SAXPY::compute, alpha, x, y)
    .transferToHost(DataTransferMode.EVERY_EXECUTION, y);

ImmutableTaskGraph immutableTaskGraph = taskGraph.snapshot();
TornadoExecutionPlan executor = new TornadoExecutionPlan(immutableTaskGraph);
executor.execute();

这段代码会在你的GPU上自动并行执行，内存管理由TornadoVM运行时处理。机器学习推理、金融模拟、科学计算，这些场景的性能天花板被抬高了，而你用的还是熟悉的Java语法。

其他变化

团队把--intellijinit这个CLI参数移除了。别担心，这不是功能砍掉，而是工作流优化。IDE配置现在只对开发者开放，普通用户拿到的是更干净的命令行界面。

另外，TornadoVM 3.0现在为JDK 21和JDK 25分别维护发布轨道。这背后的考量很实际：企业用LTS版本求稳，早期采用者想尝鲜，两边都得照顾。

NetBeans 29：老IDE的新活力

在VS Code和IntelliJ统治市场的今天，Apache NetBeans还在持续更新。29版本证明了一件事：“成熟"和"停滞"是两码事。

最大的改进是项目初始化性能。如果你开过大型Maven多模块项目，看着进度条一点点爬，你会懂这个改进的含金量。NetBeans 29把项目元数据加载推迟到你真正操作某个模块时才执行，大型代码库的启动时间明显缩短。

还有个小变化：现在支持Codeberg项目了。开发者迁移到Forgejo这类平台时，NetBeans已经准备好了。

Open Liberty：安全补丁和工具链支持

Open Liberty 26.0.0.2有两个值得注意的更新。

Java工具链支持

终于来了。以前有个让人头疼的问题：代码兼容JDK 21，但切换后构建失败。原因？构建工具用的JDK和运行时用的不是同一个版本。

现在你可以明确分开：

  • 构建JDK：Maven或Gradle用来编译
  • 运行时JDK：Open Liberty用来跑应用

不再有神秘的UnsupportedClassVersionError在生产环境冒出来吓人。

安全漏洞修复

CVE-2025-14914，一个远程代码执行漏洞，影响17.0.0.3到26.0.0.1版本。攻击路径是ZIP文件上传中的路径遍历，能导致任意文件覆盖。

如果你在受影响版本上，赶紧升级。这种漏洞会让安全团队睡不着觉。

Quarkus 3.32：更快的启动，更优雅的告别

Project Leyden集成

Quarkus 3.32集成了Project Leyden，这是Oracle改善Java启动时间和内存占用的项目。

对Quarkus开发者意味着什么？

  • 预计算优化数据：昂贵的启动计算结果可以缓存
  • 更快的首请求时间：对serverless和scale-to-zero场景至关重要
  • 更低的内存占用：共享更多数据

这不是Quarkus专属的特性，而是整个Java生态的方向。当Leyden在未来JDK版本中成为标准，Quarkus用户已经准备好了。

更优雅的关闭

部署过微服务的人都知道这个痛点：Kubernetes发送SIGTERM，Pod开始关闭，但负载均衡器还在往里导流量。结果？日志里一堆HTTP 503，用户一脸懵。

Quarkus 3.32改进了关闭流程，最大限度减少关闭期间的503响应。一个小改动，生产可靠性指标上一个台阶。

Micronaut 4.10.9：稳扎稳打

没有大版本号的喧嚣，Micronaut继续它的维护节奏。4.10.9专注于：

  • Servlet模块：传统servlet容器部署的bug修复
  • Spring集成：更好的迁移兼容
  • MCP集成：Model Context Protocol的更新

这是那种你周二下午部署也不会焦虑的版本。没有破坏性变更，只有累积的修复让生产环境更稳定。

Chicory 1.7.0：WebAssembly与JVM的握手

WebAssembly承诺"一次编写，到处运行”，主要针对Web。Chicory把这个承诺扩展了：在你跑Java的地方，也能跑WebAssembly。

1.7.0版本带来了两个重要的规范支持：

GC提案支持

WebAssembly的垃圾回收提案允许模块直接使用结构体和数组，不需要自己管理内存。这意味着编译成Wasm的语言可以保留自己的对象模型，而不是被迫线性化。

组件模型提案

这是WebAssembly的模块系统。有了它，Wasm模块之间可以用清晰的语言无关接口通信，而不是共享内存。

为什么重要

Chicory让WebAssembly成为Java生态的一等公民。你可以在JVM上安全地运行用其他语言编译的Wasm模块，享受沙箱隔离，同时保留Java生态的工具链和工作流。

这不是"Java要被取代"的信号，而是"Java变得更开放"的证明。互操作性正在成为第一等公民。

写在最后

回顾这周的Java动态，一个趋势很清晰：Java不再只是追赶现代开发的脚步，它在定义企业级现代开发的样子。

那个支撑了2000年代Web的语言，正在把自己定位成支撑2030年代AI驱动、云原生、边缘计算世界的语言。

最妙的是什么？你不需要重写应用就能受益。这些改进通过框架、库和JVM增强实现，它们会去适配你现有的代码，不是让你去适配它们。

这不止是稳。这是聪明。

常见问题

Q: Java延迟常量和传统的懒加载有什么区别？

A: 最大的区别在于线程安全和语义清晰。传统懒加载需要你自己处理并发问题，容易出错。延迟常量由JVM保证线程安全，而且语义上就是"用的时候再准备"，不需要额外的null检查或条件判断。

Q: TornadoVM适合什么场景？

A: 数据并行计算密集型任务。比如矩阵运算、图像处理、机器学习推理、金融模拟。如果你的代码有大量循环且每次迭代相互独立，GPU加速效果会很明显。

Q: Chicory和GraalVM的Polyglot有什么区别？

A: Chicory专注于WebAssembly，提供沙箱隔离和跨语言互操作。GraalVM的Polyglot是更通用的多语言运行时。Chicory更轻量，适合嵌入场景；GraalVM功能更全面，但启动开销更大。

Q: JEP 531什么时候能正式使用？

A: JEP 531目前处于Candidate状态，是第三次预览。按照JEP流程，Candidate状态意味着已经通过初步审查，正在等待最终集成。预计会在未来的JDK版本中正式发布，可能是JDK 26或JDK 27 LTS。

Q: Open Liberty的CVE-2025-14914漏洞影响范围有多大？

A: 影响Open Liberty 17.0.0.3到26.0.0.1所有版本。攻击者可以通过特制的ZIP文件上传触发路径遍历，实现远程代码执行。如果你的应用有文件上传功能且运行在受影响版本，建议立即升级到26.0.0.2或更高版本。