摘要

  • pai-auth-ws-client 的公开 README 自 2024 年 11 月创建后没有再改，要求项仍是“Java 8 或更高版本”，Maven 与 Gradle 示例仍使用 1.0.0。
  • 版本线已经前移：1.5.0 将 java.version、compiler source 与 target 一并升到 17；1.5.1 保持这一设置，公开 CI 也在 JDK 17 上构建。
  • 1.5.1 并非“没有产物”。JitPack 可直接下载 POM 与 20,580 字节的 JAR；其中十二个 class 的 major version 全是 61，manifest 记录的 Build-Jdk 为 17.0.12。
  • 有效修复不是强迫新版本退回 Java 8，而是给每个 release 配一份兼容性凭据，把最低/已测试运行时、文档修订和 PAI API 适用范围绑定在一起。

人读到 8，机器读到 61

一个运维团队要接入 LACNIC 的 PAI 认证服务，最先遇到的不是登录请求，而是环境选择。公开仓库把这个项目描述为 PAI Authentication Web Service Client；Requirements 下写着 Java 8 或更高版本。紧接着的 Maven 和 Gradle 示例都引用 1.0.0，并提示读者替换为 JitPack 上已发布的版本。同页 badge 当前显示的是 1.5.1。按照页面给出的顺序，从最低版本要求走到最新依赖，是完全正常的阅读路径。PAI 客户端仓库 1.5.1 的 README JitPack 项目页

依赖解析本身不会报“找不到”。对 JitPack 的直接请求拿到了 1.5.1 POM 和 JAR，后者为 20,580 字节，包含十二个 .class 文件。检查每个 class header 的 major_version，结果全部为 61；JAR manifest 还写明 Build-Jdk: 17.0.12。Java 虚拟机规范的版本表把 Java SE 8 对应到 major 52，把 Java SE 17 对应到 major 61。最新 JAR 对其字节码世代没有含糊之处。JitPack 1.5.1 POM JitPack 1.5.1 JAR JVM class 文件规范

这个观察只能证明兼容性说明发生了断裂，不能被扩写成事故。现有公开证据没有显示任何用户真的拿 Java 8 加载 1.5.1，没有显示登录失败、认证服务中断、生产系统受损，更没有显示漏洞或攻击。客户端 class 的版本也不能告诉我们 PAI 服务端使用什么运行时。证据边界止于“这组字节不能履行 README 对最新版本所暗示的 Java 8 下限”。

先承认升级到 Java 17 的合理性

把认证客户端迁到 Java 17，可能是一项稳健的维护决定。长期绑定旧运行时会拖累依赖升级、测试环境和安全维护；新主线抬高最低版本，并不等于工程失误。一个开源库也没有义务永远兼容它首发时支持的所有平台。

从当前 release 看，技术链条内部反而相当一致。1.5.1 的 POM 将 java.version、maven.compiler.source 和 maven.compiler.target 都设为 17。同一 tag 下的 GitHub Actions workflow 安装 Zulu JDK 17，并运行 Maven verify。最终下载的 class 是 major 61。构建配置、公开 CI 和成品字节码相互印证。1.5.1 POM 1.5.1 构建 workflow

README 的示例也不是把 1.0.0 冒充成最新版。注释明确让读者替换为已发布版本；而 1.0.0 自己的 POM 的确将 source 和 target 设为 1.8。换句话说，文档曾经准确，只是它没有随着版本线继续移动。1.0.0 POM

这正是问题的性质：不是代码不该升级，而是“请选择已发布版本”与“Java 8 或更高”两条指导之间缺了一张版本地图。

下限是在 1.5.0 改变的

逐个看 tag，可以把变化定位得很清楚。1.1.0 到 1.4.0 的 POM 仍把 maven.compiler.source 和 maven.compiler.target 明确设为 1.8，尽管 CI 已使用 JDK 17。这几版还重复声明了 java.version，先写 1.8、后写 17；因此不能把过渡期美化成“所有字段完全一致”，也不能仅凭后一个属性就断言产物必须是 Java 17。真正决定性的 source/target 仍是 1.8。

到了 1.5.0，Java 属性、source 和 target 三项同时变为 17；1.5.1 沿用该配置。1.4.0 与 1.5.0 的 POM 是这次门槛变更的公开分界。1.4.0 POM 1.5.0 POM

