JEPでは語れないJava 26

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

Java 26はLTSの次のバージョンということで、新機能も少なめ。APIの変更も少ししかありません。まぁ、そんなもんですね。

Java 26のJEPの一覧はこちら。

• 500: Prepare to Make Final Mean Final
• 504: Remove the Applet API
• 516: Ahead-of-Time Object Caching with Any GC
• 517: HTTP/3 for the HTTP Client API
• 522: G1 GC: Improve Throughput by Reducing Synchronization
• 524: PEM Encodings of Cryptographic Objects (Second Preview)
• 525: Structured Concurrency (Sixth Preview)
• 526: Lazy Constants (Second Preview)
• 529: Vector API (Eleventh Incubator)
• 530: Primitive Types in Patterns, instanceof, and switch (Fourth Preview)

 

10のJEPのうち、半分はPreviewとIncubatorです。

Standard JEPでは、JEP 500は予告のようなものでfinalは値の変更をできなくするよというもの。JEP 504はとうとうAppletのAPIが削除されるというもの。

残りの3つのStarndard JEPも、APIの変更はほとんどなし。主にパフォーマンスに関するJEPです。

Standard JEP以外のJEPも、新しいものはありません。そろそろStandard JEPになってもいいんじゃないかなぁというのもありますね。

これらのJEPに関しては、次エントリーで紹介する予定です。

 

さて、JEPで語れない方です。Java 26はAPIの変更も少なめ。

とはいうものの、java.baseモジュール以外の変更もあるので、そちらも紹介します。しかし、いつものごとくセキュリティ関連は省略させてください。

また、今回からバージョンに関する定数の追加についても省略します。

 

廃止になったAPI

Java 26ではJEP 504でアプレットに関するAPIがごそっと削除されました。

パッケージ

• java.applet

java.appletパッケージで定義されていたインタフェース、クラスなども削除されています。

 

クラス

• javax.swing.JApplet

Swingでアプレットを作るときに使われたJAppletクラスも削除です。

 

メソッド

アプレット関連以外にも削除されたメソッドが多いので、注意が必要です。とはいえ、finalize()メソッドなど基本的には使われていないメソッドのはず。

そして、とうとうThread.stop()メソッドも削除されました。

• java.beans.Beans.instantiate(ClassLoader,String,BeanContext,AppletInitializer)
• java.lang.Thread.stop()
• java.net.DatagramSocketImpl.getTTL()
• java.net.DatagramSocketImpl.setTTL(byte)
• java.net.MulticastSocket.getTTL()
• java.net.MulticastSocket.send(DatagramPacket, byte)
• java.net.MulticastSocket.setTTL(byte)
• 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.management.modelmbean.DescriptorSupport.toXMLString()
• javax.swing.RepaintManager.addDirtyRegion(Applet, int, int, int, int)

 

例外

• javax.management.modelmbean.XMLParseException

 

コンストラクター

• javax.management.modelmbean.DescriptorSupport.<init>()

 

廃止予定に追加されたAPI

Java 26でもセキュリティマネージャーの削除に関連して、パーミッション系のクラスがforRemoval=trueになっています。

クラス

• java.net.SocketPermission
• java.sql.SQLPermission

 

メソッド

• java.lang.classfile.Signature.ClassTypeSig.of
• java.net.ServerSocket.setPerformancePreferences
• java.net.Socket.setPerformancePreferences
• java.net.SocketImpl.setPerformancePreferences

 

追加されたAPI

Java 25で大幅に変更されたAPIは少ないのですが、JEP 517のHTTP/3導入にともなってjava.net.httpモジュールに追加があるのが大きなところでしょうか。

また、JDBCにAPIが追加されているのが珍しいですね。

 

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

Java 26ではサポートしているUnicdeのバージョンが17.0になりました。これに伴って、Characterクラス関連で定数が多く追加されています。

 

Character.UnicodeBlockクラス

Unicodeのブロックが追加されたことに対応して、定数が追加されています。

• BERIA_ERFE
• CJK_UNIFIED_IDEOGRAPHS_EXTENSION_J
• MISCELLANEOUS_SYMBOLS_SUPPLEMENT
• SHARADA_SUPPLEMENT
• SIDETIC
• TAI_YO
• TANGUT_COMPONENTS_SUPPLEMENT
• TOLONG_SIKI

 

Character.UnicodeScript列挙型

同様にスクリプトも追加されているので、対応する定数が追加されています。

• BERIA_ERFE
• SIDETIC
• TAI_YO
• TOLONG_SIKI

 

Processクラス

外部のプログラム実行に使用されているProcessクラスですが、Closeable/AutoCloseableインタフェースを実装するようになりました。

これでやっとtry-with-resources構文で使えるようになりました。

• close()

 

Stringクラス

Unicodeのケースフォールディングに対応した比較メソッドが追加されています。

ケースフォールディングでは、アルファベットの大文字、小文字を区別しないだけでなく、ドイツ語のßとssなどを区別しません。

