Programming Languages

概要 JetBrainsは2026年8月12日、Kotlin 2.4.20のリリース候補版（RC）を公開した。今回のRCでは、標準ライブラリへのコルーチン例外のスタックトレース復元機能やコレクションの要素チェック関数の追加に加え、Kotlin/NativeにおけるSwift Exportの強化、Kotlin/Wasmでの新たなランタイム対応、Kotlin/JSのブラウザテスト刷新など、プラットフォーム横断で多数の改善が盛り込まれている。正式版へ向けた最終確認段階の位置づけで、IntelliJ IDEAやAndroid Studioを最新版に更新した上で、ビルドスクリプトのKotlinバージョンを2.4.20-RCに変更することで試用できる。 標準ライブラリの改善 コルーチンのデバッグ性向上を目的として、新たにStackTraceRecoverableインターフェースが導入された。これは、コルーチンが例外をスローして再送出する際に、例外に紐づくスタックトレースの復元方法をカスタマイズできるようにするもので、copyForStackTraceRecovery()メソッドを実装することで、例外の再構築ロジックを定義できる。利用には@OptIn(ExperimentalStdlibCoroutineSupportApi::class)によるオプトインが必要で、全ターゲットで利用可能だが、JVM上のkotlinx.coroutinesではすでに活用されている。 また、コレクション要素の性質を検証する実験的な関数として、allDistinct()（全要素が一意かを確認）、allDistinctBy()（指定したプロパティが一意かを確認）、allEqual()（全要素が同一かを確認）、allEqualBy()（指定したプロパティが全て同一かを確認）の4関数が新たに追加された。こちらも@OptIn(ExperimentalStdlibApi::class)が必要な実験的APIとなっている。 Kotlin/Native・Wasm・JSの強化 Kotlin/NativeのSwift Exportでは、Kotlinのsealedクラス階層をSwiftのenumにマッピングし、Swift側で網羅的なswitch文を書けるようになったほか、Swift側で実装したKotlinインターフェースをKotlin関数に渡す「逆方向インポート」パターンもサポートされ、プラットフォーム固有実装の受け渡しが容易になった。さらにassembleSharedXCFrameworkタスクがSwiftPM依存関係向けのPackage.swiftを自動生成するようになり、XCFrameworkの配布が簡素化される。 Kotlin/Wasmでは、Node.jsに加えて選択できる新たなスタンドアロンWebAssemblyランタイムとして、wasmWasiターゲット向けにWasmtime対応が追加された。加えて、@JsFun宣言内でのトップレベルrequire()はコンパイルエラーとなり、@JsModuleアノテーションやimport()式への移行が求められるほか、コンパニオンオブジェクトの初期化順序がJVMと同様にスーパークラス優先へと変更され、プラットフォーム間の一貫性が向上した。Kotlin/JSでは非推奨となったKarmaに代わり、Mocha・Webpack・Playwrightを組み合わせた新しいブラウザテストDSLが実験的機能として導入され、Chromium・Firefox・WebKitでのテストに対応する。 その他の変更点 Build Tools API（BTA）の対応範囲がKotlin/JS、Kotlin/Wasm、Kotlinメタデータにも拡大され、gradle.propertiesでのオプトインを経てKotlin 2.5.0でのデフォルト化が予定されている。また、標準のkotlincより高速な起動とパフォーマンスを実現する、ネイティブコンパイライメージの初の実験的リリースも行われた。Serialization、Compose、All-openなど主要なコンパイラプラグインをバンドルしており、GitHub Releasesから入手できる。今回のRCは正式リリースに向けた最終検証段階であり、フィードバックを踏まえて安定版への反映が進められる見込みだ。

