原文はこちら。
The original article was written by Ivar Grimstad(Jakarta EE Developer Advocate, Eclipse Foundation).
https://www.agilejava.eu/2021/06/14/demystifying-java-se-level-for-jakarta-ee/

Hashtag Jakarta EE #76で述べた通り、Jakarta EE PlatformプロジェクトはJakarta EE 10に対するJava SEの要件を決定する作業をしています。

Hashtag Jakarta EE #76
https://www.agilejava.eu/2021/06/13/hashtag-jakarta-ee-76/

このエントリでは、現在投票にかけられている様々な選択肢の意味を明らかにしたいと思います。これらの選択肢が以下のステークホルダーにとってどういった意味を持つのでしょうか。

a) Jakarta EE API 開発者
b) Jakarta EE仕様を実装するベンダーやプロジェクト
c) アプリケーション開発者

選択肢と上記のステークホルダーへの影響について以下で述べていきます。

Option 1: source=Java SE 11, bin=Java SE 11, TCK=Java SE 11+

全てのAPI JARのソース/言語レベルならびにバイナリレベルをJava SE 11とします。互換実装はJava SE 11以上のバージョンを使ってTCKを自由に通すことができます。

ステークホルダー	影響
API開発者	Java SE 11の言語機能に制限される。つまり、Recordなどの機能をAPIで使用することはできない。APIのJARは、Java SE 11のクラスレベルにコンパイルする必要がある。
実装者	任意のJava SEバージョンの任意の言語機能を使って互換実装を実装できる。 Java SE 11以後の任意のバージョンを使って認証を受けることができる。例えば、ベンダーは、望めばJava SE 17以降のみをサポートすることも選択できる。また、Java SE 11以降のすべてのJava SEバージョンをサポートすることも可能。
アプリケーション開発者	任意のJava SEバージョンの任意の言語機能を使ってアプリケーションを実装できる。 Java SE 16以後を使う場合、望めばRecordをアプリケーションで利用可能。ただし、Jakarta EE APIを使用する際には、マッピングまたは変換が必要になる場合がある。 Java SEバージョンの上限は、選択した実装（ランタイム）がサポートするバージョン次第。

Option 2: source=Java SE 11, bin=Java SE 17, TCK=Java SE 17+

全てのAPI JARのソース/言語レベルをJava SE 11、バイナリレベルをJava SE 17とします。 互換実装はJava SE 17以上のバージョンを使ってTCKを自由に通すことができます。

ステークホルダー	影響
API開発者	Java SE 11の言語機能に制限される。つまり、Recordなどの機能をAPIで使用することはできない。APIのJARは、Java SE 17のクラスレベルにコンパイルする必要がある。
実装者	任意のJava SEバージョンの任意の言語機能を使って互換実装を実装できる。 実装者は、Java SE 17以上を使用して認証を行う必要がある。
アプリケーション開発者	任意のJava SEバージョンの任意の言語機能を使ってアプリケーションを実装できる。 Java SE 16以後を使う場合、望めばRecordをアプリケーションで利用可能。ただし、Jakarta EE APIを使用する際には、マッピングまたは変換が必要になる場合がある。

Option 3: source=Java SE 17, bin=Java SE 17, TCK=Java SE 17+

全てのAPI JARのソース/言語レベルならびにバイナリレベルをJava SE 17とします。互換実装はJava SE 17以上のバージョンを使ってTCKを自由に通すことができます。

ステークホルダー	影響
API開発者	任意のJava SEバージョンの任意の言語機能を利用可能。つまり、Recordなどの機能をAPIで利用できる。APIのJARは、Java SE 17のクラスレベルにコンパイルする必要がある。
実装者	任意のJava SEバージョンの任意の言語機能を使って互換実装を実装できる。 実装者は、Java SE 17以上を使用して認証を行う必要がある。
アプリケーション開発者	任意のJava SEバージョンの任意の言語機能を使ってアプリケーションを実装できる。 Java SE 16以後を使う場合、望めばRecordをアプリケーションで利用可能。

Conclusion

アプリケーション開発者としては、常に可能な限り高いバージョンのJava SEを使用したいと考えていますので、選択肢3は当然の選択です。しかし、既存の顧客ベースを持つベンダーとして考えるならば、おそらく選択肢1を選ぶでしょう。この選択肢は柔軟性に富んでいます。Java SE 11で認証することで、動きの鈍い顧客は喜んでくれることでしょう。それに加えて、Java SE 17で認証することで、よりせっかちな開発者も喜んでくれることでしょう。また、既存のお客様にJava SE 11からJava SE 17へのアップグレードパスを提供できるので、将来の明るい未来を約束することができます。選択肢2は、私にとってまったく意味のないものです。API開発者がJava SE 11の言語機能に制限されるのに、Java SE 17へのコンパイルを要求されなければならない理由がわかりません。そして、それ以外の人はJava SE 17を使うことを求められるのはおかしな話です。

考えてみると、いくつかのAPIでサポートすることに意味があるRecordを除いては、Java SE 11とJava SE 17の間には、API開発者の生活を楽にするような言語機能はそれほど多くありません。しかし、多くのユーザーがいまだにJava SE 8を使用していることを考えると、多くのユーザーを置き去りにするコストを正当化できるとは思えません。Java SE 17は、Jakarta EE 11のベースラインになるかもしれません。そうすれば API開発者に対し、仕様に追加する前に、新しい言語機能のための最適なイディオムを確立するための時間を与えることができるでしょう。

ここまで読んでくださった方は、私のお気に入りが選択肢1であることも察してくださったことでしょう。