Latin-1の文字であればequalsFoldCase()メソッドとequalsIgnoreCase()メソッドは同じ結果を返しますが、Latin-1以外の文字で結果が異なる場合があるということですね。

定数のUNICODE_CASEFOLD_ORDERはケースフォールドに対応したComparator<String>オブジェクトです。

 

• int compareToFoldCase(String)
• boolean equalsFoldCase(String)
• Comparator<String> UNICODE_CASEFOLD_ORDER

ケースフォールディングで比較するequalsFoldCaseメソッドを試してみましょう。

jshell>  "Hello, World!".equalsIgnoreCase("hello, world!")
$1 ==> true

jshell> "Hello, World!".equalsFoldCase("hello, world!")
$2 ==> true

jshell>  "ß".equalsIgnoreCase("ss")
$1 ==> false

jshell> "ß".equalsFoldCase("ss")
$2 ==> true

jshell> 

このほかにも、フランス語のŒとœなどがあります。ケースフォールディングの一覧は以下のリンクから。

CaseFoling.txt

 

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

BigIntegerクラスに演算メソッドが追加されています。

BigIntegerクラス

n乗根に関するメソッドが2つ追加されました。

• BigInteger rootn(int)
• BigInteger[] rootnAndRemainder(int)

rootn()メソッドはn乗根を求めるためのメソッドです。引数が2の場合はsqrt()メソッドと等価になります。

rootnAndRemainder()メソッドはn乗根と、自分自身とn乗根をn乗した数との差を配列で返すメソッドです。n乗根がrだとすると、rとthis - r**nが配列になります。こちらも、引数が2の場合はsqrtAndRemainder()メソッドと等価です。

 

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

クラスから列挙型に変更されるケースを初めて見たのですが、以前にもあったのでしょうか？

ByteOrder列挙型

ByteOrderはJava 25まではクラスだったのですが、列挙型に変更されました。これに伴い、定数の宣言が変更され、列挙型のメソッドが追加されています。

もともと、ByteOrderクラスの定数LITTLE_ENDIANとBIG_ENDIANの型はByteOrderクラスだったので、列挙型に変更してもプログラムを変更する必要はないはずです。

• static ByteOrder valueOf(String)
• static ByteOrder[] values()

 

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

時間間隔を表すDurationクラスに定数が追加されました。また、Instantクラスにもメソッドが追加されています。

 

Durationクラス

Durationクラスで保持できる最大時間間隔と最小時間間隔を表す定数が追加されています。なお、Durationクラスでは負の時間間隔も表せるので、最小となるのは負の値です。

• Duration MAX
• Duration MIN

MAXはLong.MAX_VALUEに999,999,999ナノ秒を加えた値で作成する時間間隔になります。MINの方はLong.MIN_VALUEで作成する時間間隔です。

 

Instantクラス

Instantクラスは時点を表すためのクラスです。これまで、自分自身の時点に指定された時間間隔を追加するメソッドとしてplusメソッドが使われてきました。これに対し、時間間隔を追加した結果が、InstantクラスのMAX、MINを超えてしまう場合、MAXとMINを返すplusSaturatingメソッドが追加されています。

• Instant plusSaturation(Duration)

 

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

なぜ今さらという感じですが、Comparatorインタフェースにメソッドが2つ追加されました。

また、JEP 526 Lazy Constantに関連して、ListインタフェースとMapインタフェースにメソッドが追加されるのですが、これはpreviewなので、正式になった時に紹介します。

 

Comparatorインターフェス

2つの引数の大きい方/小さい方を返すmax()メソッド、min()メソッドが追加されました。

• <U extends T> U max(U, U)
• <U extends T> U min(U, U)

どういう時にこれらのメソッドを使うのか、イマイチ分からないんですよね。

 

java.desktop/java.awtパッケージ

AWTにメソッドが追加なんていつ以来でしょうか？とはいっても、GUIの機能を追加するのではなく、GUIのテストなどに使用するRobotクラスに簡易的なメソッドが追加されただけでした。

 

Robotクラス

Robotクラスは基本的な機能は追加されていないのですが、今までマウスのクリックでもmousePress()メソッドとmouseRelease()メソッドが分かれているなど、ちょっと使いにくい部分がありました。そこで、これらをもう少し分かりやすい形式でコールできるようになるためのメソッドが8種類追加されています。

• void click()
• void click(int)
• void glide(int,int)
• void glide(int,int,int,int)
• void glide(int,int,int,int,int,int)
• void type(int)
• void type(char)
• void waitForIdle(int)
• int DEFAULT_DELAY
• int DEFAULT_STEP_LENGTH

たとえば、click()メソッドは、mousePress()メソッド、waitForIdle()メソッド、mouseRelease()メソッド、waitFor()メソッドの4つのメソッドを順にコールしたものと同じ動作をします。

他のメソッドも、すでに存在するメソッドを組み合わせて簡単に呼べるようにしたというものです。

また、2つの定数は、たとえばclick()メソッドの内部でコールされるwaitForIdle()メソッドの初期値を表しているように、今回追加されたメソッドで使用する定数となっています。

 