文档没有形成对应的版本史。GitHub 显示 README 只有一次提交，时间是 2024 年 11 月 1 日。检查到的内容在 1.0.0 至 1.5.1 各 tag 以及当前 main 中完全相同。GitHub 把 1.5.0 的发布日期记为 2025 年 10 月 29 日，把 1.5.1 记为 2026 年 4 月 14 日；两份 release body 都为空，没有说明最低 Java 版本已经改变。README 提交历史 GitHub release 列表 1.5.1 release

这类漂移往往没有戏剧性。代码按计划演进，旧文档继续在线，两边各自都像“正常状态”。直到有人需要把一条人类说明转成机器环境，缺失的对应关系才会暴露。

不要把六种记录压成一句话

构建 JDK 不等于最低运行时。在 JDK 17 上运行编译器，可以通过较低的 target 生成旧版 class。Maven Compiler Plugin 文档也区分 source 与 target，并提醒 target 本身不能保证所有 API 的兼容。因此，本次判断不能只看 workflow；实际 JAR 的 major 61 才证明其 class 世代。Maven Compiler Plugin 指南

反过来，major 61 也不能证明一切。它不能说明客户端测试过哪些 PAI API 修订，不能说明某种凭据一定被接受，不能说明网络连通，更不能说明应用最终建立了会话。依赖下载成功、class 加载成功、客户端初始化成功、认证请求被接受、业务会话建立，是五个连续但独立的状态。

release 页面没有附件，也不能被解释为“产物缺失”。这个项目公开选择 JitPack 作为分发路径，POM 和 JAR 都能直接取得。JitPack build API 确实给出了一组互相别扭的字段：status: ok，同时又有 message: Not found，modules 为空、build URL 为空。但当直接下载成功时，这个 API 文案不足以推翻产物存在的事实。

同样，这篇文章不接管其他已经成立的软件证据问题。它不审计 detached signature、签名密钥或可复现构建；不把线上选举服务绑定到某个 commit；也不判断某项 ASPA/RTR 能力是否实际启用。这里唯一的控制面是“哪个版本需要哪个 runtime”。

一份足够薄的兼容性凭据

修复不需要增加新的审批机构。每个 release 旁边放一份小型、版本化、机器可读又便于人读的记录即可。字段可以包括：项目、tag、commit、Maven 坐标、class target、构建 JDK、最低支持运行时、实际测试运行时、PAI 服务/API 适用范围、对应文档修订、重大兼容性变化、支持/弃用窗口，以及更正或取代链接。

artifact digest 可以把记录锚定到本次检查的具体字节，但这并不等于签名审计。“在 JDK 17 构建”“target 17”“在 17 与 21 上通过测试”也应分别保留，不能合成一个含糊的“支持 Java 17”。旧版本仍可下载，不等于旧版本仍受支持；二者也需要不同字段。

现有仓库已经提供了绝大部分素材：POM、workflow、tag、commit 和分发产物都在。缺少的不是更多后台流程，而是把这些事实在 release 边界上连接起来，让集成人员不用自己从五个页面重建答案。

运行时下限也是治理事实

PAI 客户端位于机构服务与本地自动化之间。LACNIC 控制仓库、tag 与公开说明；JitPack 控制它根据 tag 构建和提供的字节；JVM 规范控制 major version 的解释；运营者控制自己的 runtime、升级窗口与上线决定。兼容性记录的作用不是把这些权力集中起来，而是让它们互相可核对。

清楚的版本下限对双方都有利。LACNIC 可以坦率地把新主线迁到 Java 17，而不用承担“最新版仍支持 Java 8”的无意承诺。运营者可以有意识地留在旧线、评估迁移成本，或在紧急更新到来前完成测试。支持工作也可以从共同的 tag 与 runtime 事实开始。

可信度并不要求代码停止变化。它只要求兼容性承诺与代码一起获得版本号。

Sources

  1. LACNIC：PAI 客户端仓库
  2. LACNIC：1.5.1 版本 README
  3. LACNIC：1.0.0 版本 POM
  4. LACNIC：1.4.0 版本 POM
  5. LACNIC：1.5.0 版本 POM
  6. LACNIC：1.5.1 版本 POM
  7. LACNIC：1.5.1 版本构建 workflow
  8. LACNIC：GitHub release 列表
  9. LACNIC：1.5.1 release
  10. LACNIC：README 提交历史
  11. JitPack：LACNIC PAI 客户端项目
  12. JitPack：1.5.1 生成 POM
  13. JitPack：1.5.1 JAR
  14. Oracle：Java 虚拟机规范的 class 文件格式
  15. Apache Maven：设置 compiler source 与 target