Programming Languages

概要 Vercelは2026年5月7日、Next.jsのMay 2026セキュリティリリースを公開した。今回のリリースでは、DoS（サービス妨害）・ミドルウェアバイパス・キャッシュポイズニング・XSS・SSRFなど計13件の脆弱性が修正されている。修正はNext.js 15.5.18および16.2.6、ならびにReact 19系のreact-server-domパッケージ（19.0.6・19.1.7・19.2.6）に含まれる。WAFルールによる緩和は不可能であるため、影響を受けるバージョンを使用しているプロジェクトは直ちにアップグレードすることが強く推奨される。 修正された脆弱性の詳細 脆弱性は大きく3つのカテゴリに分類される。 ミドルウェア・プロキシバイパス（5件） は、認証機能に依存するアプリケーションへの影響が大きい。App Routerのセグメントプリフェッチを経由した認証回避が2件（高深刻度）、Pages Routerのi18nデフォルトロケールパスバイパス（高）、動的ルートパラメータインジェクションを介したバイパス（高）、ミドルウェアリダイレクトのキャッシュポイズニング（低）が含まれる。 サービス妨害（3件） は、React Server ComponentsやキャッシュコンポーネントなどNext.jsの主要機能に関連する。CVE-2026-23870はReact Server Components内のDoSとして高深刻度に分類されており、キャッシュコンポーネント利用時の接続枯渇（高）、画像最適化APIを経由したDoS（中）も修正された。 その他（5件） として、WebSocketアップグレード利用時のSSRF（高）、RSC関連のキャッシュポイズニング2件（中・低）、CSP nonce使用時のXSS（中）、untrustedデータを使用したbeforeInteractiveスクリプトのXSS（中）が含まれる。 対応方針 Vercelは、WAFルールによる一時的な緩和は今回の脆弱性には有効でないと明言しており、影響を受けるすべてのプロジェクトに対して修正済みバージョンへの即時アップグレードを求めている。Next.js 15系を利用している場合は15.5.18以上、16系を利用している場合は16.2.6以上に更新する必要がある。また、react-server-domパッケージを直接利用している場合は、対応するReact 19系の修正バージョンへの更新も合わせて行うべきである。今回の修正対象は広範なNext.jsの機能（App Router・Pages Router・画像最適化・WebSocket・RSC）にまたがっており、多くのプロダクション環境が潜在的な影響を受ける可能性がある点に注意が必要だ。

概要 Python 3.14の5番目のメンテナンスリリースとなる Python 3.14.5 が2026年5月10日に正式公開された。本リリースには154件以上のバグ修正、ビルド改善、ドキュメント変更が含まれる。特に注目すべき変更として、Python 3.14.0〜3.14.4で採用されていたインクリメンタルガベージコレクタ（GC）が廃止され、Python 3.13系で使われていた世代別GCへ差し戻された点が挙げられる。 インクリメンタルGCの差し戻し インクリメンタルGCはPython 3.14.0で新たに導入されたGC実装であり、大規模なヒープを段階的に処理することでGCポーズの短縮を目指していた。しかし、本番環境においてメモリ圧力に関する多数の問題報告が寄せられたことを受け、開発チームは安定性を優先する判断を下した。3.14.5では3.13系の世代別GCへの差し戻しが実施されており、本番環境でPython 3.14系を運用しているユーザーに対してはアップグレードが強く推奨される。 その他の主な変更点 macOS向けインストーラでは、同梱するTcl/TkのバージョンがTcl/Tk 8.6.17から9.0.3へアップグレードされた。これによりmacOS上でのTkinterアプリケーションの互換性・安定性が向上する。また、Windowsユーザー向けには新しいインストールマネージャーがWindowsストアおよびダウンロードページより引き続き提供されており、従来のインストーラもPython 3.14・3.15を通じて利用可能となっている。 Python 3.14系の主な特徴 Python 3.14シリーズには、フリースレッドPython（PEP 779）、アノテーションの遅延評価（PEP 649）、テンプレート文字列リテラル（PEP 750）、複数インタプリタの標準ライブラリ対応（PEP 734）、Zstandard圧縮サポート（PEP 784）、PyREPLにおける構文強調表示とカラー出力対応といった多数の新機能が含まれる。Python 3.14.5はこれらの機能を安定して利用できるバグフィックスリリースとして位置付けられており、3.14系ユーザーへの早期移行が推奨される。