java.management/javax.lang.managementパッケージ

MXBeanにメソッドが追加されました。

本来はMXBeanのインタフェースに抽象メソッドを追加したいところですが、後から追加ができないのでdefaultメソッド。default目祖度では意味のない値を返しているので、オーバーライド前提なのですが、本来であればインタフェースの変更したいところですね。

 

MemoryMXBeanインタフェース

GCのCPU時間を取得するためのメソッドが追加されました。

• long getTotalGcCpuTime()

defaultメソッドでの実装は-1を返します。つまり、MemoryMXBeanインタフェースを実装するクラスが正しく実装しないと使えないメソッドになっています。まぁ、標準ライブラリなので、実装を忘れることはないでしょうけど。

 

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

JEP 517でHTTP/3がサポートされることになって、いろいろと変わっています。しかし、プロトコルが変わるだけなので、大きな使い方の変更はないです。

これについては、次のエントリーのJEPで語る方で紹介します。

 

java.sql/java.sqlパッケージ

JDBCのバージョンが4.3から4.5にアップしました。

一番の違いは、AutoCloseableに対応したことです。

 

Arrayインタフェース、Blobインタフェース、Clobインタフェース、SQLXMLインタフェース

これらの4つのインタフェースがすべてAutoCloseableインタフェースを実装するようになりました。これで、try-with-resources構文で使用することが可能です。

• void close()

 

Connectionインタフェース

あまりJDBCを使うことがないので、よく分からないのですが、なぜか今ごろになってリテラルなどをクォーテーションするメソッドが追加されました。

• String enquoteIdentifier(String,boolean)
• String enquoteLiteral(String)
• String enquoteNCharLiteral(String)
• boolean isSimpleIdentifier(String)

 

JDBCType列挙型、Typesクラス

いずれも定数が2種類増えています。

• DECFLOAT
• JSON

 

まとめ

LTSの次のバージョンということで変更点は少ないものの、AWTやJDBCなど今まで変更の少なかったAPIに変更があったのは珍しいですね。

また、HTTP/3への変更もありますが、こちらは使い方はほとんど変わらないので、APIの変更も少なめです。これに関しては次のエントリーで紹介します。

 

さて、次のエントリーではJEPに関して簡単な説明を加えていく予定ですが... 今、さくらばは3月17日から開催されるJavaOneに参加するため、アメリカに滞在しています。そのため、JEPで語る方はJavaOneの後になりそうな予感が...

まぁ、のんびり待っていてください。

レコードクラスの中身

本エントリーはJava Advent Calendar 2025の最終日です！ 昨日は@zoosm3さんのDBFluteの複数DBをSpring Bootで実装する 開発のヒント でした。

 

24日に会社ブログでレコードクラスについて書きました。けっこうまじめに書いたので、ぜひ読んでみてください！

[Java] 今から始めるレコードクラス
https://bsblog.casareal.co.jp/archives/13817

レコードクラスの書き方や使い方については書きましたけど、じゃあレコードクラスって実際にはどういうバイトコードになっているの？？というのが本エントリーです。

レコードクラスは簡単な記述で済んでいるのですが、コンパイルするとアクセッサーメソッドやequalsメソッドが自動生成されますとよく書かれていますが(会社ブログでもそう書きました)、実際のところどうなっているのというのを紹介していきます。

 

とりあえず、逆コンパイル

では、レコードクラスのバイトコードがどうなっているのか、さっそく調べてみましょう。題材にするのは、よく出てくる座標を表すPointレコードクラスです。

 

public record Point(double x, double y) {}

 

このクラスをコンパイルした後に、javapで逆コンパイルします。

 

> javac -g Point.java
> javap -p -v Point
Classfile /C:/temp/Point.class
  Last modified 2025/12/21; size 1348 bytes
  SHA-256 checksum 4bcbbc4b22a7b6c6fb72067dba973f9f08f80def796ecca1173c7c3b6596bda4
    Compiled from "Point.java"
public final class Point extends java.lang.Record
     ... 以下、略

 

javapのオプションの-pはprivateも逆コンパイルするというオプションで、-vは詳細情報を出力するオプションです。

この後にコンスタントプールが続くのですが、とりあえず重要なところで

 

public final class Point extends java.lang.Record

 

レコードクラスは継承ができないのですが、この行が理由です。

まず、java.lang.Recordクラスのサブクラスになるということ。そして、finalクラスだということです。

Recordクラスは以下の3種類の抽象メソッドを定義しています。

• equals
• hashCode
• toString

もちろん、この3つのメソッドはObjectクラスで具象メソッドとして定義されているのですが、Recordクラスではそれらを抽象クラスとしてオーバーライドしています。

つまり、Ojbectクラスの実装は使わないということですね。

しかし、recordキーワードで定義されるレコードクラスは、これらのメソッドを定義する必要がありません。これらのメソッドがコンパイル時に自動生成されるというのが、このことからも分かります。

 

レコードコンポーネント