概要 Microsoftは8月11日、.NET 11の7番目のプレビュー版となる「.NET 11 Preview 7」を公開した。今回の目玉は、dotnet CLIにおけるNativeAOTのデフォルト有効化だ。NativeAOTはアプリケーションをネイティブコードへ事前コンパイルする仕組みで、これまではオプトインの機能だったが、Preview 7からはCLI経由での利用時に標準で有効になる。あわせてMSBuildサーバーもデフォルトで有効化され、ビルドのパフォーマンス向上が図られている。.NET 11の正式リリースは2026年11月を予定しており、SDKはdotnet.microsoft.comから、あるいはVisual Studio 2026 Insidersをインストールすることで試用できる。 C# 15の新機能 言語面ではC# 15に新しいパターンマッチング機能が加わった。「ユニオンパターン」はユニオン型そのもの、またはその値のいずれにもマッチできる「Try-Both」方式のマッチングアプローチを採用しており、より柔軟な条件分岐の記述が可能になる。また、ラベル付きbreak文とラベル付きcontinue文がサポートされ、ネストしたループの外側から直接抜け出したり、特定のループへ制御を戻したりできるようになった。型パラメータが閉じた型に制限されている場合の網羅性チェックも改善されており、パターンマッチングの安全性が高まっている。 ランタイムとツールチェーンの改善 ランタイム面では、非同期メソッドのコンパイル方式が刷新された。従来「ランタイム非同期」はコンパイル速度を優先したTier 0コードのみで実行されていたが、Preview 7からは段階的コンパイルパイプラインを通じてコンパイルされるようになり、実行時のパフォーマンス向上が期待できる。また、CoreCLRのWebAssembly対応も進展しており、Preview 6での起動成功に続き、Preview 7ではCoreCLRライブラリのテストスイートをエンドツーエンドで実行できるようになったと報告されている。 ツールチェーン面では、dotnet testコマンドに--timeoutと--maximum-failed-testsオプションが追加され、CI環境などでテスト実行を柔軟に制御できるようになった。MAUI、Android、iOS向けのテスト機能拡張や、Blazorアナライザーの5種類の追加、HTTPコンテンツの圧縮ラッパー(GZip、Brotli、Zstandard)対応なども盛り込まれている。このほか、ライブラリではIEEE 754準拠の10進浮動小数点型がサポートされ、ASP.NET CoreのBlazorでは回路の自動一時停止機能が、Entity Framework Coreではクエリ変換の改善が、Windows Formsでは視覚スタイルの改善が行われている。 今後の見通し .NET 11は2026年11月の正式リリースに向けて開発が進んでおり、今回のPreview 7はその重要なマイルストーンの一つとなる。NativeAOTのCLIデフォルト化は、起動速度やデプロイサイズを重視する開発者にとって特に注目される変更であり、正式版までにさらなる安定化や対応範囲の拡大が見込まれる。C# 15の新パターンマッチング機能についても、正式リリースまでにフィードバックを踏まえた調整が加えられる可能性がある。

概要 PHP開発チームは8月11日、次期メジャーバージョンとなるPHP 8.6.0のBeta 1をJoe Ferguson氏名義でタグ付け・公開した。PHP 8.5.0のリリースからおよそ9カ月というこれまで通りのリリースサイクルに沿ったもので、目玉となるのは部分関数適用(Partial Function Application)、ストリーム多重化を刷新するネイティブポーリングAPI「Io\Poll」、そしてナノ秒精度の時間間隔を扱うTime\\Durationクラスの3つの新機能だ。これに加えて、標準ライブラリ全体でエラー処理を厳格化する変更が数多く盛り込まれており、記事は今回のリリースを「PHPの厳格化時代の到来」と表現している。 主な新機能 部分関数適用は、引数の一部を?というプレースホルダーで残し、...で残余引数をまとめて受け取れるようにする機能で、部分的に適用した関数オブジェクトを生成できる。型ヒントや戻り値の型はリフレクションを通じて保持される仕組みで、対応するRFCは33対0という圧倒的多数で可決された。 Io\\Pollは、長らく使われてきたstream_select()を置き換えるネイティブI/O APIで、LinuxのepollやmacOS/BSDのkqueue、Solarisのevent ports、WindowsのWSAPollといった各プラットフォーム固有の仕組みを内部で使い分けて最適化を図る。あくまで「ポーリング機構であり、完全なイベントループではない」点が特徴だが、ReactPHPやAmpHP、Revoltといった非同期処理ライブラリがバックエンドとして採用していくとみられている。 もう一つの目玉であるTime\\Durationは、finalかつreadonlyなクラスとしてナノ秒精度の時間間隔を扱えるようにするもので、ISO 8601形式のパースに対応し、sleep()とも直接連携できる。 エラー処理の厳格化と非推奨機能 PHP 8.6では、これまで黙って処理を続けてきた挙動の多くが例外を投げるように変更される。たとえば文字列引数中のNULバイトはこれまで暗黙に切り詰められていたが、今後はValueErrorが送出される。array_filter()は不正なモード指定を拒否するようになり、pathinfo()やscandir()も失敗時に静かに処理を続けず明示的にエラーを出すようになった。sleep()やusleep()もプラットフォームの上限値でクランプされる。 セキュリティ関連のデフォルト設定も変更され、session.use_strict_mode、session.cookie_httponlyはいずれもデフォルトで1に、session.cookie_samesiteはデフォルトでLaxになる。このほか、戻り値を無視すると問題が起きうる関数に付与する#[\\NoDiscard]属性、スタンドアロン関数としてのclone()、クラス定数やenumケースにも対応した#[\\Override]属性の拡張、コンストラクタプロモートプロパティへのfinal修飾子の適用、参照返しに対応したパイプ演算子の強化なども追加される。 非推奨化の対象としては、MbregexおよびOnigurumaバックエンド、metaphone()、is_double()、doubleval()、spl_classes()やspl_object_hash()などのSPL関数が挙げられているほか、GMP演算子は暗黙の切り捨て挙動を失う。今回のBeta 1でAPIや挙動の変更点は概ね出そろった形であり、今後のリリース候補(RC)を経て正式版のリリースに向けて安定化が進む見通しだ。

