播客：WebAssembly在JVM上的演进——功能、性能与迁移至Endive

文字记录

Olimpiu Pop：大家好。我是 Olimpiu Pop，InfoQ 编辑。在我面前的可能是软件开发者中我最喜欢的一位，活泼开朗。他就是 Andrea Peruffo。Andrea 是一位资深开发者，做过很多有趣的事情，但我还是让 Andrea 自我介绍吧。

Andrea Peruffo：大家好。谢谢你邀请我，Olimpiu。很荣幸来到这里。我已经从事软件开发 20 年了。我做过很多事情，尤其是在 JVM 上，过去用 Scala，最近用 Java。把 WebAssembly 带到 JVM 上，这大概是你最近最常听我讲的事情。

Olimpiu Pop：是的，没错。不过至少在过去两年里，我们的大多数对话都相当细分（如果你愿意这么说的话），尽管人们也在争论它到底有多么“细分”。这些对话主要围绕 WebAssembly，以及你加入了一群认为 WebAssembly 不应该只待在浏览器里的人——基于你在 Java 方面的背景，你可以把它用到服务器端。但让我们一步一步来。为什么我们要把 WebAssembly 带出浏览器？因为它以 JavaScript 方面而闻名。我们就从那里开始。什么是 WebAssembly？

将 WebAssembly 带到服务器端 [01:58]

Andrea Peruffo：谁不想要免费午餐呢？我想要。所以，所有为浏览器中的 WebAssembly 开发的东西，理论上都可以在服务器端复用。在前端，遵循 W3C 规范，如今我们在每个足够复杂的应用里都会用到 WebAssembly。例如，它为 Google Maps、整个 Google Docs 套件以及生产力工具提供支持。它们都靠 WebAssembly 支撑。所以，它最初是为了前端而生的，为前端和客户端中一些受限环境提供几乎接近原生的速度。但是，为这个平台构建的一切都可以在后端复用。我认为这是最强大的地方。这也是驱使我更深入研究 WebAssembly 的主要原因之一。我不喜欢重写东西。我喜欢尽可能多地复用。当我审视可用的技术时，WebAssembly 显得尤为突出，它能让你所做的工作产生更广泛、更深远的影响。去年，我已经成功交付并发布了数据库、编程语言（如 CPython、JavaScript），以运行各种 Rust 和 C 库，还有 protobuf。你可以运行大量真正有用的东西，而不必重写它们。而且只需要非常非常薄的一层包装，你也不需要离开 JVM，免去 JNI 带来的种种麻烦。所以，如果你想在 JVM 上支持更多工作负载和更有趣的东西，这是一个很自然的选择。

Olimpiu Pop：好的。所以，在这些特定场景中，通常你需要从 Java 调用本地库，现在你可以用 WebAssembly 把它们整合起来，让你的生活更轻松。也许不仅仅是轻松，我认为还更安全，因为这是 WebAssembly 的重大诉求和承诺。

Andrea Peruffo：是的。而且不仅仅是更安全，更安全是因为它当然运行在不同的 API 上。所以，你的程序可以免受所嵌入库的 CVE 影响，同时也具有可移植性。使用 JNI 时，你必须为所有目标操作系统和架构预编译本地库。但使用 WebAssembly，你只需要一个目标。以 WebAssembly 为目标，意味着你最终得到一个完全可移植的 JAR，可以随处用在 JVM 能去到的地方。所以，你获得了可移植性、安全性，而且比做 JNI 容易得多——JNI 会搞崩你的 JVM，还会出现各种异常行为。我人生中做 JNI 已经够多年了。

Olimpiu Pop：好吧，说得对。所以，现在这是对 JNI 的复仇，你要让它们看看事情正在如何变化。我得承认，我之前没有太关注 WebAssembly/WASI 领域发生的事情。我知道一年前——我想上次我们见面的时候——有几件大事正在发生。也许让我们做个总结，看看 WebAssembly 在标准方面处于什么位置，WASI 那边又发生了什么。还有可能是你的“宠物项目”，Chicory。