javapでは、クラス定義の後にコンスタントプールを出力します。コンスタントプールは必要に応じて参照すればよいので、その後に続く部分を見てみましょう。

通常のクラスであればフィールドの定義が続きます。レコードクラスではどうでしょう？

 

  private final double x;
    descriptor: D
    flags: (0x0012) ACC_PRIVATE, ACC_FINAL

  private final double y;
    descriptor: D
    flags: (0x0012) ACC_PRIVATE, ACC_FINAL

 

名前だけはレコードコンポーネントになりましたが、実質的にはインスタンスフィールドと同じでした。まぁ、想像通りですね。

イミュータブルなので、finalで宣言されているところが注目すべき点です。

 

コンストラクター

レコードクラスではカノニカルコンストラクターが自動的に生成されます。と言われても、カノニカルって何？という感じですよね。

カノニカル(Canonical)は「正規の」とか「標準的な」などの意味の単語です。このため、カノニカルコンストラクターを標準コンストラクターと記述しているドキュメントもあります。でも、標準と書かれるとStandardの方をイメージしてしまうんですよね。

ネイティブの人たちはCanonicalとStandardのニュアンスの違いを分かっているのでしょうが、私には理解できないのです...

 

それはそれとして、カノニカルコンストラクターはすべてのレコードコンポーネントを初期化するためのコンストラクターです。

では、Pointレコードクラスのカノニカルコンストラクターを見てみましょう。

 

  public Point(double, double);
    descriptor: (DD)V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=3, locals=5, args_size=3
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Record."<init>":()V
         4: aload_0
         5: dload_1
         6: putfield      #7                  // Field x:D
         9: aload_0
        10: dload_3
        11: putfield      #13                 // Field y:D
        14: return
      LineNumberTable:
        line 1: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0      15     0  this   LPoint;
            0      15     1     x   D
            0      15     3     y   D
    MethodParameters:
      Name                           Flags
      x
      y

 

カノニカルコンストラクターの引数は、レコードクラスの定義におけるレコードコンポーネントの並びに対応しています。

Pointレコードクラスの場合、両方ともdoubleなので区別しにくいですが、第1引数がx、第2引数がyです。

 

一般的にコンストラクターのバイトコードでは、まずスーパークラスのデフォルトコンストラクターをコールします。それが0行目と1行目のinvokespecialです(行と書いていますが、実際にバイト数のことです。あしからず)。

4行目のaloadからがレコードコンポーネントの初期化になります。6行目のputfieldで引数のxの値をフィールドにセットしています。

同様に、11行目のputfieldで引数のyの値をフィールドにセットしています。

単純に引数の値をフィールド(レコードコンポーネント)に代入しているだけですね。

 

カノニカルコンストラクターは独自に定義することもできるのですが、それについては後述します。

 

アクセッサーメソッド

レコードクラスではレコードコンポーネントと同名のメソッドが生成され、レコードコンポーネントの値を取得できます。

まぁ、名前は違うもののgetterメソッドと同じですね。Pointレコードクラスのx()メソッドのバイトコードは以下のようになっていました。

 

  public double x();
    descriptor: ()D
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=2, locals=1, args_size=1
         0: aload_0
         1: getfield      #7                  // Field x:D
         4: dreturn
      LineNumberTable:
        line 1: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       5     0  this   LPoint;

 

getfieldでフィールド(レコードコンポーネント)の値をスタックに積んで、dreturn (doubleのretuen)で返り値にしています。

y()メソッドも同様です。

 

他の自動生成されたメソッド

ここまでは、まぁ予想通りのバイトコードでした。

レコードクラスではカノニカルコンストラクターとアクセッサーメソッド以外に、次のメソッドを自動生成します。

• equals
• hashCode
• toString

ここではequals()メソッドのバイトコードを見てみましょう。

equals()メソッドの書き方としては、Effective Javaが詳しいですね。Effective Javaの書き方と比べてどうなっているでしょう？

 

  public final boolean equals(java.lang.Object);
    descriptor: (Ljava/lang/Object;)Z
    flags: (0x0011) ACC_PUBLIC, ACC_FINAL
    Code:
      stack=2, locals=2, args_size=2
         0: aload_0
         1: aload_1
         2: invokedynamic #24,  0             // InvokeDynamic #0:equals:(LPoint;Ljava/lang/Object;)Z
         7: ireturn
      LineNumberTable:
        line 1: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       8     0  this   LPoint;
            0       8     1     o   Ljava/lang/Object;

 

なんか全然違う！！

おもしろいのは、invokedynamic (indy)を使っているところです。つまり、equals()メソッドは初回実行時に動的に作られるということですね。

このindyの初回実行時にコールされるのが、ブートストラップと呼ばれるメソッドです。ブートストラップメソッドはクラスファイルの最後の方にあるBootstrapMethods:の箇所に記述されています。

 