概要 Node.js向けパッケージマネージャー「pnpm」の開発チームは8月9日、Rustによる全面リライト版となる「pnpm 12」のリリース候補版v12.0.0-rc.3を公開した。pnpm 12は2026年8月5日にRC0が公開されて以降、rc.1、rc.2と短い間隔で改善が重ねられており、rc.3では「シェバングを持たないバイナリやインタープリタなしで実行されるターゲット（マネージドNode.jsランタイムなど)に対し、コマンドシムがwaitではなくexecするよう修正され、SIGKILLなどのシグナルで終了したプロセスが誤った終了コード(137など)として報告される問題」が修正された。 技術的な詳細 pnpm 12はTypeScriptで書かれてきた従来のpnpmの内部実装をRustで刷新するプロジェクトで、コード名「Pacquet」として開発が進められてきた。メンテナーのzkochan氏によれば、v12における破壊的変更は最小限に抑えられており、v11と基本的に同じ挙動を維持しつつ、最大の変更点は内部実装のRustへの全面書き換えである点だとしている。実際、公式ブログ「What’s different in pnpm 12」でも、コマンド・フラグ・設定・ロックファイル形式はv11から引き継がれ、既存ドキュメントがそのまま両バージョンに適用できるとされている。 もっとも、いくつかの挙動の違いも明記されている。まず、グローバルにインストールされたNode・Deno・Bunを実行する際、常にグローバル版が使われるのではなく、プロジェクトがpin留めしたバージョンのランタイムが優先して使われるようになった。また、GitHubなどでホストされたGit依存関係の解決方法が変更され、指定子が単なる「選択肢」ではなく一意の「アイデンティティ」として扱われるようになった。さらに、pnpm install --resolution-onlyフラグは廃止され、代わりに新設されたpnpm peers checkコマンドを使う必要がある。開発チームの説明によれば、Rustエンジン(Pacquet)への切り替えにより、パッケージのフェッチとリンク処理などの内部処理がネイティブコードで実行されるようになり、体感速度の大幅な向上が見込まれている。 背景と今後の展望 pnpmは効率的なディスク容量管理とシンボリックリンクベースのnode_modules構造で知られ、npmやYarnと並ぶ主要なJavaScriptパッケージマネージャーの一つとして広く使われてきた。今回のRustリライトは、既存のCLI体験やロックファイル互換性を保ったまま、内部処理をよりパフォーマンスの高い言語基盤に置き換える試みであり、単なるメジャーバージョンアップというより実装基盤の刷新に近い。開発は8月上旬にベータ版からRC版へと移行しており、rc.3ではプロセス終了コードの報告に関する細かな不具合修正が中心となっている。互換性維持を優先する方針が明言されていることから、既存のpnpm 11ユーザーにとっては大きな移行コストなしに恩恵を受けられる可能性が高く、今後のRC版を経て正式版のリリースが待たれる。

