OracleはJavaプログラミング言語とバーチャルマシンのバージョン 15を先頃リリースした。
新しいOpenJDKリリースのリズムでは、これは作業がすでにバージョン 16にシフトしていることを意味し、これは2021年3月にリリースされる予定だ。
このリリースの対象となる、いくつかの新機能がすでに発表されている。これらはいくつかのカテゴリに細分される。OpenJDKの開発方法に関する手順のアップグレードのいくつかから始める:
* MercurialからGitへの移行 (JEP 357)
* GitHubへの移行 (JEP 369)
* C++14言語機能の有効化 (JEP 347)
いくつかの新しいAPIとツールがある - これらはまだインキュベーション形式だ:
* ベクターAPI (Incubator) (JEP 338)
* 外部リンカ API (Incubator) (JEP 389)
* 外部メモリアクセス API (Third Incubator) (JEP 393)
* ユニックスドメインソケットチャネル (JEP 380)
* パッケージングツール (JEP 392)
最初のこれら3つは、Project Panamaの面からの提供だ。これは、明確に定義されているが「外部」の (つまりJavaではない) APIと相互運用するJVM管理コードの機能を向上させるOpenJDKのプロジェクトだ。特に、これにはCライブラリで一般的に使用されるインターフェイスが含まれる。Panamaは大雑把には「JNIの再イメージ化」と考えることができるが、それだけではない。これらのJEPはまだインキュベーション中であり、Javaの将来のバージョンまで最終的なものにはならない。
他の提供されるJEPのカテゴリではマイナーなVMの改善がある:
* 弾力性のあるメタスペース (JEP 387)
* ZGC: 並行スレッドスタックプロセッシング (JEP 376)
1つは内部メタデータ領域から未使用のメモリを解放しオペレーティングシステムに返すことをJVMで有効にする。2つはZGCガベージコレクタのスピードを改善する。
さまざまなオペレーティングシステムへのOpenJDKの新しいポートがいくつか期待されている:
* Alpine Linuxポート (JEP 386)
* Windows/AArch64ポート (JEP 388)
これには最初の公式のOpenJDKのメインライン (Azul Systemsはしばらくの間AlpineのJavaの有償サポートを提供していた) のAlpine Linuxポートサポートを含む。
ポートカテゴリには、Apple SiliconでJavaを有効にするポートであるJEP 391 (macOS/AArch64 ポート) も含まれるかもしれない。これは進行中であり、Azul SystemsとMicrosoftの両方の支援を受けているが (Monica Beckwith氏の最近のQCon講演で詳細をご覧ください) 、Java 16の正式な対象になっていない、プロジェクトチームは、このリリースの一部として出荷できるかについて話し合っている。
カテゴリはさらにProject Amber機能の次のイテレーションである:
* instanceofパターンマッチング (JEP 394)
* Records (JEP 395)
* Sealed Classes (2回目のプレビュー) (JEP 397) (tbc)
私たちはInfoQでRecordsとSealed Classesは以前カバーした - ただし、Sealed Classesの2回目のプレビューではまだJava 16を対象としていないが、対象となる可能性が高いことに注意。
Java 16を対象とするもう1つの開発者向け機能がある:
* デフォルトでJDK内部を強力にカプセル化 (JEP 396)
これは、OpenJDKの開発チームがより速く動くことができるように、JDK内部へのアクセスを閉鎖するジャーニーの次のステップだ。これは、有名な sun.misc.Unsafe を jdk.unsupported モジュールに移動したものと、引き続き使用できるものとが含まれる。
Java 16は長期サポート (LTS) リリースではないため広く採用される可能性は低い。- 以前のLTSではないリリースがそうだったという事実に基づいて。
ロードマップによると、次のLTSリリースはJava 17になる予定だ。これは2021年9月に予定されており、それを対象とする機能はまだ明確な発表がない。
ただし、バージョン 16のコンテンツにより、Java 17についていくつかのことは推測できる。これは、Java 16が次のLTSリリースの前にプレビューまたはインキュベーション機能を追加する最後の機会であるためだ。Oracleは通常、慎重であり、機能のプレビューを少なくとも1回行わなければ主要な新機能を提供しない。
この段階では、来年 (2021年) 3月までにプレビューとして出荷する準備が整う Project Valhalla (インラインタイプの追加、およびJVMの低レベルデータモデルの再イメージ化) や Project Loom (VM管理の「仮想スレッド」の追加と大幅に拡張された同時実行性モデル) はいずれも示されていない。結果として、これらの新しいイニシアチブは、Java 17 LTSリリースの最終機能として利用できない可能性がかなり高いようだ。
これは、現在予測する限り、OpenJDKで進行中の4つの主要プロジェクト (Valhalla、Loom、Panama、Amber) は、いずれも来年 (2021年) の9月までに完全に提供されることはないことを意味する。
運が良ければ、RecordsとSealed Classesの両方の最終機能、パターンマッチングの作業はまだまだ不完全ではあるが、switch 式と instanceof パターンのみは完全にデリバリーされる機能としてふさわしいAmberの一部がデリバリーされる可能性がある。一部のPanama JEP (特に、Java 16の3番目のIncubatorにあるJEP 393) も完成する可能性があるが、すべてではない。これはまだ進行中であり、コミュニティにとって価値はあるが、プロジェクトの範囲と約束に比べるとかなり圧倒される。
Oracleのスタッフは、LTSリリースについて特別なことは何もないという意見を頻繁に表明している。Oracleのサポートビジネスの一部であり、それほど重要ではないと彼らは指摘しているにすぎない。これは技術的な観点からは真実だが、現場の状況は変わっていない - Javaバージョンの6か月の強制的なアップグレードのリズムを採用することをいとわないチームはほとんどなく、代わりにJava 8および11を使用し続けている - たとえそれが真実でもJavaベンダーとしてのOracleから切り替えることを意味する。この傾向が2021年に変化することを示唆することは示されていない。
Java 17が次のLTSリリースになる場合、コミュニティは「パンは半分でも何もないよりはまし」と判断する可能性がある。これには、パフォーマンスのヒープやその他の内部改善だけでなく、いくつかの優れた機能 (クラスデータシェアリング、JFRストリーミング、Records、スイッチ式など) がある。それは目論見違いものになる可能性がある - そして次のLTS (LTSをLTSにアップグレードするだけが大多数の確立されたパターンが続くと仮定すると) でコミュニティが実際に気にかけている機能の完全なデリバリーの前に、さらに3年待つことに直面するのはかなり残念だ。このようなリリースの採用はかなり遅いかもしれない - おそらくJava 11の採用よりもさらに遅くなるだろう。
ただし、OracleがLTSリリースのリズムを変更し、Java 17をLTSにしないことを選択し、代わりに、より多くの機能が最終状態になるまで待つ別の可能性がある。たとえば、LTSを2022年 (Java 19) に1年遅らせると、残りのAmber、Loom、さらに多くのPanama、そしておそらくValhallaさえも完成したリリース可能な状態にするのに十分な時間が与えられる可能性がある。これはロードマップの変更であり、もう1年待つ必要があるが、コミュニティは再活性化し、今後数十年にわたってJavaを更新するために、はるかに完全で説得力のあるリリースになる可能性がある。