BootstrapMethods:
  0: #49 REF_invokeStatic java/lang/runtime/ObjectMethods.bootstrap:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/TypeDescriptor;Ljava/lang/Class;Ljava/lang/String;[Ljava/lang/invoke/MethodHandle;)Ljava/lang/Object;
    Method arguments:
      #8 Point
      #45 x;y
      #47 REF_getField Point.x:D
      #48 REF_getField Point.y:D

 

これを見ると、ブートストラップとして使われるのは、java.lang.runtime.ObjectMethodsクラスのbootstrap()メソッドだということです。実をいうと、equals()メソッドだけでなく、hashCode()メソッドもtoString()メソッドも同じブートストラップメソッドが使われています。

このObjectMethodsクラスはpublicなクラスなので、APIドキュメントが公開されています。Java 24であれば、以下のリンクから参照できます。

ObjectMethodsクラス
https://docs.oracle.com/javase/jp/24/docs/api/java.base/java/lang/runtime/ObjectMethods.html

ちょっとおもしろいのが、bootstrap()メソッドの最後の引数にアクセッサーメソッドのMethodHandleが使われているところですね。

 

では、ObjectMethodsクラスのbootstrap()メソッドを調べてみましょう。ソースは以下のリンクにあります。

ObjectMethods
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/runtime/ObjectMethods.java

以下にObjectMethodsクラスのbootstrap()メソッドのソースを示します。

 

    public static Object bootstrap(MethodHandles.Lookup lookup, String methodName, TypeDescriptor type,
                                   Class<?> recordClass,
                                   String names,
                                   MethodHandle... getters) throws Throwable {

            <<省略>>
    
        List<MethodHandle> getterList = List.of(getters);
    
        MethodHandle handle = switch (methodName) {
            case "equals"   -> {
                if (methodType != null && !methodType.equals(MethodType.methodType(boolean.class, recordClass, Object.class)))
                    throw new IllegalArgumentException("Bad method type: " + methodType);

                yield makeEquals(lookup, recordClass, getterList);
            }

              <<省略>>
        };
 
        return methodType != null ? new ConstantCallSite(handle) : handle;
    }

 

メソッド名が"equals"であれば、makeEquals()メソッドをコールしています。

makeEquals()メソッドはClassfile APIでバイトコードを操作しています。ASMの頃に比べると、Classfile APIになって格段に読みやすくなりましたね。

ちょっと長いのですが、makeEquals()メソッドを以下に示しておきます。

 

    private static MethodHandle makeEquals(MethodHandles.Lookup lookup, Class<?> receiverClass,
                                           List<MethodHandle> getters) throws Throwable {
        MethodType rr = MethodType.methodType(boolean.class, receiverClass, receiverClass);
        MethodType ro = MethodType.methodType(boolean.class, receiverClass, Object.class);
        MethodHandle instanceFalse = MethodHandles.dropArguments(FALSE, 0, receiverClass, Object.class); // (RO)Z
        MethodHandle instanceTrue = MethodHandles.dropArguments(TRUE, 0, receiverClass, Object.class); // (RO)Z
        MethodHandle isSameObject = OBJECT_EQ.asType(ro); // (RO)Z
        MethodHandle isInstance = MethodHandles.dropArguments(CLASS_IS_INSTANCE.bindTo(receiverClass), 0, receiverClass); // (RO)Z
        MethodHandle accumulator = MethodHandles.dropArguments(TRUE, 0, receiverClass, receiverClass); // (RR)Z

        int size = getters.size();
        MethodHandle[] equalators = new MethodHandle[size];
        boolean hasPolymorphism = false;
        for (int i = 0; i < size; i++) {
            var getter = getters.get(i);
            var type = getter.type().returnType();
            if (isMonomorphic(type)) {
                equalators[i] = equalator(lookup, type);
            } else {
                hasPolymorphism = true;
            }
        }

        // Currently, hotspot does not support polymorphic inlining.
        // As a result, if we have a MethodHandle to Object.equals,
        // it does not enjoy separate profiles like individual invokevirtuals,
        // and we must spin bytecode to accomplish separate profiling.
        if (hasPolymorphism) {
            String[] names = new String[size];

            var classFileContext = ClassFile.of(ClassFile.ClassHierarchyResolverOption.of(ClassHierarchyResolver.ofClassLoading(lookup)));
            var bytes = classFileContext.build(ClassDesc.of(specializerClassName(lookup.lookupClass(), "Equalator")), clb -> {
                for (int i = 0; i < size; i++) {
                    if (equalators[i] == null) {
                        var name = "equalator".concat(Integer.toString(i));
                        names[i] = name;
                        var type = getters.get(i).type().returnType();
                        boolean isInterface = type.isInterface();
                        var typeDesc = type.describeConstable().orElseThrow();
                        clb.withMethodBody(name, MethodTypeDesc.of(CD_boolean, typeDesc, typeDesc), ACC_STATIC, cob -> {
                            var nonNullPath = cob.newLabel();
                            var fail = cob.newLabel();
                            cob.aload(0)
                               .ifnonnull(nonNullPath)
                               .aload(1)
                               .ifnonnull(fail)
                               .iconst_1() // arg0 null, arg1 null
                               .ireturn()
                               .labelBinding(fail)
                               .iconst_0() // arg0 null, arg1 non-null
                               .ireturn()
                               .labelBinding(nonNullPath)
                               .aload(0) // arg0.equals(arg1) - bytecode subject to customized profiling
                               .aload(1)
                               .invoke(isInterface ? Opcode.INVOKEINTERFACE : Opcode.INVOKEVIRTUAL, typeDesc, "equals", MTD_OBJECT_BOOLEAN, isInterface)
                               .ireturn();
                        });
                    }
                }
            });

            var specializerLookup = lookup.defineHiddenClass(bytes, true, MethodHandles.Lookup.ClassOption.STRONG);

            for (int i = 0; i < size; i++) {
                if (equalators[i] == null) {
                    var type = getters.get(i).type().returnType();
                    equalators[i] = specializerLookup.findStatic(specializerLookup.lookupClass(), names[i], MethodType.methodType(boolean.class, type, type));
                }
            }
        }

        for (int i = 0; i < size; i++) {
            var getter = getters.get(i);
            MethodHandle equalator = equalators[i]; // (TT)Z
            MethodHandle thisFieldEqual = MethodHandles.filterArguments(equalator, 0, getter, getter); // (RR)Z
            accumulator = MethodHandles.guardWithTest(thisFieldEqual, accumulator, instanceFalse.asType(rr));
        }

        return MethodHandles.guardWithTest(isSameObject,
                                           instanceTrue,
                                           MethodHandles.guardWithTest(isInstance, accumulator.asType(ro), instanceFalse));
    }

 