概要 Modularは8月11日(米国時間)、Python風の高性能プログラミング言語「Mojo」の安定版1.0を正式リリースした。2023年の公開以来、初めての安定版リリースとなる。開発チームは「Mojoはもはや開発中の言語ではなく、我々が日々プロダクションで頼りにしている言語になった」と述べており、同社のMAXやModular Cloudといった商用インフラの基盤としてすでに実運用されていることを強調した。Mojoは、Pythonの読みやすさとアクセシビリティを保ちながら、Rustのようなメモリ安全性とC/C++レベルのシステムプログラミング機能を兼ね備えることを目指す言語で、CPU・GPU・ASICなど異種ハードウェアにまたがる高性能コードを単一の言語で記述できる「AI時代のシステム言語」と位置付けられている。開発をリードするのは、LLVM、Clangコンパイラ、Swift、MLIRの生みの親として知られるChris Lattner氏だ。 技術的な詳細 1.0リリースでは、これまで複数の書き方が併存していた言語仕様が整理・統一された。変数宣言はvarに一本化され、クロージャの表現も統合、ポインタ型も単一の形に整理された。新たにPython風の「lambda」構文によるインラインクロージャがサポートされたほか、List.appendが既存の参照を無効化するケースなどを検出するメモリセーフティ診断機能も追加された。開発体験の面では、VS Code連携を含む言語サーバープロトコル(LSP)の実装が大幅に改善されている。オープンソース化された標準ライブラリには、これまでに約190人のコントリビューターから1,100件を超えるプルリクエストが寄せられ、20万行以上のコードが変更されたという。Modularは「1.xの期間中、変更は基本的に追加的なものにとどめる」と表明しており、C++のような成熟した言語と同様、破壊的変更を慎重に管理する互換性方針を掲げている。同時にリリースされたMAXフレームワークのバージョン26.5では、必要な依存関係のみを選択インストールできるようインストール手順が簡素化されたほか、GLM-5.2やMamba-2ハイブリッドモデルのNemotron-Hへの対応も追加された。 背景と今後の展望 Mojoの核となる目標は、NvidiaのCUDAやAMDのROCmといったベンダー固有プラットフォームへの依存を減らし、異なるGPU・CPU・ASICなど異種システムを横断する統一的なAI開発環境を提供することにある。この文脈で注目されるのが、Modularが2026年6月にQualcommに買収された点だ。この買収を受けて、開発者コミュニティの一部からはMojoが「ベンダー中立的なAI開発プラットフォーム」であり続けられるのかという懸念の声が上がっていた。Modularはこうした懸念を払拭する動きとして、Mojoコンパイラとツールチェーンを2026年中に完全オープンソース化する方針を改めて明言している。標準ライブラリはすでにApache License 2.0(LLVM例外付き)で公開されており、Lattner氏は「Nvidiaをはじめとする各社がオープンソースコードに大規模に貢献しており、ベンダー間の干渉が働く余地は小さい」と述べ、中立性への懸念を否定した。今後の言語ロードマップとしては、堅牢な非同期プログラミングモデルや、パターンマッチング、ユニオン型といった機能の追加が予定されている。コンパイラのオープンソース化がいつ、どのような形で実現するかが、Mojoがベンダー中立なAI基盤言語としての信頼を維持できるかを占う重要な焦点となりそうだ。

概要 Rust開発チームは、次世代の借用チェッカー(borrow checker)「Polonius Alpha」をnightly版のコンパイラで有効化し、年内の安定化に向けたコミュニティによる実地テストを開始した。Rust開発者のJack Hueyによれば、現時点で既知の重大な性能低下やセキュリティ上の問題は確認されておらず、安定化を進めるのに十分な水準に達しているという。ユーザーはGitHubやZulip上のRustコミュニティを通じて問題を報告できる。 借用チェッカーとPoloniusの役割 借用チェッカーはRustコンパイラの中核をなすコンポーネントで、メモリ安全性をコンパイル時に保証するために参照に関する厳格なルールを強制する。具体的には、すべての変数が使用前に初期化されていることの確認、値の二重移動の防止、値が借用されている間の移動の禁止、可変借用中の他アクセスの制限、不変借用中の変更の防止といったチェックを行う。Poloniusはこの借用チェッカーを置き換える次世代実装であり、現行の非字句的ライフタイム(NLL: Non-Lexical Lifetimes)チェッカーでは借用エラーとして弾かれてしまう、実際には安全なコードパターンをより広く受理できるように設計されている。 開発の経緯と技術的な位置付け Polonius自体の開発は2018年から続く長期プロジェクトで、当初はDatalogベースの解析エンジンとして構想されていた。2023年になって新たな定式化が提案され、これによって既存のNLL実装を最小限に再構築するだけで実現できる見通しが立った。この新しいアプローチは拡張性を備えており、将来的にさらに多くの健全(sound)なコードパターンをコンパイル可能にする土台としても位置付けられている。今回nightly版で有効化されたのは、この再構築版の「Polonius Alpha」にあたる。 今後の見通し 安定化のスケジュールとしては2026年後半が見込まれている。従来のNLLチェッカーへの切り替え方法も引き続き提供されており、必要であれば設定ファイルでPoloniusを無効化することも可能だ。今回のnightly版での試験導入は、より広いユーザー層からのフィードバックを集め、安定版へのマージ前に潜在的な問題を洗い出すことを目的としている。