概要 Goチームは2026年5月7日、Go 1.26.3およびGo 1.25.10のパッチリリースを公開した。両バージョンはともに11件のセキュリティ脆弱性を修正するほか、コンパイラ・リンカ・ランタイムなど複数コンポーネントのバグ修正も含む。現行の本番環境で稼働しているユーザーには速やかなアップデートが推奨されている。セキュリティ修正はGoの標準ライブラリおよびツールチェーン全体に広く及んでいる。 セキュリティ修正の詳細 今回のリリースで修正された脆弱性はカテゴリ別に以下のとおりまとめられる。 XSS（クロスサイトスクリプティング）関連 html/templateパッケージで2件のXSS脆弱性が修正された。CVE-2026-39826は<script>タグに空のtype属性または空白を含むtype属性を使用した場合に発生するエスケープ処理の不備、CVE-2026-39823はメタタグのcontent属性内でURLが正しくエスケープされない問題をそれぞれ修正する。いずれも信頼済みテンプレート作成者の記述を利用して攻撃者が悪意あるスクリプトを実行できる可能性があった。 DoS（サービス拒否）関連 net/httpパッケージのCVE-2026-33814は、HTTP/2のSETTINGS_MAX_FRAME_SIZEに不正な値を送信することで無限ループを引き起こしDoS攻撃を可能にする脆弱性。net/mailパッケージではCVE-2026-39820とCVE-2026-42499の2件が修正されており、どちらも文字列の二次的連結処理に起因するCPU過消費・メモリ過消費問題で、メールアドレスのパース関数（ParseAddress・ParseAddressList・ParseDate）を悪用される恐れがあった。 パストラバーサル・ファイルシステム関連 go tool packのCVE-2026-39817は、出力ファイル名をサニタイズしないまま展開することで任意のファイルシステム位置への書き込みを可能にする脆弱性。修正としてディレクトリ成分を含むファイルの展開が拒否されるようになった。CVE-2026-39819はgo bugコマンドが予測可能な一時ファイル名のシンボリックリンクを追うことで、攻撃者がリンク先を上書きできる問題を修正する。 その他 CVE-2026-42501はモジュールプロキシがチェックサム検証をバイパスできる脆弱性、CVE-2026-33811はcgo DNSリゾルバの長いCNAMEレスポンス処理時のダブルフリーによるクラッシュ、CVE-2026-39825はnet/http/httputilのリバースプロキシがクエリパラメータ数制限を考慮しない問題、CVE-2026-39836はnetパッケージのDialおよびLookupPort関数がWindows環境でNULバイトを含む入力を受け取った際にパニックを起こす問題がそれぞれ修正されている。 バグ修正と対象コンポーネント セキュリティ修正に加え、両バージョンには以下のバグ修正が含まれる。 goコマンドおよびgo fixコマンド（Go 1.26.3のみ） コンパイラおよびリンカ ランタイム crypto/fips140・crypto/tlsパッケージ go/typesパッケージ osパッケージ Go 1.26.3ではGo 1.25.10に含まれないいくつかの追加修正（go fix・crypto/tlsなど）も取り込まれている。 アップデートの推奨 Goの公式サイトから最新バージョンをダウンロードできる。GoチームはWebサーバーやCLIツールなど本番環境で動作しているアプリケーションに対し、特にHTTPサーバーやメールパース機能を利用している場合は早急なバージョンアップを呼びかけている。今回修正されたXSS・DoS・パストラバーサル系の脆弱性は外部からの入力を介して悪用される可能性があるため、インターネット公開サービスでは優先度を高めた対応が求められる。