WebAssembly 和 WASI 的当前状态 [05:40]

嗯，它已经不是宠物项目了，因为这是一个完整的项目。现在已经有两三年了，从达到 1.0 版本算起。但我们一个一个说。现在 WebAssembly 处于什么状态？WebAssembly/WASI 领域最重要的事情是什么？因为显然，要想有有用的东西，WASI 系统接口非常重要。否则，我们在服务器端做不了多少事情。

Andrea Peruffo：我们在 WASI 方面的进展是，核心规范基本已经完成了。所以，他们整合了所有提案，也就是所谓 WebAssembly 的提案，这些提案是让更多语言在该平台上运行所必需的。因此，WasmGC 垃圾回收已被整合，多内存以及许多其他功能也被整合。这些提案奠定了坚实的基础。它被称为 Wasm 3，即 0.3 版本，是支撑 Wasm 之上其他一切的核心基础。在 Chicory 中，我们兼容所有这些规范，或者大部分规范，只要在服务器端有意义的规范都兼容。我们也有了 WasmGC 的初步实现。这意味着什么？这意味着你可以再次在 JVM 上运行一些语言，通过 Wasm 运行诸如 Scala（借助 Scala.js 编译为 WebAssembly GC）、Kotlin、Dart 这类语言。因此，我们启用了一类新的语言，使其能够在 WebAssembly 引擎之上运行。

谈到 WASI，系统接口正在被完全重新设计。所以，WASI P2 几乎已经定稿，他们正在开发 WASI P3，其中整合了组件模型，相关工具和工具链也正在逐渐适配。组件模型意味着什么？意味着你可以用 WIT 文件（一个接口文件）编写程序的接口，并生成其他所有内容，从而将你的应用与任何其他 WebAssembly 组件组合起来，这真的非常迷人。我期待看到它在实践中如何发挥作用，届时会有许多来自不同生态系统的模块协同工作。所以，这是非常令人兴奋的工作。我已经等不及看它如何发展了。

Olimpiu Pop：所以，如果从版本来讲，不仅仅是 Java 里的 Chicory，它们已经相当先进了。我现在说的是 WebAssembly 对许多其他编程语言的目标支持。Wazero，我知道它是这个领域的老前辈。Chicory 也不甘落后，因为从版本号来看，它已经有好几年了。不过你知道在生产环境中的采用情况吗？它是否被使用，用在哪里？为了更具体一点，说说使用案例吧。

WebAssembly 在生产环境中的应用 [08:46]

Andrea Peruffo：WebAssembly 最大的应用场景已经被所有主要 CDN 提供商所采用。所以，如果你看 Cloudflare、Fastly 和 Akamai，它们基本上都建立在这项技术上，或者那些能够运行 WebAssembly 工作负载的边缘公司。这意味着 Cloudflare 的 Durable Objects 以及 Fastly 和 Akamai 的 edge compute 也在其上运行你的代码，都运行在 WebAssembly 上。这意味着，没有其他技术能够在如此小巧的环境中以如此高的密度和安全性来运行这类工作负载，对提供商而言也是如此。所以，提供商能够让你把任意的应用部署到他们的基础设施上，并且他们能够借助 Wasm 运行它，因为 Wasm，即 WebAssembly 的轻量级沙箱，在这其中发挥了重要作用，让你无需危及底层平台就能运行任何你想要的工作负载。所以，WebAssembly 已经在这个领域获胜了。在前端，当然，所有需要在 CPU 上完成某些任务的网站都在使用它；如果你需要做任何渲染、任何加密算法，或者任何 CPU 密集型计算，你可能就在使用 WebAssembly。而在服务器端，有各种各样的用法。例如，你提到了 Wazero。最近他们宣布 Wazero 被集成到 Helm 4 中，这样你就可以通过注入 WebAssembly 插件来定制 Helm 的行为。所以，它使得不同系统能够在平台之上实现可插拔。例如，说到 Chicory 为 Trinodp 中的 CPython UDF 函数提供支持，这是一个用 Java 编写的 SQL 数据库，用于处理大量数据，而且是一个很棒的数据库；它让你能够用 WebAssembly 驱动的 CPython 函数在生产环境中运行，这从我们第一个 1.0 版本开始已经有好几年了。

