Java周刊2026W30 | 值类型JDK28预告、SpringAI2.0发布、Metropolis项目终结

29 阅读16分钟

Spring AI 2.0 GA、值类型JDK28预告、Metropolis终结、JHipster-Vitest迁移完成——本周Java生态重磅消息频出,同时Netflix分享了大规模服务拓扑构建经验

🌱 Spring生态

Spring Office Hours播客:S5E18——OpenAI、Anthropic和Spring AI 2.0最新动态

Spring AI 2.0现已正式发布,专门为Spring Boot 4和Spring Framework 7构建——为Java生态系统中的主导框架带来了原生级别的AI集成。Java开发者面临着碎片化的AI格局,OpenAI和Anthropic的快速迭代发布让人难以选择合适的工具并跟上变化的步伐。本期播客详细介绍了新的统一工具调用模型、渐进式工具发现机制,以及生产级AI应用中MCP支持的变化。

📦 版本发布

JHipster v9.2.0

JHipster 9.2.0完成了所有生成应用的前端向Vitest的迁移。生成代码中的每个bug和安全漏洞都可能级联为真正的生产环境漏洞,因此期待已久的测试运行器整合和后端验证加固对维护者来说至关重要。该版本涵盖了Vitest迁移的完成、增强的安全与验证机制、高影响度的生成修复以及生成器中持续的TypeScript清理工作。

Vert.x 5.1.5

Grails 7.2.1

Grails 7.2.1将三个长期独立维护的插件——spring-security、mail和redis——直接合并到核心框架中。这些模块多年来一直独立维护,造成了版本不匹配的难题和跨项目缓慢的安全补丁周期。该版本涵盖了合并整合、CI基础设施大修以及一个关键的OpenTelemetry CVE修复。

Micronaut Core 5.0.6

Micronaut Core 5.0.6作为一个针对性补丁发布,专门修复了代理默认实现中@Replaces匹配的回归问题。该bug破坏了代理场景中的依赖注入,可能导致生产应用中静默的bean解析失败。该版本涵盖了精确的修复方案以及从v5.0.5到v5.0.6的完整变更日志。

Piranha CMS 12.2版本

📖 文章与教程

考古学家的副驾驶

AI自信地为一份自奥巴马政府时期就未曾编译过的Java 1.5代码库生成了现代化的build.gradle和干净的HelloBlobStore.java——但所有这些都无法针对实际代码运行。“观光客提示(Tourist Prompt)”方法将LLM视为通用翻译器,产出了看似合理的答案,却在经年累积的代码尘埃面前不堪一击。文章揭示了如何通过基于Docker的验证和证据驱动的重构,将AI从一个自信的导游转变为真正的现代化合作伙伴。

让ServiceLoader真正可用:提供者工厂模式

Java的ServiceLoader要求无参构造函数,使得依赖注入在没有笨拙变通方法的情况下无法实现。开发者长期以来不得不依赖临时拼接的代理和初始化后注入的黑客手段,这掩盖了ServiceLoader本应提供的解耦能力。本文介绍了一种清晰的提供者工厂模式,将这种变通方法转化为JSON、JWT和支付实现中显式、可复用的设计方案。

你的Loom应用已悄然变回线程池:虚拟线程固定现场指南

你的Loom驱动应用可能已在不知不觉中降级为传统线程池。虚拟线程本应轻量且无界,但在特定条件——同步块、原生帧或某些I/O操作——下,它们会“固定(pin)”到载体线程上,重新制造出Loom本应解决的线程饥饿问题。本现场指南解释了如何在应用中检测固定现象、诊断根本原因,并应用正确的修复方案来恢复真正的虚拟线程行为。

我让GitHub Copilot分析Java应用,它找到了堆大小配置的bug并主动提出修复

