Java 生态周报：从新框架 1.0 到运行时与开源可持续性

2026-06-30 35 预计阅读时间: 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.

预计阅读时间：11 分钟

2026 年 6 月 22 日这一周的 Java 新闻很密集：Hardwood 1.0 和 Endive 1.0 正式 GA，Azul Payara 发布 2026 年 6 月版本，Quarkus 与 LangChain4j 有小版本更新，WildFly 41 进入首个 Beta，同时 Eliya JDK 和 Open Source Sustainability Initiative（OSSI）进入开发者视野。单看每条都是发布新闻，放在一起看，则能看到 Java 生态正在同时处理三个问题：新项目成熟、运行时持续演进、开源维护资金与治理压力上升。

两个 1.0：Hardwood 与 Endive 进入可评估阶段

Hardwood 1.0 和 Endive 1.0 的 GA 意味着它们从“可以关注”变成“可以认真评估”。对团队来说，1.0 不等于可以立刻进核心链路，但至少说明项目维护者开始承诺稳定的公开行为、兼容边界和发布节奏。

评估这类新 Java 项目时，不要只看 README 的示例是否漂亮。更应该检查这些问题：

  • 是否有清晰的兼容性说明，比如最低 JDK 版本、支持的构建工具、模块化支持情况。
  • 是否已经发布到常用制品仓库，是否能被 Maven 或 Gradle 稳定解析。
  • API 是否有明显的实验性标记，1.0 后是否承诺语义化版本。
  • 是否有测试、文档、issue 响应和安全披露路径。

可以把它们放进一个隔离的 spike 项目，而不是直接混进业务仓库。这样能快速验证构建、依赖冲突和运行行为。

Quarkus、WildFly、Payara：运行时仍在快速调整

这周还包括 Quarkus 的 point release、WildFly 41 的首个 Beta，以及 Azul Payara 的 2026 年 6 月版本。它们覆盖了不同风格的 Java 服务运行方式：Quarkus 更偏云原生和快速启动，WildFly 是 Jakarta EE 应用服务器路线，Payara 则延续企业级应用服务器与支持发行版的场景。

小版本更新往往看起来“不值得开会”，但它们经常包含依赖升级、兼容性修复、安全补丁和构建插件调整。尤其是 Quarkus 这类和构建期增强、扩展生态绑定较深的框架，升级时要把插件版本、扩展版本和测试插件一起看。

WildFly 41 Beta 的价值更多在提前验证。Beta 不适合直接进入生产，但很适合平台团队跑兼容性测试：部署一个真实但非关键的 Jakarta EE 应用，观察数据源、事务、CDI、JAX-RS、安全配置和日志行为有没有变化。

LangChain4j 小版本：Java AI 应用继续补齐工程化拼图

LangChain4j 的 point release 说明 Java 侧的 LLM 应用开发仍在持续迭代。对很多企业团队来说，Java 不是最早尝鲜 AI SDK 的语言，但它常常是接入真实业务系统的语言：权限、审计、交易、工单、CRM、数据访问层都已经在 JVM 里。

升级 LangChain4j 时，重点不是“模型调用能不能通”，而是这些工程问题：

  • prompt 模板和工具调用是否有行为变化。
  • streaming、timeout、retry、rate limit 是否仍按预期工作。
  • 日志里是否会泄漏 prompt、用户输入或模型输出。
  • 与 Spring、Quarkus 或其他运行时集成时，依赖版本是否一致。

如果你正在做 Java AI 服务，可以把 LangChain4j 升级验证纳入常规依赖扫描，而不是等到模型网关或 provider SDK 出问题时再补。

可以这样实践：给 Java 周更依赖建一个升级沙箱

下面这个最小 Maven 项目不是在复现某个具体发布内容，而是一个可改造的“升级沙箱”。你可以把 Quarkus、LangChain4j、应用服务器客户端库或新框架依赖放进去，先跑依赖树和测试，再决定是否进入主仓库。

把 quarkus.platform.version、langchain4j.version 和占位依赖改成你要验证的实际版本后运行。