Olimpiu Pop：不错。另外，我知道几个月前你整理了一批有趣的东西，放到 Chicory 上跑，只是想看看效果。对全球社区来说，其中一个非常重要的方面是你成功让复古游戏 DOOM 在 WebAssembly 上运行。我想还有其他不那么重要的事情你也做到了，但这件相当重要。也许你可以分享一下这段经历，如果你还想提其他事情也行。

真实使用案例：Doom 和 Prism [11:44]

Andrea Peruffo：是的。实际上，DOOM 是我们最早运行起来的工作负载之一，我们当时非常兴奋。有人做了个黑客马拉松，把 DOOM 移植到 GraalWasm 上运行，那是由 GraalVM 团队做的。而我们几乎是在项目一开始就很容易地让它跑在了 Chicory 上。另一个与我心相连的项目是 Prism。Prism 是 Ruby 组织在 GitHub 下的项目，是一个用 C 编写的 Ruby 解析器，为 JRuby 提供支持。基本上，我们从第一天起就把这个 Ruby 解析器编译成 Wasm，然后在 Java 中执行它。基本上，我们有两位朋友，Charles Nutter 和 Thomas Enebo，他们是 JRuby 的领导者。他们当然希望让 JRuby 能随处运行。而要让 JRuby 运行起来，首先要做的第一件事就是解析它的语法。但 Ruby 的语法是为人类设计的，极难解析。所以，在过去的岁月里，各个生态系统中出现了多个解析器，又不断消亡，而最近他们决定把所有资源投入到创建一个官方解析器上。这个解析器名叫 Prism。我们希望能够在任何 JVM 上解析 Ruby 语法，而无需安装本地库。这就是我们开始做 Chicory 的原因。酷的一点是，这个项目伴随 Chicory 的发展走过了好几年。这个真实的 C 解析器是我们最早在解释器上运行的载荷之一。我们通过使用编译器将性能提高了 10 倍，将其编译为 Java 字节码。我最近发布了一个新的编译器，它改为生成纯汇编，这又在 Prism 上将性能提高了 10 倍，使其与原生版本非常有竞争力。这只是一个例子。如果你愿意，我还有无数其他例子。

Olimpiu Pop：我知道你是个健谈的意大利人，我是个健谈的罗马尼亚人，两个拉丁人通过 Zoom 聊天，但一百万个有点太多了。所以，如果你还有其他想推的，我记得 Prism 那个。我知道那是去年年中。你相当自豪，因为那是第一个在 Web 上真正做出重要事情的项目。

在 JVM 上运行 JavaScript [14:23]

Andrea Peruffo：有一个我真的很想提，就是 QuickJS。如果你看一下 Java 生态，基本上没有办法在不使用非废弃库的情况下在 Java 应用内部运行 JavaScript，因为 Rhino 和 Nashorn 都已被弃用，唯一的选择是 GraalJS。如果你已经在使用 GraalVM，那很好，用它就行。但如果你没有用 GraalVM，它可能不太适合你。另一方面，我们有 Shopify，这是一个大型电商平台，让你能够运行自己的商店，并用 WebAssembly 函数对其进行定制。Shopify 在 QuickJS 这个小引擎上投入了大量资源。这个名为 QuickJS 的小引擎是用纯 C 编写的，并且有很好的 Rust 绑定。多亏了 Shopify 的 Javy 项目，让它运行在 WebAssembly 上变得非常容易。所以，我把它拿过来，嵌入到 Java 接口中，并成功应用到了几个项目中。例如，Microcks 是一个用于 API 模拟的项目，属于 CNCF。它碰巧是一个 Spring Boot 应用。他们想与一种外部语言集成，让用户能够插入自己的行为，而我们很快就接上了 QuickJS 并提供了这个功能。这相当神奇，因为上次大会我在一个房间做演讲，而在隔壁房间，Microcks 的伙伴们正在一个工作坊里教人们如何在他们平台上使用 JavaScript。他们正在使用这个功能，而人们没有注意到，因为这也许正是 Wasm 的宿命：它不会追求热度，而是为底层库提供动力，否则这些功能就不可能实现。

