天工开物 #7 Rust 与 Java 程序的异步接口互操作

许多语言的高性能程序库都是建立在 C/C++ 的核心实现上的。

例如，著名 Python 科学计算库 Pandas 和 Numpy 的核心是 C++ 实现的，RocksDB 的 Java 接口是对底层 C++ 接口的封装。

Rust 语言的基本目标之一就是替代 C++ 在这些领域的位置，为开发者提供 Rust 具备的安全性和可组合性优势。

Apache OpenDAL (incubating)^[1] 是 Databend 工程师 Xuanwo 开发的一个 Rust 语言实现的开放数据访问层。它的核心设计支持通过相同的对象存储 API 访问不同的存储服务（Service），并提供可扩展的中间件（Layer）来支持通用的请求重试、限流和指标上报功能。目前，包括 Databend / RisingWave / GreptimeDB / mozilla sccache 在内的多个软件都选用 OpenDAL 作为其存储访问接口。

OpenDAL 架构概念图

在 Rust 核心实现的基础上，OpenDAL 提供了 Java / Python / Node.js 等不同语言的 API 绑定（Binding），以支持更广泛的生态利用 OpenDAL 已经完成的工作。例如，使用 Python 绑定，诸多大模型应用库能够在不同云厂商的对象存储服务间无缝迁移，支持用户使用任意对象存储服务。而在开发期间，则可以用内存或文件实现来模拟测试相同 API 的语义。

要在 OpenDAL 实现一个特定语言的 API 绑定，涉及到功能实现、程序库打包和发布等多个环节。本文从功能实现的角度出发，以 Java 绑定为例，讨论 OpenDAL 如何在社群力量的支持下实现 opendal-java 库。同时，重点剖析行内首个完整的 Java ↔ Rust 异步接口互操作的最佳实践。

跨语言互操作的基本知识

我的本科毕业论文《多计算机语⾔原理及实现机制分析之初探》当中讨论了三种跨语言互操作的方法：外部函数接口（FFI）、进程间通信（IPC）和多语言运行时。

最常见的是基于 FFI 的方案，即通过一套语言无关的函数调用约定，完成不同语言之间的通信。例如，opendal-java 就是使用 Java 的 FFI 方案 JNI^[2] 来完成 Java 和 Rust 之间的互操作的。CPython、Ruby 和 Haskell 等语言实现，则是通过 libffi 来完成和 Native 函数的互操作。

可以看到，FFI 方案基本都是实现了本语言与 Native 函数即遵循 C ABI 的函数之间的互操作，要想使用这样的方案实现 Java 程序调用 CPython 函数是不可能的。这不仅仅是没有人为 Java 和 CPython 之间定义一套调用规则的原因，还有只有 Native 函数才不需要运行时的缘故。要想调用一个 Java 函数，或是一个 CPython 函数，都必须先启动一个对应语言的运行时（JRE 或 CPython 解释器）。如果每次调用都启动一个新的运行时实例，那么这个性能损耗将彻底疯狂，而如果常驻一个目标运行时的进程实例，那么更加成熟的解决方案是进程间通信。

说进程间通信或 IPC 可能还有很多人不知道是什么，举一个例子就很容易理解了：Protobuf + gRPC 的解决方案就是典型的 IPC 方案。

如果说 FFI 是定义了一套语言无关的 Native 函数调用约定，那么 IPC 就是定义了一套语言无关进程接口调用约定。在 gRPC 之外，Apache Thrift / Apache Avro RPC / Apache Arrow Flight RPC 也都定义了各自的语言无关的进程接口调用约定，一般称为接口描述语言（IDL）。

这种方式下，开发者需要首先使用 IDL 定义好想要进行互操作的接口，随后使用对应方案的编译器产生调用方或被调用方语言的数据结构定义和接口存根（stub）对象，接着实现接口逻辑并在进程启动时暴露访问端口。实际调用时，调用方将接口访问及其参数结构编码为字节流，发送到接收方端口，接收方解码请求及其参数，完成请求后回传编码后的结果。

显而易见，IPC 的方式比起 FFI 的方式多了大约两轮数据编解码，加上一个来回网络字节传输的开销。

最后一种跨语言互操作的方案是多语言运行时，这个词汇可能又很陌生。同样举一个实例：JVM 就是一个跨语言运行时。

JVM 上面首先可以运行 Java 语言。然后，它可以运行 Scala / Groovy / Kotlin 等 JVM 族的语言。到这里，JVM 已经可以实现定义上的跨语言互操作了，因为 Java 和后面几个语音确实不是同一个编程语言。进一步地，JVM 上可以运行 Clojure 语言，这意味着 JVM 支持 Java 和 Lisp 之间的互操作。当然，Lisp 比较小众，所以最后我给出百分百令人信服的例子：在 JVM 上可以用 Jython 和 JRuby 实现 Java 和 Python 或 Ruby 的互操作，甚至实现 Python 和 Ruby 的互操作。虽然 Jython 项目凉凉了，但是 JRuby 仍然有很多下游使用，例如 HBase 的 Shell 是 JRuby 实现的，ELK 软件栈中的 Logstash 也是 JRuby 实现的。

此外，在多语言运行时的理论先锋 GraalVM 和 Truffle Framework 的支持下，GraalPy / TruffleRuby / FastR / Sulong (LLVM bitcode) 等等方案接连出现并活跃发展至今。这也是我在毕业论文中重点讨论和研究的对象。

OpenDAL 的多语言 API 绑定最终选择了基于 FFI 的方案。

首先，OpenDAL 根本不启动进程，它被设计为程序直接调用的软件库，所以 IPC 方案从模型上就是不适合的，更不用说调用一个基本的数据访问 API 不应该有多余的网络开销。不过，由于 Golang 自闭的跨语言生态和极力推崇 RPC 的哲学，OpenDAL 支持 Golang 调用的方式可能真的得做一个 service 然后暴露出 RPC 接口。

而多语言运行时的方案，应该说目前还没有支持 Java 和 Rust 或 Native 函数互操作的多语言运行时方案。最接近的是 GraalVM 上的 Sulong 运行时，但是它和它所依赖的 GraalVM 都还不算成熟甚至还未大规模生产使用，且 Sulong 支持的是执行 LLVM bitcode 代码，采用这个方案，就要解决 Rust ↔ LLVM bitcode ↔ Java 三方的沟通和版本适配问题。一言以蔽之，这个方案技术上就很难实现。

opendal-java 的实现

Java 通过 JNI 约定调用 C ABI 函数的一般实现流程如下：

1. Java 侧定义一个 native 方法；

package org.apache.opendal;
public class BlockingOperator extends NativeObject {
    private static native long constructor(String schema, Map<String, String> map);
}

1. C ABI 侧定义一个符合方法编码规则^[3]的函数，这里以 opendal-java 中的定义为例；

#[no_mangle]
pub extern "system" fn Java_org_apache_opendal_BlockingOperator_constructor(
    mut env: JNIEnv,
    _: JClass,
    scheme: JString,
    map: JObject,
) -> jlong {
    // ...
}

1. Java 程序启动时，调用 System.loadLibrary(libname) 或 System.load(filename) 方法加载 native 库，后续对 native 方法的调用便会转为在 native 库中查找经过编码后的对应 native 函数的调用。

知道了基本的方法映射模式，我们就可以分点来讨论 opendal-java 中的设计要点和技术难点了。

Native Object

从简单的不涉及异步接口互操作的 Blocking Operator 开始。

public class BlockingOperator extends NativeObject {
    // ...

    public BlockingOperator(String schema, Map<String, String> map) {
        super(constructor(schema, map));
    }

    public String read(String path) {