概要 GPU向けネイティブソフトウェアを手がけるVectorWareは8月10日、Rustの標準ライブラリが提供するポータブルSIMD(core::simd)をGPU上でそのまま実行できるようにしたと発表した。これにより、開発者はCPUとGPUの両方で修正なしに動作する、アーキテクチャに依存しない高性能なコードを記述できるようになる。VectorWareはこれまでRustのスレッドやasync/awaitをGPU環境に実装してきた実績を持ち、チームにはRustコンパイラチームのメンバーも参加している。 技術的な仕組み 今回の実装の核となる洞察は、GPUの実行単位である「warp」(32レーンで構成される並列実行グループ)が、本質的には単なるベクターユニットとみなせるという点だ。SIMT(Single Instruction Multiple Thread)の実行モデルはSIMDと本質的に同じであるとし、たとえば32個のf32を含むSimd<f32, 32>は、warpの32レーンそれぞれに1要素ずつ配置される。 要素ごとの加算・乗算といった操作は、Rust標準のAddなどのトレイト実装を通じて自動的にwarp命令へマッピングされる。reduce_sum()のようなリダクション処理はGPUのwarp shuffle命令でレーン間のデータ交換を行い、simd_swizzle!によるクロスレーンシャッフルも同じシャッフルプリミティブを利用する。またMask<T, N>はwarpレーン内の述語を表現し、vote/ballot命令に対応させることで、ループカウンターのようなスカラー値は全レーンで同一に計算される「uniform」として扱われる。これはISPCなど既存のデータ並列言語の概念を、Rustの型システムに組み込んだ格好だ。 VectorWareはwarpを独自の小さな「マシン」と捉え、Rustのジェネリクスやconst generics、トレイト境界を活用して中間表現(IR)を実装した。このIRはインタープリターを介さず、手書きPTXと同等のコストでネイティブ命令へ直接コンパイルされる点が特徴で、同じIRはCPU上でも実行可能であり、決定的な参照実装インタープリターとしても機能する。 対応アーキテクチャと制限事項 現時点ではNVIDIA GPUを主なターゲットとしているが、AMDのwavefrontやVulkanのsubgroupも同様のプリミティブを公開しており、この仕組みはCUDA固有のものではないとされる。IRはアーキテクチャに依存しない設計を志向している。 一方で、ポータブルSIMD自体がRustではまだ不安定な機能であり、利用には#![feature(portable_simd)]が必要となる。またwarp幅より狭いベクターを使うとレーンが遊んでしまい、逆に幅の広いベクターではより多くの命令が必要になる。任意の順列によるシャッフルは複数命令やshared memoryへのアクセスを要する場合があるなど、パフォーマンス面での制約も残る。「抽象化のコストはゼロ」とうたう一方で、warp幅に一致しない場合はコストが増加するとも注記されている。 今後の展望 VectorWareは、スレッド(warp間の並列性)、core::simd(レーン内の並列性)、非同期処理(並行性)を組み合わせた複合的な抽象化や、行列形状のSIMDを扱うテンソルコア対応、スカラーループを自動的にSimd操作へ変換する自動ベクトル化、CPU/GPUで共通のベクター表現の確立などを今後の課題として挙げている。将来的には複数のプログラミング言語やランタイムへの対応も視野に入れているが、高性能かつ信頼性の高いGPUネイティブアプリケーションの構築においてはRustが最適だとの見解を示している。