Olimpiu Pop：好的。所以，这里的关键结论是，如果你想在 JVM 中安全地整合 JavaScript（或者说，来自 JavaScript 生态的任何东西），Wasm 就是正确的方式。而且我不能不借这个话题来感慨一下我们的年龄，因为我们都知道 Rhino 和 Nashorn 是什么，虽然 Nashorn 离现在更近，但 Rhino 是很久以前的事了，可能超过 10 年。我不记得确切时间，但可以说我们已经更有智慧了。

Andrea Peruffo：如果愿意的话，这个故事的趣味之处在于，某一天说到 Rhino，Rhino 试图跟上最新 ECMAScript 规范。而 WebAssembly 是那个 ECMAScript 规范的一部分。他们请我们做 Rhino 背后的 WebAssembly 引擎。

Olimpiu Pop：Rhino 只是接口，但在幕后实际上用的是 WebAssembly。好的。这可能是因为年轻一代偏爱复古游戏吧。就像你会看到年轻人手里拿着马里奥。

Andrea Peruffo：有一件我没想到的事是，在 Wasm 和 Java 的基础上，很多来自 Minecraft 社区的人加入了项目。

Olimpiu Pop：那很有意思。

Andrea Peruffo：我没想到，但我确实遇到过好几次需要调试图形用户界面，显示 Minecraft 模组之类的，而我一点头绪都没有。

Olimpiu Pop：那很有意思。这似乎是一条很好的教育路径。几周前，我和 Edera 的 CTO 兼创始人 Alex Zenla 聊过，她提到 Minecraft 是她编程生涯的起点。这让她思考了不少事情，她还拿 Minecraft 世界作比较。嗯，Andrea，我不知道他们在说什么。所以，这场对话里只有我们两个，我会和 Alex 聊一聊，她大概会解释更多，但看起来这条路很有益处。所以，也许我们应该研究一下。

Andrea Peruffo：真的吗？好的。

Olimpiu Pop：你提到了工作坊。我记得两年前我在你的“地盘”附近——差不多是科英布拉，你在那里办了一个工作坊，也做了一次演讲。我记得在你的工作坊里，你做了个解析器之类的东西。所以，也许归根结底，这就是 Chicory 的本质。如果你把它拆解到最基本的东西，它就是把一边的东西拿进来，然后从另一边吐出别的东西。所以，我知道这过于简化了，所以我想请你告诉我们，一个 Wasm 运行时到底意味着什么。

JVM 执行策略 [19:02]

Andrea Peruffo：是的。我们有不同的层来执行用 Wasm 编写的代码。第一个实现的是纯解释器。纯解释器会从你的 WebAssembly 程序或函数中逐条取出指令，并直接在 JVM 上执行，而不做任何预处理。这在某种意义上极具可移植性，因为它是自包含的，对我们来说完全构建在标准库之上。因此，它极其可移植，可以在 Native Image 上运行，可以在最严格的环境中运行，并且到处都能运行。不好的一面是，它非常慢。我们没有在解释器之上应用任何性能改进，因为它本身就是慢的。它必须一条一条地处理指令，没有机会让 JVM 的 C1 或 C2 即时编译器介入来提高 WebAssembly 程序的性能。

