2025/04/01

バイトコード入門 その4 バイトコード処理の基礎

Java 24のリリース関連エントリーが続きましたが、再びバイトコード入門に戻ってきました。

今回はJVMスタックに積まれたフレームでどのようにバイトコードを処理するのか紹介していきます。今回は動作を説明するため、個々の命令についての説明は必要最低限とさせていただきます。

  1. 準備編
  2. スタックマシン
  3. バイトコード処理の構成
  4. バイトコード処理の基礎 (今回)

 

バイトコード処理構成のおさらい

まず、バイトコードを処理する構成について簡単におさらいしておきましょう。

バイトコードを実行するために、JVMスタックが使用されるということを前回説明しました。

JVMスタックはスレッドごとに作成されます。ここでのスレッドはOSのスレッドと1対1に対応するPlatform Threadを指しています。Virtual ThreadはPlatform Thread上で動作するので、Virtual Thread用にJVMスタックが作られることはありません。

JVMスタックには、メソッドコールごとにフレームが積まれます。

たとえば、mainメソッドからfooメソッドがコールされ、fooメソッドからbarメソッドがコールされて、barメソッドを処理している場合、JVMスタックにはmainメソッドのフレーム、fooメソッドのフレーム、barメソッドのフレームという3つのフレームが積まれます。

barメソッドの処理が完了し、fooメソッドに戻ってきた時点でbarメソッドのフレームもJVMスタックから取り除かれます。

 

フレームは主にローカル変数用配列と、バイトコード処理中のデータを保持するオペランドスタックから構成されます。

いずれもそのサイズはjavacコンパイル時に決定します。

 

バイトコード処理

今回は動作だけを説明するので、とても簡単なアプリケーションを使用しましょう。

Adderクラスは整数の足し算をするメソッドaddメソッドを持つクラスです。

public class Adder {
    public int add(int x, int y) {
        int z = x + y;
        return z;
    }

    public void static main(String... args) { 
        Adder adder = new Adder();
        int result = adder.add(2, 3);
        System.out.println(result);
    }
}

 

このプログラムが実行されると、メインスレッドに対応するJVMスタックが生成されます。そして、mainメソッドがコールされて、JVMスタックにもmainメソッドに対応するフレームが積まれます。

mainメソッドの中でaddメソッドがコールされると、JVMスタックにもaddメソッドに対応するフレームが積まれます。

この状態を表したのが、以下の図です。

 

では、addメソッド実行の様子を追っていきましょう。

 

addメソッドのバイトコード

Adderクラスをデバッグオプションの-gを使用してコンパイルし、javapでaddメソッドを調べたのが以下です(-gオプションについては、前回を参照してください)。

  private int add(int, int);
    descriptor: (II)I
    flags: (0x0002) ACC_PRIVATE
    Code:
      stack=2, locals=4, args_size=3
         0: iload_1
         1: iload_2
         2: iadd
         3: istore_3
         4: iload_3
         5: ireturn
      LineNumberTable:
        line 3: 0
        line 4: 4
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       6     0  this   LAdder;
            0       6     1     x   I
            0       6     2     y   I
            4       2     3     z   I

ここで使用されているオペコード(命令)を簡単に説明しておきましょう。

  • iload: int型の整数をローカル変数配列からオペランドスタックに積む。_の後の数字はローカル変数配列のインデックス
  • iadd: int型の加算
  • istore: オペランドスタックの先頭にあるint型整数を取り出し、ローカル変数配列に格納。_の後の数字はローカル変数配列のインデックス
  • ireturn: オペランドスタックの先頭にあるint型整数を戻り値としてメソッドを完了させる

この後に実際の動きを説明するので、ここではそんなものぐらいに思っておいてください。

 

addメソッドの動作

では、オペランドスタックとローカル変数配列を含めて、addメソッドの動作を追っていきます。

addメソッドがコールされると、引数がローカル変数配列に格納されます。また、インスタンスメソッドの場合、暗黙の引数としてthisが渡され、それも一緒にローカル変数配列に置かれます。

addメソッドを引数としてx=2, y = 3でコールされた直後の様子は次のようになります。

 

 

