2022/12/20

JEP 437: Structured Concurrency

このエントリーをはてなブックマークに追加

このエントリーは Java Advent Calendar の20日目のエントリーです。

qiita.com

 

Java 19のJEP 425: Virtual Threadsの裏で、ひっそりと登場していたのが、JEP 428 Structured Concurrency です。Virtual ThreadはPreview JEPでしたが、Structured ConcurrencyはIncubator JEPです。

そして、Java 20では、Virtual ThreadsはSecond Previewとして JEP 436 になっています。同じようにStructured ConcurrencyもSecond Incubatorとして JEP 437 になりました。

JEP 428とJEP 437の違いはほとんどないので、このままいけば次のLTSであるJava 21で正式に導入されると思います。

 

動機

Structured Concurrencyは名前にConcurrencyとついていることから分かるように、並列/並行処理に関するAPIです。構造化した並列とはどういうことなのでしょう。

それを考えるために、ちょっとしたサンプルで考えてみます。

最近は、複数の外部のサービスを組み合わせて使うシステムが多くありますね。外部にあるということは、何らかのI/Oが発生して待ちがあるということです。

たとえば、HTTPで通信するWebサービスを2つ使用し、クエリ結果を組み合わせるようなサンプルを考えてみます。

HTTP通信が発生するので、逐次的に処理をしてしまうととても時間がかかってしまいます。そこで、クエリを非同期に行います。

すごい単純ですが、こんな感じ。

    String query(final String queryText) throws InterruptedException, IOException {
        var client = HttpClient.newHttpClient();
        var request = HttpRequest.newBuilder()
                .uri(URI.create(queryText))
                .build();
        var response = client.send(request, BodyHandlers.ofString());

        var status = response.statusCode();
        if (status / 100 != 2) {
            throw new IOException("HTTP Error: " + status);
        }

        return response.body();
    }

    record Result(String result1, String result2) {}

    Response complexQuery(final String queryText1, final String queryText2)
            throws InterruptedException, ExecutionException {

        try (var pool = Executors.newFixedThreadPool(2)) {
            Future<String> future1 = pool.submit(() -> query(queryText1));
            Future<String> future2 = pool.submit(() -> query(queryText2));

            String result1 = future1.get();
            String result2 = future2.get();

            return new Result(result1, result2);
        }
    }

TwoTaskクラスではHTTPのGETでクエリーを行いますが、それぞれを非同期に行っています。クエリーのURLが引数のqueryText1とqueryText2です。

これを実行すると、特に問題がなければ普通に動くはずです。

しかし、このコードには複数の問題があります。

  1. 1番目のクエリーで例外が発生した場合、complexQueryメソッドを抜けてしまうが、2番目のクエリーは実行したままになってしまう
  2. complexQueryメソッド実行中に割り込み(Thread.interrupt()メソッドがコール)されるとメソッドを抜けるが、クエリーは実行したままになってしまう
  3. 1番目のクエリーを実行中に、2番目のクエリーで例外が発生しても、1番目のクエリーが完了しない限り(future1.get()が戻らない限り)、2番目のクエリーの例外を扱うことができない

正常に動作していればいいのですが、例外や割り込みが発生した時に、それらが正しくサブタスクに伝播されないことに問題があります。

もちろん、割り込みが発生したらサブタスクにも割り込みしたり、あるサブタスクで例外が発生したら他のサブタスクをキャンセルするという処理を書くこともできます。とはいうものの、こういうボイラープレート的な記述が増えてくるのは避けたいところです。

そこで、サブタスクを構造的に扱い、例外や割り込みなどを容易に扱えるようにしたのが、JEP 437 Structured Concurrencyなのです。

 

Structured Concurrency

Structured Concurrencyで提供されるメインのクラスはStructuredTaskScopeクラスです。

JEP 437はIncubator APIなので、今のところパッケージはjdk.incubator.concurrentですが、正式なAPIになった時にはパッケージは変更になります。たぶん、java.util.concurrentに含まれると思いますが、あくまでも予想です。

StructuredTaskScopeクラスは、名前の通りスコープです。そのスコープの中で作られたサブタスクを構造化するという使い方をします。

たとえば、先ほどのサンプルのcomplexQueryメソッドをStructuredTaskScopeクラスで書き直したものが以下になります。

    Result complexQuery(final String queryText1, final String queryText2)
            throws InterruptedException, ExecutionException {

        try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
            Future<String> future1 = scope.fork(() -> query(queryText1));
            Future<String> future2 = scope.fork(() -> query(queryText2));

	    scope.join();
	    scope.throwIfFailed();

            String result1 = future1.resultNow();
            String result2 = future2.resultNow();

            return new Result(result1, result2);
        }
    }

ここでは、StructuredTaskScopeクラスのサブクラスで内部クラスのShutdownOnFailureクラスを使用しています。

try-with-resources構文で記述されたブロックがStructuredTaskScopeクラスのスコープになるわけです。

このスコープの内部でサブタスクをforkし、サブタスクの完了を待つためにjoinしています。

その次のthrowIfFailedメソッドはShutdownOnFailureクラスのメソッドで、サブタスクで例外が発生した場合、他のサブクラスに伝播させタスクをキャンセルさせます。

ShutdownOnFailureというのはサブタスクで例外が発生した時に、サブタスクをキャンセルし、スコープをシャットダウンするためのクラスになります。

その後、サブタスクの結果を取得するために、getメソッドではなくresultNowメソッドを使用しています。Future.resultNowメソッドも新たに定義されたメソッドです。タスクが完了していれば結果を返し、キャンセルされた場合はキャンセルされた時点での結果を返します(結果がないこともあります)。

StructureTaskScopeクラスはVirtual Threadでの使用が前提になっており、デフォルトでVirtual Threadを使うようになっています。

なお、ここではforkしているのは2つのタスクだけですが、さらに多くのタスクをforkすることも可能です。

 

ところで、forkしてjoinするというAPIは他にもありましたね。

そう、Fork/Join Frameworkです。

前回のエントリーでも書きましたが、Fork/Join Frameworkは計算処理などI/O処理を含まないタスクがターゲットでした。一方で、Structured ConcurrencyはVirtual Threadを使うことからも分かるように、I/O処理を含むタスクにフォーカスしています。

この2つのAPIは用途に応じて使い分けるようにしましょう。

 

さて、このサンプルをコンパイルし、実行してみましょう。

Structured ConcurrencyはIncubator JEPなので、使用するにはオプションとして--enable-previewが必要です。コンパイル時に--enable-previewを使用するには--releaseも必要なので、こちらも指定します。

また、Incubatorのため、jdk.incubator.concurrentモジュールがデフォルトでは読み込まれません。そのために--add-modulesでモジュールを指定する必要があります。

このサンプルがTwoTaskクラスだったとした場合、次のようにコンパイル、実行を行います。

> javac --release 20 --enable-preview --add-modules jdk.incubator.concurrent TwoTask.java
警告:実験的なモジュールを使用しています: jdk.incubator.concurrent
警告1個

> java --enable-preview --add-modules jdk.incubator.concurrent TwoTask

せっかくなので、例外も出してみましょう。一方のクエリーだけ失敗するようなURLを使って実行してみると、単にExecutorServiceを使っていた場合、java.util.concurrent.ExecutionException例外がスローされるのに時間がかかります。

ところが、StructuredTaskScopeクラスを使った場合、すぐに例外がスローされます。これが例外が発生させた時に、他のサブタスクをキャンセルさせて、スコープをシャットダウンさせているためです。

 

ところで、StructuredTaskScopeクラスには、もう1つサブクラス兼内部クラスのStructuredTaskScope.ShutdownOnSuccessクラスがあります。

先ほどのShutdownOnFailureクラスは例外が出た場合はシャットダウンします。逆にいうと、例外が出ない場合は複数のサブタスクがすべて完了するまでjoinメソッドはブロックします。

これに対し、ShutdownOnSuccessクラスはサブタスクのうち、どれか1つが完了すれば、他のサブタスクはキャンセルして、シャットダウンします。

ShutdownOnFailureクラスはサブタスクのANDであるのに対し、ShutdownOnSuccessクラスはORになるとも言えますね。

たとえば、先ほどのcomplexQueryメソッドを早く完了したタスクの結果を返すように書きかえてみましょう。

    String complexQuery(final String queryText1, final String queryText2)
            throws InterruptedException, ExecutionException {

        try (var scope = new StructuredTaskScope.ShutdownOnSuccess<String>()) {
            Future<String> future1 = scope.fork(() -> query(queryText1));
            Future<String> future2 = scope.fork(() -> query(queryText2));

            scope.join();
            return scope.result();
        }
    }

ShutdownOnFailureクラスと異なり、ShutdownOnSuccessクラスはサブタスクの結果を扱うため、ジェネリクスでサブタスクの戻り値の型を指定します。

最も早く完了したサブタスクの処理結果を取得するのがresultメソッドです。

他はShutdownOnFailureクラスと同じです。

 

Structured Concurrencyでは他に、サブタスク間で共有できる値を扱うScopedValueクラスがあるのですが、これはまた別の機会に紹介します。

2022/12/09

Virtual Thread導入の背景 - Javaのマルチスレッドの歴史を振り返る

このエントリーをはてなブックマークに追加

このエントリーは Java Advent Calendar の9日目のエントリーです。

qiita.com

 

Virtual ThraedはJava 19でPreview (JEP 425)、Java 20でSecond Preview (JEP 436)となり、うまくいけば次のLTSであるJava 21で導入予定です。

パフォーマンスを考える時に、一般的にはスループットと応答性の2つがあります。スループットは単位時間あたりにどのくらいリクエストをさばけるか、応答性は処理のリクエストから結果が帰るまでの時間です。Virtual Threadのこの2者のうち、スループットを向上させるために導入されます。

