ハクソク

世界を動かす技術を、日本語で。

JEP 401: 値オブジェクト（プレビュー）がOpenJDKマスターにマージされました

2026年7月31日原文(github.com)

概要

このプルリクエストは、 OpenJDK プロジェクトに関連し、 複数のレビュー と ラベル付け が行われた経緯を持つ。 CSR（Compatibility & Specification Review） の承認が必要で、 マージコンフリクト も発生した。 最終的に 統合準備完了 のラベルが付与されたが、 統合プロセス にはさらに手順が必要だった。 複数のレビュワー による承認と、 自動統合の準備 が進められた。 プルリクエストは 2026年5月11日 および 7月31日 に複数回参照・更新された。

OpenJDKプルリクエスト進捗の流れ

  • 2026年5月11日、プルリクエストが 提出 される
    • openjdk Botによる 自動ラベル付与
      • csr ：CSR承認が必要
      • merge-conflict ：ターゲットブランチとのマージコンフリクト発生
  • 5つのタスク が未解決状態
  • Dan Smith らによる 6回のコミット追加 （2026年5月12日）
    • Reviewed-by ラベルで 複数レビュワー の承認
      • liach, dholmes, sspitsyn, mchevalier, fparain, cjplummer, qamai 等
  • merge-conflict ラベルが 自動で削除 される
  • auto ラベル追加： 準備が整えば自動統合 される旨
  • 2026年7月30日、 ready ラベル追加： 統合準備完了
  • 2026年7月31日、 ready ラベル削除、 rfr（Ready for Review）、 sponsor ラベル追加
    • レビューとスポンサー の準備状態
  • blka による 参照 （2026年7月31日）
  • プルリクエストは オープン状態 で継続

プルリクエスト管理のポイント

  • CSR承認 が必要な場合、 承認完了まで統合不可
  • マージコンフリクト 発生時は 解消作業 が必要
  • 複数レビュワー による承認が求められる大規模プロジェクト
  • Botによる自動ラベル管理 で進捗を可視化
  • 統合準備 が整うと 自動統合または手動統合 が進行

まとめ

  • OpenJDKのプルリクエストは 多段階の承認・管理プロセス
  • ラベル と Bot の活用による効率的な進捗管理
  • レビュー・承認・統合 までの明確なフロー

Hackerたちの意見

これを正しく理解しているなら、Integerは値クラスになって、すべてのインスタンスがオブジェクトのアイデンティティを失うってことだよね。詳しいことはあまり知らないけど、最初からかなり大胆な動きに見えるな。

└

JavaにはIntegerやLongオブジェクトのキャッシングの仕組みがあって、すでに値オブジェクトっぽい感じになってる。キャッシュされたオブジェクトは==で比較できるし、IntegerのhashCodeはすでにintを返す、つまりボックス化されたint値だよ。失われる価値はあまりないね。

└

Integerのアイデンティティに依存しているプロジェクトは、この変更が来るっていう警告を何年も受けていたよ。また、暗黙のプリミティブ変換やオブジェクトプーリングを考えると、Integerはそもそもオブジェクトアイデンティティの候補としてはあまり適していないんだ。

└

私が理解した限りでは、これ（と今後の作業）がバリュークラスを構造体のように動作させるようにするから、メモリを節約できて、gRPCなどのためにメモリの整列も良くなるってことだね。

└

え、何それ？VirgilがJVMをターゲットにするのは、Arrayみたいな空の配列を表現するためにそれに依存してるんだ。めんどくさいな。

なんか孤独を感じるんだよね。自分はJavaという言語が大好きなんだけど、値型がないのが特定のパフォーマンスにとって一番の障害になってる。言語の進化を本当に楽しみにしてるよ。

└

今日は素晴らしい言語で、比類のないランタイムを持っているよ。重いビジネスのバックエンドサーバー負荷には標準的な選択肢で、当然そうだよね。Springは好き？うーん、そうでもない。ちょっとしたサイドプロジェクトにはTypescriptの方が好きだな。

└

Javaって言語は素晴らしいけど、問題は文化的なものだと思う。なんで IStatusChangeEntityCreationManagerFactory がどこにでもあるの？フレームワークがこんなに巨大で包括的なのも謎。バッテリー付きのRailsスタイルのフレームワークはいいと思うけど、Javaを書いてた時は全然Railsっぽくなかった。これは言語の問題じゃないよね。

└

私が一番好きなのは、Valhallaに注がれた膨大な思考と哲学だね。オブジェクト対バリューの二元的理解を超えて、実際には4つの明確なカテゴリを定義している：1: クラシックオブジェクト 2: アイデンティティのないオブジェクト 3: アトミックバリュー 4: クラシックバリュー（テアラブル）。それぞれのカテゴリには明確に定義されたパフォーマンス特性と意味的制約があるから、データの性質に応じて、完全には行けなくてもバリューから何らかの利益を得られるんだ。これはまさにアートだね。

└

昔はJavaが大好きだったな。特に、バッテリー同梱のよく設計された標準ライブラリが魅力的だった。言語自体の冗長さはあったけどね。でも、時間が経つにつれて、言語がかなり進化して、見た目もずっと良くなったと思う。

└

プログラミングを仕事にしてるわけじゃないけど（インフラ管理してる）、キャリアの初期にJavaに対する思い出がすごくあるんだ。Javaは、長年にわたって蓄積された企業向けの儀式的なものに重くされてると思う。軽量フレームワークは最近のもので、そうじゃなきゃ、テキスト/plainのHTTPレスポンスを出力するのに、アプリケーションサーバーやライブラリのエコシステム（j2ee）を立ち上げないといけなかったからね。それに…ビルドシステムの状況はまだ最悪だね。

└

前にも言ったけど、もう一度言うね：Javaの最悪なところはJavaプログラマーだ。キャリアのほとんどで、Javaが嫌いだと思ってたのは、触ったJavaコードがどれも冗長すぎて、他の言語なら10行で済むことを、何百万ものファイルでやってたから。だけど、実際にJava 8、11、17、21の機能を見てみたら、NO！Javaは、比較的きれいで簡潔でパフォーマンスの良いコードを書くための素晴らしいツールや言語機能をたくさん提供してるんだ。レコード型はボイラープレートを減らすのに役立つし、ストリームAPIはリストをきれいに扱えるし、シールドインターフェースはADTsの欲求をほぼ解決してくれる。バーチャルスレッドは本当に素晴らしいエンジニアリングの成果だし、組み込みじゃないものについては、Vert.xやDisruptorがギャップを埋めるのにいい仕事をしてる。これらを学んでからは、1999年のようにコードを書く人たちにちょっとイラッとしたけど、Javaを書くのが楽しくなった。もうこの時にはシニアやスタッフレベルだったから、コードを書く自由度が増してたし（だから、若手エンジニアたちは新しい機能を使った俺のコードに悩まされてるかも）。

Hacker Newsで議論の続きを見る