※本記事は、Alan Zeichickによる“Java 18 is here: 9 JEPs with core library improvements and updates”を自動翻訳したものです。

2022年3月23日

Java 18のJDK Enhancement Proposalは、改良されたコードスニペットから、Vector APIや switchのパターンマッチに関する作業の進展まで、あらゆるものをカバーしています。

シンプルなウェブサーバーが欲しい？Java 18にはそれがあります。リフレクションの開発・保守コストを削減するJDK Enhancement Proposal (JEP)はいかがでしょうか？インターネットアドレスの解決？Java 18にはあります。Java API ドキュメントでコードスニペットを見たいと思いませんか？ありますよ、Java 18から。Vector API、Foreign Function and Memory API、switchのパターンマッチの進展はどうですか？はい、Java 18はこれら3つのプレビューとincubator機能をすべて進化させます。

Java 18の多くの詳細は、OpenJDKサイトのJDK 18ページで数カ月前から公開されていましたが、3月22日にプラットフォームが一般に利用可能になりました。開発者はソースコードに取り組み、バイナリを実行し、多くの人がコメント、バグレポート、提案を寄せています。

Java 18と9つのJEPの詳細については、以下のリソースを参照してください。

上記のAPIの違いからわかるように、Java 17（build 35）とJava 18（build 37）の間には、186の変更文書があり、340の変更コンテキストがあることがわかりました。これらすべてが機能強化というわけではなく、報告された2,063件の問題がこのリリースで修正されたとマークされています。

なお、Java 17とは異なり、Java 18はLTS（Long-Term Support）リリースではありません。次のLTSリリースはJava 21で、2023年9月にリリースされる予定です。(LTSリリースの間隔は、最近2年に短縮されました)。

Java 18に集められた9つのJEPは、4つのカテゴリーに分類することができます：コアライブラリの改善と更新、ツールの改善、プレビューとインキュベーター、そして非推奨、つまり将来のバージョンのJavaで削除されるように準備されている機能です。ここからJEPの概要をご紹介します。

 

コアライブラリの改良と更新

JEP 400：UTF-8（デフォルト）　ファイルの読み書きやテキスト処理のための標準的なJava APIは、引数として文字セットを渡すことができます。文字セットは、生のバイトとJavaプログラミング言語の16ビット文字値との間の変換を支配します。Javaは，US-ASCII，UTF-8，ISO-8859-1を含むいくつかの文字集合をサポートしています。

このJEPは、おそらく最も一般的なUnicode文字セットであるUTF-8を、標準的なJava APIのデフォルト文字セットとして指定します。この変更により、デフォルトの文字セットを使用するAPIは、すべての実装、オペレーティングシステム、ロケール、および設定に一貫して動作するようになります。

このJEPの目標は、デフォルトの文字セットに依存するJavaプログラムの予測性・移植性を高めること、標準Java APIがデフォルトの文字セットを使用する場所を明確にすること、console I/Oを除く標準Java API全体をUTF-8に標準化することです。

JEP 408：Simple Web Server　開発者はしばしば、HTMLファイルのような静的なドキュメントをネットワーク上で提供する必要があります。例えば、コンピュータサイエンスのカリキュラムでは、学生にWeb開発を紹介することがよくありますが、これはファイルを提供することを意味します。この機能は、日常的なソフトウェア開発でも必要とされることがあります。

この JEP は、静的ファイルのみを提供する最小限のウェブサーバーを起動するためのコマンドラインツールを提供します。CGIやサーブレットのような機能はありません。このツールは、プロトタイピング、アドホックコーディング、およびテスト目的、特に教育的な文脈で有用であることが期待されます。

この JEP の目標は、簡単な設定と最小限の機能で、すぐに使える静的 HTTP ファイルサーバーを提供し、JDK をより親しみやすいものにすることです。また、この JEP は、コマンドラインによるデフォルトの実装と、プログラムによる作成とカスタマイズのための小さな API を提供します。

JEP 416: メソッドハンドルによるコアリフレクションの再実装　コアリフレクションによってメソッドとコンストラクタを呼び出すための2つの内部機構があります。高速起動のために、HotSpot JVMは特定の反射メソッドまたはコンストラクター オブジェクトの最初の数回の呼び出しのためにネイティブメソッドを使用します。数回呼び出された後、反射操作のためのbytecodeを生成し、より良いピーク性能のために、その後の呼び出しでそれらを使用します。

このJEPは、java.lang.invokeメソッドハンドルの上にjava.lang.reflect.Method, Constructor, および Fieldを再実装し、メソッドハンドルを反射のための基礎メカニズムにするものです。その結果、java.lang.reflectとjava.lang.invoke両方のAPIの将来のメンテナンスと開発コストが削減されることを意図しています。

JEP 418: Internet address resolution SPI (service-provider interface)　java.net.InetAddress APIは、ホスト名とインターネットプロトコル（IP）アドレスの解決、またはその逆を行います。JEP 418 より前は、この API はオペレーティング・システムのネイティブ・リゾルバを使用しており、通常、ローカルのホスト・ファイルと DNS (Domain Name System) を組み合わせて使用するように設定されていました。これは、呼び出しがブロックされることがあり、仮想スレッドを処理するのが容易でないため、あまり良いものではありませんでした。

そこで、このJEPでは、ホスト名とアドレスの解決のためのSPIを定義し、java.net.InetAddressがプラットフォームの組み込みリゾルバ以外のリゾルバを使用できるようにしています。

 

ツールの改善

JEP 413：Java API ドキュメントにおけるCode snippets　API ドキュメントの作者は、ドキュメントのコメント中にソースコードの断片を頻繁に含めます。しかし、コード断片を確実に検出し、その妥当性をチェックするツールはありません。さらに、そのような断片はHTMLを含んでいるかもしれず、IDEで編集できないかもしれません。