では、なぜ今になってVirtual Threadが導入されるのかということを、歴史を振り返りながら考えてみるのがこのエントリーです。

 

いにしえの時代 - Java 1.0からJ2SE 1.4

Javaが発表されたのが1995年。その当時の代表的なCPUといえばIntel Pentiumです。Pentiumのリリースが1993年、Pentium Proが1995年、Pentium IIが1997年です。

つまり、その当時のPCはほとんどがシングルCPU、もちろんシングルコアです。

そんな時代にあって、Javaはマルチスレッドを標準の言語機能としたことは驚きです。当然ながら、その当時はコアは1つなのでパラレル処理ではなく、コンカレント処理になります。

 

Javaのスレッドは、OSのスレッドに対応します(初期のSolarisはちょっと違いましたが、J2SE 1.2でOSのスレッドを使うようになりました)。Javaのスレッドが複数あったとしても、CPUは1つなのでOSのスレッドは1つです。したがって、Javaのスレッドをすべて実行するにはスレッド切り替えが必要です。このスレッドの切り替えのことをコンテキストスイッチと呼びます。

このコンテキストスイッチは比較的重い処理なので、頻繁に行うと性能劣化の原因になります。

とはいうものの、複数のスレッドを実行するには何らかの実行スケジューリングが必要になります。スレッドのスケジューリングにはラウンドロビンやタイムシェアリングなどがあります。

Javaのそれは単純で、どのようにスレッドが実行されるかはJVMSには明記されていません。スレッドに優先度も設定できますが、優先度が高いからといって優先的に実行されるとは限りません。

また、やっかいだったのが、タスクを記述するためのRunnableインタフェースは返り値を返せないところです。そのため、処理の結果は複数のスレッドでアクセスできるように同期化したオブジェクトを用意する必要がありました。

同期化のために使用できたのがsynchronizedブロック(もしくはsynchronizedメソッド)です。

synchronizedブロックはモニタというロックを使用して同期化を行います。synchronizedメソッドの場合、ロックするオブジェクトは指定しませんが、thisがロック対象になります。

たとえば、スレッド間のやりとりによく使用されるブロッキングキューを作成してみましょう。

ブロッキングキューはキューがいっぱいの時に要素を追加しようとすると、要素が追加できるまで処理をブロックします。同様に要素を取り出そうとした時に要素がなければ、要素が追加されるまで処理をブロックするキューです。

Javaが標準で提供しているブロッキングキューのArrayBlockingQueueクラスなどはかなり複雑なので、ここではキューのサイズが1つのシンプルなブロッキングキューを作ってみます。

キューがいっぱいの時や、空の時に待ち状態にするにはwaitメソッドを使用します。そして、Object.wait状態にあるスレッドを起こすには、Object.notifyAllメソッドを使用します。notifyメソッドもあるのですが、notifyメソッドだと1つの目的のスレッドを起こせるとは限らないので、通常はすべてのスレッドを起こすnotifyAllメソッドを使用します。

public class SingleBlockingQueue<T> {
    private T x;

    public synchronized void push(T x) throws InterruptedException {
        while (this.x != null) {
            System.out.println("Wait - push: " + x);
            wait();
            System.out.println("Wake up - push");
        }

        System.out.println("NotifyAll - push: " + x);
        this.x = x;
        notifyAll();
    }

    public synchronized T pull() throws InterruptedException {
        while (this.x == null) {
            System.out.println("Wait - pull");
            wait();
            System.out.println("Wake up - pull");
        }

        T result = x;
        x = null;
        System.out.println("NotifyAll - pull: " + result);
        notifyAll();

        return result;
    }
}

notifyAllメソッドで起こされるのはすべてのスレッドなので、本当に起こされるべきスレッドではないこともあります。そこで、while文でチェックを毎回行っているわけです。

では、このSingleBlockingQueueクラスを使ってみましょう。

public class QueueTest {
    static SingleBlockingQueue<String> queue = new SingleBlockingQueue<>();

    public static void main(String[] args) throws Exception {
        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    queue.push("A");
                    queue.push("B");
                    queue.push("C");
                } catch (InterruptedException ex) {
                    Thread.currentThread().interrupt();
                }
            }
        }).start();
        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    queue.pull();
                    queue.pull();
                    queue.pull();
                } catch (InterruptedException ex) {
                    Thread.currentThread().interrupt();
                }
            }
        }).start();
    }
}

これを実行すると次のようになります。

> java QueueTest
NotifyAll - push: A
Wait - push: B
NotifyAll - pull: A
Wait - pull
Wake up - push
NotifyAll - push: B
Wait - push: C
Wake up - pull
NotifyAll - pull: B
Wait - pull
Wake up - push
NotifyAll - push: C
Wake up - pull
NotifyAll - pull: C

Aをpushした後、Bをpushしようとしますが、すでに要素がキューにあるのでwaitします。すると、別スレッドがAをpullし、notifyAllメソッドをコールします。

キューに要素がなくなったので、waitしていたスレッドがnotifyAllで起き、Bをpushします。

といような流れで処理が進みます。

このように、synchronizedを使用するとアクセスできるスレッドを制限することができます。しかし、あるスレッドがsynchronizedブロックを実行している間、他のスレッドは処理待ち状態になってしまいます。

この当時は、想定しているスレッド数はたかがしれていました。しかし、同時に動作できるスレッド数が増えてくると、synchronizedブロックがボトルネックになってしまいます。

 

Java SE 1.0から1.4までの時代をまとめると

  • スレッドを実行するには、OSのスレッドとの対応付けが必要
  • スレッドの実行スケジューリングはシンプルなものしかなかった
  • 必要に応じて、明示的に他のスレッドに処理を移す処理を記述する
  • タスクはRunnableインタフェースで記述するため、処理の結果を直接返すことはできない
  • 複数のスレッドからアクセスするにはsynchronizedが必要

 

マルチコア黎明期 - Java 5, Java 6

Java 5がリリースされたのは2004年、Java 6は2006年。このころ、ちょうどAMDやIntelがマルチコアのCPUをリリースし始めたころです。

AMDがAthlon64 X2で先行し、Intelが1つのパッケージに2つのダイをのせたPentium Dをリリースし、その後にちゃんとしたマルチコアのCore 2をリリースしたなんてこともありました。また、Intelはハイパースレッディングで1つのコアで2つのスレッドを処理できるようになっています。

それに合わせたわけではないと思いますが、Java 5ではご存じの通りConcurrency Utilities (java.util.concurrentパッケージ)が導入され、マルチスレッドに関するAPIが大幅に拡充されました。

主なAPIをあげてみましょう

  • スレッドプール
  • 非同期処理を結果を返すCallableとFuture
  • 多様なロックのAPI
  • スレッドセーフなコレクション
  • プリミティブ型に対するアトミック処理

スレッドプールであるExecutorServiceインタフェースが導入されたことで、スレッドとタスクが切り離され、スレッドを直接生成する必要はなくなりました。

Executorsクラスが作成するスレッドプールはJava 5では4種類ありましたが、一般的には以下の2つのメソッドで作成するスレッドプールを使用します。

  • newFixedThreadPoolメソッド
  • newCachedThreadPoolメソッド

newFixedThreadPoolメソッドで作成するスレッドプールはメソッド名の通り、指定した数しかスレッドを作成しません。通常はマシンのトータルのCPUのコア数よりも少ないスレッド数を指定します。トータルのコア数を超えるスレッドを作成してしまうとコンテキストスイッチが発生してしまいます。

スレッドに割り当てられないタスクはキューで管理されます。タスクがスレッドに割り当てられれば、コンテキストスイッチが発生しないので応答性を高めることができます。

 

一方のnewChachedThreadPoolメソッドではタスクが登録された時にスレッドが余っていれば新たにスレッドを作成することはありません。しかし、余っているスレッドがない場合はスレッドを作成して、タスクに割り当てます。

このスレッドプールはWebアプリケーションなどでリクエストごとにスレッドを作成するThread per Request方式で使われることが多くあります。Thread per Requestはスループットを向上させることが可能です。しかし、応答性は低下します。また、リクエストごとにThreadオブジェクトを生成してしまうので、ヒープの消費も大きくなります。

 

ExecutorServiceインタフェースで扱えるタスクには、Runnableインタフェースに加え、Callableインタフェースが導入されました。Callableインタフェースを使うと非同期処理の結果を返せるようになります。これに伴い、非同期処理の結果を取得するためのFutureインタフェースが導入されています。

こんな感じで使います。

    ExecutorService pool = Executors.newFixedThreadPool(4);

    Future<String> future = pool.submit(new Callable<>() {
        @Override
        public String call() throws Exception {
            String result = // 何らかの処理
            return result;
        }            
    });

    String result = future.get();

    pool.shutdown();

結果が返せるということは、複数のスレッドで結果をやりとりするためにだけ使っていたsynchronizedブロック(もしくはsynchronizedメソッド)を使用しなくてもいいということです。synchronizedが減らせれば、マルチスレッドのボトルネックを減らすことができます。

ただし、Future.getメソッドは、非同期処理が完了して値が戻るまでブロックしてしまいます。この点は気を付ける必要があります。

 

さらに、セマフォなどのロックのAPIが導入されています。

特にReentrantLockクラスはsynchronizedと同様の動作をするので、synchrnozedを減らすことができます。ReentrantLockクラスは実行時に必要のないロックはロックを外すなどの最適化が行われるため、synchnorzedよりも効果的です。

 

他のスレッドセーフなコレクションやアトミック処理APIはスレッド数が少ない場合は有効に使えるのですが、多くのスレッドが同時にアクセスするような場合はボトルネックになりがちです。この当時はまだ同時に扱えるスレッドが少なかったので、よかったのですが、コア数が増えて同時に動作するスレッドが増えれば増えるほど、使い方を考えなくてはいけません。というか、多くのスレッドが同時にアクセスするような場合は、なるべく使わない方が賢明です。

 

