以前のバージョンから Red Hat build of OpenJDK 21 への移行

OpenJDK は、Java Platform、Standard Edition (Java SE) の無料のオープンソースリファレンス実装です。Red Hat build of OpenJDK ディストリビューションは、アップストリームの OpenJDK 8u、OpenJDK 11u、OpenJDK 17u、および OpenJDK 21u プロジェクトに基づいています。Shenandoah ガベージコレクターは、サポートされているすべての Red Hat build of OpenJDK バージョンに含まれています。

Red Hat build of OpenJDK のすべてのバージョンには、次の利点があります。

Red Hat build of OpenJDK 8 と Red Hat build of OpenJDK 11 の間には、暗号化とセキュリティーに若干の違いがあります。ただし、Red Hat build of OpenJDK の両バージョンには、多くの類似した暗号化およびセキュリティー動作があります。

Red Hat build of OpenJDK はシステム全体の証明書を使用し、各ビルドはシステムのグローバル設定から無効な暗号化アルゴリズムのリストを取得します。これらの設定は、Red Hat build of OpenJDK のすべてのバージョンに共通であるため、Red Hat build of OpenJDK 8 から Red Hat build of OpenJDK 11 以降に簡単に変更できます。

FIPS モードでは、Red Hat build of OpenJDK 8 と Red Hat build of OpenJDK 11 のリリースは自己設定されるため、どちらのリリースでも起動時に同じセキュリティープロバイダーが使用されます。

Red Hat build of OpenJDK 8 と Red Hat build of OpenJDK 11 の TLS スタックは同じです。これは、Red Hat build of OpenJDK 11 の SunJSSE エンジンが Red Hat build of OpenJDK 8 にバックポートされたためです。Red Hat build of OpenJDK の両バージョンが、TLS 1.3 プロトコルをサポートしています。

Red Hat build of OpenJDK 8 と Red Hat build of OpenJDK 11 の間には、次のように、暗号化とセキュリティーに若干の違いがあります。

ガベージコレクションの場合、Red Hat build of OpenJDK 8 ではデフォルトで Parallel コレクターが使用されますが、Red Hat build of OpenJDK 11 ではデフォルトで Garbage-First (G1) コレクターが使用されます。

ガベージコレクターを選択する前に、次の詳細を考慮してください。

起動時に ‑XX:+<gc_type> JVM オプションを指定することにより、使用するガベージコレクターのタイプを選択できます。たとえば、‑XX:+UseParallelGC オプションは Parallel コレクターに切り替えます。

Red Hat build of OpenJDK 11 には、古いロギングフレームワークよりも効率的に機能する、より強力な新しいロギングフレームワークが含まれています。Red Hat build of OpenJDK 11 には、統合された JVM ロギングオプションと統合された GC ロギングオプションも含まれています。

Red Hat build of OpenJDK 11 のロギングシステムは、デフォルトで - XX:+PrintGCTimeStamps および -XX:+PrintGCDateStamps オプションをアクティブにします。Red Hat build of OpenJDK 11 のロギング形式は Red Hat build of OpenJDK 8 とは異なるため、ガベージコレクターログを解析するコードを更新する必要がある場合があります。

次の表は、Red Hat build of OpenJDK バージョン 8 と 11 の間のガベージコレクターのログオプションの変更点を示しています。

-XX:+PrintGCDetails オプションを使用する場合は、-Xlog:gc* フラグを渡します。アスタリスク (*) を指定することで、より詳細なロギングがアクティブになります。または、-Xlog:gc+$tags フラグを渡すこともできます。

-Xloggc オプションを使用する場合は、:file=$FILE 接尾辞を追加して、ログ出力を指定されたファイルにリダイレクトします。たとえば、-Xlog:gc:file=$FILE です。

Red Hat build of OpenJDK 11 では、タイムスタンプと日付スタンプの出力が自動的に有効になるため、次のオプションも削除されます。

バージョン 8u252 以前の Red Hat build of OpenJDK 8 では、デフォルトのレンダリングエンジンとして Pisces を使用していました。バージョン 8u252 以降の Red Hat build of OpenJDK 8 では、新しいデフォルトのレンダリングエンジンとして Marlin が使用されます。Red Hat build of OpenJDK 11 以降のリリースでも、デフォルトで Marlin が使用されています。Marlin は、負荷の高いアプリケーショングラフィックスの処理を改善します。

