Java 無法輕鬆訪問本機工具用來沙盒化其外掛的平臺特定安全機制（seccomp 等），因此在純 JVM 庫中擁有 WebAssembly 精心設計的安全模型是很好的。
Chicory 似乎非常有用。
人們最初以為 Chicory 是使用 WebAssembly 的 JVM 替代品（例如，使用 WebAssembly 在現代瀏覽器中執行 Java 小程式）。
它實際上是一個 WebAssembly 執行時，用於在 JVM 上執行 WebAssembly 程式碼。
JVM與WASM比較
把 JVM 和 wasm拿來比確實挺難的，因為它們倆差得太多了，用的地方也完全不一樣。
wasm 帶來的核心東西就是專注解決一個問題：抽象出安全的沙盒計算環境。它最大的好處就是不像成熟的執行時環境那樣揹著一堆負擔，也不會拖著很多跟系統打交道的隱形管道。
這就讓 wasm 變得很靈活，能用在 Java 永遠搞不定的一些場景裡——比如把可插拔的邏輯小塊塞到高頻粘合程式碼裡。
Wasm 加上一些資料庫 API，就能變成一個純粹的儲存過程計算抽象，客戶端可以隨便指定，而且還很安全。
Wasm 再加上一個簡單檔案 API（假設就處理單個底層檔案）再加上一個流 API（假設就輸出單個流），這就成了一個類似 S3 服務的漂亮管道，能讓你在下載資料前，先在伺服器上動態處理檔案。
在很多情況下，“X + 可插拔沙盒計算”都能讓底層的 X 變得威力翻倍。
wasm 的未來不是把那些特別老派的系統 API 接到它上面（雖然這種用法也會存在）。
wasm 真正的牛勁兒和影響力在於，整個軟體架構都能圍著“移動程式碼”這個概念搭起來，而這個移動程式碼的簽名（也就是執行時需要的外部 API）可以根據不同的用法隨便變。
掉坑
複雜的介面加上垃圾回收（GC）再加上多執行緒，這意味著 WASM 可能會（而且很可能會）掉進跟 JVM 一樣的坑裡。
Java Applet的安全問題翻車，不是因為它的模型本身壞了，而是因為它功能太多、跟主機的介面太豐富，結果給一堆實現上的錯誤開了大門。
像 Rust 這種“記憶體安全”的語言在這兒其實幫不上啥忙，當然你要是把 JIT（即時編譯）加進來，那就更沒轍了。
確實有辦法搞出能證明正確性的 JIT 虛擬機器，但這得花老鼻子力氣了，而且現在最流行、跑得最快的虛擬機器壓根兒不是按這種架構寫的。
WASM 背後的最初想法是把虛擬機器的語義定義得特別簡單，簡單到在實際中都不用費勁去實現正確性和安全性；尤其是在用現成的 JavaScript 虛擬機器引擎的時候。
Chicory vs. GraalWASM
今年，Oracle 的 GraalWASM 宣佈“已準備好投入生產”：
- Chicory 的純直譯器 注重簡單性和可移植性，但也有一個代價：效能較慢。
- GraalWASM GraalWasm 使用 Graal JIT（如果可用）將 WASM 直接編譯為機器程式碼，從而提供出色的效能。
- Chicory 的 AoT 轉換器 生成純位元組碼工件，可在任何標準 JVM 上實現具有競爭力的效能。
Blazor
微軟針對 WebAssembly 和 C# 製作的最好的工具之一是 Blazor。
開發人員可以專注於構建 Web 應用程式，並在前端和後端使用 C#，並在伺服器端或 WASM 上驅動 UI，而不會錯過任何一個節拍。本質上繞過了對 JavaScript 的需求。
使用 Gemini 和 Chicory 在 Android 上執行 MCP 伺服器
Chicory 是能夠在 Android 上執行新流行的 MCP 伺服器的方法！
WebAssembly 是這項技術的基礎。您在伺服器上安裝的每個 servlet都由 Wasm 二進位制檔案提供支援：根據您首選的MCP 客戶端的請求獲取這些二進位制檔案並執行命令。
雖然外部服務呼叫通常是必要的（例如我們的演示中使用了 Google Maps API），但人工智慧正變得越來越個性化，並融入我們的日常生活。隨著人工智慧和代理遷移到我們的個人裝置，透過網際網路服務路由一切的傳統模式變得不那麼理想。請考慮以下場景：
- 你的銀行應用程式不需要向遠端財務代理傳送報表
- 您的健康應用不應將個人記錄傳輸給外部遠端醫療代理
- 個人資訊應保密
隨著本地 AI 能力的擴充套件，我們將看到更多完全在裝置上執行的 AI 系統，並且它們的支援工具也必須隨之跟進。
Wasm 二進位制 servlet 可在裝置上無縫執行，完全沙盒化（僅授予對 Google Maps API 的訪問許可權），並且執行速度很快。