ローカル変数配列のインデックス0にthis、1にxの値である2、2にyの値である3が入ります。

上図では分かりやすさのため、ローカル変数配列にx、y、zを記述してありますが、実際にはローカル変数名はコンパイル時に削除され、インデックスだけで扱われます。

ただし、前回説明したようにコンパイル時に-gオプションをつければ、LocalVariableTableが付随し、インデックスと変数名の対応が付けられるようになります。

 

はじめのiload_1はローカル変数配列のインデックス1の値をオペランドスタックに積むということです。iloadのiはint型を表しています。i以外にも接頭辞はありますが、それは次回説明することにします。

この結果、オペランドスタックには2が積まれます。

 

同様に、iload_2でオペランドスタックに3が積まれます。

 

次のiaddはint型の加算です。

ここでは、「バイトコード入門その2」で示したHPの電卓のように、演算に必要な個数だけ値をスタックから取り出し、結果をスタックに積みます。

加算の場合、演算に必要な値は2つなので、オペランドスタックに積まれていた3と2を取り出し、加算をした結果の5をオペランドスタックに積みます。

 

加算の結果はオペランドスタックにしかないので、オペランドスタックから値を取り出し、ローカル変数配列に収めるのが、次の行のistore_3です。

istore_3なので、配列のインデックス3の場所に加算結果の5を格納します。

この操作が、ローカル変数zに5を代入していることに相当します。

 

残りはJavaのコードのreturn z;の部分です。

iload_3で再び5をオペランドスタックに積みます。

 

そして、オペランドスタックに積んだ値を戻り値として、メソッドを完了させるのがireturnです。

ireturnが完了すると、addメソッドに相当するフレームは削除されます。

 

これでaddメソッドが完了しました。

このaddメソッドはとても単純なメソッドですが、オペランドスタックとローカル変数配列の使い方は変わらないので、これが理解できれば後はそれほど難しいことはないはずです。

ちなみに、最後のストアとロードが不要のように見えるかもしれませんが、気にしない方がよいです。

もし、このメソッドが何度もコールされるようであればHotSpot VMによって最適化されます。

javacでコンパイルした時点では最適化はされずに、本当に必要であれば実行時に最適化されるのです。

 

次回はメソッドコールやオブジェクト生成など、もうちょっと複雑なバイトコードを紹介していきます。また、if文やループなども紹介する予定です。

2025/03/18

JEPで語るJava 24

いつもはJEPで語れないだけですが、前回のエントリーで紹介したようにJava 24のAPIの変更はとても少なく、逆にJEPは24もあります。

そこで、今回はJava 24は24のJEPについて簡単に紹介していきます。

反応がよければ、シリーズ化するかも。

前回もリストアップしましたが、Java 24のJEPは以下の通り24になります。

  • 404: Generational Shenandoah (Experimental)
  • 450: Compact Object Headers (Experimental)
  • 472: Prepare to Restrict the Use of JNI
  • 475: Late Barrier Expansion for G1
  • 478: Key Derivation Function API (Preview)
  • 479: Remove the Windows 32-bit x86 Port
  • 483: Ahead-of-Time Class Loading & Linking
  • 484: Class-File API
  • 485: Stream Gatherers
  • 486: Permanently Disable the Security Manager
  • 487: Scoped Values (Fourth Preview)
  • 488: Primitive Types in Patterns, instanceof, and switch (Second Preview)
  • 489: Vector API (Ninth Incubator)
  • 490: ZGC: Remove the Non-Generational Mode
  • 491: Synchronize Virtual Threads without Pinning
  • 492: Flexible Constructor Bodies (Third Preview)
  • 493: Linking Run-Time Images without JMODs
  • 494: Module Import Declarations (Second Preview)
  • 495: Simple Source Files and Instance Main Methods (Fourth Preview)
  • 496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism
  • 497: Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm
  • 498: Warn upon Use of Memory-Access Methods in sun.misc.Unsafe
  • 499: Structured Concurrency (Fourth Preview)
  • 501: Deprecate the 32-bit x86 Port for Removal