レンダリングエンジンは同じ結果を生成するため、ユーザーにとっては、パフォーマンスの向上以外に特に違いはありません。

RHEL 7、RHEL 8、および Microsoft Windows オペレーティングシステム上の Red Hat build of OpenJDK 8 および Red Hat build of OpenJDK 11 で IcedTea-Web プラグインを使用することで、Java WebStart を使用できます。IcedTea-Web プラグインでは、システムに依存関係として Red Hat build of OpenJDK 8 がインストールされている必要があります。

アプレットは、Red Hat build of OpenJDK のどのバージョンでもサポートされていません。一部のアプレットは、Netscape プラグインアプリケーションプログラミングインターフェイス (NPAPI) ブラウザーで OpenJDK 8 と IcedTea-web プラグインを使用することで RHEL 7 上で実行できますが、Red Hat build of OpenJDK ではこの動作はサポートされていません。

OpenJDK 9 で導入された Java Platform Module System (JPMS) は、非公開 API へのアクセスを制限または防止します。JPMS は、Java アプリケーションの起動およびコンパイル方法 (クラスパスを使用するか、モジュールパスを使用するかなど) にも影響します。

以下に例を示します。

--add-opens java.base/jdk.internal.math=ALL-UNNAMED

さらに、--illegal-access=warn オプションを java コマンドに渡すことで、不正アクセスのケースを確認できます。このオプションは、Red Hat build of OpenJDK のデフォルトの動作を変更します。

Red Hat build of OpenJDK 11 では、システムクラスローダーが URLClassLoader のインスタンスではなくなりました。Red Hat build of OpenJDK 11 で ClassLoader::getSystemClassLoader を呼び出してその結果を URLClassLoader にキャストする既存のアプリケーションコードでは、ランタイム例外が発生します。

Red Hat build of OpenJDK 8 では、クラスローダーを作成するときに、このクラスローダーインスタンスの親として null を渡すことができます。ただし、Red Hat build of OpenJDK 11 では、クラスローダーの親として null を渡すアプリケーションにより、クラスローダーがプラットフォームクラスを見つけられなくなる可能性があります。

Red Hat build of OpenJDK 11 には、特定のクラスのロードを制御できる新しいクラスローダーが含まれています。これにより、クラスローダーが必要なすべてのクラスを見つける方法が改善されます。Red Hat build of OpenJDK 11 では、クラスローダーインスタンスを作成するときに、ClassLoader.getPlatformClassLoader() API を使用してプラットフォームクラスローダーを親として設定できます。

Red Hat build of OpenJDK 11 では、オプションパッケージをサポートする拡張メカニズムと承認された標準オーバーライドメカニズムの両方が利用できなくなりました。

これらの変更により、<JAVA_HOME>/lib/ext または <JAVA_HOME>/lib/endorsed ディレクトリーに追加されたライブラリーは使用されなくなり、これらのディレクトリーが存在する場合、Red Hat build of OpenJDK 11 ではエラーが生成されます。

JDK Flight Recorder (JFR) サポートは、バージョン 8u262 以降の Red Hat build of OpenJDK 8 にバックポートされました。JFR サポートは、Red Hat build of OpenJDK 8u272 以降デフォルトで有効になりました。

別途配布される JDK Mission Control も、Red Hat build of OpenJDK 8 と互換性を確保できるように更新されました。

この取り組みを支援するために、Red Hat は、実行時に JFR が無効になっているかのように動作する、JFR の空の実装を提供する特別な互換性レイヤーを開発しました。JFR 互換性 API の詳細は、openjdk8-jfr-compat を参照してください。生成された .jar ファイルは、OpenJDK 8 ディストリビューションの jre/lib/ext ディレクトリーにインストールできます。

これらのアプリケーションが、MBean インターフェイスを照会するのではなく、バージョン番号のみをチェックして OpenJDK 8 を除外していた場合、一部のアプリケーションを更新する必要がある可能性があります。

RHEL プラットフォーム用の Red Hat build of OpenJDK のすべてのバージョンは、以下のタイプのパッケージに分かれています。次のパッケージタイプのリストは、最も最小限のものから順にソートされています。