我让GitHub Copilot对一个Java应用进行性能分析,它不仅找到了堆大小配置中的bug,还主动提出编写修复代码。堆配置错误是最常见却最难诊断的JVM性能问题之一——开发者常常花费数小时翻阅GC日志,或依赖照搬来的-Xmx参数。文章记录了一次真实性能分析过程,展示了Copilot从代码补全跃迁到运行时故障排查的能力,解释了它如何诊断堆大小问题以及生成的修复方案是什么样子的。

在Quarkus LangChain4j中通过OPA策略实现护栏

使用独立的LLM来检测提示注入攻击既消耗token又增加延迟——这正是LLM驱动应用最为敏感的资源。确定性的模式匹配更快更便宜,但嵌入应用代码中的正则规则脆弱且与发布周期紧密耦合。本文展示了如何在Quarkus LangChain4j中将Open Policy Agent(OPA)策略与基于LLM的护栏相结合,将明显的攻击路由到快速的声明式路径上,而将LLM留作最后手段。

Temporal之于你的代码,犹如数据库之于你的数据

Temporal为应用程序代码执行带来了数据库级别的持久性保障,而不仅仅是数据存储。如今的分布式系统在数据层处理可靠性问题,但应用逻辑仍然容易受到数据库早在数十年前就已解决的故障、重试和超时问题的影响。文章解释了Temporal的工作流引擎如何为你的代码提供与数据库为数据提供的相同的原子性、持久性和重放保障。

“这怎么可能行得通”:我在Temporal.io工作坊中学到的东西

一位开发者走进Temporal.io工作坊时,满心认为这个编排框架会在现实世界的复杂性面前崩溃。分布式工作流以脆弱著称——超时、重试和状态管理制造了无穷无尽的边界情况,让大多数编排尝试功亏一篑。工作坊揭示了Temporal的持久执行模型如何完全绕开这些故障模式,以及作者在实践中构建弹性工作流的经验教训。

F00jay播客第100期:当播主采访播主,以及他们的共同点

F00jay播客迎来了第100期——这是少数技术播客才能达成的里程碑,本期节目将话筒反转,采访其他Java播主。维持一档播客走过100期需要应对倦怠、技术难关和不断演进的内容策略,这些都是大多数听众看不到的。本期节目邀请了资深Java播主分享他们为何开始、在路上遇到了什么困难,以及多年制作面向开发者节目所积累的宝贵经验。

Valhalla,就是现在!

经过十余年的期待,OpenJDK Project Valhalla的值类型终于将在JDK 28中预览。Java的类型系统长期以来一直存在基本类型与对象之间的裂痕,迫使开发者在两者都不需要的地方承受装箱开销和身份包袱。文章明确了值类型将在JDK 28中带来什么——同样重要的是,它们不会带来什么,因为通往Valhalla的道路仍然漫长,仅凭值类型无法满足该项目的所有期望。

Quarkus Insights #254:领域驱动设计与六边形架构——第二部分

一次DDD会议引发了太多问题,以至于演讲者无法讲完自己的材料——于是他构建了一个可用的征稿应用作为后续内容。将领域驱动设计和六边形架构从理论转化为生产代码仍然是一个挑战,尤其是在子域边界、聚合设计和适配器分层方面。本期节目端到端地讲解了一个真实的提案提交流程,附带一个完整可克隆的Quarkus仓库,并涵盖了Quarkus 4即将迎来的Vert.x 5和Jackson 3升级。

BoxLang 1.15.0发布:极速字符串处理、运行时可移植性等

BoxLang 1.15.0版本重写了字符串引擎,提供了媲美原生Java的性能——对于一门动态JVM语言来说是一次重大飞跃。CFML运行时长期以来一直承受着运行时反射和动态类型带来的性能代价,尤其是在每毫秒都至关重要的字符串密集型Web应用中。该版本涵盖了新的字符串架构、跨Java版本的运行时可移植性改进,以及“极速”声明背后的具体基准测试数据。

Quarkus 3.37.3——维护版本