<!-- pom.xml -->
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.example</groupId>
  <artifactId>java-roundup-upgrade-lab</artifactId>
  <version>1.0.0-SNAPSHOT</version>

  <properties>
    <maven.compiler.release>21</maven.compiler.release>
    <quarkus.platform.group-id>io.quarkus.platform</quarkus.platform.group-id>
    <quarkus.platform.artifact-id>quarkus-bom</quarkus.platform.artifact-id>
    <quarkus.platform.version>CHANGE_ME</quarkus.platform.version>
    <langchain4j.version>CHANGE_ME</langchain4j.version>
  </properties>

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>${quarkus.platform.group-id}</groupId>
        <artifactId>${quarkus.platform.artifact-id}</artifactId>
        <version>${quarkus.platform.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>

  <dependencies>
    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-resteasy-reactive-jackson</artifactId>
    </dependency>
    <dependency>
      <groupId>dev.langchain4j</groupId>
      <artifactId>langchain4j</artifactId>
      <version>${langchain4j.version}</version>
    </dependency>
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter</artifactId>
      <version>5.10.3</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>3.2.5</version>
      </plugin>
    </plugins>
  </build>
</project>

配一个极小的测试，先确认 JDK、测试框架和依赖解析没有基本问题：

// src/test/java/com/example/RuntimeSmokeTest.java
package com.example;

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.assertTrue;

class RuntimeSmokeTest {
    @Test
    void runsOnExpectedJavaBaseline() {
        int feature = Runtime.version().feature();
        assertTrue(feature >= 21, "Expected Java 21 or newer, got " + feature);
    }
}

然后用这些命令检查升级影响：

mvn -q test
mvn -q dependency:tree -Dincludes=io.quarkus,dev.langchain4j
mvn -q versions:display-dependency-updates

如果你验证 WildFly 41 Beta 或 Payara 相关更新，可以把业务应用打成 WAR，再用容器镜像做一次临时部署验证。镜像名和标签请按你团队实际使用的发行版替换：

mvn -q -DskipTests package

docker run --rm \
  -p 8080:8080 \
  -v "$PWD/target:/deployments" \
  YOUR_APP_SERVER_IMAGE:YOUR_TAG

curl -i http://localhost:8080/your-app/health

这里的目标不是一次性证明“可以升级”，而是把风险拆小：构建能不能过、依赖树有没有冲突、启动是否正常、健康检查是否稳定、日志是否出现新警告。

Eliya JDK 与 OSSI：发布之外的供应链问题

Eliya JDK 的出现提醒我们，JDK 发行版选择仍然是 Java 平台工程的一部分。不同发行版可能在支持周期、补丁策略、认证、容器镜像、商业支持和安全响应上有所不同。团队不应该只问“能不能跑 Java”，还要问“谁负责补丁、何时发布、如何回滚”。

OSSI 由 HeroDevs 和 Commonhaus Foundation 发起，指向另一个更长期的问题：开源项目如何持续维护。Java 生态长期依赖大量基础库、框架、构建插件和运行时组件。越靠近生产系统，越应该把开源可持续性纳入供应链风险管理，而不是只在许可证扫描里打勾。

采用建议：别追每个发布，但要有固定节奏

这周的新闻不要求所有团队立刻升级。更合理的做法是建立固定节奏：每周看发布，每月做升级沙箱，每季度处理较大的运行时或 JDK 变更。

可以用这份清单落地：

  • 新 1.0 项目先做 spike，不直接进核心链路。
  • Quarkus、LangChain4j 这类活跃依赖用自动化工具监控 point release。
  • WildFly Beta 适合兼容性实验，不适合生产承诺。
  • Payara、JDK 发行版更新要和支持周期、安全补丁、镜像来源一起评估。
  • 对 OSSI 这类开源可持续性倡议保持关注，因为它影响的是长期维护成本和供应链韧性。

Java 生态的节奏不是一夜之间换赛道，而是每周把地基加固一点。真正成熟的团队，不会被每条发布新闻牵着走，但会让每条新闻都进入一个可验证、可回滚、可记录的工程流程。

# AI # InfoQ # Java # 全栈 # 后端

相关推荐