Windows プラットフォーム用の Red Hat build of OpenJDK バージョンは、ヘッドレスパッケージをサポートしていません。ただし、Windows プラットフォーム用の Red Hat build of OpenJDK パッケージも、RHEL プラットフォームのパッケージと同様に JRE および JDK コンポーネントに分割されています。

OpenJDK 9 では、名前空間ごとに分割された JDK クラスライブラリーのモジュール化バージョンが導入されました。Red Hat build of OpenJDK 11 以降、これらのライブラリーは jmods モジュールにパッケージ化されています。詳細は、Jmods を参照してください。

OpenJDK 9 では、JDK クラスライブラリーのモジュール化されたバージョンである jmods が導入され、各モジュールは関連するパッケージのセットからクラスをグループ化します。jlink ツールを使用して、選択したアプリケーションを実行するために必要なモジュールのサブセットのみを含む派生ランタイムを作成できます。

Red Hat build of OpenJDK 11 以降、RHEL プラットフォーム用の Red Hat build of OpenJDK では、jmods ファイルが、デフォルトでインストールされない別の RPM パッケージに配置されます。jlink を使用してアプリケーション用のスタンドアロン OpenJDK イメージを作成する場合は、jmods パッケージ (例: java-11-openjdk-jmods) を手動でインストールする必要があります。

Red Hat build of OpenJDK 11 では、Red Hat build of OpenJDK 8 がサポートする一部の機能が非推奨または削除されています。

Red Hat build of OpenJDK 17 には、Concurrent Mark Sweep (CMS) ガベージコレクターが含まれなくなりました。これは、一時停止時間と遅延に敏感なワークロードに対して以前のリリースで一般的に使用されていました。

CMS コレクターを使用している場合は、Red Hat build of OpenJDK 17 以降に移行する前に、ワークロードに基づいて以下のいずれかのコレクターに切り替えます。

詳細は、JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector を参照してください。

Red Hat build of OpenJDK 17 には、以下の機能が含まれなくなりました。

OpenJDK 9 で JMOD モジュール形式が導入されて以来、これらのツールと API の使用は制限されています。

詳細は JEP 367: Remove the Pack200 Tools and API を参照してください。

Red Hat build of OpenJDK 17 には、以下の機能が含まれなくなりました。

スクリプト API javax.script は、Red Hat build of OpenJDK 17 以降でも引き続き使用できます。OpenJDK 8 より前のリリースと同様に、Rhino や現在は外部で管理されている Nashorn JavaScript エンジンなど、任意の JavaScript エンジンで javax.script API を使用できます。

詳細は、JEP 372: Remove the Nashorn JavaScript Engine を参照してください。

Red Hat build of OpenJDK 17 では、sun.misc.Unsafe などの重要な内部 API を除いて、JDK のすべての内部要素の強力なカプセル化が導入されています。Red Hat build of OpenJDK 17 以降では、コマンドラインオプション 1 つを使用して内部要素の強力なカプセル化を軽減できません。つまり、Red Hat build of OpenJDK 17 以降のバージョンでは、重要な内部 API 以外の JDK 内部型へのリフレクションアクセスができません。

詳細は、JEP 403: Strongly Encapsulate JDK Internals を参照してください。

Red Hat build of OpenJDK 17 では、バイアスロックがデフォルトで無効になっています。Red Hat build of OpenJDK 17 では、起動時に -XX:+UseBiasedLocking JVM オプションを設定して、バイアスロックを有効にすることができます。ただし、-XX:+UseBiasedLocking オプションは Red Hat build of OpenJDK 17 では非推奨となっており、OpenJDK 18 では削除される予定です。

詳細は、JEP 374: Deprecate and Disable Biased Locking を参照してください。

Red Hat build of OpenJDK 17 では、Java リモートメソッド呼び出し (RMI) 用の java.rmi.activation パッケージとそれに関連する rmid アクティベーションデーモンが削除されます。その他の RMI 機能は、Red Hat build of OpenJDK 17 以降のバージョンでも引き続き利用できます。

詳細は、JEP 407: Remove RMI Activation を参照してください。

Red Hat build of OpenJDK 17 では、jaotc ツールと jdk.internal.vm.compiler および jdk.internal.vm.compiler.management モジュールで構成される Graal コンパイラーが削除されます。Red Hat build of OpenJDK 17 以降では、事前 (AOT) コンパイルを使用する場合は GraalVM を使用できます。

詳細は、JEP 410: Remove the Experimental AOT and JIT Compiler を参照してください。