概要 Djangoのスチアリングカウンシルは、リリース体制を刷新する提案「DEP 20（Django Enhancement Proposal 20）」を承認した。Carlton Gibson氏が8月10日付のブログで発表したもので、2028年1月にリリース予定の「Django 2028」から、年1回のリリースサイクルに移行する。バージョン番号にはリリース年をそのまま用いる方式となり、以降は「Django 2029」「Django 2030」のように命名される。従来のような細かいマイナーバージョン番号ではなく、リリース年が版番号を兼ねる形になる。 新リリースサイクルの詳細 新体制の核心は、すべてのフィーチャーリリースが一律3年間サポートされる点にある。内訳は、リリース後1年目は一般的なバグ修正、続く2年間はセキュリティ修正とデータ損失に関わる重大なバグの修正のみを提供するというものだ。これにより、常に3つのバージョンが同時にサポートされる状態が保たれ、ユーザーは急いでアップグレードする必要がなくなり、サポート期間内であれば自分のペースで段階的に移行できるようになる。またサードパーティパッケージの開発者にとっても、対応すべきバージョンの見通しが立てやすくなるという利点がある。各リリースはリリース時点で最新の3つのPythonバージョンをサポートし、初年度中に新しいPythonバージョンへの対応も追加される。 LTS廃止の背景 これまでDjangoは、通常のリリースと長期サポート（LTS）版を区別してきたが、新体制ではこの「LTS」という呼称自体が廃止される。全リリースが同じ3年間のサポート約束を得ることになるため、特定のバージョンだけを「長期サポート版」として特別視する必要がなくなるためだ。LWNの記事のコメント欄では、期限ベースのリリースが定期的なサイクルの維持に役立つとしてDjangoの新体制を好意的に受け止める声がある一方、Symfonyのリリース体系（半年ごとのマイナーバージョンと2年ごとのメジャーバージョン、3年間のバグ修正と4年間のセキュリティサポートを伴うLTS版）を引き合いに出し、それを好ましいと評価する意見も見られた。 移行スケジュール 新体制への移行は段階的に行われ、2028年より前のリリースについては既存のサポート約束がそのまま維持される。具体的には、2026年8月リリース予定のDjango 6.1は2027年12月までサポートされ、2027年4月リリース予定のDjango 6.2はLTSとして2030年4月までサポートされる。そして2028年1月にリリースされるDjango 2028から新方式が適用され、2030年12月までサポートされる予定だ。続くDjango 2029は2029年1月のリリースから2031年12月までサポートされる見込みで、以降は毎年1月に新バージョンがリリースされるサイクルが定着していく。

概要 長年開発が続けられてきたOpenJDKの「Project Valhalla」が、大きな節目を迎えた。JDK 28にプレビュー機能として統合されたJEP 401「値オブジェクト（プレビュー）」は、Javaに新しいvalue修飾子を導入し、アイデンティティを持たないクラスインスタンス「値クラス（value class）」を定義できるようにする。最も注目すべき変更点は、値クラスのインスタンスに対して==演算子の挙動が再定義されることだ。従来のアイデンティティ・オブジェクトでは、==は「同一のオブジェクトを参照しているか」を判定していたが、値クラスでは「同じクラスで同じフィールド値を持つかどうか」を判定するようになる。この機能はプレビュー段階のため、--enable-previewフラグを付けてコンパイル・実行する必要がある。 値クラスの仕組みと==演算子の変更 値クラスは、複素数やピクセルの色、日付のように、本質的にはデータを運ぶためだけに存在する小さなクラスを想定した機能だ。value修飾子を付けて宣言すると、すべてのインスタンスフィールドが暗黙的にfinalとなり、コンストラクタが完了するまでにすべてのフィールドへの代入を終える必要があるという厳格な初期化ルールが課される。またインスタンスメソッドの同期化（synchronized）も制限される。レコード（record）にもvalue修飾子を付けられる。 最大の変更は==の意味だ。たとえば次のようなコードでは、従来ならp1とp2は別々のオブジェクトなのでp1 == p2はfalseになっていたが、値クラスではtrueと評価される。 Point p1 = new Point(3, 4); Point p2 = new Point(3, 4); assert p1 == p2; // true: 同じクラス、同じフィールド値 もっとも、これはequals()メソッドの使用を放棄する招待ではなく、「オブジェクトの比較にはequals()を使うべき」という通常のアドバイスは引き続き有効だとされている。 Project Valhallaの背景 JEP 401は、この問題を「開発者が意図することと、Javaが保証すること間の不一致」として位置づけている。複素数やピクセル色、日付を表す小さなクラスの多くは単なるデータの入れ物として使われているにもかかわらず、通常のJavaオブジェクトはアイデンティティによって定義されており、コンストラクタ呼び出しのたびに区別可能な別個のオブジェクトが生成されてしまう。この不一致を解消するため、OpenJDKの「valhalla-dev」メーリングリストで長年にわたり議論が重ねられ、今回のプレビュー実装に至った。 パフォーマンスへの最適化と注意点 値クラスの導入によって期待される主な成果は、JVMによる最適化だ。アイデンティティを持たないことで、JVMは値オブジェクトを構成フィールドに分割する「スカラー化」や、フィールドや配列要素にコンパクトな表現で直接格納する「フラット化」といった最適化を適用できるようになる。ただし、こうした最適化が常に適用されるとは限らず、適用されない場合は通常のオブジェクト割り当てにフォールバックする。フラット化はアトミック性の制約を受けるため、典型的なプラットフォームでは64ビット程度までのコード化が現実的とされる。またベンチマーク上の性能向上が保証されているわけではない点にも注意が必要だ。一方でセキュリティ面では、==やidentityHashCodeが間接的にプライベートフィールドの値を露出させる可能性があることや、大規模な値オブジェクトのツリー同士を比較する処理が無制限に時間を要しうることも指摘されている。 開発者への影響と今後の展望 開発者にとっては、新しいvalue修飾子の使い方を習得するだけでなく、==やsynchronizedの挙動変化によって予期しない動作に遭遇する可能性がある。またプリミティブラッパー型やLocalDateなど、JDKが提供する複数の「値ベース」クラスも今後この仕組みへ移行していくとみられる。関連するJEP 539「JVM内の厳格なフィールド初期化」では、バイトコード検証によって値クラスの構築ルールを強制する仕組みが導入される予定で、コンパイラの警告機能も拡充される見込みだ。今回のプレビューはJavaのオブジェクトモデルに重大な変化をもたらすものと認識されているが、開発者が実際に驚きに直面する頻度は限定的で、対応可能な範囲にとどまると見られている。

