Project Detroit：从外部库到外部语言运行时
内容提要
Java团队介绍Project Detroit：不再用Java重写语言运行时，而是借助FFM API将V8、CPython等原生运行时嵌入Java应用。文章回顾Nashorn因维护成本高被移除，并探讨运行时桥接难点，如双垃圾回收器协调和避免虚拟线程固定。
延伸解读
从重写到嵌入：Nashorn的教训
文章回顾了Nashorn的兴衰：JDK 8引入的JavaScript引擎因维护成本高、兼容性滞后，在Java 11被弃用、Java 15移除。这揭示了用Java重写语言运行时的根本困境——需要持续跟进上游语言演进，负担沉重。Project Detroit转向嵌入V8、CPython等原生运行时，正是对这一教训的回应，避免重复造轮子。
FFM API：桥接原生运行时的关键
Project Detroit的核心是借助Foreign Function & Memory (FFM) API，将V8、CPython等工业级原生运行时嵌入Java应用。FFM API简化了与外部库的交互，但文章指出，与整个语言运行时交互仍很困难。这要求开发者理解运行时桥接的“晦涩艺术”，而非简单调用几个函数。
运行时桥接的两大技术挑战
文章点明了桥接中的具体难点：一是协调两个垃圾回收器（JVM与原生运行时各自的GC），避免内存管理冲突；二是避免虚拟线程固定（pinning），确保Java虚拟线程在调用原生代码时不被阻塞。这些细节决定了嵌入方案能否在生产中稳定运行，也是Project Detroit深度探索的重点。
Q&A
Project Detroit 是什么？它和之前的 Nashorn 有什么不同？
Project Detroit 是 Java 团队提出的新方案，它不再用 Java 重写语言运行时，而是借助 FFM API 将 V8、CPython 等原生运行时嵌入 Java 应用。与 Nashorn 不同，Nashorn 是用 Java 实现的 JavaScript 运行时，而 Detroit 直接复用行业标准的原生运行时。
为什么 Java 移除了 Nashorn？
Nashorn 在 JDK 8 引入，但由于维护成本不断增加以及兼容性滞后，在 Java 11 被弃用，最终在 Java 15 被移除。
Project Detroit 如何将外部语言运行时嵌入 Java 应用？
Project Detroit 利用 Foreign Function & Memory (FFM) API 来嵌入像 V8 和 CPython 这样的原生运行时，而不是从头实现语言运行时。
运行时桥接有哪些难点？Project Detroit 提到了哪些挑战？
运行时桥接的难点包括协调两个垃圾回收器（JVM 的和外部运行时的）以及避免虚拟线程固定（pinning）。
Project Detroit 支持哪些语言运行时？
Project Detroit 支持嵌入行业标准的原生运行时，例如 V8（用于 JavaScript）和 CPython（用于 Python）。
Project Detroit 的演讲是在哪个会议上录制的？
该演讲录制于 Devoxx Belgium 2026。