Red Hat build of OpenJDK 21 以降では、ファイルの読み取りと書き込み、およびテキストの処理に API を使用する場合、UTF-8 がデフォルトの文字セットになります。以前のリリースでは、引数として文字セットが渡されなかった場合、文字セットはランタイム環境に基づいており、呼び出される特定のメソッドに依存していました。アプリケーションで使用される文字エンコードの想定が異なるものとならないように、アプリケーションのソースコードと環境を確認してください。

詳細は、JEP 400: UTF-8 by Default を参照してください。

Red Hat build of OpenJDK 21 では、Z ガベージコレクター (ZGC) が拡張され、新しいオブジェクトと古いオブジェクトの割り当てリージョン (つまり、世代) が別々に維持されます。この機能強化により、ZGC は新しいオブジェクトをより頻繁に収集できるようになり、アプリケーションのパフォーマンスが向上します。

起動時に -XX:+UseZGC および -XX:+ZGenerational JVM オプションを指定し、世代別 ZGC を有効にすることができます。

詳細は、JEP 439: Generational ZGC を参照してください。

Red Hat build of OpenJDK 21 では、実行中の JVM にエージェントが動的にロードされると警告が発行されます。エージェントの動的ロードは、今後のリリースではデフォルトで許可されない予定です。アプリケーションが現在、JVM へのエージェントの動的ロードに依存している場合は、別のアプローチを使用するようにアプリケーションコードを更新することを検討してください。

詳細は、JEP 451: Prepare to Disallow the Dynamic Loading of Agents を参照してください。

Red Hat build of OpenJDK 21 では、オブジェクトの破棄前のクリーンアップ操作に使用されるファイナライズ機能が非推奨になりました。ファイナライズ機能は今後のリリースで削除される予定です。

Red Hat build of OpenJDK 21 では、引き続きデフォルトでファイナライズが有効になっています。早期のテストを容易にするために、--finalization=disabled コマンドラインオプションを設定してファイナライズを無効化できます。

ファイナライズに依存するライブラリーやアプリケーションを保守している場合は、cleaners や try -with-resources ステートメントなどの他のリソース管理手法への移行を検討してください。この変更により、ライブラリーとアプリケーションのメンテナーはできるだけ早くコードをテストすることを推奨します。

詳細は、JEP 421: Deprecate Finalization for Removal を参照してください。

Red Hat build of OpenJDK 21 には、さまざまなリゾルバープロバイダーの使用をサポートするホスト名とアドレス解決用のサービスプロバイダーインターフェイス (SPI) が含まれています。Red Hat build of OpenJDK 21 では、InetAddress API はサービスローダーを使用してリゾルバープロバイダーを検索します。以前のリリースと同様に、プロバイダーが見つからない場合、JDK は組み込み実装を使用します。

詳細は、JEP 418: Internet-Address Resolution SPI を参照してください。

Red Hat build of OpenJDK 21 には、シンプルな Web サーバーを起動するために使用できる jwebserver コマンドラインツールが含まれています。この機能の目的は、特に教育目的でのプロトタイピング、アドホックコーディング、テストをサポートすることです。

jwebserver ツールは HTTP 1.1 プロトコルをサポートし、静的ファイルのみを提供します。シンプルな Web サーバーは安全な HTTPS プロトコルをサポートしていないため、実稼働サービスには適していません。

シンプルな Web サーバーを実行するには、次のコマンドを使用できます。

$ jwebserver

デフォルトでは、ファイルは現在のディレクトリーから提供されます。要求されたリソースがインデックスファイルを含むディレクトリーである場合、インデックスファイルが提供されます。

この機能には、jwebserver ツールに加えて、HTTP ヘッダーを返すために使用できる拡張リクエスト処理をサポートする API も含まれています。

以下に例を示します。

jshell> var h = HttpHandlers.handleOrElse(r -> r.getRequestMethod().equals("PUT"),
   ...> new SomePutHandler(), new SomeHandler());
jshell> var f = Filter.adaptRequest("Add Foo header", r -> r.with("Foo", List.of("Bar")));
jshell> var s = HttpServer.create(new InetSocketAddress(8080),
   ...> 10, "/", h, f);
jshell> s.start();

詳細は、JEP 408: Simple Web Server を参照してください。

