Java 25 / JDK 25 正式リリース

 (openjdk.org)
6 ポイント 投稿者 GN⁺ 2025-09-17 | 3件のコメント | WhatsAppで共有
  • Java 25 とその参照実装である JDK 25 が正式にリリース
  • 今回のバージョンには新たに 18件の JEP（Java Enhancement Proposal）機能を含む
  • x86 32ビットポートの削除、Scoped Values、Structured Concurrency、Primitive Types の改善 などの主要な変更が適用

Java 25 / JDK 25: 正式リリース

  • JDK 25、つまり Java 25 の参照実装が、正式に 本番向け配布 バージョンとしてリリース
  • 2025年8月15日に2回目のリリース候補である build 36 が提供され、その後 重大な（P1）バグ報告はなし。
  • build 36 は最終的な GA（General Availability）版であり、運用環境でも利用可能
  • GPL ライセンスベースの OpenJDK ビルド は Oracle から公式提供されており、その他の複数ベンダーによるビルド版もまもなく配布予定

OpenJDK 公式ダウンロードリンク

広告

主な機能と改善点

今回のリリースには 18件の JEP（Java Enhancement Proposal） が含まれている

  • 470: PEM ベースの 暗号オブジェクトエンコーディング（プレビュー）
  • 502: Stable Values（プレビュー）
  • 503: x86 32ビットポートの削除
  • 505: Structured Concurrency（5回目のプレビュー）
  • 506: Scoped Values
  • 507: パターン、instanceof、switch における Primitive Types のサポート（3回目のプレビュー）
  • 508: Vector API（10回目のインキュベータ版）
  • 509: JFR CPU 時間プロファイリング（実験的機能）
  • 510: Key Derivation Function API
  • 511: Module Import 宣言
  • 512: Compact Source Files とインスタンス main メソッド
  • 513: Flexible Constructor Bodies
  • 514: Ahead-of-Time コマンドライン最適化
  • 515: Ahead-of-Time メソッドプロファイリング
  • 518: JFR 協調サンプリング
  • 519: Compact Object Headers
  • 520: JFR メソッドタイミングとトレース
  • 521: Generational Shenandoah

このリリースには上記の JEP に加えて、数百件の小規模な機能改善 と 数千件のバグ修正 も反映されている

詳しいリリース情報および JEP の詳細は
OpenJDK JDK 25 プロジェクトページで確認可能

関連記事

3件のコメント

 
ahwjdekf 2025-09-18

去年も来た門付け芸人が、死にもせずまた来たな。おっとっと、また始まるぞ……お前、なんでそんなに何度も出てくるんだ？
 
click 2025-09-18

JDK24で入った機能ではありますが、JavaはLTSだけを使う傾向が強いので、synchronizedキーワードを使う際に仮想スレッドのpinning現象がなくなったJEP 491: Synchronize Virtual Threads without Pinningも注目に値します。
仮想スレッドの実運用ベンチマークがより遅いケースがしばしばありましたが、その多くはpinningが原因であることが多かったです。
 