JEPで語れないシリーズでもそうですが、セキュリティ関連のJEP (JEP 478, JEP496, JEP 497)はさくらばがよく分かっていないので、省略します。

 

JEP 404 Generational Shenandoah (Experimental)

ShenandoahはRed Hatが中心となって作られているGCです。

Shenandoahはオブジェクトの世代を使用せずにGCを行うアルゴリズムでしたが、ZGCと同様に世代別GCを導入することになったようです。

Experimentalなのですぐに世代別GCを正式に導入するわけではないですが、次の次のLTSには世代別GCが正式になっていると思われます。

後ほど紹介しますが、ZGCは世代別GCだけを残すことになりました。今後、Shenandoahはどうするんでしょうね。

 

さて、世代別GCを使う方法です。

以下の実行時オプションを3つ指定します。

  • -XX:+UnlockExperimentalVMOptions
  • -XX:+UseShenandoahGC
  • -XX:ShenandoahGCMode=generational

ただし、Oracle OpenJDKやOracle JDKはShenandoah GCを含まないので、Red Hat JDKやEclipse Temurinなどを使ってみてください。

 

JEP 450 Compact Object Headers (Experimental)

Javaのオブジェクトはヒープに配置されますが、オブジェクトにはヘッダーがつきます。

オブジェクトヘッダーはJVMの実装依存の部分なのでJVMSには定義されていないのですが、HotSpot VMの場合ヘッダーに128bit使用します。

しかし、小さいクラスだとヘッダーがバカになりません。

たとえば、record Point(int x, int y) {} なんていうクラスだと、データとしては8byte (64bit)しかありません。こうなると、ヘッダーの方が大きくなってしまうわけです。

そこで、現状128bitあるオブジェクトヘッダーを小さくするために立ち上がったのがProject Lilliputです。

Project LeadはAmazonのRoman Kennkeさん。数少ないOracleがリードではないプロジェクトです。

彼はJVMLSでProject Lilliputの講演をしているのですが、Lilliputの背景や概要についてはJVMLS 2023の講演が参考になると思います。

 

ちなみに、プロジェクト名のLilliputですが、ガリバー旅行記の出てくる小人の国のリリパット王国のことです。

なかなかいいプロジェクト名だと思いませんか?

 

Project Lilliputは、64bit VMと32bit VMの両方に対応していますが、ここでは64bit VMについて説明します。

オブジェクトヘッダーには以下のような情報が保持されます。

  • GC Age
  • 型(クラス)
  • ロック
  • ハッシュコード

GC Ageというのは、オブジェクトがGCから生き残ってきた回数を表します。世代別GCの場合、このAgeによってオブジェクトをYoung領域からOld領域に移動させます。

64bit VMではオブジェクトヘッダーが128bitで、上位64bitと下位64bitに分割されて使用されます。

上位64bitはマークワードと呼ばれ、ハッシュコード、GC Age、ロック情報が格納されます。ロック情報は下図のTagビットで表されます。

Mark Word (normal):
 64                     39                              8    3  0
  [.......................HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH.AAAA.TT]
         (Unused)                      (Hash Code)     (GC Age)(Tag)

 

下位64bitはクラスワードと呼ばれ、クラスポインターが格納されます。

Class Word (uncompressed):
64                                                               0
 [cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc]
                          (Class Pointer)

 

これに対し、Project Lilliputでは以下のようにヘッダーを64bitに抑えます。

Header (compact):
64                    42                             11   7   3  0
 [CCCCCCCCCCCCCCCCCCCCCCHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHVVVVAAAASTT]
 (Compressed Class Pointer)       (Hash Code)         /(GC Age)^(Tag)
                              (Valhalla-reserved bits) (Self Forwarded Tag)

 

これが実現されれば、多量のオブジェクトを使うシステムではかなりヒープ使用量が減るはずです。

ただし、ちょっと分からない部分もあります。上図のValhalla-reserved bitsです。

これはValue Class用のビットです。Value Objectはヒープの平坦化がされれば、オブジェクトヘッダーを使用しません。しかし、平坦化されない場合は通常のオブジェクトと同様にヘッダーを使用します。

この場合、通常のオブジェクトとValue Objectを区別するために上記のビットが使われることになると思われます。