Quarkus 3.37.3附带了一个升级工具,可以在单个命令中将应用从2.x迁移到3.37。主要版本升级通常需要人工介入处理数十项破坏性变更,使得升级成为企业团队经常面临的痛点。该维护版本详细介绍了变更日志、迁移指南以及通过Quarkus CLI应用更新的步骤。

规模化构建服务拓扑:架构、挑战与经验教训

Netflix的生产服务拓扑系统并未按计划工作——第一个在本地成功的版本在Kafka消费者落后时崩溃,节点出现了100倍的流量偏差,垃圾回收消耗的CPU甚至超过了业务逻辑。传统的批处理以小时为单位聚合拓扑数据,这意味着当工程师看到依赖关系图时,他们正在调试的事故已经结束了。本文介绍了流式架构、分布式聚合管道以及优化方法,这些最终使其能够以Netflix的规模每秒处理数百万条流记录、在任意时间点重建拓扑,并实现亚秒级查询响应。

哪种文档格式最适合AI规范?

在一个674文档的项目中,HTML规范文档的格式开销是Markdown的10倍——9.9%的标签噪声对比0.9%。格式选择悄然影响着AI的token效率和人工审阅流程;GitHub将HTML渲染为原始源代码,彻底破坏了审阅闭环。基于将181份规范转换为全部三种格式的经验,文章推荐将Markdown用于AI生成的工作文档,将AsciiDoc用于人工策审的规范文档。

塔越建越高

AI辅助编程让个体开发者的生产效率大幅提升,但大型软件项目仍然和以往一样脆弱。真正的瓶颈从来不是一个人写代码的速度有多快,而是一个团队协调对系统的共同理解有多好。文章以巴别塔为隐喻,认为没有共同的概念语言,再多的个人AI产出也无法阻止软件在自身的混乱中崩塌。

用于ID-JAG跨应用访问的Okta SAML与Keycloak

SSO告诉SaaS应用用户是谁,但无法说明用户能在应用内做什么——每个API仍然需要一个独立的、有作用域的OAuth token,而不仅仅是一个登录断言。ID-JAG弥合了企业身份与服务特定权限之间的差距,然而企业将SAML作为标准,而草案的Happy Path使用的是OIDC,这造成了现实世界中的互操作性挑战。本文介绍了一个可工作的Okta SAML到Keycloak ID-JAG流程,证明了跨域token交换在今天是可以实现的,并附带一个完全可复现的演示。

领域特定语言让LLM的可靠使用成为可能

对于复杂软件来说,预先制定的规范从根本上来说是不可能的——真正的设计决策只在实现过程中才会浮现,而非之前。LLM可以从自然语言生成整个系统,但没有精确的边界,它们的输出很少与真正的意图一致。领域特定语言(DSL)提供了结构化的约束框架,从一开始就引导LLM,将代码生成转变为小型、可审阅变更的可靠迭代循环。

为编码代理选择合适的安全策略

拥有文件写入和执行权限的编码代理已经导致了生产系统崩溃和数据泄露——而要求每次工具调用都经过人工审批的明显修复方案严重降低了生产效率,以至于用户陷入权限疲劳,不加思考地点击“允许”。挑战在于赋予代理足够的自主权以发挥作用,同时防止提示注入或善意错误导致的灾难性故障。本文分析了三种无需持续人工监管就能保障代理安全的主要方法。

衡量个性化推荐的真正影响

衡量推荐是否增加了观看量并不像检查推荐内容在总观看时长中的占比那么简单——因为推荐并非随机分配。一个内容出现在会员的首页上,恰恰是因为系统预测其会引起兴趣,这使得我们无法判断是推荐导致了观看,还是会员本来就会观看。Netflix的研究人员构建了一个计量经济学模型,将内容本身的吸引力与在正确时间将正确内容推送给正确的人所带来的增量价值区分开来。

拥抱Agentic:来自AI工程活动的演讲与反思