GN⁺ 2025-09-17
Hacker Newsの意見
  • もっと多くの新規プログラムがJavaやJVM上で書かれるべきだと思う。過去にJavaの人気が落ちた理由は、今ではほとんどなくなっており、現在は非常に安定して成熟したエコシステムになっている。10年前に書いたClojureのプログラムも問題なく動く一方で、TypeScriptで書いたプログラムは6か月で保守やアップデートが必要になる
    • Oracleの存在がかなり気になる。Javaを使う際にOracleのEULAに違反しないよう注意しなければならないのが面倒だ。OpenJDKを使えば大丈夫そうだが、いっそ心配せずに別の言語を使いたい。C#もJavaに近い環境を提供しつつOracleを気にせず使える。Javaを安全に使う方法を学ぶより、別の言語を選んだほうがいいと思う。Javaが絶対に必要というわけでもなく、代替も多い
    • Javaは大規模バックエンドシステムでは今でも圧倒的に人気があり、広く使われている。ここではそういうシステムを扱う人があまりいないようで驚いた。自分の経験では、Javaに触れないことのほうがほとんどない
    • KotlinとComposeがJVM上でデスクトップアプリを再び復活させてくれることをひそかに期待している
    • Javaが採用率の面で引き続き危うい部分は、関連する文化にあると思う。古いJava開発者や既存のJavaプログラムは不必要に冗長に書かれており、言語自体にはすでに他のモダン言語のように簡潔に書ける機能があるのに、そうなっていない。それでもJavaはあまりに大きな存在なので、変化の余地はあると思う
    • 10年前に書いたClojureのプログラムがちゃんと動くのはJVMのおかげなのか、それともClojure特有のやり方のおかげなのか気になる。自分もClojureScriptのプロジェクトで似た経験がある。昔のnbbスクリプトも特に問題なくそのまま動くことが多い（たまにnpm依存関係を少し直すだけで済む）。一方でPythonでは依存関係の問題やvenv管理で半日つぶれることもある
  • Javaは長年にわたって驚くほど堅牢な技術基盤であり続けてきた。最も魅力的な言語ではないかもしれないが、常に安定性を見せてくれる。Java 1.4で作ったアプリがJava 21 LTSでも問題なく動いており、近いうちにJava 25へアップグレードする予定だ。Java最高
    • JetBrainsの優れたツールと賢い学生向けプログラムがなかったら、今のJavaがどうなっていたのか気になる
    • 距離は置いているが、2009年に自分のタッチ対応Symbian携帯で動いていたJava製のGmailアプリはいまだに印象に残っている。本当にかわいくて、機能的にもよくできていた
    • 自分の経験では全面的には同意できない。複数の会社でJVMのバージョンを上げるたびに、いつも大きな問題が出て、多くの手戻りや再テストが必要だった。Java 17〜18あたりで自分は離れたが、一緒に働いている人たちは新しいバージョンをほとんど使っていなかった。2022年にはあるプロジェクトでJVM 1.5を更新しなければならなかったが、重要なサードパーティライブラリがJava 1.7以前までしか対応しておらず、非常に苦労した。ソースコードを入手して自分でコンパイルしようとしたが、どんどん範囲が広がってしまった。管理職とも意見が合わず大変で、最終的にはFortune 10の最上位クライアントを離れることにした。今でもそのシステムは更新されていないと聞いている
    • 昔書いたswingアプリをもう一度使ってみたかったので、大きな修正なしに復活できそうなら試してみようと思う
    • JVMとそのエコシステムはScalaやClojureなど他の言語とも組み合わせて使えるので、多様で魅力的な活用ができる
  • コンストラクタでsuper呼び出しの前にパラメータの妥当性検証や変換が許されるようになるのに、ここまで時間がかかったのが不思議だ。以前から直感に反する部分だと思っていた
    • JDK 1.0以前からJavaを使ってきたが、この点は昔から気になっていた。ただ、今では慣れて回避方法にも習熟している
    • validate処理をsuperパラメータに使うstatic関数にしていれば、実際にはsuperより前に呼ばれるため、コンパイラ的にも問題なかった
  • Java開発者ではないが、モジュールのimportシステムは個人的にあまり好きではない。import *のような構文はコードを書くときは楽だが、読むのはずっと難しい。特にその言語やコードベースに不慣れな開発者にはなおさらだ。C#やNimもそういうスタイルだが、IDEなしではほとんど読めない。そのためPythonのような短いエイリアスの例（import torch.nn.functional as F）のほうが好ましいと思う
    • 大きなコードベースでimportの主な問題は「これはどこから来たのか？」という点だ。明示的なimportはやはり必要だ。ビルドが壊れたり依存関係のバージョンがややこしくなったりしたときは特にそうだ。小さなコードベースなら何でもよい。今どきのエディタはimport文を隠してくれるし、コードをクリックしたりショートカットで直接追えるので、import自体はあまり気にしていない
    • C#の経験があまりよくないのは、まともなVisual Studioを使っていないからだと思う。VSCodeも悪くないが、csprojやslnファイルをVSCodeで開くことは絶対にしない。ちなみにVisual Studioはここで500ドルの永久ライセンスを購入でき、別途サブスクリプションは不要だ
    • IDEなしでは理解しづらい言語構成に文句を言うのはよく分からない。コードはIDEで見るのだから問題ないと思う。IDEを使わない人が自分で不便を招いているだけで、GitHubでコードを見るのも普通は参照を深く分析するためではないので、その程度の簡潔さによる不便は受け入れられる
    • 私の理解では、このスタイルは単一ソースファイルのプログラムをより書きやすくする意図がある
  • 新機能はOpenJDK 25公式ページによくまとまっている。Java 25はLTSリリースだ
    • 10年後に17から25へマイグレーションする仕事をする日が早く来てほしい
  • 個人的な感覚だが、Javaは古い言語でありながらこの10年で着実に進化してきた一方、C++はむしろ難しくなったように感じる
  • 残念ながら、structured concurrencyはまだ完全リリースにはなっていない。この機能を本当に楽しみにしている。その代わりScoped Valuesの追加はうれしい。これだけでもJavaで「rails-like」なスタイルでコード構造を作るときに、god-classやgod-objectを乱用せずに済むと思う
    • C++が現在、実装のないまま標準化された機能で混乱している状況に比べると、Javaがプレビューで段階的に進めている今のやり方のほうがはるかに良いと思う
    • structured concurrencyがasync/awaitのように過度に糖衣構文っぽいものではなく、実質的な進歩として感じられるといいのだが。例だけ見た限りではまだ確信が持てないので、もう少し様子を見たい
  • 最近JDK8からのマイグレーションを決めて、JDK21へ一気に移行した。25が目前だったので、17を飛ばして21にした。自分の感覚では、8から11へのマイグレーション（新しいモジュールシステムの登場）が最も大変で、その後は簡単だった。Proof-of-Conceptはjdk17で行ったが、ほぼそのままjdk21でも動いた（guiceだけはメジャーバージョンアップが必要だった）。ちなみにJavaではなく別のJVM言語を使っていたのも助けになった気がする
    • 私たちのチームは8から17へ移るのが大変だった。sunパッケージのような非公式なものも多用していたし、javaxからjakartaへの移行も負担だった。その段階を越えれば、21や25へ行くのは簡単だと感じる。今後は最新バージョンを継続的に追うのが以前より楽になることを期待している
    • Java 9はエコシステムにとってのPython 3モーメントだったが、今では問題なく整理されたと感じる
    • ちなみに最近17から21へマイグレーションしたが、何の問題もなかった。細かな問題はGradleも一緒に上げたときに少しあった程度だ（これは本質的には別の問題）
  • Java 25の新機能はbaeldungの投稿でもよくまとめられている
  • 法的な観点で、現在Javaを使う状況がどうなっているのか気になる。オープンソースでも商用利用でも、OracleはTruffleのような優れた技術をJavaに結び付けているが、新規プロジェクトで採用するのがどれほど合理的なのか知りたい
    • OpenJDKは実質的にOracleからそのまま出ているオープンライセンス版だ。Oracleが嫌なら、Eclipse Foundation、Microsoft、Amazonなど他社のビルドを使えばよい。Javaの寿命は長く、8や11のような古いバージョンが今も使われる理由にもなっている。書いてしまえば本当に長く動く。機能面では競合より遅いが、重要な開発には十分だ。JVMに依存するならKotlinを勧める（特にJavaにはいまだnullable typeがなく、NullPointerExceptionが起こりがちだから）。Kotlinが嫌ならC#でもよい。それでもJavaは十分実用的だ
    • 現時点では、Oracle配布版については最新LTSだけは自由に使えると考えてよい。それより古いバージョンはOTNライセンスなので、個人・開発用途のみで、本番利用は不可だ。Oracleのマークが必須でないなら、OpenJDKや他社JDKにはライセンス上の心配はない
    • OpenJDKは完全なオープンソースなので、まったく心配する必要はない
    • OpenJDKのようなものを使えば、Oracleの問題から完全に自由になれる
    • 自分でJava実装を作って配布するのでなければ、法的な問題はほとんど考慮しなくてよい