在那之后我们开发的是一个完整的编译器，从 WebAssembly 编译到 Java 字节码。如果你站得足够远，你会看到 WebAssembly 字节码和 Java 字节码看起来非常非常相似。WebAssembly 具有结构化控制流，而 JVM 上则是非结构化的，但我们是从一个受更多限制的环境走向一个受较少限制的环境。所以，这并非一次很糟糕的转换。我们几乎在一趟中完成……我们直接从 WebAssembly 翻译到 Java 字节码。我们观察到的是，一旦你开始把所有函数翻译成生成的 Java 函数，映射原始 WebAssembly，它们就会开始被即时编译器 C1 和 C2 优化。经过一定次数的迭代后，它们最终会在 JVM 上变得非常非常快，几乎能匹配面向本地汇编的原生编译器的性能。这是第二层，这个编译器可以在运行时运行，你需要通过一个非常非常薄的反射层来链接新程序——如果你想在受限环境中运行的话，就需要启用这个反射层。或者，我们大多数时候使用的是：如果你的 WebAssembly 载荷总是一样的，比如 QuickJS 这个引擎总是相同的，那你只需要把它编译一次到 WebAssembly，然后从 WebAssembly 编译成字节码。一旦你有了字节码，它就是固定的，你可以直接拿过来、分发、复用，而无需再额外调整。话虽如此，发生的情况是，我一直在宣扬一个观点：在 JVM 中完全运行一切是一个很棒的策略，对你的应用非常好，不会造成任何损害或程序卡住，但人们一直在追求性能。我们收到了很多报告，人们尝试在解释器上甚至在编译器上运行一些东西，然后他们说：“好吧，这没有 Wasmtime 快。这没有 V8 或浏览器快。”基于这一经验，我想做下一步。所以，我有一个新的实验性编译器，在去年春季的 Spring I/O 上公布了，我们实际上重写了编译器，但不是从头重写。Wasmtime 是一个非常著名的用 Rust 编写的 WebAssembly 运行时。它在后台使用一个编译器，生成纯汇编、特定于机器的汇编代码，这个编译器叫做 Cranelift。我们没有自己承担编写一个多趟编译器的全部工作，也没有开启这个多年项目，而是直接采用了 Cranelift，把它编译成 WebAssembly 本身，因为它只是纯 Rust，所以我们可以在纯 Java 中再次复用它，并使用这个 Cranelift 编译器把你的 WebAssembly 程序预编译为特定汇编。这样一来，我们就获得了基本上和运行在 Wasmtime 上一样的性能，Wasmtime 是 WebAssembly 领域最先进的运行时。因此，这给了我们最后一段速度之旅，而且无需打包任何本地库，因为我们不是链接到 Wasmtime，而只是复用了支撑 Wasmtime 的 WebAssembly 编译器。

Olimpiu Pop：如果要重写 Chicory，你会做哪些不同的事情？我知道你最初提到的一件事是 Chicory 是纯 Java。这源于“零依赖”家族，因为现在显然有很多人非常重视零依赖，我们看到供应链攻击等问题频发。但我不久前和 Gunnar Morling 聊过，他强调了他的新项目 Hardwood，这是一个外部依赖极少的库。所以，看起来这类事情如今越来越重要，人们真的在意这些。

Chicory 的设计与安全 [24:39]

Andrea Peruffo：嗯，我不知道在 Chicory 中会做什么不同的事，因为我们从一开始就是先考虑安全性，然后才获得性能，我相信这仍然是对我们用户最有用的路径。运行在 Chicory 上的一切都依赖于数量非常有限的外部库，而这些库本身又建立在 Java 标准库之上。所以，依赖非常非常薄，即使生成的代码通常也比原始 Wasm 小得多。所以，我认为目前我们拥有一个非常非常好的运行时，性能达到最先进水平，安全性良好，并且有“标准 Java”的血统，这对项目来说很棒。是的，不确定我会做什么不同。

