2024/09/17

JEPでは語れないJava 23

毎度おなじみ半年ぶりのJavaのアップデートです。

Java 23はLTSのちょうど中間のリリースということもあって、それほど変化があるわけではないです。

Java 23のJEPは12ありますが、Previewばかり。PreviewでないStandard JEPは3つですがAPIの変更が伴うものはありません。

Java 23のJEPは以下の通り。

  • 455: Primitive Types in Patterns, instanceof, and switch (Preview)
  • 466: Class-File API (Second Preview)
  • 467: Markdown Documentation Comments
  • 469: Vector API (Eighth Incubator)
  • 473: Stream Gatherers (Second Preview)
  • 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal
  • 474: ZGC: Generational Mode by Default
  • 476: Module Import Declarations (Preview)
  • 477: Implicitly Declared Classes and Instance Main Methods (Third Preview)
  • 480: Structured Concurrency (Third Preview)
  • 481: Scoped Values (Third Preview)
  • 482: Flexible Constructor Bodies (Second Preview)

Standard JEPの1つめ。JEP 467はJavadocにマークダウンが使えるというものです。

これは地味にうれしいかも。ただ、マークダウンにする時にはスラッシュ3つというのはちょっと面倒かもしれません。

IDEがマークダウンのJavadocに対応して、ショートカットでスラッシュ3つを簡単に使えるようになってほしいですね。

2つめのJEP 471は、UnsafeクラスのヒープではないネイティブメモリまわりのAPIをDeprecated for RemovalにするというJEPです。通常の用途ではUnsafeクラスは使わないとは思いますが、昔は高速化のためにヒープではなくUnsafeを使って直接メモリにアクセスしていたフレームワークやライブラリがそれなりにあったのです。

しかし、FFMが導入されたので、Unsafeを使わずにメモリアクセスできるようになったので、ようやく削除できるようになったということですね。ただ、ほんとに削除されるのがいつになるのかは微妙なところです。

Standard JEPの最後のJEP 474は、ZGCのデフォルトを世代別ZGCに変更するというものです。もともとZGCは世代別GCではなかったのですが、Java 21で世代別GCをサポートするようになりました。これに伴い、ZGCのデフォルトが世代別GCの方に変わるというものです。

ただ、これはあくまでもZGCの話で、JVMのデフォルトのGCの話ではないことに注意が必要です。

 

残りのJEPはすべてPreviewです。

JEP 455はパターンマッチングにプリミティブ型が使えるようになるというJEPです。ちょっとおもしろいのが、プリミティブ型の値と型のcaseを同じswitch式の並べて書けるところですね。まぁ、そんなに使うことはないと思いますが...

ちなみに、JEP 455は1st Previewなので、次のLTSであるJava 25に入らないんじゃないかなぁ。

 

JEP 466はバイト操作を行うためのClas-File APIです。バイトコードを直接編集してしまうわけですが、一時期ちょっとだけはやったAOPなどで使われる技術です。Class-File APIはAOPというよりは、ラムダ式の実行時に動的にクラス生成するなどJVM内部での用途が主目的のようです。

 

JEP 469 Vector APIは8回目のPreview。Project Valhallaが導入されるまで、ずーーーーっとPreviewのままです。7thからの変更点もありません。

 

JEP 473 Stream Gatherersはストリームの中間処理をもうちょっとどうにかしようというJEP。簡単にいえば、終端処理のcollectと同様のことを中間処理でもできるようにしましょうというAPIです。

これで、今までのストリームではできなかった移動平均なんかも簡単に書けるようになります。

JEP 473は2nd Previewで、すでにPreviewが外されたJEP 485が提案されているので、Java 24で正式導入ということになりそうです。

 

JEP 476 Module Import Declarationsは、インポート文をクラス単位で書くのではなくて、moduleで書けるようにしてしまいましょうというJEPです。これができると、import module java.base;で基本的なAPIは全部使えます。

これはかなり便利になりますけど、使っているクラスがどのパッケージで定義されているのか調べるにはIDEの力に頼らなければいけないという負の側面がなきにしもあらず...

JEP 476は1st Previewなので、Java 25にはまにあわないかもしれません。

 

JEP 477 Implicitly Declared Classes and Instance Main Methodsはmainメソッドを含むクラスを書かなくても、mainメソッドだけ書けばいいんじゃないというJEPです。

ちなみに、このJEPでは動的にクラスを作成していますが、その生成はバイトコード操作ではなくて、実行中にJavaのコードを動的に生成して、コンパイルとクラスロードも行うという実装になっています。

 

JEP 480 Structured ConcurrencyとJEP 481 Scoped ValuesはProject LoomでVirtual Threadsと一緒に仕様策定されていたAPIです。

