Oracleは、Javaプログラミング言語と仮想マシンのバージョン17をリリースした。最終的な機能セットには、2018年にリリースされた最初のLTS(long-term support)であるJDK 11以降の14のJEPが含まれている。
- 306: 厳密性を維持する浮動小数点セマンティクスの復活
- 356: 仮想乱数生成器の強化
- 382: 新しいmacOSレンダリングパイプライン
- 391: macOS/AArch64への移植
- 398: Applet APIの削除に向けた非推奨化
- 403: JDK内部のカプセル化の強化
- 406: switchパターンマッチング(プレビュー)
- 407: RMIアクティベーションの削除
- 409: Sealedクラス
- 410: 実験的AOTおよびJITコンパイラの削除
- 411: Security Managerの削除に向けた非推奨化
- 412: 他言語関数とメモリAPI(インキュベータ)
- 414: Vector API(セカンドインキュベータ)
- 415: コンテキスト固有のデシリアライズフィルタ
Java 17のフィーチャーケイデンス(feature cadence)は、従来のJava 16(17機能)やJava 15(14機能)、Java 14(16機能)と変わっていないが、
機能セット中のJEP 403とJEP 411の2つのJEPが、Javaコミュニティ内にいくつかの懸念を引き起こしている。今回はそれらを検証してみよう。
403: JDK内部のカプセル化の強化
Project Jigsawの大きな目標のひとつとして、JEP 403では、sun.misc.Unsafeなどの重要な内部APIを例外として、JDKの内部要素すべてを強力にカプセル化することにより、セキュリティとメンテナンス性を改善する提案がされている。 "JDK内部をデフォルトで強力にカプセル化"したJEP 396に続いて、Java 17では、コマンド行オプションの--illegal-accessによるカプセル化の回避が不可能になる。例えば、値としてpermitを設定してこのオプションを試すと、以下のような警告を受け取ることになる。
$ java --illegal-access=permit {filename}.java
OpenJDK 64-Bit Server VM warning: Ignoring option --illegal-access=permit;
support was removed in 17.0
詳細はこちらのInfoQニュースで紹介している。
JEP 411: <a0>Security Managerの削除に向けた非推奨化
Security Managerは長い間、クライアント側のJavaコードを安全にする主要な手段としても、サーバ側コードをセキュアにするためにも、ほとんど使われていなかった。このJEPは、JEP 398 "Applet APIの削除に向けた非推奨化"と同じく、Java 1.0で導入されたSecurity Managerを、削除を前提とした非推奨化の対象にするものだ。その理由は、JEP 411の"リスクと仮定"の章で説明されている。
Jakarta EEには、Security Managerに関するいくつかの要件があります。Jakarta EE準拠アプリケーションが将来的に、Security Managerがデグレードし削除された以降のJavaリリースでも動作するためには、これらの要件を緩和あるいは廃止しなければなりません。
Jakarta EEの今後の開発に関する懸念については、独立系ソフトウェアコンサルタントで著作者、23のEE4JプロジェクトのコミッタでもあるArjan Tijms氏も、次のように記している。
以前にも論じたように、Security ManagerをJava SEから削除することは、Jakarta EEにも影響します。
現在のJakarta EE 10はJava SE 11をターゲットにしているので、理屈の上では影響はないはずなのですが、実際にはJakarta EE 9.1の実装(GlassFishなど)がすでにJDK 17で動作しているので、コンソールに出力され続けるSecurity Manager非推奨の警告を何とかしなくてはなりません。ですから、すべてのjakarta EE実装がこれと同じ問題に突き当たるのは、もはや時間の問題なのです。
Security Managerが実際に削除される正確な時期は分かりませんが、Java SE 18やJava SE 19などバージョンに関係なく、EEの実装を実行する上での障害になります。さらに、APIアーティファクトにも影響します。これらがSecurity Manager呼び出しを行うからです。現状では、これらのAPIアーティファクトは、Security Managerを削除したJava SEでは動作しないはずです。
ですから、EE 10でもこれに備えておいた方が、おそらくはよいでしょう。まず最初にすべきなのは、Jakarta EEがJava SEに追従し、将来的にSecurity Managerの使用を廃止するという意図のステートメントを追加することだと思います。現時点でこれが明確になっていないために、問題に関する公式声明があるまで対応を保留しているという、慎重なチームも一部にあるようです。
次のJEPになると予想されている、Java 18におけるSecurity Managerの非推奨化をさらに進めるプランには、エンドユーザが明示的な許可を与えない限り、アプリケーションやライブラリがSecurity Managerを動的にインストールしないようにすること、Security Manager APIは維持するが、機能を制限するか、あるいはまったく機能しないものにデグレードすること、などが含まれている。
詳細はこちらのInfoQニュースで紹介している。
Java 17は"必要十分(Glass Half Full)"か？
今年始めのInfoQの記事では、Java 17のリリースは"必要十分"なものであって、多くの開発者が期待したレベルには達していない、と評していた。Record(JEP 395)とSealed Type(JEP 409)は完全な形で提供されたものの、パターンマッチング(JEP 409)がプレビューのままであったことが、その理由のひとつだ。
Java 18
現時点では、Java 18でTargetedあるいはIntegratedとなっているJEPはわずか2つである。
- JEP 400: UTF-8をデフォルトとする
- JEP 413: Java APIドキュメントのコードスニペット
Proposed to TargetのJEPがひとつある。
- JEP 417: Vector API(サードインキュベータ)
JEP 400は、すべての実装、オペレーティングシステム、ロケール、設定に対して、UTF-8を標準Java APIのデフォルト文字セットにする、というものだ。
JEP 413では、デフォルトのHTML形式出力を生成する標準的なJava APIドキュメントユーティリティである、OracleのStandard Docletに、@snippetタグを導入する。APIドキュメントにソースコード例を含むための便宜を図る、というのがその意図だ。
Java 18のリリース日はまだ発表されていないが、6か月というリリースケイデンスを考えれば、2022年3月中旬に提供されるものと思われる。開発者に対するフューチャーフリーズは2021年12月中旬になるだろう。
Java 17は現在、Oracleからダウンロードすることができる。その他のベンダからも、近日中に提供されるものと期待される。