Olimpiu Pop：好的。这很能说明你的为人，因为你非常有主见，对编程中的大多数事情都有自己的观点。所以，Andrea，这很能说明问题。看来你对自己团队取得的成就非常满意。

本地优先软件与云架构 [25:49]

我不知道你是否了解那个测试场景。如果你不了解，我就在你肩上拍几巴掌。不过，不是几周前，而是几个月前，我和 Martin Kleppmann 聊过。对听众来说，Martin Kleppmann 是那个在数据密集型应用领域掀起热潮的人。他写了一本“圣经”，因为那本书太厚了。他现在非常投入本地优先（Local First）运动。他也是 Bluesky 协议的顾问，实际上就是其背后协议。所以，在分布式系统方面，他是真正懂行的人之一。他提到了其中一个库，嗯，实际上是一个用于构建本地优先软件的库，Automerge。我当时想：“好，你在做什么呢？”感觉你有太多不同的场景，不可能在没有核心的情况下为每个场景创建一个 SDK，而且很难移植。而他非常自信、非常平静地说：“这很容易。我们用 Rust 构建 Automerge，你只需要把它编译成 WebAssembly，然后在几乎所有语言里就有很多选择了，然后就可以用了。”这非常好，因为你提到，WebAssembly 在云领域相当重要。我想我去年和 Scaleway 的几个伙伴聊过，我觉得他们当时就在做这方面的工作。所以，云开发领域似乎有两条路。一条是使用微型虚拟机，有些人用 Firecracker，这是一种方式；其余人则使用 WebAssembly。我认为另一个有趣的对话是我和 Max Körbächer 的。他是在 Kubernetes 上做 WebAssembly 运行时的人之一。

Andrea Peruffo：SpinKube。

Olimpiu Pop：SpinKube，没错。他说：“好吧，如果我想在 Kubernetes 领域做点非常高效的事，你有几种负载可以在 Kubernetes 中运行，而在内存和 CPU 的剩余小缝隙里，你可以跑几个 WebAssembly 任务，然后就会有一种非常高效的看法。”所以，似乎有一个完整的生态系统，而且有很多共生关系正在发生，看到这些真的很好。

Andrea Peruffo：现在有很多不同的方式来使用 WebAssembly，但让我感到非常熟悉的是 Red Hat 所说的，他们要用 Rust 编写，随处部署。这听起来和他们与 OpenFeature 还有 Spotify Confidence 所做的非常相似。这些是功能开关，用于在程序中启用或禁用标志。他们需要有相同的核心逻辑，以便在大量不同的编程语言中分发这些标志，比如 Java、Go、原生语言、Swift 等等。他们正在走或者说试图走的路，是用 Rust 编写这个初始规则子集。然后，正如这个案例一样，只需在特定生态系统中运行一个 WebAssembly 运行时。这似乎对两种工作负载都非常可移植、非常高效。

Olimpiu Pop：嗯，我们确实涵盖了很多可以用 WebAssembly 做的事情。现在，有没有反面的应用场景，哪些事情人们不应该用 WebAssembly 做，要么因为这太小题大做，要么因为不会高效，按你的了解？

WebAssembly 的当前局限 [29:23]

Andrea Peruffo：我们最近用 WasmGC 实现的一个能力是，你可以拿一个 Java 应用，编译它，例如使用 WebImage——这是 GraalVM 团队推出的 Native Image 的一个版本，可以生成 WebAssembly——一旦你有了 WebAssembly，你可以把它翻译回 Java 字节码，然后在 JVM 上运行。所以，尽管这在今天是可行的，但这是否是我会鼓励人们去做的事情呢？因为每经过一步、每一次翻译，都会增加一点绑定的数量和你运行原始程序所需的嵌入数量，从而使其变慢。但这件事仍然是可能的，这依然很棒。WebAssembly 有一个非常鲜明且良好的内存模型，可以用分离技巧防止 CVE。所以，在任何应用中，只要你想运行一段你不太放心、或者你真的不想因为这段代码而让机器崩溃的软件，WebAssembly 都是完美的选择。至于目前还不清楚的地方，比如它没有任何并发或并行的概念。到今天为止，这是一个不可用之处。因此，如果你的应用需要大量性能，并且这些性能是通过并发使用机器来实现的，那么这不是如今仅靠 WebAssembly 就能给你的。