Value Classが正式化されるまで、Previewのままなのか、それとも見切り発車で進んでしまうのか、どちらなんでしょうね。

 

Compact Object Headerを使用するには以下の2つの実行時オプションを使用します。

  • -XX:+UnlockExperimentalVMOptions
  • -XX:+UseCompactObjectHeaders

 

472: Prepare to Restrict the Use of JNI
498: Warn upon Use of Memory-Access Methods in sun.misc.Unsafe

最近、OpenJDKではIntegrityがトピックになっています。

Integrityの意味は「誠実さ」とか「正直さ」などです。JavaでIntegrityってよく分からないですよね。

JavaのAPIや機能、ツールなどには黒魔術とも呼べるような安全ではない使い方ができるものがあります。

しかし、安全で堅牢なシステムを作成するにあたっては、このような機能は徐々に取り除いていかないとダメだよねというのが、JEP draft: Integrity by Defaultです。

また、このJEPの背景を語るドキュメントとしてPeaceful and Bright Future of Integrity by Default in Javaがあります。ありがたいことに、このドキュメントは西川さんが翻訳してくれています。

このJEPはまだdraftなので今後どうなるか分からないのですが、Java 24でもIntegrity by Defaultに関連したJEPがあります。それが、JEP 472とJEP 498です。

JEP 472がJNIの使用を制限するJEPで、JEP 498がsun.misc.Unsafeの使用を制限するというJEPです。

特にUnsafeはいろいろと危険なことができてしまっていたのですが、徐々に機能が減らされていって、最後に残っていたのがネイティブメモリへのアクセスだったのです。これに対し、安全にメモリにアクセス可能なFFMが提供されたので、ようやくUnsafeがお役御免となったわけです。まだ、Unsafeを使用すると警告が出るだけですが、だんだんと使えなくなっていくはずです。

 

475: Late Barrier Expansion for G1

G1GCの実装を改善しましょうというJEP。

バリアは何かしらを守るために使用される、同期方法の一種です。たとえば、CPUでメモリ操作の順序性を保証するために使われるメモリバリアなどがあります。

G1GCでもプリライトバリアやポストライトバリアなどのバリアが使われるのですが、そのバリアの処理が重いので、特にJITのC2コンパイラ使用時に改善していきましょうという提案です。

これはStandard JEPで、特に指定しなくてもG1GCを使用時には適用されます。

このJEPに関してThomas Schatzlが解説を書いてくれています。ありがたいことに、西川さんが翻訳してくれています。

 

479: Remove the Windows 32-bit x86 Port
486: Permanently Disable the Security Manager
501: Deprecate the 32-bit x86 Port for Removal

Integrity by Defaultとは関係ないのですが、機能を削除する関連のJEPがJEP 479、JEP 486、JEP 501です。

JEP 479とJEP 501は32bitのx86のポートを削除するJEPで、JEP 486が使わなくなったSecurity Managerを削除するJEPです。

 

483: Ahead-of-Time Class Loading & Linking

Javaは起動時間が遅いとよく言われますが、それを改善するためのプロジェクトがProject Leydenです。

Leydenとはライデン瓶のライデンですね。ライデン瓶は一種のコンデンサーで、導通した時に一気に電気を流せることからプロジェクト名になったんだと思います。あくまでも、櫻庭の予想ですが...

さて、Project LeydenではAOTコンパイラーが提供される予定ですが、その前にJEP 483で事前クラスローディングやリンクを可能とします。

 

Javaの起動時には様々な処理が行われます。その中でも、クラスロードし、クラスの解析、リンク、staticの初期化までの処理はシステムが大規模になればなるほど長い時間を必要とします。また、システムによっては、実行時アノテーションの解決も必要になります。

しかし、これらの処理は毎回同じことを繰り返すだけなので、その部分を事前にやってしまおうというのがJEP 483です。

実際には、トレーニング実行でこれらの処理をキャッシュとして保存しておき、本番時にはキャッシュを使用してシステムを起動します。