簡単にいうと、まずレコードコンポーネントごとにその型に応じたequals()メソッドを探します。次に、レコードコンポーネントごとにequals()メソッドをコールするメソッドを持つクラスを動的に作成して、そのメソッドのMethodHandleを作っています。

なかなかおもしろいですね。

 

Classfile APIのビルド系のメソッドはバイトコードと対応したメソッド名になっているので、バイトコードを読めればだいたい分かるはずです。

 

というわけで、equals()メソッド、hashCode()メソッド、toString()メソッドは中身が動的に作成されるのでした。

 

カノニカルコンストラクター再び

最後に、もう一度カノニカルコンストラクターについて。

前述したカノニカルコンストラクターは自動生成されたものでしたが、カノニカルコンストラクターは自分で書くこともできます。

たとえば、範囲を示すRangeレコードクラスで下限が上限を超える場合IllegalArgumentException例外をスローするようなカノニカルコンストラクターを記述してみます。

 

public record Range(double min, double max) {
    public Range {
        if (min > max) {
            throw new IllegalArgumentException();
        }
    }
}

 

カノニカルコンストラクターは引数がレコードコンポーネントの宣言部分と同じなので省略した書き方になります。

そして、コンパイルした後のバイトコードが以下になります。

 

  public Range(double, double);
    descriptor: (DD)V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=4, locals=5, args_size=3
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Record."<init>":()V
         4: dload_1
         5: dload_3
         6: dcmpl
         7: ifle          18
        10: new           #7                  // class java/lang/IllegalArgumentException
        13: dup
        14: invokespecial #9                  // Method java/lang/IllegalArgumentException."<init>":()V
        17: athrow
        18: aload_0
        19: dload_1
        20: putfield      #10                 // Field min:D
        23: aload_0
        24: dload_3
        25: putfield      #16                 // Field max:D
        28: return
      LineNumberTable:
        line 2: 0
        line 3: 4
        line 4: 10
        line 2: 18
        line 6: 28
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0      29     0  this   LRange;
            0      29     1   min   D
            0      29     3   max   D
      StackMapTable: number_of_entries = 1
        frame_type = 255 /* full_frame */
          offset_delta = 18
          locals = [ class Range, double, double ]
          stack = []
    MethodParameters:
      Name                           Flags
      min                            mandated
      max                            mandated

 

前半にminとmaxの比較を行って、minが大きければ例外をスローする処理が記述されています。18行目からコンストラクターの引数をフィールド(レコードコンポーネント)に代入する処理です。

フィールドに代入する処理から行われると思っていたら、それは最後なんですね。ちょっと意外でした。

 

まとめ

レコードクラスはデータを扱うのに便利なクラスですが、その中身がどうなっているのかを紹介しました。

 

まとめてみると

• レコードクラスはRecordクラスのサブクラスでfinalクラス
• レコードコンポーネントはfinalなインスタンスフィールド
• カノニカルコンストラクターが生成される
• アクセッサーメソッドはgetter相当
• equals(), hashCode(), toString()は実行時に動的に作成
• カノニカルコンストラクターでフィールドへの代入は最後

 

レコードクラス自体は単純ですが、その裏側はなかなかおもしろかったですね。

OpenJDKのソースを読むのはたいへんですが、このぐらいの小さいところから読み始めるというのはいいかもしれません。

Lazy Constant 実装編

本エントリーはJava Advent Calendar 2025の6日目です。

 

