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），但人工智能正变得越来越个性化，并融入我们的日常生活。随着人工智能和代理迁移到我们的个人设备，通过互联网服务路由一切的传统模式变得不那么理想。请考虑以下场景：
- 你的银行应用程序不需要向远程财务代理发送报表
- 您的健康应用不应将个人记录传输给外部远程医疗代理
- 个人信息应保密
Wasm 二进制 servlet 可在设备上无缝运行，完全沙盒化（仅授予对 Google Maps API 的访问权限），并且执行速度很快。