キャッシュファイルをapp.aotconfとした場合、以下のようにトレーニング実行、キャッシュファイルの保存という2段階でキャッシュファイルを作成します。

  • トレーニング実行
    $ java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar com.example.App ...
  • キャッシュファイル作成
    $ java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar

2番目のキャッシュファイル作成時にはアプリケーションは実行しません。

キャッシュファイルができたら、それを使用して実行します。

  • 本番実行
    $ java -XX:AOTCache=app.aot -cp app.jar com.example.App ...

 

484: Class-File API

Class-File APIはバイトコード操作のためのAPIです。

クラスファイルを解析したり、バイトコードで記述して直接クラスファイルを生成したりすることができます。

JDKの内部では動的にクラスを生成する場合などにバイトコード操作が行われてきました。この時に使用されていたのが、ASMです。

では、なぜ今になってASMではなくて、自前のバイトコード操作APIを作成することになったのでしょう。

クラスファイルにもバージョンがあり、バージョンが上がるごとに記述できる情報が増えていっています。しかし、サードパーティーのASMだと、最新のバージョンをサポートするまでに時間がかかってしまいまいます。

新しいクラスファイルをすぐにサポートするためには、やはり自前でバイトコード操作APIを作らないとダメということのようです。

 

Class-File APIでは、クラスファイルの読み、書き、改変をサポートしています。また、ストリーミング的な使い方と、イベント的な使い方の両方ができるようになっています。XMLでいうところのSAXとDOMのような使い分けができるはずです。

 

Class-File APIに関しては、今続けているバイトコード入門の続きとして紹介する予定です。

また、JJUGのナイトセミナーで少しだけ紹介したので、参考までに資料を張っておきます。

 

485: Stream Gatherers

Stream APIの中間操作をカスタマイズできるようにするのがStream Gathererです。

Stream Gathererに関しては、すでに解説エントリーを書いているので、そちらを参照してみてください。

 

487: Scoped Values (Fourth Preview)

Project Loomで策定されているAPIの1つであるScoped Valueはスレッド間でイミュータブルなデータを共有するための機能です。

今まで使用してきたThreadLocalはいろいろと問題があるので、それを全部ではないですけど、ある程度置き換えられる機能になっています。

4th PreviewでなかなかStandardにならないですが、次のJava 25でStandardになればいいかなという感じですね。

Java 24では1つだけメソッドが削除されて、一貫性のある使い方に整理されたようです。

 

488: Primitive Types in Patterns, instanceof, and switch (Second Preview)

パターンマッチングにプリミティブ型を使用できるようにしようというのがJEP 488です。

これのおもしろいのが、プリミティブ型の値とのマッチングと、型とのマッチングを同居させることができるところです。たとえば、こういう記述ができます。

switch(x) {
    case 0 -> System.out.println("Zero");
    case 1 -> System.out.println("One");
    case int i when i > 100 -> System.out.println("Big int: " + i);
    case int i -> System.out.println("Small int: " + i);
}

いろいろとルールはあるので、細かいところはJEP 488を読んでみてください。

 

489: Vector API (Ninth Incubator)

Javaでベクター処理を行うためのVector APIですが、Value Classが導入されるまではずっとインキュベータのままということになっています。

 

490: ZGC: Remove the Non-Generational Mode

ZGCはJava 23で世代別ZGCがデフォルトになりましたが、そうそうに元々の非世代別ZGCが削除されることになりました。

世代別と非世代別の両方をサポートするのは大変なのは分かりますが、そこまで急いで削除しなくてもいいのではと思ってしまいます。

 

491: Synchronize Virtual Threads without Pinning

Virtual Threadの使用時にsynchronizedを使うと、Virtual Threadを実行するキャリアスレッドをブロックしてしまうため性能が落ちるという問題がありました。

そのため、Virtual Threadを使う時にはsynchronizedではなく、ReentrantLockを使うようにしましょうというのが今までの解決法でした。

これに対し、synchronizedを使ってもキャリアスレッドをブロックしないようにするのがJEP 491です。

とはいえ、JEP 491が導入されれば、Virtual Threadでもsynchronizedを書き放題と思うのは早計です。