さて、Java SE 5, 6時代をまとめると。

  • スレッドプールは応答性重視とスループット重視の2種類
  • Callable/Futureの導入で非同期処理の結果を返せる
  • 非同期処理の結果の受け渡しのためにだけ使用していたsynchronizedは減らせる
  • synchronizedではなく、ロックAPIを使用することでロックの最適化が可能

 

マルチコア実用期 - Java SE 7

Java 6がリリースされた後、ラムダ式導入でもめたり、Sun MircrosystemsがOracleに買収されたりなどあって、Java 7のリリースは大幅に遅れ、2011年にやっとリリースされました。結局、ラムダ式はJava 8に延期されたのはご存じのとおりです。

この当時、インテルは2010年に6コアのCPUをリリース、一方のAMDは2011年に8コアのCPUをリリースしています。ノートPCでもマルチコアが当たり前になってきたのもこの頃ですね。

 

さて、ラムダ式がJava 8にスリップしたということで、Java 7ではあまり大きな変化はないように思えますが、マルチスレッドに関しては大きな変化がありました。それがFork/Join Frameworkの導入です。

Fork/Join Frameworkは主に計算処理や再帰処理の効率化を行うために導入されました。たとえば、ソートや行列計算などです。

たとえば、Java SE 6まで標準APIで使われていたマージソートを考えてみましょう。

マージソートはソートを行う範囲を半分に分割していき、ソートする範囲を小さくしていきます。小さい範囲でまずソートを行い、それを組み合わせて徐々に大きい範囲のソートを行うアルゴリズムです。

このような処理の方法を分割統治法と呼びます。

現在のJavaの標準APIのソートはティムソートに変更されていますが、ティムソートも分割統治法を用いたソートアルゴリズムです。

分割統治法で分割したタスクを非同期に実行するようにすれば、マルチスレッドで処理することができます。しかし、Java 6までのスレッドプールはタスクスケジューリングが単純で、多くのタスクを非同期に実行させなければならない分割統治法では有効にスレッドを活用することができません。

そこで、Fork/Join Frameworkでは、Work Stealingを採用したタスクスケジューリングが導入されました。

それまではタスクを1つのキューで管理していましたが、Work Stealingではスレッドごとにタスクキューを持ちます。このキューはFIFOではなく、両端キューで構成されます。

スレッドが自身のタスクキューからタスクを取り出す場合は、キューの先頭から取り出します。

もし、あるスレッドのタスクキューが空になった場合、そのスレッドは他のスレッドのタスクキューからタスクを取り出す(他のスレッドから取り出すのでSteal、つまり盗むということです)ことができます。この時、タスクキューの先頭から取り出すのではなく、キューの最後から取り出します。

分割統治法では大きい粒度のタスクの処理中に分割したタスクを再びキューに登録していきます。このことは、タスクキューの先頭に近いほどタスクが大きく、最後になればなるほどタスクが小さくなることを示しています。

このため、他のスレッドが盗んでいくタスクは小さい粒度で短時間で処理ができるはずです。このようにすることで、複数のスレッドで効率よく分割したタスクを処理していくことができます。

Work Stealing方式のスレッドプールは、Java 8で導入されるパラレルストリームでも使用されます。

 

Fork/Join Frameworkは計算処理の効率化はできるものの、Webアプリケーションのような通信やDBへのアクセスがあるような用途には向いていません。しかし、Work Stealing方式のタスクスケジューリングを含むスレッドプールは、Fork/Join Framework以外の用途でも使われていくようになりました。

このスレッドプールはForkJoinPoolクラスで使用できます。デフォルトではトータルのCPUのコア数だけスレッドを生成します。このため、タスクスイッチは頻繁に行うものの、スレッドのコンテキストスイッチは抑えることができます。

また、Executors.newWorkStealingPoolメソッドでもForkJoinPoolオブジェクトを取得できます。ただし、このメソッドはJava 8以降で使用することができます。

 

マルチコア熟成期 - Java SE 8

Java SE 8は2014年にやっとリリースされました。Java 8で最も注目されたのがProject Lambda、つまりラムダ式とストリームです。マルチスレッド的にはパラレルストリームの導入もあります。

しかし、ここで取り上げるのはパラレルストリームではなく、CompletableFutureです。く

Java 7のFork/Join Frmeworkで計算処理は効率よく行うことが可能になりました。しかし、通信やDBアクセスなどのI/O処理を含むようなタスクには向いていません。

I/O処理は処理をブロックします。たとえば、Readerオブジェクトから読み込む処理はどうでしょう。

    try (BufferedReader reader = new BufferedReader(...)) {
        int c = reader.read();
    }

readメソッドは文字が読み込めるまでブロックします。Readerオブジェクトがソケットから生成されていれば、通信が届かない限り文字を読み込めません。その間、ブロックします。

I/O処理はCPUの計算時間に比べると多大な時間を使います。しかし、ブロックしてしまうと、その間CPUは遊んでしまうわけです。

そこで、I/O処理を非同期に行うことが考えられます。たとえば、こんな感じです。

    Future<String> future = pool.submit(() -> {
        // I/O読み込み処理

        return contents;
    });

    // 非同期処理の結果を受け取る
    String contents = future.get();

お分かりかと思いますが、これでは非同期処理の利点を生かすことができません。というのも、Future.getメソッドが非同期処理が完了するまでブロックしてしまうからです。

そこで、導入されたのがCompletableFutureクラスです。

非同期で行いたいような処理は1つだけということはあまりなく、複数の処理を連ねることが多いのではないでしょうか。

たとえば、Webアプリケーションであれば

  1. リクエストを受けて何らかのロジック処理を行う
  2. DBへのクエリを投げる
  3. クエリ結果からレスポンスを作成し、送信する

のような感じです。もちろん、こんな単純なことで済まないことも多いとは思いますが、こんな感じで処理が進むという例のつだと思ってください。

Thread per Requestでリクエストごとにスレッドを生成して、非同期に1, 2, 3の処理を行えばスループットは向上します。しかし、2のDB処理は完了するまでブロッキングしてしまいます。そのため、ブロッキングしている間、CPUは遊んでしまいます。

その間にも、リクエストがあればスレッドがどんどん増えるばかりで、あっという間にスループットは飽和してしまいます。そこで、DB処理も非同期にして... とやっていると先ほどのFuture.getメソッドのようにまたブロッキングを増やしてしまうかもしれません。

CompletableFutureクラスを使うと、このような一連の処理をラムダ式で記述し、メソッドチェーンで記述することができます。

たとえば、リクエストを受けるメソッドがhandleメソッドだとしてみましょう。引数の型はRequestクラスとResponseクラスだとします。

    void handle(final Request request, final Response response) {
        record Param<S>(S s, Response response) {}
        
        CompletableFuture
            .completedFuture(new Param(request, response))
            .thenApply(param -> {

                // 1. ロジック処理

                return new Param(logicResult, response);
            })
            .thenApplyAsync(param -> {

                // 2. 非同期でDBへのクエリ

                return new Param(queryResult, response);
            })
            .thenAccept(param -> {

                // 3. レスポンスの作成、送信

                param.response().response(responseContents);
            });
     }

ここではタプル的に2つのオブジェクトを扱うためにレコードクラスのParamクラスを作りましたが、これが必須というわけではないです。

そのParamオブジェクトを引数としてcompletedFutureメソッドでCompletableFuture生成しています。その後のメソッドチェーンで処理を連ねていきます。

thenが先頭につくメソッドは前段までの処理が完了した時に引数のラムダ式がコールバック的に呼ばれるメソッドです。ApplyやAcceptはラムダ式の引数や返り値によって異なります。

メソッド名の最後がAsyncのメソッドは、引数のラムダ式がさらに非同期に実行されることを示します。したがって、1.のロジック処理と2.のDBクエリが同じスレッドで実行されるわけではないことを示します。

このように、一連の処理を同期、非同期を交ぜながら記述できるのが、CompletableFutureクラスの特徴です。また、CompletableFutureクラスはデフォルトでForkJoinPoolを使用するので、スレッド数は抑えたまま、効率的に実行することができます。

 

このCompletableFutureクラスを使えば、Thread per Requestに比べるとスループットの飽和も抑えることができます。

しかし、残念ながら、いまだにCompletableFutureクラスはそれほど使われていません。

単にシーケンシャルに処理を記述していくのに比べると、CompletableFutureクラスで処理を記述するには考え方を変えなければいけません。処理のキャンセルや、例外の扱いなどが煩雑になるという点もあります。

さらに、CompletableFutureクラスのデバッグは難しいのです。

ストリームのデバッグをしたことがある方は分かると思うのですが、ラムダ式が含まれるとスタックトレースが読みにくくなります。

しかも、CompletableFutureクラスは処理を記述したラムダ式が同じスレッドで動作するわけでありません。スタックトレースのスタックは、スレッドが持つスタックのことです。スレッドが異なればスタックトレースは別ものになります。このため、CompletableFutureクラスにおいて、ラムダ式で記述した処理で例外が発生したとしてもスレッドが異なるため、スタックトレースも別々になり、一連の処理の流れはスタックトレースからは追うことができません。

このように、CompletableFutureクラスは使いこなすうえで難しい点があります。しかし、CompletableFutureクラスを使いこなせるのであれば、スループットの高いシステムを実現することができます。

これはSpring WebFluxのようなリアクティブ系のフレームワークでも同じです。使いこなせるのであれば、高いスループット性能が可能です。

そして、CompletableFutureクラスでも、リアクティブなフレームワークでも使いこなせるのであれば、Virtual Threadは使わなくても大丈夫なはずです。

 