Red Hat build of OpenJDK 21 では、順序付けられたコレクションを表すための新しいインターフェイスを追加するシーケンスコレクション機能が導入されています。各コレクションには、検出順序が明確に定義されたさまざまな要素があります。この機能は、順序付けられた各コレクションが最初の要素、最後の要素、およびその他の特定の要素にアクセスする方法を統一します。

interface SequencedCollection<E> extends Collection<E> {
    // new method
    SequencedCollection<E> reversed();
    // methods promoted from Deque
    void addFirst(E);
    void addLast(E);
    E getFirst();
    E getLast();
    E removeFirst();
    E removeLast();
}

SequencedCollection インターフェイスは、SortedSet、NavigableSet、LInkedHashSet、List、および Deque インターフェイスで実装されます。

interface SequencedMap<K,V> extends Map<K,V> {
    // new methods
    SequencedMap<K,V> reversed();
    SequencedSet<K> sequencedKeySet();
    SequencedCollection<V> sequencedValues();
    SequencedSet<Entry<K,V>> sequencedEntrySet();
    V putFirst(K, V);
    V putLast(K, V);
    // methods promoted from NavigableMap
    Entry<K, V> firstEntry();
    Entry<K, V> lastEntry();
    Entry<K, V> pollFirstEntry();
    Entry<K, V> pollLastEntry();
}

SequencedMap インターフェイスは、SortedMap、NavigableMap、および LInkedHashMap インターフェイスによって実装されます。

詳細は、JEP 431: Sequenced Collections を参照してください。

Red Hat build of OpenJDK 21 では、switch ステートメントのパターンマッチングによって Java プログラミング言語が強化されています。この機能拡張により、それぞれ特定のアクションを持つさまざまなパターンに対して switch 式をテストし、複雑なデータ指向クエリーを簡潔かつ安全に表現できるようになります。

オブジェクトのクラスに基づく switch ステートメントを実装できます。

以下に例を示します。

switch (obj) {
		case Integer i -> String.format("int %d", i);
		case String s  -> String.format("String %s", s);
		default        -> obj.toString();
	};

switch ステートメントの case ブロック内に when ガードを入れ子にし、より複雑な switch ステートメントを実装することもできます。

以下に例を示します。

switch (response) {
    	case null -> { }
    	case String s when s.equalsIgnoreCase("YES") -> {
        	System.out.println("You got it");
    	}
    	case String s when s.equalsIgnoreCase("NO") -> {
        	System.out.println("Shame");
    	}
    	case "n", "N" -> {
        	System.out.println("Shame");
    	}
    	case String s -> {
        	System.out.println("Sorry?");
    	}
}

アプリケーションで switch ステートメントを使用する場合は、これらのステートメントが最新であることを確認してください。

詳細は、JEP 441: Pattern Matching for switch を参照してください。

Red Hat build of OpenJDK 21 では、鍵カプセル化メカニズム (KEM) 用の API が導入されています。KEM は、公開鍵暗号を使用して対称鍵を保護するための暗号化手法です。KEM API は公開鍵暗号化の使用を容易にし、秘密やメッセージを処理する際のセキュリティーの向上に役立ちます。

詳細は、JEP 452: Key Encapsulation Mechanism API を参照してください。

Red Hat build of OpenJDK 21 には、Javadoc ツールの標準ドックレット用の @snippet タグが含まれています。@snippet タグは、API ドキュメントへのソースコードのサンプルの追加を簡素化するのに役立ちます。

以下に例を示します。

/**
 * The following code shows how to use {@code Optional.isPresent}:
 * {@snippet :
 * if (v.isPresent()) {
 * 	System.out.println("v: " + v.get()); // @highlight substring="println"
 * }
 * }
 */

/**
 * The following code shows how to use {@code Optional.isPresent}:
 * {@snippet :
 * if (v.isPresent()) {
 * 	System.out.println("v: " + v.get()); // @highlight substring="println"
 * }
 * }
 */

以下に例を示します。

/**
 * The following code shows how to use {@code Optional.isPresent}:
 * {@snippet file="ShowOptional.java" region="example"}
 */

上記の例では、ShowOptional.java は次のコードを含むファイルです。

public class ShowOptional {
	void show(Optional<String> v) {
    	// @start region="example"
    	if (v.isPresent()) {
        	System.out.println("v: " + v.get());
    	}
    	// @end
	}
}