synchnronizedでもReentrantLockでも同期をするためにVirtual Threadをブロックします。キャリアスレッドのブロックよりはいいかもしれませんが、ブロックはブロックです。

Virtual Threadを使うようなスケールでは、些細なブロックでもできれば避けた方が賢明です。

ライブラリやフレームワークでsynchornizedを使用しているため、今までVirtual Threadを使っていても性能が出なかったという場合であればよいのですが、新たにVirtual Threadを使うコードを記述するのであれば、なるべくスレッドを独立にしてブロックしないような設計にするのがよいと思います。

 

492: Flexible Constructor Bodies (Third Preview)

コンストラクター内でスーパークラスや自分自身のコンストラクターをコールするのは、コンストラクターの先頭と決まっていました。

これに対し、フィールドの初期化の後にも書けるようにしたのがJEP 492です。

なぜこんなことが必要なのかというのと、Project Valhallaが関係しています。

Project ValhallaではValue Classの導入と、その効率化のためにNull非許容な型が導入されます。

しかし、コンストラクター内でスーパークラスのコンストラクターを先頭でコールしてしまうと、フィールドが初期化されていない状態でスーパークラスから参照できてしまいます。これはNull非許容の場合だと問題になります。

そのため、Value ClassやNull非許容型が導入される前に、JEP 492で問題となりそうな箇所をつぶしておこうというわけです。

Java 23の3rd Previewからの変更点はないので、Java 25ではStandardになるはずです。

 

493: Linking Run-Time Images without JMODs

JDKの標準ライブラリーはモジュール構成になっており、JARではなくJMODで提供されています。

当然、jlinkでランタイムを作成する場合もJMODがそのまま使われていました。これに対し、モジュールのJARでも可能にするようにしたのがJEP 493です。

 

494: Module Import Declarations (Second Preview)

import文にモジュール単位で記述できるようにするのがJEP 494です。

import module java.base;と書いておけば、java.langパッケージやjava.utilパッケージのクラスやインタフェースのimport文を書かずに済みます。

モジュール間で同じクラス名を使用している場合、明示的に優先的に使用するクラスのimport文を記述します。

たとえば、java.baseとjava.desktopをインポートしてしまうと、java.util.Listとjava.awt.Listなどの同じ名前のクラス/インタフェースをインポートしてしまいます。java.util.Listを優先的に使うのであれば、次のように記述します。

import module java.base;
import module java.base;

import java.util.List;

 

495: Simple Source Files and Instance Main Methods (Fourth Preview)

JEP 495は、mainメソッドの記述を簡素化するためのJEPです。

mainメソッドのためのクラスを書く必要がなくなり、void main() { ... }だけでOKになります。

また、標準出力への出力もSystem.out.println(...);ではなく、println(...);だけでよくなります。

このJEPもなかなかStandardになりませんが、Java 24での変更点はないので、このままJava 25でStandardになると予想されます。

 

499: Structured Concurrency (Fourth Preview)

JEP 499はProject Loomで策定されている仕様の1つです。

複数のスレッドの結果をまとめるためのAPIで、すべての処理結果を待つことや、失敗が1つでもあったら処理を失敗とするなどといったことが簡単に記述できます。

今までであれば、CompletableFutureを使えば同じようなことを記述できるのですが、Thread単体だとちょっと面倒でした。

そこで、Virtual Threadの導入とともにStructured Concurrencyが導入されるはずだったのですが、なかなかStandardにならないまま...

しかし、Java 24での変更はないので、Java 25でStandardになるのではないかと思うのですが、どうでしょう。

 

まとめ

というわけで、セキュリティ関連を除いてJava 24のJEPを簡単に紹介してきました。

最後の方はかなり簡単な紹介だけになってしまいましたが...

PreviewやIncubatorのJEPはStandardになった時に改めて紹介したいと思います。

2025/03/17

JEPでは語れないJava 24

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

Java 24はLTSの1つ前のバージョンだからか、怒涛のJEP祭の様相を呈しています。

なんとJEPが24!!Standard JEPに限っても14もあります。こんなにJEPが多いのはJava 9以来はじめてです!