概要 JetBrainsは2026年4月22日、Kotlin 2.4.0のEarly Access Preview第2弾（Beta2）をリリースした。安定版のリリースは2026年6〜7月を予定しており、今回のBeta2では言語機能・標準ライブラリ・各プラットフォーム（JVM、Native、Wasm、JS）にわたる広範な改善が盛り込まれている。最大のポイントは、Experimentalステータスだった複数の機能がStableに昇格したことと、Kotlin/Wasmのインクリメンタルコンパイルがデフォルト有効化されたことだ。 言語機能の安定化と新機能 今回のリリースで最も注目されるのは、コンテキストパラメータ（Context Parameters） のStable昇格だ（呼び出し可能参照を除く）。コンテキストパラメータは関数シグネチャに暗黙的なコンテキストを宣言できる機能で、依存性の受け渡しを明示的に書くことなく表現できる。合わせて、明示的バッキングフィールド（Explicit Backing Fields） と @all メタターゲット for properties もStableとなった。 新たにExperimentalで追加された機能として、明示的コンテキスト引数 が挙げられる。同名の関数が複数のコンテキスト型に対してオーバーロードされている場合に曖昧さを解消するための構文で、sendNotification(emailSender = defaultEmailSender) のように名前付きで指定できる。また、コレクションリテラル（-Xcollection-literals フラグ）も新たに導入され、val fruit = ["apple", "banana", "cherry"] のような簡潔な構文でリストを生成できるようになった。さらに、コンパイル時定数の改善（-XXLanguage:+IntrinsicConstEvaluation）として、文字列関数（.lowercase()・.uppercase()・.trim()）や符号なし型演算、enumの .name プロパティがコンパイル時に評価されるようになった。 標準ライブラリの変更 kotlin.uuid.Uuid APIがStableに昇格した（V4/V7生成関数を除く）。また、コレクションのソート順序を検証する新しい拡張関数群（isSorted()・isSortedBy()・isSortedDescending()・isSortedWith() など）が追加された。JVM向けには、符号なし整数（ULong、UInt）から BigInteger への変換関数も追加されている。 プラットフォーム別の改善 Kotlin/JVM では Java 26 のバイトコード生成に対応し、Kotlinメタデータに保存されたアノテーションへのアクセスがデフォルトで有効化された。 Kotlin/Native では2つの大きな進展がある。GradleのビルドスクリプトからSwift Package Manager（SwiftPM）の依存関係を宣言できる Swiftパッケージインポート がExperimentalで追加された。また、ガベージコレクタのデフォルトがCMS（Concurrent Mark Sweep）に変更 され、GCによる一時停止時間が短縮されてCompose Multiplatformなどのアプリでのレスポンスが向上する。さらに、Swift Exportで kotlinx.coroutines.Flow をSwiftの AsyncSequence としてエクスポート できるようになった。 Kotlin/Wasm では、インクリメンタルコンパイルがStableに昇格しデフォルト有効化された。大規模プロジェクトではビルド時間の大幅な短縮が見込まれる。また、WebAssembly Component Model への対応により、言語非依存なコンポーネント構成やFaaS（サーバーレス）アプリケーションでの活用が可能になった。 Kotlin/JS では、インライン value class をTypeScriptにエクスポートできるようになったほか、js() 関数内でアロー関数・ESクラス・テンプレート文字列・スプレッド演算子など主要なES2015構文が使用可能になった。 ...