一昨日はLazy Constantの使い方を紹介したので、今日はLazy Constantがどうやって実装されているかを紹介していきます。

 

Lazy Constant
https://www.javainthebox.com/2025/12/lazy-constant.html

 

シングルトン

いきなりシングルトンと言われても... という感じだとは思いますが、Lazy Constantの実装を紐解く前に、シングルトンについて考えてみます。

シングルトンはデザインパターンの1つで、インスタンスを1つに制限するためのパターンです。

シングルトンは一種の大域変数になってしまうので、使いすぎるのはよくないですし、最近はほとんど使われなくなったように思います。でも、その実装はLazy Constantにつながるのです。

そもそもシングルトンの実装ってどうなっていたか覚えていらっしゃいますでしょうか？

 

シンプルなシングルトン

まずはシンプルなシングルトンの実装です。

シングルトンは自身のインスタンスをstaticフィールドで1つ保持します。そして、インスタンスを取得するメソッドが初めてコールされた時に、インスタンスを生成します。インスタンスが存在すれば、それを返します。つまり、遅延初期化なのです。

 

public class Singleton {
    private static Singleton instance;

    private Singleton() {}

    public static Singleton get() {
        if (instance == null) {
            instance = new Singleton();
        }

        return instance;
    }
}

 

インスタンスを勝手に作られないように、コンストラクターはprivateで宣言します。

getメソッド(getInstanceメソッドのことも多いですが、ここではgetメソッドにします)では、staticフィールドのinstanceがnullだったら、つまり初期化されていなければSingletonインスタンスを生成します。そして、そのinstanceを返します。

シングルトンにデータを持たせるのであれば、それなりにフィールドなどを定義しますが、インスタンスを1つに限定させるための実装としてはこれでOKです。

しかも、実際にシングルトンのインスタンスを実際に使う時まで、その初期化を遅らせることができます。

しかし、問題もあります。この実装はスレッドセーフではないという点です。シングルスレッドであればいいのですが、マルチスレッドでは使えません。

 

スレッドセーフなシングルトン

スレッドセーフにするにはどうすればよいでしょう？

もっとも単純なのは、getメソッドをsynchronizedにするという方法です。

 

public class Singleton {
    private static Singleton instance;

    private Singleton() {}

    public synchronized static Singleton get() {
        if (instance == null) {
            instance = new Singleton();
        }

        return instance;
    }
}

 

これでマルチスレッドでも動作します。

問題はスケールしないということです。スレッド数が2, 3であればよいのですが、スレッド数が増えるととたんにロック待ちで渋滞してしまいます。

instanceフィールドは初期化した後は参照されるだけなので、本来であれば同期化は必要ありません。問題は未初期化の状態時に複数スレッドからgetメソッドをコールされる場合です。

 

そこで、getメソッドのインスタンス生成のところだけ同期化することを考えてみます。

 

    public static Singleton get() {
        if (instance == null) {
            // NG これはダメな実装
            synchronized(instance) {
                instance = new Singleton();
            }
        }

        return instance;
    }
}

 

しかし、これではダメなのです。

CPUの効率化のために命令を入れ替えたり、キャッシュにinstanceの値が残っていることもあるので、instanceを初期化しているときに複数のスレッドからアクセスされてしまうことがあります。

そこで、出てくるのがダブルチェックロックという方法です。でも、単にダブルチェックロックだけでは、キャッシュ上のinstanceとメモリのinstanceが同期化されているか保証されません。

そこで、instanceフィールドをアトミックに処理されるようにします。

厳密にやるのであればjava.util.concurrent.atomic.AtomicReferenceクラスを使用しますが、volatileでも大丈夫です。

最終的には次のようになります。

 

public class Singleton {
    // volatileで宣言することによりアトミック性を保証する
    private static volatile Singleton instance;

    private Singleton() {}

    public static Singleton get() {
        if (instance == null) {
            synchronized (Singleton.class) {
                // ダブルチェック
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }

        return instance;
    }
}

 

これでマルチスレッドでスケールするスレッドセーフなシングルトンになります。

 

Lazy Constant

シングルトンが理解できたとして、Lazy Constantの実装です。

java.lang.LazyConstantはインタフェースなので、実際の遅延初期化の部分は実装されていません。どこで実装されているかというと、LazyConstantインタフェースのstaticメソッドのofメソッドを見れば分かります。

 

    static <T> LazyConstant<T> of(Supplier<? extends T> computingFunction) {
        Objects.requireNonNull(computingFunction);
        if (computingFunction instanceof LazyConstant<? extends T> lc) {
            return (LazyConstant<T>) lc;
        }
        return LazyConstantImpl.ofLazy(computingFunction);
    }

 

return文のところを見ると、LazyConstantImplクラスというのがあることがわかります。これがLazyConstantインタフェースを実装したコンクリートクラスです。パッケージはjdk.internal.langパッケージで、公開されていないクラスだということが分かります。

 

では、遅延初期化を行うgetメソッドを見る前に、クラスの宣言と関連するフィールド、そしてofLazyメソッドを見ておきましょう。この他にもフィールドありますが、関連するところだけ。

 

@AOTSafeClassInitializer
public final class LazyConstantImpl<T> implements LazyConstant<T> {