Java 24のJEPは以下の通り。

  • 404: Generational Shenandoah (Experimental)
  • 450: Compact Object Headers (Experimental)
  • 472: Prepare to Restrict the Use of JNI
  • 475: Late Barrier Expansion for G1
  • 478: Key Derivation Function API (Preview)
  • 479: Remove the Windows 32-bit x86 Port
  • 483: Ahead-of-Time Class Loading & Linking
  • 484: Class-File API
  • 485: Stream Gatherers
  • 486: Permanently Disable the Security Manager
  • 487: Scoped Values (Fourth Preview)
  • 488: Primitive Types in Patterns, instanceof, and switch (Second Preview)
  • 489: Vector API (Ninth Incubator)
  • 490: ZGC: Remove the Non-Generational Mode
  • 491: Synchronize Virtual Threads without Pinning
  • 492: Flexible Constructor Bodies (Third Preview)
  • 493: Linking Run-Time Images without JMODs
  • 494: Module Import Declarations (Second Preview)
  • 495: Simple Source Files and Instance Main Methods (Fourth Preview)
  • 496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism
  • 497: Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm
  • 498: Warn upon Use of Memory-Access Methods in sun.misc.Unsafe
  • 499: Structured Concurrency (Fourth Preview)
  • 501: Deprecate the 32-bit x86 Port for Removal

 

こんなにJEPがあるのですが、なんとAPIの変更はとてもわずかしかないのです。

JEP 484 Class-File APIとJEP 485 Stream GatherersによるAPI追加以外はほとんどありません。

しかたないので、今回に限ってJEPを語るにしてしまいましょう。本エントリーではいつも通りJEPで語らない部分を紹介し、次のエントリーでJEPについて紹介していきます。

なお、java.baseモジュール以外だと、java.desktopモジュールに変更がありますが、変更点が少ないので省略します。また、いつも通り、セキュリティ関連も省略します。

 

廃止になったAPI

Java 24で削除されたAPIは2つだけです。いずれもフィールドです。

フィールド

削除されたフィールドはすでに削除された機能に関連しているフィールドです。

  • java.awt.Window.warningString
  • javax.naming.Context.APPLET

1つ目のWindowクラスのwarningStringはpublicなフィールドではありません。

この文字列はgetWarningString()メソッドで返される文字列でした。セキュリティマネージャで設定されるパーミッションが設定されている場合はnullが返るようになっていたのですが、セキュリティマネージャが廃止されたため、常にnullを返すようになっています。

このため、getWarningString()メソッドで返す文字列が必要なくなったため、削除されました。

 

2つ目のContextクラスのAPPLETは、まぁしかたないですね。APPLETはなくなってしまいましたし。

 

廃止予定に追加されたAPI

Java 24では3つのクラスと2つのメソッドが廃止予定に追加されました。

クラス

  • java.awt.AWTPermission
  • java.util.zip.ZipError
  • javax.sound.sampled.AudioPermission

AWTPermissionクラスとAudioPermissionクラスはWindow.warningStringと同様にセキュリティマネージャが削除されたためです。

ZipError例外はエラー出ないZipExcpeion例外があるので、もはや使われていない例外のため削除予定です。

 

メソッド

  • java.awt.Window.getWarningString()
  • java.swing.JInternalString.getWarningString()

どちらもセキュリティマネージャが削除されたためで、現状はnullを返すだけになっています。

 

追加/変更されたAPI

いつもの通り、Preview JEPに関するAPI変更はここでは省略します。また、セキュリティ関連も省略します。

 

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

JEP 495で導入予定のjava.io.IOクラスに関連してConsoleクラスに2つのメソッドが追加されました。Java 23でもメソッドが追加されていましたが、追加の追加という感じ。

IOクラス自身はプレビューなので、Starndard JEPになったら説明します。まぁ、大したことではないんですけどね。

Consoleクラス

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

  • Console println()
  • Console readln()

printlnメソッドは改行を出力で、readlinメソッドは1行読み込みです。

いずれも引数があるオーバーロードがJava 23で導入されていたので、おまけのような感じ。

とはいっても、Java 23とJava 24で追加されたメソッド群はまだPreviewなので、使うには--enable-previewオプションが必要です。

 