概要 2026年5月4日、Pythonコア開発チームはPython 3.14.5のリリース候補第1版（RC1）を公開した。最終リリースは2026年5月8日を予定しており、約113件のバグ修正・ビルド改善・ドキュメント変更が含まれる。このリリースで最も注目すべき変更は、Python 3.14.0〜3.14.4で採用されていたインクリメンタルGCを、Python 3.13時代の世代別GCへ差し戻したことだ。開発チームはこのRC版のテストを強く推奨しているが、プレビューリリースのため本番運用への適用は推奨されていない。 インクリメンタルGCの差し戻し インクリメンタルGCはPython 3.14で導入された新しいガベージコレクション方式だったが、本番環境から多数のメモリ圧力に関する報告が寄せられていた。最悪のケースでは、ピーク時のメモリ使用量が世代別GCの最大5倍に達することが確認されており、これがパッチリリースによる異例の差し戻しの直接的な原因となった。Python 3.14.5以降は、Python 3.13で実績のある世代別GCに戻る形となる。なお、Python 3.14自体が持つその他の主要機能——フリースレッド対応（PEP 779）、遅延アノテーション評価（PEP 649）、テンプレート文字列リテラル（PEP 750）、Zstandard圧縮サポート（PEP 784）、JITコンパイラ——はそのまま維持される。 Python 3.15.0 Beta 1と機能フリーズ 5月5日にはPython 3.15.0 Beta 1がリリースされ、機能フリーズを達成した。Beta 1への移行前の最終アルファ版（Alpha 8、4月7日リリース）の段階で、JITコンパイラはx86-64 Linux上で約6〜7%、AArch64 macOS上で約12〜13%のジオメトリック平均パフォーマンス改善を記録している。Beta 1以降は新機能の追加は凍結され、安定性とバグ修正に焦点を当てた開発フェーズへ移行する。 Pythonパッケージング評議会の発足 2026年4月16日に受理されたPEP 772により、Pythonエコシステムに選出制の「Packaging Council（パッケージング評議会）」が正式に設立された。5名のメンバーで構成されるこの評議会は、パッケージング標準・ツール・実装に関して広範な権限を持つ。これまで非公式な組織であったPython Packaging Authority（PyPA）モデルから脱却し、パッケージング分野として初めての正式なガバナンス体制が整ったことになる。あわせて、PEP 803（フリースレッドPython向けStable ABIサポートとしてabi3tを導入）、PEP 800（型システムの非互換性を表現する@typing.disjoint_baseデコレータ）、PEP 829（セキュリティ上の懸念から.pthファイルを.start形式に置き換えるドラフト提案）なども注目を集めている。 エコシステムの動向 パッケージング以外の分野でも動きが続いた。OpenAIがAstralを買収し、月間1億2600万ダウンロードを誇るuvパッケージマネージャー、リンター/フォーマッターのRuff、および型チェッカーのtyの管理権を取得した。一方、2015年から84プロジェクトを維持してきたコラボレーティブなメンテナンス組織「Jazzband」は、AIによるスパムの増加とメンテナーの疲弊を理由に活動終了を発表した。ライブラリ面では、FastAPIの基盤であるStarlette 1.0が安定版に到達したほか、Polars 1.40.0がストリーミングエンジンのスピル・トゥ・ディスク対応を拡充、FastAPI 0.136.0がPython 3.14tのフリースレッドを正式サポートした。

