要約

  • pai-auth-ws-clientのREADMEは2024年11月の作成以来更新されておらず、要件をJava 8以上、依存例を1.0.0としている。
  • リリース側では1.5.0でMavenのJava/source/targetが17へ移り、1.5.1も同じ設定を維持する。公開CIもJDK 17を使う。
  • 1.5.1の成果物はJitPackに存在する。20,580バイトのJARに含まれる十二個のclassはすべてmajor 61で、manifestのBuild-Jdkは17.0.12だ。
  • Java 8へ戻すことが答えではない。版ごとに最低・試験済みruntime、適用する文書、PAI APIの範囲を結ぶ小さな互換性台帳が要る。

読み手の「8」とJVMの「61」

LACNICの公開リポジトリを訪れた実装者は、まずPAI認証Webサービスを利用するJavaクライアントだという説明を読む。RequirementsにはJava 8以上とある。MavenとGradleの例はいずれも1.0.0を指定し、JitPackで公開された版へ置き換えるようコメントしている。そのすぐ上のbadgeは現在1.5.1を示す。説明どおりに最新版を選ぶこと自体は、不注意ではない。PAIクライアントのリポジトリ 1.5.1時点のREADME JitPackのプロジェクトページ

依存物は解決できる。JitPackは1.5.1のPOMと20,580バイトのJARをHTTP 200で返す。JAR内の十二個の.classについてheaderを確認すると、major_versionはすべて61だった。manifestにはBuild-Jdk: 17.0.12とある。JVM仕様の表ではJava SE 8がmajor 52、Java SE 17が61に対応する。したがって、配布された1.5.1のclass形式がJava 17世代であることは、名称ではなくバイナリから確認できる。JitPack生成POM 1.5.1 JitPack JAR 1.5.1 JVM仕様のclass形式

ここから実利用の失敗を推定してはならない。Java 8上で1.5.1を読み込もうとした利用者は確認されていない。ログイン失敗、PAI停止、侵害、脆弱性も確認されていない。クライアントのclass形式からPAIサーバーのruntimeを知ることもできない。立証できるのは、最新版に対して一般要件のJava 8が成立しない、という狭い点だけだ。

Java 17への移行には筋が通る

認証クライアントの保守基盤をJava 17へ上げることには、十分な合理性がある。古いruntimeへの永続的な対応は、依存関係の更新や試験環境を難しくしうる。新しい主系列で最低版を引き上げ、旧系列を別に扱うのは一般的な判断だ。Java 17を要求すること自体を欠陥と呼ぶ根拠はない。

むしろ1.5.1の技術記録はよく揃っている。POMのjava.version、maven.compiler.source、maven.compiler.targetはいずれも17。tagに紐づくworkflowはZulu JDK 17を用意してMaven verifyを実行する。成果物もmajor 61だ。設定、公開build、配布物の三者は同じ結論に達している。1.5.1のPOM 1.5.1のbuild 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までは、CIがJDK 17で動く一方、maven.compiler.sourceとtargetを明示的に1.8のままにしている。これらのPOMにはjava.versionが二度あり、先に1.8、後に17と書かれている。この過渡期を「全項目が17」と単純化するのは誤りだ。class出力に直接関わる明示的targetは1.8である。

1.5.0になるとJava属性、source、targetがそろって17へ変わる。1.5.1も同じだ。公開tagの比較では、1.4.0と1.5.0の間がruntime floorの転換点になる。1.4.0のPOM 1.5.0のPOM

ところがREADMEの履歴は一本しかない。GitHubが示すcommitは2024年11月1日の作成時だけで、確認した内容は1.0.0から1.5.1までの各tagと現在のmainで同一だった。1.5.0は2025年10月29日、1.5.1は2026年4月14日のreleaseだが、両release bodyは空で、Java 17への変更を書いていない。READMEのcommit履歴 GitHub releases release 1.5.1

悪意を想定する必要はない。コードを日常的に見る保守者には新しい前提が自明で、入口の文章だけが初版の時間に残る。文書driftとは、多くの場合このような静かな分離である。

build、target、動作確認を分ける

JDK 17でbuildしたことと、Java 17を最低runtimeとすることは同じではない。新しいcompilerから古いtargetを生成できる。Maven Compiler Pluginの説明もsourceとtargetを区別し、targetだけでは利用APIまで完全に保証できないと注意する。このため、workflowだけで結論を出さず、実際のJARを確認する必要があった。Maven Compiler Pluginの解説

一方、major 61にも限界がある。classを読むJVM世代は示せるが、どのPAI API版と試験したのか、認証情報が有効か、通信経路が通るか、sessionが成立するかは示せない。「取得できた」「classをloadできた」「clientを初期化できた」「認証応答を受けた」「業務sessionが成立した」は別々の観測だ。

GitHub releaseに添付assetがないことも、配布物の不存在を意味しない。公開手順はJitPackを指定し、そこでPOMとJARを取得できる。JitPackのbuild APIはstatus: okと「Not found」を同時に返し、modulesとbuild URLを空にしているが、この不整合な表示を直接downloadの成功より強い証拠として扱うべきではない。

この境界を守れば、既存の別テーマとも混ざらない。本稿は署名鍵、detached signature、reproducible build、install済みbinaryの同一性を監査しない。稼働中の選挙サービスをsource commitへ結びつけない。ASPA/RTR機能が有効かも問わない。問うのは版とruntimeの対応だけである。

releaseに添える小さな互換性票

必要な記録は大きくない。各releaseに、project、tag、commit、Maven座標、class target、build JDK、最低対応runtime、実際に試験したruntimeを並べる。さらに、対象となるPAI service/APIの範囲、適用する文書revision、互換性に影響する変更、support/deprecation期間、訂正または後継へのlinkを付ける。

artifact digestで観測したbytesへ固定してもよい。ただし、それは署名の権威やbuild再現性を証明するものではない。「JDK 17でbuild」「target 17」「17と21で試験済み」は別項目にする。download可能とsupport中も同義にしない。

この表の材料は既に公開されている。tagとcommit、POM、workflow、JARがある。欠けているのは新しい中央管理ではなく、選択時点でそれらを一つの版に束ねる薄いreceiptである。

runtimeの説明は制度側の責任範囲でもある

どのJVMを採るかはoperatorの判断だ。LACNICは利用者のbase image、vendor、更新日程を決めない。しかし、自ら公開するclientの入口説明は管理できる。JitPackは配布したbytesを管理し、JVM仕様は形式の意味を定め、operatorはlocal testとdeployを決める。

対応表は権限を奪わない。LACNICにはJava 17へ進む自由を残しつつ、最新版もJava 8で動くという意図しない期待を防ぐ。operatorには旧版に残る、runtimeを更新する、あるいは新releaseを検証してから採るという選択を残す。

変化するコードに信頼を持たせる方法は、変化を止めることではない。互換性の約束にも版を持たせることだ。

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のbuild workflow
  8. LACNIC：GitHub release一覧
  9. LACNIC：release 1.5.1
  10. LACNIC：READMEのcommit履歴
  11. JitPack：LACNIC PAIクライアント
  12. JitPack：1.5.1生成POM
  13. JitPack：1.5.1 JAR
  14. Oracle：JVM仕様のclassファイル形式
  15. Apache Maven：compiler sourceとtargetの設定