ここまでのJavaでのマルチスレッドの流れをまとめてみると

  • Thread per Requestを使えば、スループットを上げることは可能だが、飽和するのも早い
  • 計算処理など処理をブロックする要因がない処理であればFork/Join Frameworkもしくはパラレルストリームで応答性を向上することができる
  • I/Oなど処理をブロックする要因がある場合はブロックする処理を非同期に処理する。そのためにCompletableFutureクラスやリアクティブ系のフレームワークが使用可能
  • しかし、CompletableFutureクラスやリアクティブ系のフレームワークは使いこなすのが難しく、デバッグもやりにくい

ここらへんを何とかしてくれるのがVirtual Threadです。

Concurrency Utilities以降のJavaでは、自分でスレッドを生成することはなくなっているはずです。Virtual Threadも自分で生成させることはないはずです。

フレームワークなどがVirtual Threadに対応すれば、コードを変更しなくても自動的にVirtual Threadを使えるようになっているはず。

Springが早々にVirtual Threadに対応することを発表しているように、意外にVirtual Threadを使えるようになる日も近いかもしれません。

 

おまけ

わざわざ、Java 1.0のころの古いスレッドん使い方を説明したのは、ここで説明したことはほとんどがVirtual Threadではバッドマナーになるからです。

Virtual Threadは、Virtualではないスレッドの上で動く仮想スレッドです。しかし、Java 1.0のころのsynchronizedやwait/notifyなどの操作は仮想スレッドではなく、仮想スレッドが動作しているスレッドに対して行われます。

スレッドがブロックしてしまったりすると、スレッドの上で動作する複数のVirtual Threadすべてが影響を受けてしまいます。

ThreadクラスのいくつかのAPIは@deprecatedになり、使うことが非推奨になっています。

 

Threadクラスの非推奨(@deprecated)のAPI

  • checkAccess
  • countStackFrames
  • getId
  • resume
  • stop
  • suspend

これらのメソッドはいつ削除されても不思議はありません。

ちなみに、Java 8では使えていたdestroyメソッドとstop(Throwable)メソッドはすでに削除されています。

また、synchronizedブロック(メソッド)はロックAPIで書きかえられます。wait/notifyを使う場面はほとんどないとは思いますが、なるべくタスクは独立に処理できるようにし、これらを使わないような設計を考えていく必要があります。

2022/11/15

JavaOne 2022に行ってきました

このエントリーをはてなブックマークに追加
_DSC7423
10月18日から3日間にわたって開催されたJavaOne 2022に参加してきました。
今年は久しぶりにJavaOneという名前が復活し、ラスベガスでの初めての開催ということになりました。

技術的なことはさておき、初のラスベガス開催ということで、来年参加する人たちの参考になればということで備忘録を書いておきます。

現地まで

残念ながら日本からラスベガスまでの直行便はありません。日本からだと以下の3つが主な乗り継ぎ空港ですね。
  • ロスアンゼルス
  • サンフランシスコ
  • シアトル
今回は知り合いの日本人参加者ではロス乗り継ぎが多かったです。私はサンフランシスコで乗り継ぎました。

飛行機代を抑えたいのであれば、LCCのZipairがロスアンゼルスやサンノゼまで飛んでいるので、それを利用するというのもありかもしれません。

アメリカ入国

どの空港で乗り継いだとしても入国審査は乗り継ぎの空港、私の場合はサンフランシスコ空港で行います。

アメリカに入国するにはESTAが必要です。ESTAは2年間有効で、ESTAを申請したはじめての時は有人の入国審査になりますが、その後は自動入国審査端末での審査になります。

今年はコロナになってから久々のアメリカだったので、ESTA申請し、審査官による入国審査でした。アメリカの入国審査官ってなんであんなにいろいろ聞いてくるんでしょうね😰

そして、来年はどうなるか分からないですが、今年はコロナに関する宣誓書を書いておく必要がありました。また、コロナワクチンの接種証明はいつでも見せられるようにしておきました。実際には見せる機会はありませんでしたが、念のため。

接種証明はマイナンバーカードを持っている人であれば、スマホの接種証明書アプリが便利です。マイナンバーカードを持っていない場合は、役所で英語表記の接種証明書を入手します。

ラスベガスまで

入国した空港から、ラスベガスのハリーリード国際空港(以前はマッカラン国際空港でしたが去年名称が変わりました)までは国内線で乗り継ぎます。

ハリーリード空港はターミナル1と3があります。私はUnited Airlinesだったのでターミナル3でした。

ハリーリード空港はいたるところにスロットマシンが置いてあって、さすがカジノの街という感じです。

ターミナル3はゲートがある建物と荷物カウンター(Baggage Claim)がある建物が別々になっていて、トラムで結ばれています。ただ、トラムが荷物カウンターに向かうものと、ターミナル1に向かうものの2種類あるので間違わないようにしないといけません。

大きい階段があって、Welcome to Las Vegasと書いてある看板?を下っていった先にあるのが、荷物カウンター行きのトラムです。

荷物を受け取ったら街に向かいましょう。
_DSC0834

ホテルまで

ハリーリード空港は市街地まではUberやLyftなどのライドシェア、タクシー、バスなどの選択肢があります。

タクシーの場合、空港から市街地は定額で$27だそうです。これに空港使用料とチップが加わります。

ライドシェアは混雑する時間帯はタクシーとあまり変わらない値段ですが、混雑していない場合はチップも含めても$20ぐらいです。

ライドシェアはどこでも呼べるわけではなく、空港内の決められた場所でしか乗車できないようになっています。

ターミナル3の場合、乗車できるのはパーキングの建物の中にあります。

荷物カウンターの階(Level 0)から1つあがって、49番の出口を出るとパーキングに向かう橋があります。パーキングについたら、1つ下の階(Level V)にライドシェアの乗車場があります。

乗車場についたらUberやLyftのアプリを使って、行き先と車の種類を指定して、配車できます。

ホテル

ラスベガスは南北に走るストリップを中心に街が構成されています。ストリップでも中心に なるのがフォーコーナー (Four Corners)と呼ばれる交差点です。

おおざっぱにいうとフォーコーナーに近い方がホテルの宿泊費が高く、離れると安くなる傾向があります。特に東西方向はストリップからちょっと離れるだけで急に安くなるようです。

JavaOneの会場はフォーコーナーにほど近いシーザースフォーラムというところです。そこのため、ホテルを選ぶには2つの選択肢があると思います。
  • 会場に近くて便利だが、宿泊費は高いホテル
  • 会場から遠いが、宿泊費は安いホテル
宿泊費は高いといっても、今までのサンフランシスコに比べればかなり安いです。

私は今回、会場に近いフラミンゴ(Flamingo)に宿泊しました。フラミンゴは古いホテルなので設備とかはかなりイマイチな感じ。古いホテルのためか、フォーコーナー近くのホテルの中では比較的安いです。

会場に近いので、ノベルティもらって荷物が多くなった時など、部屋に戻って荷物を置いてくるなんてことができるのは便利です。

フラミンゴやベネチアン(The Venetian)などは、JavaOne登録と一緒にホテルの予約もできるので、それを利用するというのも1つの手です。カンファレンスレートで、通常よりは少しだけ安くなっているはずです。

気候

ラスベガスは砂漠の中にあります。10月でしたが、最高気温は30度ぐらい。最低気温が15度ぐらいで、朝晩は過ごしやすいです。乾燥しているので、昼でも直射日光に当たらなければ、意外に過ごしやすかったです。

気になるのが会場の冷房だったのですが、意外にもそんなに冷えてはいませんでした。それでも、1枚羽織るものがあるといいと思います。

治安

最近、アメリカ各地で治安が悪くなったと聞きますが、ラスベガスのストリップ近辺は特に治安が悪い感じは受けませんでした。

ストリップからちょっと離れたところには治安の悪いところもあるらしいですが、そこまで行くことはないでしょうから、治安について心配することはないようです。

もちろん、ホームレスはいますが、お金をせびってくるようなホームレスには遭遇しませんでした。とはいっても、日本の感覚でいるのは危険なので、注意は必要です。

SIM

今まで海外旅行に行くときには、プリペイドSIMを普段使っているSIMと入れ替えて使っていました。

今回はじめてeSIMを使用しました。日本でプリペイドのeSIMを購入して、事前に設定しておきました。後はアメリカについたら、eSIMを有効化すればいいだけなので、とても楽。

プリペイドeSIMもいくつか選択肢がありますが、今回はソラコムのグローバルeSIMを使用しました。ソラコムのeSIMはデータ通信だけなのですが、通話はしないので全然OKです。

プリペイドeSIMを提供している企業によっては通話もできるところがあるようなので、必要であれば探してみるのもいいかもしれません。

なお、会場やホテルではWi-Fiが使えます。今回、会場のWi-Fiが瞬断することがありましたが、使えない状態が続くとか、遅くて使えないということはありませんでした。

まぁ、今回は参加人数が少なかったからということもあるかもしれません。

会場

今回のJavaOneの会場はCaesars Forumで、CloudWorldはThe Venetian Expoで行われました。両会場は橋でつながっていて行き来できるようになってます。

本来なら、3年前にCaesars Forumのこけら落としがOpenWorld/Code Oneだったんですけど、コロナで延期。まぁ、しかたありません。


Caesarsと名前がついていますが、Caesars Palaceからは離れていて、Harrahsの東側にあります。HarrahsやLINQからは直接Caesars Forumに入ることができ、またFlamingoの北側の道から観覧車のHigh Rollerの真下にCaesars Forumへ入る通路があります。

The Venetian ExpoはCaesars Forumの北側で、The Venetianから直接入ることができるのですが、カジノを通り抜けなくてはいけなくて、これがまた迷路のようになっているので、迷わずにいくのはなかなか大変です。

先述したように、会場はWi-Fiが使えます。また、今回は朝食とランチが提供されて、Caesars Forumの南側のテラス席でも食べることができました。暑くなければ、いい感じなんですけどね。

