Helidon 27 是项目首个按 OpenJDK Tip-and-Tail 模型发布的版本：想跟 JDK 新特性走就上 Tip，企业验证周期长就继续守 4.5 LTS。MicroProfile 应用现在不应迁到 27，Declarative、Messaging、Data JDBC 仍处 Preview/Incubating，适合试用反馈而非直接当生产终态。架构与运维要先分清自己在哪条轨道上，再谈依赖与 JDK 基线。

Tip 跟 JDK，Tail 留给慢升级

2026 年 9 月 21 日前后，Helidon 团队发布了 Helidon 27（Inside Java 与 ADT Mag 记为 9 月 22 日）。这是 Helidon 第一次把 OpenJDK 的 Tip-and-Tail 落到正式版本号上：Tip 版本号与 JDK 对齐，基线也跟着抬高。要用 Helidon 27，就必须用 JDK 27。

按官方说明，Tip 分两类：非 LTS 的 Tip 支持约六个月，直到下一个 Tip；LTS Tip 则支持到下一次 LTS 发布后一年。Helidon 27 属于非 LTS Tip，修复会持续到 Helidon 28 发布为止；28 再修到 29（LTS）发布。Helidon 4.5 仍是当前 LTS Tail；下一次 LTS 目标是 Helidon 29。当 29 发布时，它既是当时的 Tip 也是新的 LTS；随后 Helidon 30 与 JDK 30 一起出来时，29 才会变成 Tail。4.5 的支持会在 29 发布后一年结束。LTS 大致按两年节奏推进，一条 LTS 线大约可覆盖三年支持窗口。

这条分叉对运维直接有意义。Tip 适合愿意同步 JDK 半年节奏、愿意试用未定稿 API 的团队；Tail 适合变更窗口窄、合规与回归成本高的生产线。官方在 4.4 时代就预告过这一模型，27 是第一次真正按 JDK 编号发 Tip。

JDK 基线抬到 27 后，框架内部终于能用上 JDK 21 之后才正式可用的语言与库能力。一个已经落地的例子是 Scoped Values：从 Helidon 27 起，活动 Context 改由 ScopedValue 承载，而不再依赖原先的 ThreadLocal 实现。公开的 Helidon Context API 没有改，应用代码通常不用动就能吃到作用域绑定更清晰、也更贴合虚拟线程的内部实现。Helidon 4 线自 2023 年 9 月起以 JDK 21 为基线；从 4.3 起官方也推荐跑在 JDK 25 上，但为兼容 21，框架自身此前没法全面采用更新的 Java 特性。基线抬到 27 之后，这类限制才真正解开。官方在 4.3 发布说明里提到的基准里，同一应用从 JDK 21 换到 25 吞吐大约高 70%，具体仍取决于负载与环境，需要自行复测。

命名重组：Core、MP、Extensions 各走各的钟

Helidon 27 不再沿用「Helidon SE」这个名字。共享基础（配置、网络、安全、可观测性等）改称 Helidon Core，并提供两种内建编程模型：

  • Imperative：手写普通 Java，直接控制流程，对应过去的 SE。
  • Declarative：注解加依赖注入，构建期生成命令式代码与装配，不靠运行时反射或字节码改写。

Helidon MicroProfile 仍面向 MicroProfile 与相关 Jakarta 规范，但 27 里没有 MP。CHANGELOG 与升级指南写得很明确：MP 已拆到独立仓库，会按 MicroProfile/Jakarta 自己的节奏发版。使用 Helidon MP、CDI、JAX-RS 或 MicroProfile 规范 API 的应用，应留在 Helidon 4.5.x，直到单独的 MP 发行版可用；除非你愿意把编程模型换成 Helidon Core，否则不要把这类工作负载升到 27。

MCP、LangChain4j、OCI 这类集成被归到 Helidon Extensions，各自按外部生态的节奏独立发版。Core 跟 Java，Extensions 跟各自上游，MP 跟规范委员会。原先硬绑在同一列车上时，快的一方会被拖慢，慢的一方又会被强迫空发。现在的命名是把早已存在的分层说清楚，并允许它们分开发车，不是架构重写。

Declarative 面齐了，定稿还要等 29

Declarative 在 27 补齐了剩余四个模块：gRPC、Messaging、GraphQL、OpenAPI。开发者不必因为缺某一项就跳出 Declarative。覆盖面齐了，并不等于 API 已定稿。官方仍将其标为 Preview，计划在 Helidon 29 LTS 定稿。现在正适合拿真实负载去压边界、提反馈，而不是当成「已经稳定三年」的契约。

Helidon Messaging（Preview）

新的 Messaging 模块刻意避开 MicroProfile Reactive Messaging 那一套响应式类型。业务代码写普通阻塞 Java，面对的是逻辑 channel；Kafka、JMS、Pulsar 通过可插拔 connector 绑到具体 destination。官方示例大致如下：