高盛在2023年预测29%的软件工程任务将受到AI自动化的影响——这个数字如今看来已经明显保守,因为我们的行业已经成为自动化程度最高的行业之一。然而大多数行业活动仍然聚焦于工具和技术,忽略了关于AI如何重塑个人角色、团队动态和软件企业结构的更重要的讨论。本文回顾了一次刻意围绕这些人与组织维度展开的活动中的演讲,完整的会议视频现已上线YouTube。

☕ JVM周报

1. Metropolis项目正式宣告终结

Project Metropolis——将HotSpot从C++重写为Java并用Graal替代C2作为原生JIT编译器的雄心勃勃计划——正式宣告死亡,然而本应支撑这一计划的技术却在OpenJDK之外悄然成功。Oracle在JDK 17(JEP 410)中将Graal从JDK树中移除,理由是使用率低和维护成本高,而GraalVM作为外部项目继续独立发展,留下了承诺与交付之间的裂痕。文章追溯了这一历程中的三个关键节点,并调查了GraalVM近几个月来的其他变化。

2. 独立的日历,JDK跟踪的终结

Oracle在JDK 17中从OpenJDK移除了自己的实验性基于Java的JIT编译器,实质上终结了Project Metropolis——将HotSpot从C++重写为自引导Java的雄心勃勃计划。在承诺GraalVM将作为原生JIT存在于JDK内部多年之后,两者已分化为独立的生态系统,Graal在外部蓬勃发展,而OpenJDK退回到了数十年历史的C++。文章追溯了这一悄然瓦解的三个关键里程碑,阐述了这对JVM性能未来的意义以及GraalVM现在的发展方向。

3. 沙盒功能降临免费版

Oracle终止了其最雄心勃勃的OpenJDK项目之一——用Java重写HotSpot——之后GraalVM却在JDK之侧而非之内蓬勃发展。JEP 410在JDK 17中移除了实验性的基于Java的AOT和JIT组件,理由是用量低和维护成本高,让开发者疑惑接下来会发生什么。文章追溯了GraalVM演变过程中的三个转折点,最终以脚本沙盒功能登陆免费版作为收尾。

4. 封闭世界敞开了一扇门

最雄心勃勃的OpenJDK项目——用Java重写HotSpot并用Graal替代C2作为原生JIT编译器——并没有死亡,它只是走出了OpenJDK的高墙。JDK 17(JEP 410)以“维护成本过高”为由将Graal从JDK树中移除,留给Oracle的任务则是调和这次移除与一个可工作的Java-on-Java运行时那不可否认的吸引力。文章追溯了这条弧线上的三个节点,从2021年的分岔,到2022年JavaOne上试探性的桥梁建设,再到当下,揭示了GraalVM如何从外部塑造着JVM生态圈。

5. Leyden拿走了启动速度的故事

Project Metropolis的目标是用Java重写HotSpot并用Graal替代C2——然后JDK 17(2021年)将Graal完全从OpenJDK树中移除。Oracle放弃其最雄心勃勃的JVM项目看起来像是退却,但实际上是一次转向:GraalVM独立发展,而JVMCI为外部编译器保留了入口。文章追溯了从那次移除、经过Oracle 2022年主题演讲到当下的三个节点,展示了一系列零散的JVM版本发布实则讲述了同一个关于Java-on-Java未来的连贯故事。

7. 多语言能力一直是真正的主题

Oracle曾提议通过Project Metropolis将HotSpot JVM从C++重写为Java本身——一个从自身静态可验证代码自举的JVM。当Graal在JDK 17中被从OpenJDK移除时,这个雄心勃勃的计划陷入了停滞,然而GraalVM在JDK树之外继续成熟,创造了一个关于分道扬镳后又试图和解的破碎叙事。文章追溯了从JDK 17、经过2022年JavaOne到当下的三个关键节点,揭示了GraalVM的多语言愿景从一开始就是真正的故事主线。


往期精选


阅读原文


扫码关注「右耳朵猫AI」

扫码关注「右耳朵猫AI」