GitHubで公開されている Endive は、ひとことで言うと Java Virtual Machine（JVM）上で動く WebAssembly runtime です。
WebAssembly、略して Wasm は、もともとブラウザ向けの高速な実行形式として広まった技術ですが、いまではブラウザの外でも注目されています。
「いろんな言語で書かれた部品を、安全に、軽く、どこでも動かしたい」という欲求にかなりハマるからです。
Endive の説明を読むと、かなりはっきりした思想があります。
Javaの世界でWasmを“普通に”使えるようにしたい、しかも native code に頼らずに、という方向です。
ここ、私はかなり重要だと思います。
Javaって、長年「一度書けばどこでも動く」という強みで戦ってきた言語です。そこにわざわざ native library を持ち込むと、せっかくの気軽さが一気に崩れます。Endive はその面倒をできるだけ消そうとしているわけで、発想がかなり気持ちいいです。
元記事では、既存のWasm runtimeとして v8、wasmtime、wasmer、wasmedge、wazero などが挙げられています。
どれも強力ですが、Javaアプリに組み込むとなると別の壁が出ます。
Javaのライブラリを配るとき、普通は jar などを渡せば済みます。
でも native runtime を一緒に使うとなると、OSやCPUアーキテクチャごとの native ファイルも必要になります。
つまり、
みたいな組み合わせを考えないといけない。
これ、地味ですが本当にしんどいです。
「Javaなのに、なんで急に配布マトリクス地獄が始まるの？」となりがちです。
native runtime を呼ぶときは、たいてい FFI（Foreign Function Interface、別言語の関数を呼ぶ仕組み）を使います。
すると、JVMの外の世界に足を踏み出すことになります。
それ自体が悪いわけではありません。
でも、JVMの中にある 安全性 や 観測性、つまり「何が起きているか追いやすいこと」が弱くなりやすい。
Endive はそこを避けて、純粋な JVM runtime として完結させたいという考えです。
これはかなり筋がいいと思います。
「Javaらしさ」を捨てずにWasmを持ち込みたいなら、むしろこういう方向が自然です。
READMEには、Endiveの目標がはっきり書かれています。
「default runtime for Wasm on the JVM」を目指す、というのはかなり野心的です。
ただ、目標としてはすごくわかりやすい。
“JavaでWasmを使うならまずEndive” みたいな立ち位置を取りたいのでしょう。
個人的には、この “自然に使える” という言葉が好きです。
技術は性能だけで勝つわけではなくて、最後は「使うのが楽かどうか」で広がり方が決まることが多いからです。
READMEには、Completed と Ongoing が整理されています。
ここを見ると、ただのアイデア段階ではなく、かなり実装が積み上がっているのがわかります。
ざっと見るだけでも、かなり本格的です。
Wasmの仕様って、見た目よりずっと広いです。単純な「コードを実行する」だけではなく、メモリ、例外、スレッド、SIMD、GC まで入ってくると、一気に実行系としての難易度が上がります。
そのうえで、これだけの項目が completed に入っているのは、かなり頼もしいです。
やはり次の焦点は 性能 と WASIの次世代対応 という感じです。
WASI は、Wasmに「ファイルやネットワークなどの世界とのやりとり」を与える仕組みです。
ざっくり言えば、Wasmをただの計算エンジンではなく、実用アプリとして使うための土台ですね。
Endiveの背景には、「WasmをJavaで使いたい理由」があります。
READMEでは、Javaにネイティブランタイムを持ち込むと配布と実行の面で面倒が増える、と説明されていますが、裏を返すと、Javaユーザーは “安全で、依存が少なくて、運用しやすい” ものを求めている、ということでもあります。
そこにWasmはかなり相性がいいです。
Wasmは、ざっくり言えば “サンドボックス化された実行形式” です。
サンドボックスというのは、アプリを小さな安全な箱の中で動かすイメージです。
暴れにくい、壊しにくい、持ち運びやすい。そういう性質があります。
JavaのJVMももともと安全な実行環境として知られています。
その上にWasm runtime を純JVMで載せるのは、思想としてかなり一貫しています。
「安全な箱の中で、安全な箱を動かす」みたいな構図で、少しややこしいけれど、方向性はきれいです。
READMEの内容を見る限り、Endiveは次のような人に刺さりそうです。
逆に言うと、
「とにかく最速のWasm runtimeがほしい」
「すでに native runtime をうまく運用できている」
という人には、必ずしも第一候補ではないかもしれません。
ただ、Javaの世界では性能だけでなく 運用の軽さ がかなり重要なので、この設計方針は十分に価値があると思います。
正直、Endiveはかなり面白いです。
特に、**“JavaでWasmを動かす”ことを、ちゃんとJavaらしくやろうとしている** のがいい。
多くの技術は「できること」を増やす方向に進みますが、Endiveはむしろ “余計な複雑さを増やさない” ことに価値を置いているように見えます。
この発想は地味だけど強いです。実運用では、派手な最適化より「壊れにくさ」や「配布しやすさ」のほうが効くことが多いからです。
また、Bytecode Alliance の文脈にあるのも大きいです。
Wasmを単なる流行語ではなく、実際のソフトウェア基盤として育てていく流れの中にある、という安心感があります。
もちろん、そこから先に広く普及するかどうかは別問題ですが、少なくとも方向性はかなり筋が通っています。
Endiveは、JVM上でWebAssemblyを動かすためのpure Java寄りの runtime です。
ネイティブ依存を避け、Javaの安全性や運用のしやすさを保ったままWasmを使えるようにする、というのが最大の魅力です。
「Wasmを使いたい。でも native の配布やJNIはできれば避けたい」
そんなJava開発者にとって、Endiveはかなり有力な選択肢になりそうです。
まだ発展途上の部分はありますが、すでに対応範囲はかなり広く、目標も明快。
これは単なる実験ではなく、**“JavaでWasmをちゃんと使う未来”** を本気で作りにいっているプロジェクトだと感じました。
参考: GitHub - bytecodealliance/endive: A JVM native WebAssembly runtime
