Summary

  • Oracle 把 JDK 21.0.12 及更早版本继续列在 NFTC 许可下；10 月 20 日的 21.0.13 起采用 OTN，或由客户已有的适用权利覆盖。商业边界出现在同一 Java 大版本内部。
  • Java 21 的商业支持延续到广泛免费更新窗口之后。企业选择留在旧代际或迁移，实际是在许可证支出、兼容性验证和业务排期之间分配成本。

工单少写几个数字，预算就少看一个决定

“升级 Java 21。”这张工单很简洁，也恰好省掉了十月最值钱的部分。

Oracle 的 21.0.13 发布说明明确把 10 月 20 日的更新列为 JDK 21 家族第一个采用 Java SE OTN 许可证的版本。它仍然符合 Java SE 21 规范。应用负责人看到的是熟悉的大版本，采购负责人需要看到的是新二进制文件携带的使用权。

原本分开的工作在这里撞到了一起。运维希望跟上补丁，应用团队希望守住已经验证过的运行环境，财务希望知道这次维护究竟动用哪份合同。只记“21”的资产台账，把需要回答的问题留到了部署窗口。

Oracle 同日更新的许可问答把分界写得很具体：21.0.12 及更早版本仍列在 NFTC 一栏，21.0.13 及后续版本则列入 OTN 或相应客户渠道。旧文件在表中的位置继续保留，新补丁按新文件的条件取得。

长期支持有一张更长的账单日历

LTS 这个名字很容易让一次采购讨论过早结束。Oracle 的商业支持路线图把 Java 21 的 Premier Support 列到 2028 年 9 月，Extended Support 列到 2031 年 9 月。这些是适用于商业客户的支持时间线。JDK 21 新更新广泛适用的免费许可窗口，已经先走到了终点。

因此，企业仍可买到旧代际的连续性。兼容性越难重新验证，这份连续性对应用负责人的价值就越高。供应商提供的是继续维护这一代软件的路径，客户要安排的是应用什么时候有条件离开它。

Oracle 当前最新的 LTS 是 JDK 25。公司现计划让它的更新采用 NFTC 到 2028 年 9 月，即计划于 2027 年 9 月到来的 Java 29 之后一年。迁移到 25，也会把企业带入另一段许可窗口。软件取得成本可以是零，应用测试仍然要有人排期、有人验收、有人承担工时。

保留已经取得的旧 NFTC 二进制文件，会保留那个版本本身。后来版本包含的修复，需要后来版本的文件。Oracle 建议跟进每次 Critical Patch Update。许可证表和补丁计划需要在同一张决策桌上相遇。

同一个安装包，去向决定它依靠哪项权利

NFTC按其条件允许企业内部业务运行。OTN则列出具体授权用途：个人使用、开发、Oracle 批准产品的使用，以及指定的 Oracle Cloud Infrastructure 使用。开发用途包括测试、原型与演示。超出这些授权范围的用途，需要另行取得有效许可。

这使开发机和业务运行环境有了不同的核对路径。关键是这次部署的实际用途，以及哪项权利覆盖它。下载完成，只解决文件到了哪里。

已有客户也有不同入口。Oracle 列出的客户范围包括有效 Java 订阅、符合条件的旧产品支持权、适用 OCI 权利，以及仅为另一款有相应授权的 Oracle 产品运行 Java。企业需要把具体部署对应到适用授权。一个“已经买过 Oracle”的总标签，装不下这些范围。

资产清单应当把运行时供应方、完整版本、应用、用途和授权放在一起。这样才能看清哪些部署已经覆盖，哪些需要另一条更新路径。按大版本把机器加成一个总数，会抹掉 Oracle 刚在补丁号里画出的界线。

免费版本也会把费用送到工程部

客户合同与迁移验证成本尚未公开；这两项会决定某家企业的实际支出。公开文件已经给出清楚的取舍：为连续性付费，可以保留熟悉的代际；推进到更新的免费许可代际，要提前兑现应用验证；另一条正确取得许可的运行时路径，也有自己的测试与维护安排。

采购部能压低外部费用，应用团队能推迟一项升级，各自的表格都可能更好看。两件事放到同一日历，才看得见下一次维护前还有谁必须完成工作。供应商定义更新窗口，企业承担业务排期的成本。

审批人现在可以先问一句很小的话：究竟是哪个 Java 21？资产台账曾经省略的小数点后几位，已经坐到了预算桌前。

来源