両方とも3rd Previewですが、Java 23でStandardになると予想していたので、外してしまいました😱

JEP 480は複数の非同期タスクの結果を待つような処理を簡単に書けるというAPIです。CompletableFutureクラスを使えば同様の処理は書けるのですが、CompletableFutureクラスの宣言的な書き方ではなくて、手続き的な記述でも使えるよというのがポイントでしょう。

JEP 481はThreadLocalクラスの置き換えになるAPIです。ThreadLocalクラスはいろいろと問題があり、特にVirtual Threadのように多くのスレッドを使うようになるとその問題が顕現しやすくなります。

これを解決するために、JEP 481ではScopedValueクラスを導入しています。

Scoped Valueは4th PreviewがJEPのドラフトに上がっているので、Java 25に間に合うかは微妙なところです。

 

最後のJEP 482 Flexible Constructor Bodiesは、Java 22の時のJEP 447 Statements before super()の名前が変更されたJEPです。

JEP 447ではコンストラクターで、親クラスのsuper()をコールする前に処理を書けるようにしましょうというJEPでした。JEP 482ではこれに加えて、super()をコールする前に子クラスのフィールドの初期化も行えるようにしましょうというJEPになりました。

これはクラスの初期化のスキームの大きな変更なのですが、使う側からするとフィールドを先に初期化したいというニーズはほとんどないはずです。

JEPには書いてないのですが、これはProject ValhallaのVlue Classに関連しているのです。Value Classの露払いとなるJEPなのでした。

 

軽くJEPを説明したところで、本題のAPIの変更について紹介していきましょう。

 

例によって、セキュリティ関連のAPIは省略します。本バージョンでも、java.baseモジュール以外にもAPIの変更はありますが、使用頻度が低いAPIであるため、解説を省略します。

 

廃止になったAPI

Java 23では4つのクラス、5つのメソッドが削除されました。ただし、削除された4つのクラスはjava.managementモジュールのJMXに関するクラスなので、ここでは省略します。

 

メソッド

Java 22でもThreadクラスのメソッドが削除されましたが、Java 23でもスレッド関連のメソッドが削除されてインす。

  • java.lang.Thread.resume()
  • java.lang.Thread.suspend()
  • java.lang.ThreadGroup.resume()
  • java.lang.ThreadGroup.suspend()
  • java.lang.ThreadGroup.stop()

これらのメソッドはJava 14でforRemovalがtrueになっていたので、とうとう削除されたという感じですね(ThreadGroup.stopメソッドだけはJava 16です)。

それ以前からスレッドのresume/suspendは使うべきではないメソッドだったので、ようやくです。

ThreadクラスのforRemovalがtrueのメソッドは残り2つ。1つはstopメソッドですが、ThreadGroupクラスで削除されたので、Threadクラスも近いうちに削除されるような気がします。

もう1つはcheckAccessメソッドですが、こちらもいつ削除されても不思議はない感じ。

 

廃止予定のAPI