食事

ラスベガスは観光客向けの飲食店はいたるところにあります。でも、なんかみんな観光客向けの大箱、かつバックに資本がついているところばかりなような気がするんですよね。もちろん、そういう需要があることは分かるのですが、私の嗜好とは合わないのです。

ファストフード

1人でさくっと行きやすいといえば、ファストフードですね。McDonald'sやBurger Kingなどのように日本でも展開しているチェーン店もありますが、せっかくならば日本にない、もしくは日本ではまだそれほど店舗が多くないところを選んでみるのはどうでしょう。

  • In-N-Out Burger
  • Chick-fil-A
  • Chipotle Mexican Grill
  • Panda Express
In-N-Out (イン アンド アウト)はハンバーガーチェーンですが、裏メニューのカスタムがいっぱいあることや、冷凍のポテトを使わないなどで有名なところです。

Caesars Forumからも近いのですが、人気なのでいつも行列してました。とはいうものの、回転は早いので、そんなに待つこともないと思います。

Chick-fil-A (チックフィレイ)はチキンバーガーのチェーン店。KFCのチキンフィレバーガーのような感じです。Chik-fil-Aも人気ありますね。

Chipotoleはブリトーやタコスなどのメキシカンのチェーン店。ファストフードとしては珍しい地産地消をうたっています。日本からのJavaOne参加者にもここのファンという人が多いです。

最後のPanda Expressはアメリカンな中華のチェーンです。名物はオレンジチキン。日本では1度撤退していますが、2016年に再進出してます。でも、まだ店舗はそんなにないので、アメリカで行ってみるのはありだと思います。

フードコート

フードコートも1人で行くにはいいですね。だいたいのカジノにはフードコートがあるようです。

たとえば、Cloud World会場のベネチアンには2つのフードコートがあり、ハンバーガーのJohnny RocketsやFat Burger、上にも書いたPanda Expressなどがあります。

店を探す

やっぱりファストフードはやだという場合には店を探すわけですが、そんな時に役に立つのがアメリカ版食べログとでもいえるYelpです。
だいたいの店が予約可能なので、できることなら予約してから行った方がいいと思います。そんな時に使えるのが、OpenTableです。
日本のトレタやTableCheckのようなものですが、OpenTableの方が古くからあり、店の検索などもずっとやりやすくなっています。

今回もOpenTableで予約をとっていったところが多かったです。ただし、ホテル内にあるレストランはホテルの予約システムを使っていることがあるので、そちらもチェックした方がいいと思います。

とはいうものの、店が多いので、目当ての店があるとかでもないと、なかなか難しいですね。

参考までに今回ラスベガスで行ったレストランを列挙しておきます。

レストラン
  • Bouchon Bistro
    ナパにあるミシュラン三つ星のThe French Laundryの姉妹店のビストロ。本店はナパにあります。ナパのBouchonにも行ったことがありますが、ラスベガスの方がフォーマルな感じですね。とはいっても、ドレスコートがあるわけではなさそうですが。
    ベネチアンの10階にありますが、テラス席まであります。ぜんぜん10階のような感じがしないですが、とても静かでいいですね。
    朝ごはんに行ったのですが、ナパのBouchonはパンがおいしいので、クロワッサン。それとメインのサーモンのグリル。デザートも朝から頼めるというので、プロフィットロール。朝からいい気になって頼んだら、1万円超えてしまいました😰 でも、おいしかったので、OK。
    _DSC5763 _DSC5810 _DSC5875
  • Bardo Brasserie
    ARIAリゾートの中にあるブラッセリー。内装がウッディーで重厚な感じ。
    ここも朝ごはんで開店と同時に入店したのですが、開店待ちの人がいっぱい。このブログを書くために調べてみたら、Michael Mina系列のブラッセリーでした。Michael Minaもスターシェフなので、この人気もわかりますね。
    ここでは、タルタルとフレンチトースト。フレンチトーストはブリオッシュなので、そんなに大きくないだろうと高をくくっていたら、超巨大でした。
    _DSC0704 _DSC0751 _DSC0822
  • Sugarcane Raw Bar Grill
    _DSC6119 _DSC6127 _DSC6160
  • Off the Strip
    _DSC6300
ハンバーガー

WahlburgersもBurger Barもチェーン店ですが、Wahlburgersの方がファストフードに近い感じで、私にはBurger Barの方がよかったです。アメリカでハンバーガー食べると、日本のグルメバーガーがいかにおいしいか分かりますね😂

Wahlburgersでハンバーガーとサラダを食べていたら、隣に座っていたおじいさんにBig Dinnerだねと言われてしまいました🤣 
  • Wahlburgers
    _DSC5704 _DSC5723
  • Burger Bar
    _DSC0528
ステーキ
ステーキは、フレンチやイタリアンなどに比べると、シェフの技量よりも材料に起因する部分が大きいような気がします。つまり、いい肉を使っているかどうか。値段が高いところはいい肉を使っているので、おいしいわけです。もちろん、例外はありますけど。

とはいうものの、2倍の値段だったら、2倍おいしいということはないので、そこらはバランスですね。

2店行きましたが、Gordon Ramsayの方が値段が高いだけあっておいしかったです。Smith & Wollenskyもおいしかったんですけどね。

ちなみに、Gordon Ramsayもスターシェフで、ラスベガスにいろいろなジャンルの店があります。最近、Fish & Chipsの店をオープンしたらしいのですが、いつも行列していたので行くのをあきらめました。来年、行こうっと!
  • Smith & Wollensky
    _DSC6413 _DSC6459
  • Gordon Ramsay Steak
    _DSC7214 _DSC7219 _DSC7260 _DSC7294
スイーツ

アメリカは、おいしいスイーツがなかなかないんですよね。ラスベガスでもそういう感じでした。

たまたま帰国する日が、シザースパレスにドミニクアンセル (Dminique Ansel Bakery)がオープンするということだったので行ってみたのですが、すごい行列。

ドミニクアンセルは以前、表参道にもあったのですが撤退してしまったので、久しぶりに食べられると思ったのですが、さすがに行列に並ぶと飛行機に遅れてしまうので断念。

来年リベンジします。
  • Sweets Raku
    アメリカでアシェットデセールの店があるとは思いませんでした。とはいっても、日本人がオーナーで、パティシエも日本人。どおりで!
    日本人が作っているということで、日本の繊細なデザートが食べられます。ラスベガスでパフェ食べらるのはたぶんここだけ。というか、日本のパフェは日本独自のデザートなので、外国ではなかなか食べられないのです。
    _DSC6075 _DSC5981
  • Dandelion Chocolate
    サンフランシスコに本店があるビーントゥバーチョコレートのDandelion Chocolate。日本にも蔵前に店があります。
    ここはチョコはもちろん、チョコを使ったスイーツもおいしいです。
    ついでですが、ここが使っているコーヒー豆がサードウェーブ系で有名なRitual。ラスベガスでおいしいコーヒーをなかなか見つけられなかったので、チョコを食べなくてもコーヒーを飲みに来るのはありですね。
    _DSC7493 _DSC7508 _DSC7520
  • Bouchon Bakery
    上に書いたBouchon Bistroのベーカリー部門です。パンもありますが、スイーツもあります。もうちょっと種類が多いといいんだけどなぁ...
    _DSC9679 _DSC9707 _DSC9766
  • Bellagio Patisserie
    _DSC6336 _DSC6353
  • Donut Bar
    _DSC5896 _DSC5917

アメリカのレストランでクレジットカードで支払う時、一度カードを持って行ってレシートを持ってきてくれます。そこにチップと合計額を書いて、サインをして完了なんですけど、それがめんどうくさい。

チップのないフランスやシンガポールだと、店員さがハンディターミナルを持ってきて、タッチ機能がついていればピッとタッチすればそれでおしまい。アメリカはチップあるし、こうはできないよなぁと思っていたのですが、Bardo Brasserieではじめてハンディターミナルで決済しました。

ハンディターミナルを店員さんが置いていって、ディスプレイにチップのパーセンテージが表示されるので、その中から選択して、後はタッチすればOK。タッチ機能がなければ、暗証番号を入れるのだと思います。

今後、こういう店が増えていくのでしょう。それにしても、チップのパーセンテージの選択肢が決め打ちというのもなんかへんな感じですね。
_DSC0826

買いもの

ラスベガスはショッピングモールやアウトレットもあるので、時間があるのであればそういうところにいけばいいと思います。

アウトレットはちょっと離れているので、バスかタクシー/ライドシェアでしょうね。

さて、問題は日用品です。水とかね。

スーパーとかコンビニ的に使えるのは、以下の2つのショップ。

  • Walgreens
  • CVS
どちらも複数の店舗がJavaOne会場近辺にあります。どちらの店舗ももともとはドラッグストアなのですが、Walgreensの方が食べものなどは多い感じ。バラマキ用のおみやげのお菓子なんかはWalgreensの方がいいかもしれません。


その他

ドルは持って行った方がいい?

ほとんどクレジットカードで支払うので、現金はほとんど使いませんでした。

レストランに複数人で行った時も、クレジットカードを4枚ぐらいまでなら受け付けてくれます。

今回、現金を使ったのは、6人で食事に行った時の支払いと、チェックアウトの日に荷物を預かってもらったので、ポーターに対してのチップぐらい。後は全部クレジットカードでした。

Google Mapsのオフラインマップ

Google Mapsは便利なので、旅行には必需品だと思うのですが、意外に知られてないのがオフラインマップ。

Wi-Fiのあるところで、事前にマップをダウンロードしておけば、ネットが使えない場所でもGoogle Mapsを使うことができますよ。

帰国時

10月の時点では帰国時にMySOSに登録しておく必要があったんですが、11月からはVisit Japan Webに統一されたようです。来年はどうなるのか分からないですね。