    @Stable
    private T constant;

    @Stable
    private volatile Supplier<? extends T> computingFunction;

    private LazyConstantImpl(Supplier<? extends T> computingFunction) {
        this.computingFunction = computingFunction;
    }

    public static <T> LazyConstantImpl<T> ofLazy(Supplier<? extends T> computingFunction) {
        return new LazyConstantImpl<>(computingFunction);
    }

 

見慣れないアノテーションが使われていますが、Leyden関連や最適化のヒントになるアノテーションです。

ここで注目しておいていただきたいのが、値を保持するconstantフィールドがvolatileではないということです。そして、ofメソッドの引数のラムダ式はcomputingFunctionフィールドで保持しています。

 

では、保持している値を返すgetメソッドを見ていきましょう。

 

    @ForceInline
    @Override
    public T get() {
        final T t = getAcquire();
        return (t != null) ? t : getSlowPath();
    }

    private T getSlowPath() {
        preventReentry();
        synchronized (this) {
            T t = getAcquire();
            if (t == null) {
                t = computingFunction.get();
                Objects.requireNonNull(t);
                setRelease(t);
                // Allow the underlying supplier to be collected after successful use
                computingFunction = null;
            }
            return t;
        }
    }

 

getメソッドの最初に出てくるgetAcquireメソッドはconstantフィールドを取得するメソッドです。このメソッドについては後でもう一度触れます。

getAcquireメソッドでconstantフィールドをローカル変数のtに代入しています。続いて、tがnullでなければ、tをそのまま返しています。逆に、tがnullならばgetSlowPathメソッドをコールしています。

getSlowPathメソッドの先頭でpreventReentryメソッドをコールしていますが、これはロックを取得している状態で再びロックを取得する(これを再入すると呼びます)ことを防ぐメソッドです。Javaのsynchronizedは再入が可能なロックなのですが、ここではそれを防いでいるということです。

そして、synchronizedでロックを取得し、再びtを取得してnullかどうかをチェックしています。つまりダブルチェックになっているということです。

ダブルチェックをしてtがnullの場合、computingFunctionフィールドに対してgetメソッドをコールしています。これがSupplierのラムダ式の実行を意味しています

つまり、ここで値の初期化を行っています。

初期化した値がnullの場合はrequireNonNullメソッドでチェックしてNullPointerException例外をスローします。これが、前回のエントリーで例外を扱う場合の1の選択肢(ラムダ式でnullを返す)時の挙動になります。

次のsetReleaseメソッドはgetAcquireメソッドの逆です。

そして、computingFunctionにnullを代入しています。つまり、一度Supplierのラムダ式が実行されたら、その後はラムダ式を実行することができないということです。

このようにして、ダブルチェックロックを使って値の初期化を行っています。

しかし、気になるのは、シングルトンでは遅延初期化するフィールドがvolatileだったのにLazyConstantImplクラスではvolatileではないという点です。

この問題はgetAcquireメソッドを見てみれば、理由が分かります。

 

    @SuppressWarnings("unchecked")
    @ForceInline
    private T getAcquire() {
        return (T) UNSAFE.getReferenceAcquire(this, CONSTANT_OFFSET);
    }

 

ここで使われているUNSAFE変数は、一般には使わないようにと言われている危険なjdk.internal.misc.Unsafeクラスです。標準ライブラリだからこそ、使えるということですね。

そして、UnsafeクラスのgetReferenceAcquireメソッドを見てみると...

 

    @IntrinsicCandidate
    public final Object getReferenceAcquire(Object o, long offset) {
        return getReferenceVolatile(o, offset);
    }

 

なんと参照をvolatileで取得するメソッドをコールしていました。

つまり、LazyConstantImplクラスのconstantフィールドはvolatileで定義されてはいないものの、アクセスする時はvolatile相当で行われるということです。

これがconstantフィールドがvolatileで定義されていない理由になります。まぁ、普通にはできない技ですね(そもそもUnsafeクラスは使えないですし)。

 

もう1つ標準ライブラリだからこその技が最適化のヒントとなるアノテーションです。

たとえば、@ForceInlineアノテーションはメソッドのインライン化を行わせるアノテーションです。また、@Stableアノテーションは値が変更されないことを保証して、値を埋め込むなどの最適化を可能にしています。

このような最適化に対するアノテーションを使うことで、実行時最適化をやりやすくしているわけです。

 

まとめ

finalフィールドの遅延初期化を行うLazy Constantの実装を見てきました。

遅延初期化で使われている手法は、シングルトンで使われていたvolatileとダブルチェックロックです。この手法を使う場面というのはなかなかないとは思いますが、知識として知っておくのはよいですね。

そもそも、Lazy Constant自体がそれほど頻繁に使われるAPIではありません。しかし、もしイミュータブルなクラスで遅延初期化をしなければならないような場合はぜひ思い出してやってください。