このJEPは、Javadocの標準的なdocletのための新しい@snippetタグを定義し、APIドキュメントにソースコードの例を含めることが容易になります。このタグは、ソースコードの断片への API アクセスを提供することで、ソースコードの断片の検証を容易にします。また、この新しいタグは、syntax highlightingなどのモダンなスタイルを可能にし、snippetの作成と編集のためのIDEサポートを充実させることができます。

 

プレビューと インキュベータ

JEP 417：Vector API（第3インキュベータ）　ベクトル演算は、ベクトルに対する一連の演算からなります。同じレーン数の2つのベクトルにバイナリ演算を適用すると、各レーンに対して、各ベクトルから対応する2つのスカラ値に対して同等のスカラ演算が適用されることになる。これは一般にSIMD（Single Instruction, Multiple Data）と呼ばれています。

HotSpot JVMはすでに自動ベクトル化をサポートしており、スカラー演算をスーパーワード演算に変換し、それをベクトル命令にマッピングしています。しかし、変換可能なスカラー演算のセットは限られており、コード形状の変化に対して脆弱な場合もあります。さらに、利用可能なベクトル命令の一部しか利用できない可能性があり、生成されるコードの性能に制約が生じます。

本JEPは、3回目のインキュベータであり、サポートするCPUアーキテクチャ上で最適なベクトル命令を実行時に確実にコンパイルできるベクトル計算を表現するAPIを作成します。スカラー計算での同等の計算と比較して、優れた性能を発揮します。 これまでのインキュベータは、Java 16やJava 17で提供されていました。

つまり、Vector APIは、スケーラブルなベクトル拡張を提供するCPUアーキテクチャを確実に活用するための、開発者向けAPIです。広範なベクトル計算を明確かつ簡潔に表現する信頼性の高い方法を提供するようになるのです。

JEP 419: Foreign Function and Memory API (第2インキュベータ)　Java APIは開発者にJava以外のリソースを公開しますが、JVMと同じマシン上にあるJava以外のコードやデータ、しかしJavaランタイムの外にあるものにアクセスするのは困難な場合があります。

このJEPは2番目のインキュベータで、JavaプログラムがJavaランタイム外のコードやデータと相互運用できるAPIを導入しています。このAPIは、外部関数（JVM外のコードとして定義される）を効率的に呼び出したり、外部メモリ（JVMによって管理されていないメモリ）に安全にアクセスすることによって、Java Native Interface（JNI）の脆弱性や危険性なしに、Javaプログラムによるネイティブ・ライブラリの呼び出しやネイティブ・データの処理を行うことができます。

このJEPは、使いやすさ、パフォーマンス、安全性に重点を置いています。また、さまざまな種類の外部メモリ（ネイティブメモリ、永続メモリ、管理ヒープメモリなど）で動作するように設計されており、時間の経過とともに、他のプラットフォーム（32ビットx86など）やC以外の言語（C++やFortranなど）で書かれた外部関数に対応するように進化しています。

以前のインキュベータはJava 17にあり、それまでの2つのインキュベータAPI、すなわちForeign-Memory Access APIとForeign Linker APIを組み合わせたものであった。

JEP 420: switchのパターン・マッチング（第２プレビュー)　Java 16 では、JEP 394 (pattern matching for instanceof) が instanceof 演算子を拡張して、型パターンを受け取ってパターン・マッチングを行うようにしました。JEP 420は、パターンの言語の拡張とともに、switch式やステートメントに対するパターンマッチングでJava言語を強化するものです。

switchにパターンマッチングを拡張することで、式が多くの異なるパターンに対してテストされ、それぞれが特定のアクションを持つようになり、複雑なデータ指向のクエリを簡潔かつ安全に表現できるようになります。

switchのためのパターンマッチングの最初のプレビューはJava 17でした。このバージョンではいくつかの改良が加えられています。

 

将来に対応したJavaプログラム

JEP 421：ファイナライズを非推奨とし削除に備える　この JEP で扱われる問題は、リソース・リークを効率的に防止する必要性です。もし、JVMのガベージコレクタが、リソース自体がオペレーティングシステムに解放される前に、未使用のリソースのメモリを取り戻すと、そのリソースを解放するために必要な情報が失われてしまいます。このような場合、オペレーティングシステムは、リソースがまだ使用中であるとみなすため、リソースを解放することができません。このように、リークが発生してしまうのです。

Java 1.0で導入されたfinalization mechanismは、リソース・リークを避けるために設計されましたが、この機構は、予測できない待ち時間、制約のない動作、不特定のスレッドを導入するため、欠陥があると言えます。また、必要であろうとなかろうと、常に有効になってしまいます。

幸い、try-with-resources や cleaners など、より新しく、より効果的なメカニズムが存在します。

この JEP は、将来のリリースで削除するために、finalization を非推奨としています。最終化は今のところデフォルトで有効なままですが、初期のテストを容易にするために無効にすることができます。将来のリリースでは、finalization はデフォルトで無効化され、後のリリースで削除される予定です。

 

まとめ

Java 18は、4つのバケットに9つのJEPを提供しています。おそらくほとんどの開発者は、switchのパターンマッチングに注目するでしょうが、Java 18 には誰にとっても役立つものがあります。

 

さらに詳しく

 

 

Alan Zeichick

Editor in Chief, Java Magazine

Alan Zeichickは、Java Magazineの編集長であり、オラクルのContent Centralグループの編集長でもあります。元メインフレーム・ソフトウェア開発者、テクノロジー・アナリストで、これまでAI Expert、Network Magazine、Software Development Times、Eclipse Review、Software Test & Performanceの編集者を務めてきました。Twitterアカウントはこちら @zeichick.