外部コードの場所は、class 属性を使用してクラス名として指定することも、file 属性を使用して相対ファイルパスとして指定することもできます。

詳細は、JEP 413: Code Snippets in Java API Documentation を参照してください。

Red Hat build of OpenJDK 21 では、仮想スレッドが導入されています。これは、高スループットの同時実行アプリケーションの作成、保守、監視の労力を軽減する軽量スレッドです。アプリケーションが数千を超える同時スレッドを使用し、ワークロードが CPU に依存していない場合は、仮想スレッドを使用するとアプリケーションを最適化できます。

仮想スレッドはスレッドローカル変数と割り込みをサポートします。仮想スレッドは、従来のスレッドが実行できる任意のコードも実行できます。したがって、スレッドの作成方法を変更することで、仮想スレッドのみを使用するようにソースコードを移行できます。

次の例では、実行可能なインスタンスを実行する仮想スレッドを作成します。

Thread thread = Thread.ofVirtual().name("example").unstarted(runnable);

次の例は、ループを使用して仮想スレッドを作成する方法を示しています。仮想スレッドはプールを必要としないため、スレッドプールは作成されません。同時実行性を制限する場合は、代わりにセマフォを使用できます。

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
	IntStream.range(0, 10000).forEach(i -> {
    	  executor.submit(() -> {
        	  Thread.sleep(Duration.ofSeconds(1));
        	  return i;
    	});
    });
}  // executor.close() is called implicitly, and waits

上記の例では、同時に実行される 10,000 個の仮想スレッドが作成されます。JDK は、少数のオペレーティングシステムスレッド、または 1 つのスレッドのみでコードを実行できるため、オーバーヘッドが削減されます。

詳細は、JEP 444: Virtual Threads を参照してください。

OpenJDK 16 では当初、Vector API がインキュベーション機能として導入されました。Red Hat build of OpenJDK 21 には、6 回目のインキュベーションに基づいて Vector API に機能拡張が複数含まれています。Vector API は、サポートされている CPU アーキテクチャー上で最適なベクトル命令に実行時に確実にコンパイルできる、幅広いベクトル計算を表現します。この API は、同等のスカラー計算よりも優れたパフォーマンスレベルを実現します。

最新の機能拡張により、すべてのアーキテクチャーで Vector API の信頼性と効率性を確保するだけでなく、予想されるネイティブ命令をすべてサポートしていないアーキテクチャーでは API の質の低下を適切に抑えることができます。Vector API の今後の機能拡張には、ベクタークラスをプリミティブクラスとして定義することで実現できる Project Valhalla との整合性も含まれる可能性があります。

詳細は、JEP 448: Vector API (Sixth Incubator) を参照してください。

Red Hat build of OpenJDK 21 には、java.lang.invoke メソッドハンドルの上に java.lang.reflect.Method、java.lang.reflect.Constructor、および java.lang.reflect.Field クラスの再実装が含まれています。このコアリフレクション機能の再実装により、java.lang.reflect および java.lang.invoke API の保守および開発コストが削減されます。

詳細は、JEP 416: Reimplement Core Reflection with Method Handles を参照してください。

Red Hat build of OpenJDK 21 には、Foreign Function and Memory (FFM) API が含まれています。この API は、Java プログラムが Java ランタイム外のコードとデータを相互運用できるようにするプレビュー機能です。FFM API は、JVM 外部の外部関数を効率的に呼び出し、JVM が管理しない外部メモリーに安全にアクセスできます。

FFM API は、既存の Java Native Interface (JNI) を pure Java 開発モデルに置き換え、ネイティブライブラリーを呼び出し、ネイティブデータを処理するためのより効率的で、クリーンかつ安全な方法を提供します。

FFM API は、ライブラリーおよびアプリケーション内のクライアントコードが次のタスクを実行できるようにするクラスとインターフェイスを定義します。

FFM API は、java.base モジュールの java.lang.foreign パッケージにあります。

詳細は、JEP 442: Foreign Function & Memory API (Third Preview) を参照してください。

Red Hat build of OpenJDK 21 では、レコードパターンが導入されています。これは、レコード値を分解するために Java プログラミング言語を強化するプレビュー機能です。この機能により、instanceof Operator を使用する変数の宣言と割り当てが可能になります。