Readerクラス

Readerクラスにファクトリメソッドが追加されました。

Reader/Writerクラスはアブストラクトクラスで、基本的にはデコレーターパターンで機能を付け加えるという使い方をしていました。しかし、ファクトリーメソッドができたということは、今後Readerクラスの使い方が変わるかもしれません。

  • static Reader of(CharSequence cs)

ofメソッドでは、引数で指定したCharSequenceオブジェクトから読み込んでいくReaderオブジェクトを生成します。

動作としては、StringReaderクラスとほぼ同じです。

 

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

Java 24は2024年にリリースされたUnicode 16.0をサポートしました。これに対応して、文字関連のAPIが追加されています。

Charater.UnicodeBlockクラス

Unicode 16.0では新たに絵文字が追加されたり、ヒエログリフが追加されたことが話題になりましたね。

これに応じて、UncodeBlockクラスでは新たに10のブロックに対応する定数が追加されています。

  • static final UnicodeBlock EGYPTIAN_HIEROGLYPHS_EXTENDED_A
  • static final UnicodeBlock GARAY
  • static final UnicodeBlock GURUNG_KHEMA
  • static final UnicodeBlock KIRAT_RAI
  • static final UnicodeBlock MYANMAR_EXTENDED_C
  • static final UnicodeBlock OL_ONAL
  • static final UnicodeBlock SUNUWAR
  • static final UnicodeBlock SYMBOLS_FOR_LEGACY_COMPUTING_SUPPLEMENT
  • static final UnicodeBlock TODHRI
  • static final UnicodeBlock TULU_TIGALARI

 

Charater.UnicodeScript列挙型

UncodeScript列挙型でもUnicode 16.0に対応するため、新たに7つの定数が追加されています。

  • GARAY
  • GURUNG_KHEMA
  • KIRAT_RAI
  • OL_ONAL
  • SUNUWAR
  • TODHRI
  • TULU_TIGALARI

 

Processクラス

メソッドが1つだけオーバーロードされました。

  • boolean waitFor(java.time.Duration duration)

waitForメソッドはプロセスの終了を待つというメソッドです。

Java 23までは引数なしで終了を待つものと、タイムアウトをlongとTimeUnit列挙型で指定する2つのオーバーロードがありました。

Java 24では、これらに加えてタイムアウトをDate & Time APIのDurationクラスで指定するものが加わっています。

 

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

java.lang.classfileパッケージとそのサブパッケージはJEP 484 Class-File APIで使用するパッケージです。

簡単な紹介は次回の「JEPで語る」でしますが、詳細な説明は「バイトコード入門」の続編として書く予定です。

 

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

java.lang.reflectパッケージはいつも通り新しいバージョンに合わせた定数が追加されています。

ClassFileFormatVersion列挙型

いつものように、Java 24に対応する定数が追加されました。

  • RELEASE_24

 

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

JEP 485 Stream Gatherersによって、インタフェースとクラスが追加されています。

Gathererインタフェース

中間操作のためのインタフェースが追加されました。Gathererインタフェースを使うと、終端操作のCollectorインタフェース相当の機能が中間操作で実現できます。

 

Gatherersクラス

Gathererインタフェース用のユーティリティクラスです。

Stream Gathererの使い方は、本ブログの Stream Gatherer 基礎編 を参照してください。

 

Streamインタフェース

StreamインタフェースにはGathererを使うためのメソッドが追加されました。

  • <R> Stream<R> gather(Gatherer<? super T, ?, R> gatherer)

Stream Gathererの使い方は、本ブログの Stream Gatherer 基礎編 を参照してください。

 

おわりに

なんとAPIの変更はこれだけ!!

追加されたAPIとしては、Class-File APIがあるのでむちゃくちゃ多いのですが、それ以外はほんのわずか。Java 24はAPIの変更よりも、次のLTSのために不要な実装を削除するなどの整理が主になっている感じです。

また、プリミティブ型のパターンマッチングなどの文法の変更も次のLTSでStandard JEPになることが予想されます。

 

さて、次のエントリーではJEPに関して簡単な説明を加えていきます。