【ITニュース解説】The Cost of Concurrency Interop: Trading Clean Modularity for Shared JVM Efficiency

このニュース記事では、異なるプログラミング言語であるKotlinとJavaを、同じコンピュータの実行環境（JVM）上で効率的に連携させる方法と、その際に生じる設計上の課題について詳しく説明する。著者は、自身の開発した二つの並行処理ライブラリが、異なる言語で書かれていながらも全く同じように動作することを証明するため、特殊な連携の仕組みを構築した。この実験は、技術的には成功したものの、長期的なシステム設計において考慮すべき重要な問題点を明らかにしたのである。

コンピュータのプログラムは通常、上から下へと順番に処理を実行していくが、複数の処理を同時に進めたい場合がある。これを「並行処理」と呼ぶ。例えば、ウェブブラウザでページを表示しながら裏で画像をダウンロードするような状況だ。Kotlinの「コルーチン」やJavaの「仮想スレッド」は、このような並行処理を効率的かつ安全に実現するための仕組みである。特に「構造化並行処理」は、複数の並行タスクが相互にどのように影響し合うか（例えば、あるタスクが失敗したら関連する全てのタスクを停止させるなど）を明確に定義し、複雑な状況でもプログラムを管理しやすくする手法である。

著者は、自身の開発したJava用の「JCoroutines」とKotlin用の「ABCoroutines」という二つの並行処理ライブラリが、全く同じルールで動作することを検証したかった。見た目のAPIが似ているだけでなく、例えば処理のキャンセルやタイムアウト、エラーが、それぞれ異なる言語のライブラリ間でも正確に伝播されることを確認する必要があったのだ。そこで、通常は行わないような挑戦として、この二つの並行処理エンジンを同じJVM上で動作させ、あたかも一つのシステムであるかのように振る舞うことを検証する仕組みを作り上げた。これが「abcoroutines-jcoroutines-interop」と呼ばれる軽量な橋渡し層である。

この橋渡し層は、Kotlinの並行処理の書き方をJavaの並行処理の書き方に合わせたり、その逆を行ったりするための「カスタムインターフェース層」として機能した。具体的には、「機能アダプター」と呼ばれる小さな部品を使い、Kotlinのコルーチンとして書かれたブロックをJavaの呼び出し可能な形式に、あるいはその逆へと変換できるようにした。これにより、両方のライブラリは仮想スレッドや処理の範囲（スコープ）といった実行環境を共有し、あたかも同じ言語で書かれたかのように連携して動作することが可能になった。記事内の例では、KotlinのコードがJavaの並行処理の作法に従って記述されたコルーチンを作成し、それをKotlinの環境で実行して、その振る舞いがJavaのそれと全く同じであることを検証する様子が示されている。これは単に異なる言語の機能を呼び出すというよりも、一方の言語がもう一方の言語の並行処理のセマンティクス（意味論、振る舞い方）を内部で再現している状態に近い。この手法は技術的には完璧に機能し、二つのライブラリが同じ構造化並行処理の法則に従うことを明確に証明できた。

この連携の仕組みは、テストの観点からは非常に有用であった。異なる言語で書かれたコード間の振る舞いが完全に一致することを確認でき、また、Javaのコードを少しずつKotlinに移行していく際の「足場」としても機能した。既存のテストが無効になることなく、段階的な移行が可能になったのである。しかし、この橋渡し層は「移行のための足場」であり、長期的にシステムの一部として残しておくべきものではないと著者は述べている。その理由は、このような深いレベルでの連携は、システム全体の設計に大きな影響を与えるからだ。具体的には、この橋渡し層は、本来ならば明確に区別されるべき異なるサブシステム（例えばKotlinのコードとJavaのコード）間の境界を曖昧にしてしまう。これにより、両者が同じ実行環境の状態を共有することになり、どのコードが実行の責任を持つのか、または処理のキャンセルをどのタイミングで行うのかといった所有権が不明確になる。

さらに深刻な問題として、このような連携が恒常的に行われると、システム内に「暗黙的なライフサイクル結合」が生まれる。これは、ある片方のコードの変更が、もう片方のコードの動作に予期せぬ影響を与える可能性を意味する。また、両方の言語がお互いのアダプターを呼び出すようになると、「循環依存性」という問題が発生する。これは、Aという部品がBという部品に依存し、同時にBという部品がAという部品に依存するという状態だ。このような循環依存性は、プログラムの起動順序を複雑にし、長期的な改修（リファクタリング）を非常に困難でコストのかかるものにする。著者は、これらの設計上の問題点を承知の上で、あえてこのような深い結合を作り、そのコストを測定し、両ライブラリの等価性を証明したのである。

この経験から得られた教訓は、非常に重要である。意図的な結合、つまり特定の目的のために一時的にシステムを深く連携させることは、研究や問題の診断、あるいは移行のプロセスにおいては許容される。しかし、それは決して最終的なAPI設計や、恒久的なシステム統合の形とするべきではない。「ExposeAsKotlin」のようなアダプターは、一時的な移行のための強力なツールではあるが、安易にシステムの永続的な統合に用いると危険であると著者は警告している。システム設計の成熟度とは、このような「近道」が単なる「足場」なのか、それとも永久的な「土台」になるべきものなのかを見極める能力を指す。特に、互いの言語がアダプターを通じて相互に依存し合う「循環的認識」は避けるべきである。一度このような状態になると、本来守られるべきシステムの境界は事実上消滅してしまう。

クリーンなアーキテクチャとは、決して境界を全く破らないことではない。重要なのは、なぜその境界を一時的に破ったのか、そこから何を学んだのか、そしてその橋渡し役をいつ解体すべきかを知っていることである。一時的に構築された連携は、その目的を果たしたら速やかに取り除く「解体計画」を持つべきだと結論付けている。この記事の教訓はKotlinやJavaに限らず、ランタイムを共有することで便利さと引き換えに設計の整合性を失いやすい、あらゆるプログラミング言語やシステムに共通する普遍的な原則である。