概要 Node.js 26.0.0が2026年5月5日に正式リリースされた。本バージョンは「Current」ステータスで提供され、2026年10月にLTS（長期サポート）へ移行する予定だ。リリースマネージャーはRafael Gonzaga氏が担当している。最大のハイライトは、これまで実験的フラグ付きでのみ利用できたTemporal APIがデフォルトで有効化されたことだ。JavaScriptにおける日付・時刻処理の根本的な刷新が、ついて一般ユーザーの手に届く形となった。 Temporal API — Dateの後継がついに標準化 Temporal APIは、従来のDateオブジェクトが抱えてきた多くの問題（タイムゾーン処理の曖昧さ、可変性、直感に反するAPI設計など）を解消するために開発されたモダンな日付・時刻APIだ。日付、時刻、期間、タイムゾーン、カレンダー対応操作のそれぞれに専用の型が用意されており、より安全で明確なコードが書けるよう設計されている。Node.js 26ではこのAPIがフラグなしで利用できるようになったことで、実プロジェクトへの採用が現実的なものとなった。 V8 14.6とJavaScript新機能 V8エンジンがChromium 146ベースの14.6.202.33に更新された。これに伴い、いくつかの新しいJavaScript言語機能が利用可能になった。Map.prototype.getOrInsert()およびMap.prototype.getOrInsertComputed()（WeakMap版も含む）は、キーが存在しない場合に値を挿入する操作を簡潔に書けるUpsertパターンのサポートだ。またIterator.concat()によるイテレーターの連結も追加されている。なお、NODE_MODULE_VERSIONは147に更新されており、ネイティブアドオンの再コンパイルが必要になる場合がある。 レガシー機能の削除と非推奨化 Node.js 26ではプラットフォームのモダン化を意図した整理も行われた。http.Server.prototype.writeHeader()メソッドが削除され、代わりにwriteHead()の使用が求められる。内部ストリームモジュール群（_stream_wrap、_stream_readable、_stream_writableなど）も廃止された。またmodule.register()やストリーム・暗号関連のAPIがランタイム非推奨（DEP0201、DEP0203、DEP0204）に昇格した。HTTPクライアントライブラリUndiciは8.0.2へ更新されている。セキュリティ面ではCVE-2026-21717（配列インデックスハッシュ衝突）への対応が含まれる。 ビルド要件の変更 ビルド環境の要件も引き上げられた。GCC 13.2以上が必須となり、Python 3.9のサポートが廃止された。Windows向けにはSDKバージョン11への更新が必要となる。これらの変更は、古いビルド環境で独自にNode.jsをコンパイルしているケースに影響する。Node.js 26はLTSへの移行を控えた重要なバージョンであり、新機能の評価と既存アプリケーションへの影響確認を今のうちに進めておくことが推奨される。

概要 CPythonへのRust統合を進めるコミュニティが2026年4月8日に進捗レポートを公開した。最大の変更点は、当初のターゲットだったPython 3.15からPython 3.16へとマイルストーンを後ろ倒しにしたことだ。これにより開発・議論のための時間を十分に確保し、3.16のベータ1が予定される2027年5月までに、コミュニティが変更内容を十分に議論できる体制を整えるという。 達成済みのマイルストーン 最も大きな成果はビルドシステムの完成だ。フォーク上のCPython CIで、全テスト対象プラットフォームにわたってRustを含むクロスプラットフォームコンパイルが正常に動作することを確認した。また、Rustチームとの協力体制を構築し、統合上の技術的課題への対処を進めている。さらに、GitHubのIssueに「api-design」ラベルを付けてRust向け内部APIの設計議論を開始しており、将来のPEP提案の基礎固めが着実に進んでいる。 今後のロードマップ プロジェクトは2026年3月から7月にかけてのロードマップを示している。4月以降はRust API設計の計画立案と拡張モジュールの実装対象の選定を行い、5月にはAPIの設計を固めて実装に着手するとともに、PyConUS スプリントでの活動を予定している。6月からはPEP草稿の作成を始め、7月中に草稿を完成させてコミュニティに提出する計画だ。コミュニティへの参加は公式Discordで受け付けており、毎週月曜日12:00 PDTに定例ミーティングを開催している。 今後の展望 Python 3.16への組み込みが実現すれば、CPythonの内部実装にRustが正式採用される初のケースとなる。ビルドシステムの整備完了という基盤を踏まえ、今後数ヶ月のAPI設計とPEP策定が統合の成否を大きく左右する局面に入る。Pythonコアチームとの連携を深めながら、段階的かつ慎重に統合を進める方針が明確にされており、大規模言語実装へのRust採用という前例のない取り組みに注目が集まっている。