概要 MicrosoftとUno Platformは、.NET向け2Dグラフィックスライブラリ「SkiaSharp」の4系における最初の安定版として、バージョン4.148.0と4.150.0をリリースした。あわせて4.151.0のプレリリース版も公開されている。今回の刷新で最も重要なのは、パッケージのバージョン付けをChromeのリリースチャンネルが使用する上流Skiaのマイルストーンに合わせる新方針を採用した点だ。安定版はChromeのStable/Extended Stableマイルストーンに、プレリリース版はChrome Betaに追従する形となり、従来の3.119ブランチが上流から数マイルストーン遅れていた状況を解消し、更新の予測可能性を高める狙いがある。 技術的な詳細 最初の安定版となる4.148.0では、バンドルされるSkiaエンジンをm148に更新し、OpenTypeの可変フォント軸制御やカラーフォントのパレット選択に対応したほか、SKWebpEncoderによるアニメーションWebPエンコードを新たに導入した。また共有ネイティブオブジェクトのライフサイクル管理を見直し、use-after-freeによる障害を低減している。パフォーマンス面では、GPUレンダリングのUIで最大24%の性能向上、CPUベースのPerlinノイズシェーダーでは約6倍の高速化が報告されている。 7月7日にリリースされた4.150.0ではSkia m150へと進み、SKPaint.GetFastBounds()をはじめとするグラフィックス診断APIや画像フィルタリング関連のメソッドが追加されたほか、SKSurface.Canvasラッパーをキャッシュしてアロケーションを削減する改善が加えられた。一方でこのバージョンでは、.NET InteractiveおよびPolyglot Notebooks統合パッケージが削除されている。 プレリリース段階の4.151.0はSkia m151に対応し、ホットパスにおけるP/Invoke呼び出しをマネージドな整数演算に置き換えたほか、アロケーションフリーなReadOnlySpanオーバーロードを追加した。さらに.NET WebAssembly向けにEmscripten 5.0.6を同梱するなど、Web/WebAssembly方面での最適化も進められている。 破壊的変更と移行における注意点 今回のリリースでは互換性に関わる変更も含まれている。SKPaintの非推奨テキスト・フォント関連メンバーはコンパイルエラーとなるため、開発者はSKFontへの移行が必須となる。既存プロジェクトでSkiaSharpをアップグレードする際は、この非推奨APIの利用箇所を事前に洗い出しておく必要があるだろう。上流Skiaのマイルストーンに追従する体制により、今後は最新のSkia機能や修正がより速やかに.NETエコシステムへ反映されることが期待される。