WebAssembly と JVM の違いは何ですか?

本質的に、JVM と WebAssembly はどちらも、コンパイルされたコードをほぼどこでも実行できるように設計されていました。JVM の場合、これは当時としては前例のない、さまざまなオペレーティング システムや CPU アーキテクチャを搭載したマシンを意味し、WebAssembly の場合、これは今後いつでも、あらゆる場所のあらゆるコンピューター上のあらゆる Web ブラウザーを意味しました。

1990 年代半ばに Java とともに導入された JVM は、ガベージ コレクション、広範な標準ライブラリ、管理実行用のツールなど、豊富なランタイム サポートを提供する本格的なプラットフォームへと進化しました。 しかし、これによって JVM がかなり肥大化し、メモリ使用量が大きくなり、起動時間が遅くなると言う人もいるかもしれません。 非常に強力ですが、これにより JVM は軽量applicationsには適さなくなります。

対照的に、WebAssembly は Web を念頭に置いて設計されており、特にブラウザー内でコードを実行することを目的としています。 その結果、軽量なランタイムと超高速の起動時間を優先するように設計されましたが、豊富なランタイム サポートは提供されませんでした。 ブラウザのみをターゲットにすると、Wasm の移植性は Java バイトコードよりも低くなりますが、現在ではスタンドアロンの Wasm ランタイムは Web の外部でも実行できるため、サーバー側applications、組み込みシステム、エッジ コンピューティングに新たな可能性が開かれています。 さらに、WebAssembly にはガベージ コレクションなどの限定的な追加ランタイム サポートが導入される予定ですが、JVM が提供するランタイム サポートのすべてが WebAssembly でサポートされる可能性は低いでしょう。

JVM は、Java、Kotlin、Scala などの言語ファミリーでのみ動作します。これらの言語はすべて、JVM 上で実行されるように意図的に設計されています。 Java エコシステムには広範なライブラリとフレームワークがありますが、相互運用性はこれらの JVM 言語間でのみ実現されます。 JVM ベースのapplicationsはネイティブ コードを呼び出すことができますが、多大な労力と注意が必要です。

WebAssembly は、1 つのプログラミング言語のみをサポートするように、または関数型、ガベージ コレクション型、インタープリタ型など、特定の言語スタイルを優先するように設計されたものではありません。 Rust、JavaScript、Python、C++ など、あらゆる言語を Wasm ランタイムで実行するようにコンパイルできます。 これは、これらの各言語のコードが現時点で相互に通信できることを意味するわけではありませんが、新しいコンポーネント モデル標準を通じて、開発者は異なる言語で記述された複数の Wasm モジュールを取得して、それらをシームレスに接続することができます。 まもなく、WebAssembly ではリンクと相互運用性が実現されます。

プラグインやカスタム ロジックを実行するために JVM をapplicationに埋め込むという話を最後に聞いたのはいつですか? 最近、いや、今まで一度もなかったですよね？ JVM は強力ですが、他のapplicationsに組み込むのは非常に難しいことで知られています。 いくつかの注目度の高い埋め込み（ブラウザ内の Java アプレットなど）が行われました。しかし、それらは扱いにくさや保守性の問題から、ほとんど使用されなくなりました。

一方、WebAssembly は埋め込み性を重視して設計されています。 Wasm ランタイムをapplicationに埋め込むのは、多くの場合、新しいライブラリを取り込むのと同じくらい簡単です。 これが完了すると、applicationはWasm コードを実行できるようになります。これにより、ゲーム エンジンを拡張したり、アルゴリズムを変更したり、イベントに応答したり、その他思いつく限りのあらゆることが可能になります。 Wasm は、JVM が提供できない (または提供したくない) 埋め込みの多様性を提供します。

おそらく、WebAssembly が最も輝くのはここです。 JVM には独自のセキュリティ モデルがありますが、実行されるコードが信頼されているという前提で設計されています。 WebAssembly は根本的にその前提を否定します。Web サイトにアクセスすると必然的に信頼できないコードがダウンロードされて実行されるブラウザーで生まれ、Wasm はデフォルトで厳格な拒否のサンドボックス モデルを採用しています。 明示的に承認されない限り、システム リソース、メモリ、またはその他の機能へのコード アクセスは許可されません。 このアプローチにより、攻撃対象領域が本質的に最小限に抑えられ、信頼できないコードの実行が懸念される環境に Wasm が最適になります。

JVM のセキュリティ モデルは機能しますが、Wasm が提供するセキュリティ レベルに合わせて設計されていません。

JVM はテクノロジーの世界ではベテランです。 数十年の歴史を誇り、圧倒的な導入率、幅広いエンタープライズ ツール、そしてソフトウェア開発において揺るぎない力のように感じられるほどの巨大なコミュニティに支えられた .NET は、当分の間消滅することはないと私たちは考えています。 使用ケースにおいて寿命の長さと実証された安定性が重要であれば、JVM がそれを実現します。

一方、WebAssembly はまだ新参者です。 Wasm はまだ誕生して 10 周年を迎えたばかりですが、その熱狂は飛躍的に高まっています。 現時点では JVM ほど成熟していませんが、WebAssembly の軌跡は明るい未来を示唆しています。

WebAssembly と JVM はどちらも素晴らしいテクノロジーであり、それぞれの環境やユースケースに適した優れた機能を備えています。 JVM は、本格的なapplicationsと豊富なランタイム機能が重要となるエンタープライズ ワークフローで活躍します。 一方、Wasm の埋め込み可能性、軽量ランタイム、言語間の互換性、比類のないセキュリティは、プラグインやエッジ コンピューティングにとって魅力的な選択肢となります。

それで、どれを選ぶべきでしょうか? 堅牢なランタイム ニーズを持つスタンドアロンapplicationsを開発している場合、JVM は依然として実用的かつ実績のある選択肢です。 しかし、言語間の柔軟性や既存のアプリに簡単にプラグインする機能が必要な場合は、WebAssembly が有利になるかもしれません。