属性 x と y を持つ Point という名前のレコードの次の宣言を考えてみましょう。

record Point(int x, int y) {}

前述の宣言に基づいて、次のコードは値が Point のインスタンスであるかどうかをテストし、値から x および y コンポーネントを直接抽出することもできます。

if (obj instanceof Point(int x, int y)) {
    	System.out.println(x+y);
}

この機能は、他のレコード内にネストされたレコードでも使用できます。たとえば、属性が Point レコードと Color 列挙型の ColoredPoint レコードの属性を持つ、Rectangle という名前のレコードに対する以下の宣言を考えてみます。

record Point(int x, int y) {}
enum Color { RED, GREEN, BLUE }
record ColoredPoint(Point p, Color c) {}
record Rectangle(ColoredPoint upperLeft, ColoredPoint lowerRight) {}

前述の宣言に基づいて、次のコードは値が Rectangle のインスタンスであるかどうかをテストし、左上の点から色を抽出できます。

if (r instanceof Rectangle(ColoredPoint ul, ColoredPoint lr)) {
     	System.out.println(ul.attribute());
}

詳細は、JEP 440: Record Patterns を参照してください。

Red Hat build of OpenJDK 21 では、無名パターンと変数が導入されています。これは、Java プログラミング言語を強化するプレビュー機能です。

無名パターンと無名変数は、アンダースコア (_) 文字を使用して表すことができます。変数が関連がなく、使用されない場合は、変数に名前を付ける必要はありません。このような状況では、アンダースコア文字を使用して、変数は存在するが使用されていないことを指定できます。

次の lambda 式の例では、パラメーターは関係がないため、JVM はこのパラメーターの変数を作成する必要がありません。

...stream.collect(Collectors.toMap(String::toUpperCase, _ -> "NODATA"))

次の switch ステートメントの例では、変数は 大文字と小文字 が一致する必要がありますが、これらの変数は使用されません。

switch (b) {
	case Box(RedBall _), Box(BlueBall _) -> processBox(b);
	case Box(GreenBall _)            	-> stopProcessing();
	case Box(_)                      	-> pickAnotherBox();
}

前の例では、最初の 2 つのケースでは、右側で Box レコードのコンポーネントが使用されないため、無名パターン変数が使用されています。3 番目のケースは新しいもので、無名パターンを使用して、Box レコードを null コンポーネントと一致させます。

詳細は、JEP 443: Unnamed Patterns and Variables (Preview) を参照してください。

Red Hat build of OpenJDK 21 では、Java プログラミング言語を強化するプレビュー機能である文字列テンプレートが導入されています。文字列テンプレートは、リテラルテキストを埋め込み式およびテンプレートプロセッサーと結合して特殊な結果を生成することにより、Java の既存の文字列リテラルとテキストブロックを補完します。

文字列テンプレート機能には、検証と変換をサポートするテンプレートプロセッサーである STR ユーティリティーが含まれており、文字列を設定する Java プログラムのセキュリティーの向上に役立ちます。STR ユーティリティーはコードの読みやすさも向上させます。他の変数、属性、または関数を使用して文字列を作成できます。

たとえば、次のテンプレート式を考えてみましょう。

STR."\{username} access at \{req.date} from \{getLocation()}"

上記の式は、次のサンプル文字列を生成します。

“Guest access at 12/1/2024 from 127.0.0.1”

プレビュー機能は Java 言語への実験的な追加機能であり、今後のバージョンで改善される可能性がありますが、下位互換性は保証されません。

詳細は、JEP 430: String Templates (Preview) を参照してください。

Red Hat build of OpenJDK 21 では、無名クラスとインスタンスの main() メソッドが導入されています。これは、教育目的で Java プログラミング言語を強化するプレビュー機能です。

無名クラスとインスタンス main() メソッドを使用すると、大規模で複雑なプログラムの Java 言語機能を理解していなくても、簡潔な方法で基本的な Java プログラムを書き始めることができます。Java の別の方言を使用するのではなく、単一クラスプログラムの合理化された宣言を記述し、Java の知識が増えるにつれて、より高度な機能を使用するようにプログラムをシームレスに変更できます。

ソースコードを簡素化し、学生が自分のコードに集中できるようにするために、Java では、学生が次の基準を満たすインスタンス main() メソッドを起動できます。

以下に例を示します。