@Service.Singleton
final class OrderValidator {
    @Messaging.ReceiveFrom("orders")
    @Messaging.SendTo("validated-orders")
    String validate(String order) {
        // 业务逻辑
        return order;
    }
}

messaging:
  connector:
    helidon-kafka:
      bootstrap.servers: "localhost:9092"
  incoming:
    orders:
      connector: helidon-kafka
      topic: orders
      group.id: order-validator
      auto.offset.reset: earliest
  outgoing:
    validated-orders:
      connector: helidon-kafka
      topic: validated-orders
      properties:
        acks: all

方法签名里没有 Consumer、Producer、响应流类型，也没有 Kafka/JMS/Pulsar API。换传输栈主要改配置。Helidon 4 的 SE Messaging 用过 MicroProfile Reactive Messaging；升到 27 后同坐标下的实现已换，只改依赖版本不够，源码与配置都要迁。旧 connector 也不再二进制兼容，需要改用 Extensions 侧为新 Messaging API 构建的版本。

Helidon Data JDBC（Incubating）

Data 原先已有 JPA 仓库路径（EclipseLink / Hibernate）。27 增加 Data JDBC：你自己写 SQL 与仓库接口，Helidon 在构建期生成 JDBC 样板（参数绑定、执行、映射、关闭资源）。示例：

@Data.Repository
@Data.PersistenceUnit("contacts")
public interface ContactRepository {
    @Jdbc.Statement("""
        SELECT ID AS id, NAME AS name
        FROM CONTACT
        WHERE ID = :id
        """)
    @Jdbc.Execution(Jdbc.ExecutionType.QUERY)
    Optional<ContactSummary> findById(long id);

    @Jdbc.Statement("""
        UPDATE CONTACT
        SET STATUS = :status
        WHERE ID = :id
        """)
    @Jdbc.Execution(Jdbc.ExecutionType.UPDATE)
    long updateStatus(long id, String status);
}

没有持久化上下文、脏检查、懒加载；结果就是普通 Java 值。SQL 就是仓库方法上声明的那条，便于 DBA 与开发一起看同一份语句。它标为 Incubating，成熟度低于 Messaging 的 Preview。

运维侧还能写进变更单的点

官方还列出若干可直接进升级清单的改动（均以博客与 CHANGELOG/升级指南为准）：

  • TOML 配置：加入 helidon-extensions-toml-config 后可自动发现 application.toml，自带解析器，支持 TOML 1.0/1.1，不引入外部 TOML 库依赖。
  • registerLocator：请求到达时再按路径参数或应用状态选择 HttpService，适合租户、API 版本、动态后端这类启动时定不下来的路由。
  • SNI：WebServer / WebClient 一等公民支持，同一监听端口可按主机名或通配选证书；缺 SNI 或未识别时可走默认证书或拒绝。
  • OpenTelemetry 启动告警：多处集成改为协调复用全局 OTel 实例，去掉误导性启动警告，应用侧一般不用改。
  • Helidon JSON 进入 Core：约十八个组件从 JSON-P / Parsson / HSON 迁到 Helidon JSON，减少 Core 内多种 JSON 实现并存；应用仍可选用 JSON-P、JSON-B、Jackson 等。
  • HTTP/3：不在 27 内，早期实现按 pre-Incubator 准备，尚未成为受支持特性。

兼容性上还有两处写进 CHANGELOG 的硬事实：HTTP 方法名与选择器改为大小写敏感，配置与代码里请统一写成 GET 这类标准大写形式；安全相关配置对已知方法的小写/混写暂时兼容并打迁移警告，未来大版本会去掉。依赖升级包括 OpenTelemetry 1.65.0 与 Micrometer 1.17.1，可能影响现有遥测与指标集成。

升级指南建议的路径也很务实：先升到最新 4.5.x，用 JDK 27 编译跑通并清掉弃用警告，盘点 io.helidon.microprofile / jersey / lra / integrations 坐标，再决定是留在 Tail，还是迁到 Core 并跟 Tip。

怎么选轨

需要长支持窗口、仍依赖 MP/CDI/JAX-RS，或 Extensions 替换尚未齐套：留在 Helidon 4.5.x。愿意用 JDK 27、试用完整 Declarative 面、参与 Messaging / Data JDBC 定稿前反馈：选 Helidon 27。两条线是官方明确的双轨发布与支持策略。写进架构决策记录时，把 JDK 基线、支持截止、编程模型（Core 还是 MP）三件事写在同一段即可。

主要依据：Helidon 官方博客、Inside Java 通告、ADT Mag 报道、GitHub CHANGELOG 与 27 升级指南。

— 感谢阅读 —
# Helidon# java

一起交流

分享你的思考，让讨论更进一步。