ちなみに、Visit Japan Webを使うと、入国審査や税関申告も事前に登録しておくことができます。税関申告の紙を書かなくてもいいというのはいいのですが、使い方がイマイチなんですよね。

申告を事前に行っておくと、2次元バーコードが表示されるので、空港の税関のところでリーダーで読ませて、そのまま出ていけるのですが、導線がイマイチ。出口のところにリーダーを置いておけばいいのにと思いました。

まぁ、でも徐々に改善されるでしょう。


さて、来年のJavaOneは同じくラスベガスのCaesars Forumで9月18日から21日。今年は3日間でしたが、1日増えて4日間の会期に戻ります。

今年はいろいろと準備ができていない様子がありありだったのでしたし、はじめての会場だったこともあり、もうちょっとなんとかならないかなぁというところも多くありました。

来年はラスベガスでも2回目ですし、会期も公開されていますから、今年よりはよくなっているでしょう。

今のところ、私は参加する予定なので、ぜひご一緒に!

2022/09/20

JEPでは語れないJava 19

このエントリーをはてなブックマークに追加

半年ぶりのJavaのアップデートで、Java 19がリリースされます。

Java 19はJava 18よりJEPは少なく、しかもPreviewやIncubatorでないJEPはJEP 422のLinux/RISC-V Portしかありません。こんなアップデートは初めてかも。

  • 405: Record Patterns (Preview)
  • 422: Linux/RISC-V Port
  • 424: Foreign Function & Memory API (Preview)
  • 425: Virtual Threads (Preview)
  • 426: Vector API (Fouth Incubator)
  • 427: Pattern Matchning for switch (Third Preview)
  • 428: Structured Concurrency (Incubator)

JEP 424のForeign Function & Memory APIは、Java 18まではIncubatorだったのですが、なぜかPreviewに変更されました。今までのFFM APIはjdk.incubator.foreignモジュールから、java.baseモジュールに変更されて、パッケージがjava.lang.foreignになったからなのかもしれません。

なお、Java 19からはFFMに関連して、Restricted MethodsがSpecificationに記述されるようになりました。Javaが管理していないメモリへのアクセスするAPIなどがRestricted Methodsに指定されています。

JEP 426 Vector APIはなかなかIncubatorが外れずにFouthまで行ってしまいました。なかなか難しいですね。

JEP 427 Pattern Matching for switchもThird Previewです。JEP 405 Record Patternsはinstance ofでRecordのプロパティを直接扱えるようになる機能です。これもinstance ofの後はswitchでも使えるようになるはずなので、Pattern Matching for switchが正式になるのはいつになるのか...

JEP 425 Virtual ThreadsはProject Loomで策定されているAPIで、当初はFiberと呼ばれていたものです。Virtual Threadsが銀の弾丸のように書いてある記事もありますけど、実際はそんなことは全然ないんですけどね。ちゃんと設計されたマルチスレッドのシステムであれば、Virtual Threadsを使わなければならない場面は少ないはずです。

JEP 428 Structed Concurrencyは複数のタスクを例外も含めて扱いやすくするためにStructuredTaskScopeクラスを導入するJEPです。

 

ということで、PreviewやIncubatorがついていないStandard JEPの新機能というのは、Java 19ではないことになってます。しかし、JEPに記述されていないAPIの追加は意外に多いんですよね。

 

今回はjava.baseモジュールなどにPreview JEPのAPIが多く導入されていますが、JEPでの新機能は他にゆずって、ここではPreviewやIncubatorのAPIの説明は省略します。また、java.baseモジュール以外のモジュールの変更は少ないし、普通の開発ではほぼ使われないAPIなので、今回はjava.baseモジュールだけ説明します。例によってセキュリティ系のAPIの変更は櫻庭がよく理解していないので省略します。

 

廃止になったAPI

Java 19では、なんと廃止になったAPIはありません。これも珍しいですね。

 

廃止予定のAPI

Java 19で追加された廃止予定のAPIは、SwingのPluggable Look-and-Feel関連のクラスとメソッドです。

 

クラス

前述したようにSwingのPluggable Look-and-Feel関連のクラスがforRemoval=trueになりました。

  • javax.swing.plaf.basic.BasicMenuItemUI.MouseInputHandler
  • javax.swing.plaf.basic.BasicScrollPaneUI.HSBChangeListener
  • javax.swing.plaf.basic.BasicScrollPaneUI.PropertyChangeHandler
  • javax.swing.plaf.basic.BasicScrollPaneUI.ViewportChangeHandler
  • javax.swing.plaf.basic.BasicScrollPaneUI.VSBChangeListener

 

メソッド

メソッドもSwingのPluggable Look-and-Feel関連です。

  • javax.swing.plaf.basic.BasicDirectoryModel.intervalAdded
  • javax.swing.plaf.basic.BasicDirectoryModel.intervalRemoved
  • javax.swing.plaf.basic.BasicDirectoryModel.lt
  • javax.swing.plaf.basic.BasicToolBarUI.createFloatingFrame

 

追加されたAPI

Java 19で追加されたAPIはかなり多いのですが、半分以上はFFM APIです。とはいうものの、FFM以外でもかなり多くのAPIが追加されています。

 

java.base/java.ioパッケージ

java.ioパッケージではシリアライゼーション関連の例外のコンストラクタが追加されました。なぜ、今、これらのコンストラクタが追加されたのかはよく分かりません。

 

InvalidClassException例外

例外の原因を示すcauseがコンストラクタ引数で指定できるようになりました。

  • InvalidClassException(String reason, Throwable cause)
  • InvalidClassException(String cname, String reason, Throwable cause)

 

InvalidObjectException例外

こちらも同じく、例外の原因を示すcauseがコンストラクタ引数で指定できるようになりました。

  • InvalidObjectException(String reason, Throwable cause)

 

ObjectStreamException例外

こちらも同じです。

  • ObjectStreamException(String message, Throwable cause)
  • ObjectStreamException(Throwable cause)

 

java.base/java.langパッケージ

java.langパッケージも多くのAPIが追加されていますが、Virtual Thread関連のものが多いため、それ以外のAPI変更を説明します。

 

Character.UnicodeBlockクラス

Java 19ではUnicode 14.0をサポートするようになりました。

Unicode 14.0というと敬礼の絵文字などが使えるようになっています。しかし、それ以外にも古代アルバニア文字やインドなどで使われているらしいTangsa語の文字などが追加されています。そのためにBlockとScriptも追加されています。

  • ARABIC_EXTENDED_B
  • CYPRO_MINOAN
  • ETHIOPIC_EXTENDED_B
  • KANA_EXTENDED_B
  • LATIN_EXTENDED_F
  • LATIN_EXTENDED_G
  • OLD_UYGHUR
  • TANGSA
  • TOTO
  • UNIFIED_CANADIAN_ABORIGINAL_SYLLABICS_EXTENDED_A
  • VITHKUQI
  • ZNAMENNY_MUSICAL_NOTATION

 

Character.UnicodeScriptクラス

こちらも同じく、Unicode 14.0で追加されたScriptが追加されています。

  • CYPRO_MINOAN
  • OLD_UYGHUR
  • TANGSA
  • TOTO
  • VITHKUQI

 

note: 以下の説明はJava 19ではなくて、Java 20の機能でした。Satoさん、ご指摘ありがとうございます。

APIの変更ではないのですが、java.text.BreakIteratorクラスの実装が拡張されて結合文字の絵文字に対応できるようになっています。

今までは正規表現の\b{g}で分解するしかなかったのですが、BreakIteratorクラスのgetChracterInstanceメソッドでできるようになったようです。詳しくはJBSのJDK-8291660をご覧ください。

   - ここまで -

 

Doubleクラス

定数が1つ追加されていますが、これはJLS 4.2.3で定義されている浮動小数点のNを表すものです。

  • PRECISION

PRECISIONはintで定義されていて、doubleでは53になっています。

 

Floatクラス

FloatクラスもDoubleクラスと同じく、JLS 4.2.3で定義されている浮動小数点のNを表す定数が追加されました。

  • PRECISION

floatでは24に定義されています。

 

Integerクラス/Longクラス

まさかIntegerクラスにメソッドが追加されるとは思いもよりませんでした。

  • static int compress(int i, int mask)
  • static int expand(int i, int mask)

Longクラスの場合は引数と戻り値の型がlongになります。

compressはmaskのビットが立った桁のみを残して、取り除いた桁は詰めて表現した数にします。Javadocにある例は

jshell> int compress = Integer.compress(0xCAFEBABE, 0xFF00FFF0)
compress ==> 830379

jshell> System.out.printf("%X%n", compress)
CABAB

maskがFF00FFF0 (1111 1111 0000 0000 1111 1111 1111 0000)なので、16進のCAFEBABEの1になっているビット桁だけにすると CA は残って FE は削除、BAB が残って E が削除。残った部分をくっつけると CABAB となるわけです。

expandメソッドは逆にマスクのビットが立っている桁に、ビットを置きなおす感じです。

jshell> int ex = Integer.express(0xCABAB, 0xFF00FFF0)
ex ==> 211860144

jshell> System.out.printf("%X%n", ex)
CA00BAB0

この演算は下位ビットから当てはめていくので、ビットの立っている箇所だけではiが表されない場合、上位ビットが省略されてしまうようです。

jshell> int ex = Integer.express(0xCABAB, 0x0000FFF0)
ex ==> 47792

jshell> System.out.printf("%X%n", ex)
BAB0

 

Mathクラス/StrictMathクラス

定数にτが追加されました。

  • static final double TAU

τは円の半径に対する円周長の比になり、値としては2πになります。

jshell> Math.TAU
$1 ==> 6.2831853071795

 

Threadクラス