class HelloWorld {
	void main() {
    		System.out.println("Hello, World!");
	}
}

学生がオブジェクト指向の概念を学習する前にコードの作成を開始できるように、Red Hat build of OpenJDK 21 では、クラス宣言を暗黙的にする無名クラスも導入されています。以下に例を示します。

void main() {
	System.out.println("Hello, World!");
}

この機能をテストするには、プレビュー機能を有効にしてください。以下に例を示します。

詳細は、JEP 445: Unnamed Classes and Instance Main Methods (Preview) を参照してください。

Red Hat build of OpenJDK 21 では、スコープ値が導入されています。これは、scoped value 変数をサポートする API を提供するプレビュー機能です。通常、scoped value 変数は、多くのメソッドからアクセスできる最終的な静的フィールドとして宣言されます。

scoped value は、メソッドパラメーターを使用せずにメソッド間で変数を共有する安全で効率的な方法を提供します。scoped value は、メソッド自体でパラメーターを宣言しなくてもメソッドが使用できる暗黙的なメソッドパラメーターに相当します。scoped value オブジェクトにアクセスできるメソッドのみがそのデータにアクセスできます。scoped value を使用すると、アプリケーションは、このデータのパラメーターを宣言せず、そのデータにアクセスできない他の中間メソッドを介して、呼び出し元から呼び出し先にデータを安全に渡すことができます。scoped value は、特に多数の仮想スレッドを使用する場合に、thread-local 変数の代わりとして推奨されます。

呼び出し先メソッド (bar) がネストされたバインディング内にある同じ scoped value を使用して、別の呼び出し先メソッド (baz) に異なる値を送信できる次のコード例を見てみましょう。

private static final ScopedValue<String> X = ScopedValue.newInstance();

void main() {
	ScopedValue.where(X, "hello").run(() -> bar());
}

void bar() {
	System.out.println(X.get()); // prints hello
	ScopedValue.where(X, "goodbye").run(() -> baz());
	System.out.println(X.get()); // prints hello
}

void baz() {
	System.out.println(X.get()); // prints goodbye
}

前の例では、main() メソッドは scoped value X を hello に設定し、この値を bar() メソッドに送信します。bar() メソッドは hello (X の値) を出力し、ネストされたバインディングを使用して X の値を変更し、変更された値を baz() メソッドに送信します。baz() メソッドが戻ると、bar() メソッドの残りの部分には、X の元の hello 値が残ります。

詳細は、JEP 446: Scoped Values (Preview) を参照してください。

Red Hat build of OpenJDK 21 では、構造化並列性が導入されています。これは、異なるスレッドで実行されている関連タスクのグループを 1 つの作業単位として扱うために API を提供するプレビュー機能です。この API は並行プログラミングを簡素化し、エラー処理と取り消しを効率化し、読みやすさを向上させ、監視性を強化します。

構造化並列性パラダイムでは、タスク (つまり、スレッド) をサブタスクに分割でき、サブタスクをさらにサブタスクにネストすることもできます。このタイプのタスク階層により、取り消しの伝播 (つまり、タスクを取り消すと、そのサブタスクも自動的に取り消される) と、タスク間の相互作用をより適切に制御できるようになります。

以下に例を示します。

Response handle() throws ExecutionException, InterruptedException {
	try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    	Supplier<String>  user  = scope.fork(() -> findUser());
    	Supplier<Integer> order = scope.fork(() -> fetchOrder());

    	scope.join()        	// Join both subtasks
         	.throwIfFailed();  // ... and propagate errors

    	// Here, both subtasks have succeeded, so compose their results
    	return new Response(user.get(), order.get());
	}
}

上記の例では、最初にスコープを作成し、次にこのスコープをフォークしてサブタスクを作成します。いつでも、元のスレッドまたはいずれかのサブタスクからスコープのシャットダウンを要求して、未完了のタスクをすべてキャンセルし、新しいサブタスクが作成されないようにすることができます。scope.join() メソッドは、スコープがすべてのサブタスクの実行が完了するまで待機させます。.get() メソッドは各サブタスクの結果を返します。

各サブタスクは、独自の StructuredTaskScope を作成して、ワークロードをさらにサブタスクに分割することもできます。この場合、追加のサブタスクは、全体の階層内で親サブタスクの下にネストされます。

詳細は、JEP 453: Structured Concurrency (Preview) を参照してください。