概要 Rustプロジェクトは2026年4月30日、Google Summer of Code（GSoC）2026の採択プロジェクトを発表した。今年は96件の応募が集まり、前年比50%増という記録的な数字を達成。その中から13件のプロジェクトが採択された。応募増加の一方でAI生成による低品質な提案も増加しており、メンター陣は応募者との事前のやり取り・過去の貢献実績・提案の質・プロジェクトへの重要性・メンターのキャパシティといった複数の基準で選考を行った。 採択された13プロジェクト 採択プロジェクトはコンパイラ、標準ライブラリ、ツールチェーンにまたがる多岐にわたる領域をカバーしている。 A Frontend for Safe GPU Offloading in Rust（Marcelo Domínguez、メンター: Manuel Drehwald） Adding WebAssembly Linking Support to Wild（Kei Akiyama、メンター: David Lattimore） Bringing autodiff and offload into Rust CI（Shota Sugano、メンター: Manuel Drehwald） Debugger for Miri（Mohamed Ali Mohamed、メンター: Oli Scherer） Implementing impl and mut restrictions（Ryosuke Yamano、メンター: Jacob Pratt・Urgau） Improving Ergonomics and Safety of serialport-rs（Tanmay、メンター: Christian Meusel） libc: transition differing bit-width time and offset variants（Adam Martinez、メンター: Trevor Gross） Link Linux kernel and its Modules with Wild（Vishruth Thimmaiah、メンター: David Lattimore） Migrating rust-analyzer assists to SyntaxEditor（Shourya Sharma、メンター: Chayim Refael Friedman・Lukas Wirth） Port std::arch test suite to rust-lang/rust（Sumit Kumar、メンター: Jakub Beránek・Folkert de Vries） Reorganizing tests/ui/issues（zedddie、メンター: Teapot・Kivooeo） Utilize debugger APIs to improve debug info（Anthony Bolden、メンター: Jakub Beránek・Jieyou Xu） XDG path support for rustup（Guicheng Liu、メンター: rami3l） GPU オフロードや WebAssembly リンク、自動微分（autodiff）、デバッガ改善、rust-analyzerのリファクタリングなど、Rustエコシステムの実用性と品質向上を目指すテーマが並んでいる。 ...

概要 Rubyコミッターとして知られる遠藤侑介氏が、13のプログラミング言語を対象にClaude Codeのコーディング効率を比較する大規模ベンチマークを実施し、その結果を公表した。600回以上の実行からなる本研究では、「簡略化されたGitの実装」という共通タスクを各言語で20回ずつ実行し、生成コストと処理時間を計測した。結果として、Ruby・Python・JavaScriptなどの動的言語が静的型付き言語より1.4〜2.6倍速く、かつ低コストであることが示された。AIによるコーディング補助において、言語の選択がパフォーマンスとコストに定量的な影響を与えることを示した注目の研究となっている。 ベンチマーク結果 各言語の1回あたりのコストと平均実行時間の上位・下位は以下の通り。 動的言語がトップ3を占めた： Ruby: $0.36/回、73.1秒、分散低、成功率100% Python: $0.38/回、74.6秒、分散低、成功率100% JavaScript: $0.39/回、81.1秒、分散低、成功率100% 一方で静的型付き言語は相対的に低い効率を示した： Go: $0.50/回、101.6秒（標準偏差37秒と高いばらつき） Rust: $0.54/回、分散大、テスト失敗あり C: $0.74/回、生成コード517行（Rubyの219行に対して） 型チェックのオーバーヘッドも計測されており、PythonにMyPy strict検査を適用すると1.6〜1.7倍、RubyにSteep型チェックを適用すると2.0〜3.2倍遅くなった。TypeScriptはJavaScriptと生成行数が近いにもかかわらず、コストはJavaScriptの$0.39に対して$0.62と約1.6倍高かった。 考察と限界 遠藤氏自身も認めているように、このベンチマークが測定しているのは「生成コストと速度」であり、コード品質・保守性・ランタイム性能は対象外である。またタスク規模は約200行程度のプロトタイプ開発に相当するものであり、大規模な本番コードベースでの結論を直接導くものではない。 コミュニティからも批判的な意見が寄せられており、各言語のエコシステムの充実度や標準ライブラリの豊富さといった利点が考慮されていない点や、プロトタイピングレベルの知見が大規模開発にそのまま適用できるかどうかについて疑問視する声がある。動的言語の生成コードが短くなりやすい一方で、実務上は型情報が長期保守において重要な役割を果たすという観点も見逃せない。 今後の展望 本研究は、AIコーディングツールの普及とともに「どの言語でAIに書かせるか」という問いが現実的な意味を持ち始めていることを示している。特に速度やコストを重視するプロトタイピングや自動生成パイプラインにおいては、言語選択の戦略的重要性が増すだろう。今後は、より大規模・複雑なタスクや複数のAIモデルを対象にした追加検証が待たれる。