ThreadクラスにはVirtual Thread関連のAPIが増えていますが、それ以外にもいくつかメソッドが追加されました。

  • boolean join(Duration duration)
  • void sleep(Duration duration)
  • long threadId()

joinメソッドとsleepメソッドはタイムアウトをミリ秒で設定できましたが、Java 19で任意の単位の時間で指定できるようなオーバーロードが追加されました。

threadIdメソッドはスレッドのIDを取得するためのメソッドです。

 

java.base/java.mathパッケージ

BigDecimalクラスに定数が追加されました。

 

BigDecimalクラス

2を表す定数が追加されています。

  • BigDecimal TWO

 

BigIntegerクラス

パラレルに乗算を行うメソッドが追加されています。

  • BigInteger parallelMultiply(BigInteger val)

this×valを行う演算ですが、数値が千を超えるようなビット数の場合、処理をパラレルで行います。

 

java.base/java.textパッケージ

DecimalFormatSymbolsクラスにメソッドが追加されました。

 

DecimalFormatSymbolsクラス

ロケールを返すメソッドが追加されています。

  • Locale getLocale()
jshell> var symbols = DecimalFormatSymbols.getInstance()
symbols ==> java.text.DecimalFormatSymbols@f6cadb1e

jshell> symbols.getLocale()
$1 ==> ja_JP

 

java.base/java.time.chronoパッケージ

ISO 8601準拠かどうかを返すメソッドが追加されました。

 

Chronologyインタフェース

暦がISO 8601に準拠しているかどうかを返すメソッドが追加されました。

  • defualt boolean isIsoBased()

デフォルトではfalseを返しますが、ISOChronologyクラスなどはtrueを返します。JapaneseChronologyクラスなどもtrueを返します。ただし、太陰暦であるヒジュラ暦を表すHijrahChronologyクラスはfalseを返します。

 

java.base/java.time.formatパッケージ

ロケール指定に関してのメソッドが追加されています。

 

DateTimeFormatterクラス

ローカライズしたパターンの生成を行うメソッドが追加されました。

  • DateTimeFormatter ofLocalizedPattern(String requestedTemplate)

今までofPatternメソッドでロケールを渡すことで同じようなことができましたが、このメソッドはISO 8601準拠の暦をしようすることが前提となっているようです。引数のrequestedTemplateには通常のDateTimeFormatterのフォーマットとは異なり、正規表現で記述するようになっています。使用できる正規表現はJavadocに記載されています。

また、ResolverStyleがSMARTになります。

 

DateTimeFormatterBuilderクラス

こちらも、ロケールに応じたビルダー生成のメソッドが追加されました。

  • DateTimeFormatterBuilder appendLocalized(String requestedTemplate)
  • String getLocalizedDateTimePattern(String requestedTemplate, Chronology chrono, Locale locale)

appendLocalizedメソッドは、DateTimeFormatter.ofLocalizedPatterメソッドのために作られたメソッドのようです。ofLocalizedPatterメソッドの実装で使われていました。

getLocalizedDateTimePatternメソッドはofLocalizedPatternメソッドで指定した正規表現のrequestedTemplateから通常のDateTimeFormatterクラスで使われるパターンを取得するためのメソッドのようです。

 

java.base/java.utilパッケージ

 

HashMapクラス, LinkedHashMapクラス, WeakHashMapクラス, HashSetクラス, LinkedHashSetクラス

マップオブジェクトを生成するためのファクトリメソッドが追加されています。

  • <K, V> HashMap<K, V> newHashMap(int numMappings)

上のnewHashMapメソッドはHashMapクラスで定義されたメソッドです。LinkedHashMapクラスはnewLinkedHashMapメソッド、WeakHashMapクラスはnewWeakHashMapメソッドになります。

同様に、HashSetクラスはnewHashSetメソッド、LinkedHashSetクラスはnewLinkedHashSetメソッドになります。

これらのメソッドはいずれも空のミュータブルなマップオブジェクトを生成します。マップオブジェクトの初期容量は、引数のnumMappingsが負荷係数0.75になるように設定されます。

 

Localeクラス

3種類のファクトリメソッドが追加されています。

  • static Locale of(String language)
  • static Locale of(String language, String country)
  • static Locale of(String language, String country, String variant)

最近のJavaではファクトリメソッドにofが使われるようになっているので、Localeクラスもそれにならったようです。ofメソッドを使う方がキャッシュを使用するので、不要なオブジェクト生成を抑制できます。今後はnewでオブジェクト生成をするのではなく、ofメソッドを使うべきです。

 

Objectsクラス

どこかで見たことのあるはずな表記を作るためのメソッドが追加されました。

  • static String toIdentityString(Object o)

このメソッドを使うと、 型名@ハッシュコード 形式の文字列を作ってくれます。

jshell> var text = "ABC"
text ==> "ABC"

jshell> Objects.toIdentityString(text)
$2 ==> "java.lang.String@b1a58a3"

この形式、Java使っていたら見たことあるはずですよね。toStringメソッドのデフォルトがこの形式の文字列を返します。まぁ、だいたいのクラスはtoStringメソッドをオーバーライドしてしまいますけど。

 

Randomクラス

ファクトリメソッドが1つ追加されました。

  • static Random from(RandomGenerator generator)

RandomGeneratorインタフェースはJava 17で追加されたインターフェースです。RandomクラスはRandomGeneratorインタフェースを実装していますが、乱数生成器を指定することはできませんでした。fromメソッドを使用すると任意の乱数生成器を指定して、Randomオブジェクトを生成することができます。

 

java.base/java.util.concurrentパッケージ

java.util.concurrentパッケージもいろいろと追加されていますが、JEP 425関連のメソッドも多いです。

 

ExecutorServiceインタフェース

やっと、ExecutorServiceインタフェースがAutoClosableになりました!!

  • default void close()

AutoClosableインタフェースを実装しているということは、try-with-resources構文で記述できるようになるということです。今まで使い終わった後にshutdownメソッドをコールしなくてはいけなかったのが、解放されました。

デフォルト実装ではshutdownメソッドをコールして、awaitTerminationメソッドで終わるまで待つ実装になっています。

 

ForkJoinPoolクラス

ForkJoinPoolクラスはExecutorServiceインタフェースを実装しているので、こちらもAutoClosableになっています。それ以外に2つのメソッドが追加されました。

  • default void close()
  • <T> ForkJoinTask<T> lazySubmit(ForkJoinTask<T> task)
  • int setParallelism(int size)

lazySubmitメソッドは、名前の通りsubmitメソッドのlazy版です。最終的には実行されますが、いつ実行されるかはスレッドの空き状況によります。

ForkJoinPoolクラスは生成時に並行度を指定できますが、setParallelismメソッドを使うと後から変更することができます。

 

ForkJoinTaskクラス

ForkJoinTaskクラスには3つのメソッドが追加されました。

  • static <T> ForkJoinTask<T> adaptInterruptible(Callable<? extends T> callable)
  • boolean quietlyJoin(long timeout, TimeUnit unit)
  • boolean quietlyJoinUninterruptibly(long timeout, TimeUnit unit)

adaptInterruptatibleメソッドはadaptメソッドの割り込み可能版です。タスクをcancelメソッドでキャンセルするときに、cancelメソッドの引数のmayInterruptIfRunningをtrueにしておくと、割り込みをかけてキャンセルしてくれます。

quietlyJoinメソッドのオーバーロードはタイムアウトを指定できるようになりました。引数無しのquietlyJoinメソッドは例外をスローしませんが、タイムアウトを指定できるようになったのでInterruptedException例外がスローされる可能性があります。

もう1つのquietlyJoinUninterruptiblyメソッドはquietlyJoinをする時に割り込みをかけないメソッドです。

 

ForkJoinWorkThreadクラス

ForkJoinWorkThreadクラスはFork/Join Frameworで使用するスレッドです。コンストラクタが1つ追加されました。

  • ForkJoinWorkerThread(ThreadGroup group, ForkJoinPool pool, boolean preserveThreadLocals)

今まで提供されていたコンストラクタはForkJoinPoolオブジェクトだけを指定するものでしたが、ThreadGroupとThreadLocalの有無を指定できるようになっています。このコンストラクタはVirtual Threadに関連してそうなんですけど、Previewではないようです。

 

Future.State列挙型

Futureインタフェースに状態を示す列挙型が追加されました。

定数として、以下の4種類が定義されています。

  • CANCELLED
  • FAILED
  • RUNNING
  • SUCCESS

というか、State列挙型のようなものが今までなかったのが不思議だったんですよね。

 

Futureインタフェース

Future.State列挙型の導入に伴い、それを使うメソッドが追加されました。

  • default Throwable exceptionNow()
  • default V resultNow()
  • default Future.State state()

stateメソッドは現在の状態を表すメソッドです。戻り値の方はもちろんFuture.State列挙型です。

resultNowメソッドは結果を取得するメソッドなのですが、getメソッドとは異なって、結果取得を待たないです。つまり、正しい値を取得するには状態がSUCCESSの場合だけです。

デフォルト実装では、その他の状態の場合、IllegalStateException例外がスローされるようになっています。

exceptionNowメソッドも同様に例外の取得を待たないメソッドです。今ままではgetメソッドのExecutionException例外のcauseで原因となる例外を取得していましたが、状態がFAILの場合はexceptionNowメソッドで例外を取得できるようになっています。

デフォルト実装では、その他の状態の場合、同じようにIllegalStateException例外がスローされます。

 

java.base/java.util.spiパッケージ

ToolProviderクラスにメソッドが追加されました。

 

ToolProviderクラス

ToolProviderクラスはServiceLoaderクラスによって呼び出されるクラスなので、普通は使わないとは思いますが...

  • Optional<String> description()

ToolProviderオブジェクトの説明があれば返します。デフォルト実装ではOptional.empty()を返していました。