Olimpiu Pop：好的。这意味着，如果你想做一些希望保证单线程的事情，直接把它放进 WebAssembly，在 WebAssembly 里运行，那就有了保证。除此之外，如果你需要更多，你必须在抽象层面自己处理。所以，可能就把它拆开，用不同的 WebAssembly 构建，然后再用允许这样做的编程语言来做编排。事实上，回想一下，今年在 QCon 上有个家伙正好在谈这件事，他说因为他想保证只在一个线程上运行，所以他直接把所有东西放进 WebAssembly，这给了他安全上的保证和沙箱。而且，几乎每个我们聊到的项目，我都想以社区话题来结尾，因为你显然参与得很深。人们如果想来做贡献，应该怎么联系？在那之后，我知道你还有一个公告想公开。

Endive 分支接管 Chicory [31:50]

Andrea Peruffo：是的。来和我们聊聊吧。我们有 Zulip 频道，但也有 issue 和 pull request。所以，只管开一个 issue，试着和我们聊一聊。这很简单。我们欢迎来自各方的贡献。所以，开个 issue，或者说我们正在尝试使用这项技术，我们会尽力支持这个用例，并帮你开始在你的应用中运行 WebAssembly。谈到重大公告，是的，我们确实有一个。事实是，我们将把 Chicory 分叉到 Bytecode Alliance 组织下，新名字将叫 Endive。我们曾尝试与 Dylibso 沟通。不幸的是，我们无法达成协议，以保留项目名称的方式进行干净移交，但旧项目的相同维护者会出现在 Endive，并维护这个新的运行时，我们希望很快在 Bytecode Alliance 下发布它。这带来了很多非常好的东西。项目更贴近社区，我们希望能有更多个人和公司为运行时做贡献。而且这与任何特定公司无关。所以，我们进入一个基金会，这样每个人都可以自由贡献，而不是为某一家公司做贡献。我们还将遵守 Bytecode Alliance 所有更严格的规则，他们正在帮助我们让这个运行时在 JVM 上尽可能安全、可用。

Olimpiu Pop：那么，继续，我得把植物视角从 Chicory 换成 Endive。我得讲个故事，因为我们之前讨论过，chicory 在罗马尼亚也有使用，在意大利也曾被用来制作一种尝起来很像咖啡但味道很糟糕的东西。是的，现在我们保留植物学的名字。谢谢你，Andrea，抽出时间。祝你在新挑战中好运，也祝 Endive 的社区不断壮大。

Andrea Peruffo：谢谢。我们希望一切顺利，但我们相当确信这次举动，因为所有旧社区都会跟着来，我们也将能够在 JVM 之上交付大量价值，就像我们已经在做的那样。

Olimpiu Pop：谢谢。祝你好运。

Andrea Peruffo：谢谢你，Olimpiu。

提及内容：

关于作者

[LOADING...]

Andrea Peruffo

凭借近二十年的编码经验，Andrea Peruffo 依然充满激情，每天都在键盘上敲击。作为 Red Hat 的首席软件工程师，Andrea 积极参与各种开源项目，既有个人满足，也有职业发展驱动。他并不那么秘密的热情在于编程语言、开发者工具、编译器，以及更多。欢迎来某个项目里找我！显示更多显示更少

你可以通过我们的 RSS Feed 持续了解播客动态，也可以在 SoundCloud、Apple Podcasts、Spotify、Overcast 和 YouTube 收听。从本页面你还可以访问我们的录制节目笔记。它们都有可点击的链接，可以直接跳转到音频的那一部分。

分类导航