BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース 次期LTSリリースJava 17の提供が開始

次期LTSリリースJava 17の提供が開始

ブックマーク

原文(投稿日:2021/09/14)へのリンク

Oracleは、Javaプログラミング言語と仮想マシンのバージョン17リリースした。最終的な機能セットには、2018年にリリースされた最初のLTS(long-term support)であるJDK 11以降の14のJEPが含まれている。

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つである。

Proposed to TargetのJEPがひとつある。

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からダウンロードすることができる。その他のベンダからも、近日中に提供されるものと期待される。

この記事に星をつける

おすすめ度
スタイル

BT