一応、jar, javac, jlinkの場合の説明がJavadocに記載されているので、興味があれば見てみてください。

 

 

というわけで、Java 19のJEPにのっていないAPIの変更でした。Java 19ではFFM APIやVirtual ThreadsなどのPreviewのAPI変更が多いのですが、意外にもそうでないAPIの変更も多めでした。個人的にはFuture.State列挙型の導入がうれしいですね。

PreviewやIncubatorもいつか紹介したいとは思ってはいます。

2022/03/22

JEPでは語れないJava 18

このエントリーをはてなブックマークに追加

半年ぶりのJavaのアップデートの時間です。

Java 18はLTSの次のバージョンということもあり、JEPは少なめです。

  • 400: UTF-8 by Default
  • 408: Simple Web Server
  • 413: Code Snippets in Java API Documentation
  • 416: Reimplement Core Reflection with Method Handles
  • 417: Vector API (Third Incubator)
  • 418: Internet-Address Resolution SPI
  • 419: Foreign Function & Memory API (Second Incubator)
  • 420: Pattern Matching for switch (Second Preview)
  • 421: Deprecate Finalization for Removal

しかし、日本、特にWindowsの日本語環境で運用しているシステムにとって、とても重大な変更があります。

それが、JEP 400のUTF-8 by Defaultです。

Reader/Writer系のクラスで文字コードを指定しない場合、デフォルトの文字コードとしてUTF-8が使われるようになります。今まで、Windowsの日本語環境ではデフォルトの文字コードはWindows-31j (MS932)だったので、それを前提とした入出力は動作がおかしくなります。

もちろん、互換性維持のための策もちゃんとあって、file.encodingプロパティをCOMPAT、つまり実行時にオプションとして-Dfile.encoding=COMPATを指定すれば今まで通りのデフォルトの文字コードになります。

しかし、デフォルトの文字コードに依存したコードはなるべく早いうちに、文字コードを指定するコードに書き換えるべきです。

なお、NIO.2を使用した入出力はすでにデフォルトの文字コードがUTF-8になっているので、変更は必要ありません。

 

JEP 408は以前よりJDKに含まれていたWeb Server機能を使用できるツールの提供、JEP 413はJavadocにコードを書くために@snippetタグの導入です。

JEP 416はリフレクションの実装方法の改善です。JEP 421は以前より予告されていたfinalizerの廃止です。for Removalになったので、どんなに遅くなったとしても次のLTSではfinalizeメソッドは使えないと思った方がいいです。

他のIncubatorモジュールやPreviewは2ndや3rdなので、もうおなじみ?

 

例によってセキュリティ系のAPIの変更は櫻庭がよく理解していないので、省略します。

 

廃止になったAPI

メソッド

JEP 421関連でfinalizeメソッドが廃止になりました。これらはJava 16でfor Removalになっていたものです。

  • java.awt.color.ICC_Profile.finalize()
  • java.awt.image.ColorModel.finalize()
  • java.awt.image.IndexColorModel.finalize()

いずれもAWT関連なので、特に問題にはならないと思います。

 

廃止予定のAPI

Java 18で追加された廃止予定のAPIは、JEP 421関連のfinalizeメソッドがほとんどだけです。

 

メソッド

JEP 421関連のfinalizeメソッド以外のメソッドとして、とうとうThread.stop()メソッドがforRemovalになりました。stopメソッドを使われていることも少なくなっているとは思いますが、注意が必要です。

また、セキュリティ系の情報を保持するSubjectクラスのdoAsメソッドが廃止予定になりました。

  • java.awt.Graphics.finalize()
  • java.awt.PrintJob.finalize()
  • java.lang.Enum.finalize()
  • java.lang.Object.finalize()
  • java.lang.Runtime.runFinalization()
  • java.lang.System.runFinalization()
  • java.lang.Thread.stop()
  • java.util.concurrent.ThreadPoolExecutor.finalize()
  • javax.imageio.spi.ServiceRegistry.finalize()
  • javax.imageio.stream.FileCacheImageInputStream.finalize()
  • javax.imageio.stream.FileImageInputStream.finalize()
  • javax.imageio.stream.FileImageOutputStream.finalize()
  • javax.imageio.stream.ImageInputStreamImpl.finalize()
  • javax.imageio.stream.MemoryCacheImageInputStream.finalize()
  • javax.security.auth.Subject.doAs(Subject,PrivilegedAction)
  • javax.security.auth.Subject.doAs(Subject,PrivilegedExceptionAction)

 

追加されたAPI

LTSの次のバージョンということもあり、Java 18のAPIの追加はあまりありません。ただし、java.baseモジュールにメソッド追加が多いです。

 

java.base/java.ioパッケージ

java.ioパッケージでは2つのメソッドが追加されましたが、1つはスーパークラスで定義されていたものをオーバライドしたメソッドです。それがFileInputStreamクラスのtransferToメソッドです。

もう1つのメソッドがJEP 400に関連したメソッドです。

 

PrintStreamクラス

PrintSreamクラスでは現在使用している文字セットを返すcharsetメソッドが追加されました。

  • Charset charset()

Java 17でCosoleクラスにcharsetメソッドが追加されましたが、同じようにファイルに出力を行う文字セットを返します。

 

java.base/java.langパッケージ

java.langパッケージではMathクラスとStrictMathクラスにメソッドが追加されました。いずれも同じメソッドなので、一緒に説明します。

Mathクラス/StrictMathクラス

Math/StrictMathクラスでは、それぞれ13のメソッドが追加されました。

  • int ceilDiv(int x, int y)
  • long ceilDiv(long x, int y)
  • long ceilDiv(long x, long y)
  • int ceilDivExact(int x, int y)
  • long ceilDivExact(long x, long y)
  • int ceilMod(int x, int y)
  • int ceilMod(long x, int y)
  • long ceilMod(long x, long y)
  • int divideExact(int x, int y)
  • long divideExact(long x, long y)
  • int floorDivExact(int x, int y)
  • long floorDivExact(long x, long y)
  • long unsignedMultiplyHigh(long x, long y)

Exactがつくメソッドは、ArithmeticException例外を投げるという違いだけなので、それ以外のメソッドを説明します。

ceilDiv系のメソッドは演算結果より大きいもしくは同じになる最小の整数を返します。

jshell> Math.ceilDiv(10,3)
$1 ==> 4

jshell> Math.ceilDiv(9, 3)
$2 ==> 3

jshell> Math.ceilDiv(-10, 3)
$3 ==> -3

ceilMod系の割り算の余りなのですが、負の値になることもあります。つまり、z = Math.ceil(x, y)だったときに、ceilModメソッドの返り値はx - z * yになります。

jshell> Math.ceilMod(10,3)
$1 ==> -2

jshell> Math.ceilMod(9, 3)
$2 ==> 0

jshell> Math.ceilMod(-10, 3)
$3 ==> -1

unsignedMultiplyHighメソッドはmultiplyHighメソッドの符号なし版です。

 

java.base/java.net.spiパッケージ

JEP 418でインターネットアドレスの名前解決がSPI化され、それに応じて4つのインタフェース/クラスが追加されました。

  • InetAddressResolverインタフェース
  • InetAddressResolver.LookupPolicyクラス
  • InetAddressResolverProviderインタフェース
  • InetAddressResolverProvider.Configurationクラス

これで独自の名前解決クラスを実装することができるようになります。

 

java.base/java.nio.charsetパッケージ

Charsetクラスにメソッドが1つ追加されています。

Charsetクラス

指定された文字セットを返すforNameメソッドがオーバーロードされました。

  • Charset forName(String charsetName, Charset fallback)

今までのforNameメソッドは指定された文字セットがない場合、IllegalCharsetNameException例外を投げます。これに対し、Java 18で追加されたforNameメソッドは文字セットがない場合、第2引数のfallbackが戻ります。

今までは文字セットがなかった場合は例外処理で処理しなくてはならなかったのが、fallbackを指定できるのでコードが分かりやすくなるはずです。

 

java.base/java.timeパッケージ

Durationクラスにメソッドが1つ追加されています。

Durationクラス

Durationクラスは時間間隔表すクラスですが、保持している時間間隔が正の値なのか調べるためのメソッドが追加されました。

  • boolean isPositive()

isZeroメソッドと、isNegativeメソッドはあったので、これで3つ揃いました。

 

java.net.http/java.net.httpパッケージ

HTTPリクエストを作成するBuilderクラスにメソッドが1つ追加されています。

HttpRequest.Builderクラス

HTTPリクエストを作成するBuilderクラスは、これまでHTTPメソッドのGET, POST, PUT, DELETEを作成するメソッドはあったのですが、HEADを作成するメソッドはありませんでした(HEADメソッドのリクエストを作ることはできます)。そこで、HEADメソッドが追加されています。

  • HttpRequest.Builder HEAD()

これまで、HEADメソッドはmethodメソッドで作らなくてはならなかったのが、少し簡単になりました。

 

java.xml/javax.xml.xpathパッケージ

なぜ、この時期にXPathにメソッドが追加されたのか全然わからないのですが、XPathのファクトリにメソッドが2つ追加されました。

XPathFactoryクラス

XPathFactoryクラスで属性を設定、取得するメソッドが追加されました。

  • String getProperty(String name)
  • void setProperty(String name, String value)

追加されたのはいいのですが、使い道がよく分かりません。デフォルトの実装ではUnsupportedOperationException例外が投げられるようになっています。

 

java.compilerモジュール

毎度のことですが、java.compilerモジュールはいろいろと追加されています。いつものソースバージョンやらなにやらが大半ですが、アノテーション処理関連でも少しだけメソッドが追加されています。とはいうものの、普通は使わないので省略します。

 

ということで、Java 18のAPIの変更をまとめました。

LTSの次のバージョンということで、変更点は少なめですね。