Java 23では6つのメソッドと2つのコンストラクタが廃止予定に追加されました。

  • java.io.ObjectOutputStream.PutField.write(ObjectOutput out)
  • java.net.DatagramSocketImpl.getTTL()
  • java.net.DatagramSocketImpl.setTTL(byte ttl)
  • java.net.MulticastSocket.getTTL()
  • java.net.MulticastSocket.setTTL(byte ttl)
  • java.net.MulticastSocket.send(send(DatagramPacket p, byte ttl)

PutFieldクラスのwriteメソッドの代わりは、ObjectOutputStreamクラスのwriteFieldsメソッドです。

DatagramSocketImplクラスとMulticastSocketクラスのTTLに関するメソッドは、TTLではなくTimeToLiveを使うようにします。たとえば、getTTLメソッドではなく、getTimeToLiveメソッドを使用します。

最後のMulticastSocketクラスのsendメソッドは、MulticastSocketクラスの親クラスのDatagramSocketクラスで定義されているsend(DatagramPacket p)メソッドを使用するようにします。TimeToLiveを指定するにはDatagramSocketクラスのsetOptionメソッドを使用します。

 

削除予定のコンストラクタは以下の2つです。

  • java.net.Socket(InetAddress host, int port, boolean stream)
  • java.net.Socket(String host, int port, boolean stream)

このメソッドはDatagramSocketクラスが提供される前に使われていたメソッドなのですが、DatagramSocketクラスを使うようにしましょうということです。

 

なお、java.desktopモジュールのjava.bean.beancontextパッケージもforRemovalがtrueになりました。benacontextパッケージでは18のクラスが定義されていますが、すべてforRemoval=trueになっています。

また、java.desktopモジュールに含まれるSwingのBasicSliderUI()コンストラクタも削除予定に追加されています。

 

追加/変更されたAPI

いつもの通り、Preview JEPに関するAPI変更はここでは省略します。ということで、Class-File APIなどはまた別の機会に。

 

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

JEP 477でjava.io.IOクラスが導入されるのですが(Preview APIなので、ここでは省略します)、そのIOクラスの実装で使わるConsoleクラスに多くのメソッドが追加されました。

 

Consoleクラス

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

  • Console format(Locale locale, String format, Object... args)
  • Console print(Object obj)
  • Console printf(Locale locale, String format, Object... args)
  • Console println(Object obj)
  • Console readLine(Locale locale, String format, Object... args)
  • Console readPassword(Locale locale, String format, Object... args)
  • Console readln(String prompt)

追加されたメソッドの多くは、メソッドをオーバーロードしてLocaleを指定できるようにしたものです。だいたい使い方は分かりますよね。

 

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

Java 22のPreview JEPだったString Templatesがやり直しになったので、StringTemplateクラスは削除されています。また、上述したThreadクラスとThreadGroupクラスのメソッドが削除されています。

また、JEP 481 Scoped ValueのAPIが変更になっていますが、ここでは省略します。

 

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

Java 22でStandard JEPになったFFMですが、メソッドが2つ追加されました。

 

MemorySegmentインタフェース

MemorySegmentインタフェースで定義されるメソッドが1つ追加されました。

  • long maxByteAlignment()

メモリーセグメントの最大アライメントを返すメソッドです。しかし、この値を何らかの処理に使うというよりは、MemoryLayoutインタフェースのbyteAlignmentメソッドで得られる値と比較してメモリーセグメントの最大アライメントの方が小さいときには例外処理をするという使い方になります。

 

SymbolLookupインタフェース

SymbolLookupインタフェースで定義されるメソッドが1つ追加されました。

  • default MemorySegment findOrThrow(String name)

SymbolLookupインタフェースは、基本的にはfindメソッドでライブラリ内のシンボルのアドレスを探索するために使用します。findメソッドの戻り値の型はOptionalクラスで、見つからなかった場合はOptionalオブジェクトでどうにかしていました。

これに対し、Java 23で追加されたfindOrThrowメソッドを使用すると、見つからなかった場合にNoSuchElementException例外をスローします。

個人的にはOptionalクラスで見つからなかった場合に対処する方がいいとは思いますが、お好みで使い分けてください。

 

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

毎度のことですが、新しいリリースを表す定数が追加されています。

 

ClassFileFormatVersion列挙型

Java 23に対応する定数の追加です。

  • ClassFileFormatVersion RELEASE_23

 

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

プリミティブ型の値を他の型に変換する場合に、正確であるかを調べるExactConversionsSupportクラスが追加されました。

 

ExactConversionsSupportクラス

ExactConversionsSupportクラスで定義しているメソッドは以下の21メソッドです。いずれもstaticメソッドになります。

  • static boolean isDoubleToByteExact(double n)
  • static boolean isDoubleToCharExact(double n)
  • static boolean isDoubleToFloatExact(double n)
  • static boolean isDoubleToIntExact(double n)
  • static boolean isDoubleToLongExact(double n)
  • static boolean isDoubleToShortExact(double n)
  • static boolean isFloatToByteExact(float n)
  • static boolean isFloatToCharExact(float n)
  • static boolean isFloatToIntExact(float n)
  • static boolean isFloatToLongExact(float n)
  • static boolean isFloatToShortExact(float n)
  • static boolean isIntToByteExact(int n)
  • static boolean isIntToCharExact(int n)
  • static boolean isIntToFloatExact(int n)
  • static boolean isIntToShortExact(int n)
  • static boolean isLongToByteExact(long n)
  • static boolean isLongToCharExact(long n)
  • static boolean isLongToDoubleExact(long n)
  • static boolean isLongToFloatExact(long n)
  • static boolean isLongToIntExact(long n)
  • static boolean isLongToShortExact(long n)

ExactなConvertって何だろうという感じですが、これはコードを見てみればすぐに意図が分かります。たとえば、isIntToByteExactメソッドの実装を見てみましょう。

    public static boolean isIntToByteExact(int n) {
        return n == (int)(byte)n;
    }

キャストが2つつなげて書いてあります。つまり引数のintの値をbyteにキャストして、その後にintに戻した時に元の値と同じかどうかを調べているわけです。もし、変換の時に情報が欠落するような変換であれば、2回キャストすると元の値と異なってしまうはずです。これが、Exactかどうかということです。

 

動作は分かりましたが、なぜこんなクラスが今になって追加されたのですね。理由は単純でJEP 455 Primitive Types in Patterns, instanceof, and switchのためです。

パターンマッチングでプリミティブ型が使えるようになりましたが、その時に値を正確に変換できるかどうかが重要になるからです。たとえば、下のコードで考えてみましょう。

    int x = ...;
	
    var y = switch (x) {
        case 0 -> "0";
        case byte a -> "Byte " + a;
        case int b -> "Int " + b;
    };

このコードでは、xの値が-128から127であれば、byteのcaseにマッチします。それを超える範囲、たとえば128だとbyteの範囲を超えるので、intのcaseにマッチします。

つまり、正確に変換が行えるのであれば、型が異なっていてもマッチするわけです。この正確な変換ができるかどうかをチェックするためにExactConversionsSupportクラスが使われるのです。

型の変換に関してはJEP 455にも記述があるので、参考にしてみてください。

 

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

Java 22でInet4Address/Inet6Addressクラスのファクトリメソッドが追加されましたが、Java 23ではInet4Addressクラスにファクトリメソッドがさらに追加されました。

 

Inet4Addressクラス

Inet4AddressクラスにアドレスをPosixのリテラルで指定できるファクトリメソッドが追加されました。

  • static Inet4Address ofPosixLiteral(String posixIPAddressLiteral)

ofLiteralメソッドでは10進数でアドレスを表記しますが、ofPosixLiteralメソッドでは8進数や16進数も使用することができます。

 

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

数値をフォーマットするNumberFormatクラスと、そのサブクラスにフォーマットの厳密さを指定するメソッドが追加されました。

 

NumberFormatクラス

NumberFormatクラスのパースはデフォルトでは寛大になっています。これに対し、厳密なパースに関するメソッドが追加されました。

  • boolean isStrict()
  • void setStrict(boolean strict)

NumberFormatクラスでは、これらのメソッドをコールするとUnsupportedOperationException例外がスローされます。

厳密なパース処理は、以下の3種類のサブクラスで使用することができます。

  • ChoiceFormat
  • CompactNumberFormat
  • DecimalFormat

それぞれのクラスのparseメソッドのAPIドキュメントに厳密な場合について記述されているので、参考になさってください。まぁ、それほど使うとは思わないですけどw

 

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

時点を表すInstantメソッドにメソッドが1つオーバーロードされました。

 

Instantクラス

Instantクラスには時間量を調べるuntilメソッドがありましたが、オーバーロードされています。

  • Duration until(Instant endExclusive)

既存のuntilメソッドはもう一方の時点をTemporalオブジェクトで指定し、戻り値はlongで表されます(どの時間量なのかは第2引数で指定します)。

これはちょっと使いにくいので、時点をInstantオブジェクトで表し、戻り値は時間間隔を表すDurationオブジェクトで表されるuntilメソッドのオーバーロードが追加されたわけです。

 

その他

なんとAPIの変更はこれだけなのです。なのですが、他にちょっとだけ気になる変更があったので、それも一緒に紹介しておきます。

 

COMPATロケールプロバイダーの廃止

ロケールプロバイダーってなんだという感じですが、ロケールのデータベースのようなものです。

Javaでは歴史的経緯から3種類のロケールプロバイダーを提供していました。しかし、Java 9からは世界的な標準であるCommon Locale Data Repository (CLDR)がデフォルトになっています。

そして使われなくなった残り2つのロケールプロバイダー(JREとCOMPAT)が削除されることになりました。

Java 21から、JREかCOMPATを使っていると警告が表示されていたのですが、早々に削除されることになりました。

詳しくはJava Bug Systemの JDK-8325568 をご覧ください。

 

標準Docletの変更

DocletというのはJavaのソースコードからJavadocを生成するためのツールです。

JEP 467でJavadocの見直しがあったためなのかどうか分かりませんが、標準Docletが変更されJavadocの見た目が変わりました。

具体的には下図のように左側にサイドバーが出るようになっています。以前のように階層をたどるためのサイドバーではなく、右側に表示しているクラスやインタフェースの目次的なサイドバーになっています。

しかし、これが微妙なんですよね。メソッドの一覧がソートされておらず、書いてある順になっているので探しにくいのです。Method Summaryの表のようにソートされないですかねぇ。

 

というわけで、Java 23のAPI変更について紹介してきました。

Java 23のAPIの変更は少なかったのですが、次のJava 24では大幅にAPIが追加されそうです。

というのも、すでにPreviewではなくなったJEP 484 Class-File APIやJEP 485 Stream Gatheresが提案されているからです。この2つのJEPはまだターゲットリリースが記述されていませんが、Java 24になるのは既定路線でしょう。