概要 Java 26が2026年3月17日にリリースされ、Spring Boot開発者にとって実用的な改善が複数導入された。主な変更点はG1ガベージコレクターのパフォーマンス向上、標準ライブラリへのHTTP/3サポート追加、ファイナルフィールドへの不正な反射的変更への警告導入、そしてUUIDv7の標準APIサポートである。同時期にはSpring Boot 4.1.0-RC1をはじめとするSpringエコシステムの複数プロジェクトもリリースを迎えている。 Java 26の主要な新機能 G1 GCの大幅なスループット向上（JEP 522） G1ガベージコレクターが参照オブジェクトの追跡方式をデュアルカードテーブル方式へと刷新した。これにより、参照オブジェクトを多用するワークロードで5〜15%のスループット改善が見込める。設定変更は不要で、JDKをアップグレードするだけで自動的に恩恵を受けられる。 標準ライブラリへのHTTP/3対応 JDK付属のHttpClientがQUICプロトコル上のHTTP/3に対応した。利用するにはHttpClient.Version.HTTP_3を指定するだけでよく、HTTP/3が利用できない場合はHTTP/2へ自動的にフォールバックする。これまで外部ライブラリが必要だったHTTP/3通信が標準APIで実現できるようになった。 ファイナルフィールド変更への警告（JEP 500） フィールドの不変性の強制が始まった。Java 26ではリフレクションによるファイナルフィールドへの変更に対して警告が出力され、将来のリリースではエラーとなる予定だ。HibernateやMockitoなど一部のライブラリが影響を受ける可能性があるため、依存関係の互換性確認が推奨される。 UUIDv7の標準サポート UUID.ofEpochMillis()メソッドが新たに追加され、時刻順に並んだUUIDv7を生成できるようになった。ランダムなUUID v4と比べてデータベースのインデックス性能が向上し、挿入時のページ分裂を抑えられるため、主キーや連番IDの用途で有効に活用できる。 Springエコシステムのリリース動向 Java 26のリリースと前後して、Springエコシステムでも多くのプロジェクトが新バージョンを公開した。 Spring Bootではバグ修正版の3.5.14・4.0.6に加え、次世代版となる4.1.0-RC1がリリース候補として公開された。Spring for Apache Kafkaも4.1.0-RC1・4.0.5・3.3.15の3バージョンを同時リリースし、Spring AIでは1.0.6・1.1.5・2.0.0-M5と幅広いバージョン帯をカバーするリリースが行われた。そのほか、Spring Modulith 2.1 RC1・2.0.6・1.4.11、Spring Shell 4.0.2、Spring for Apache Pulsar 1.2.17・2.0.5、Spring Authorization Server 1.5.7も相次いで公開されている。 移行に関する考慮事項 Java 26はサポート期間が6ヶ月の非LTSリリースであるため、本番環境への採用にはJava 25 LTSをそのまま使い続けることが推奨される。一方で、CIパイプラインにJava 26を加えて依存ライブラリの互換性を今から確認しておくことは、将来のアップグレードをスムーズに進めるうえで有益だ。特にファイナルフィールド変更への警告は将来的にエラーとなるため、HibernateやMockitoなどリフレクションを多用するライブラリのアップデート対応状況を早めに把握しておくとよい。