Java 外部函数接口

  • Bienvenido David
  • 马德奎

2014 年 3 月 20 日

话题:Java语言 & 开发架构

JDK 增强提案(JEP)191 定义了Java Foreign Function Interface(FFI),它是可以将本地函数绑定到 Java 方法以及管理本地内存块的接口。该提案会使得向 JDK 中添加本地级别的新特性更容易,而且帮助提供了一个用于 Java 开发的标准 FFI。当前,Java Native Interface(JNI)是编写 Java 本地代码的标准编程接口。JNI 创建本地函数的方式并不简单,于是产生了像Java Native Access(JNA)和Java Native Runtime(JNR)这样的库。JNA 和 JNR 都是基于 JNI 创建的,而 JEP 191 可能会基于 JNR。

JEP 191 在 Java 级别提供了类似于 JNA 或 JNR 的外部函数接口。开发人员可以通过它轻松地访问本地函数,以及在 JVM 级别管理本地内存。它还将支持未来针对标准 Java FFI 的 JSR。Java FFI API 可用于实现本地支持的功能,像 NIO、高级文件系统元数据、进程管理。使用 FFI API 而不是 JNI 绑定本地代码和内存将成为开发人员更喜欢的方式。JEP 191 并不包含对 JNI 的增强,不过这些可能会加入到 JSR 进程中。

目前,JNI 是编写 Java 本地方法以及将 Java 虚拟机嵌入本地应用程序的标准编程接口。它管理着 JVM 和非托管的本地环境之间的边界,提供数据编组和对象生命周期管理协议。根据 JEP 191,JNI 在下列几个方面最令开发人员痛苦:

  • 需要开发人员编写 C 代码,这意味着他们需要具备一个完全不同于 Java 的世界的专业知识。
  • 由于开发人员必须对 JVM 如何管理内存和代码多少有一些了解,所以典型的 C 和 Java 开发人员通常并不具备使用 JNI 所需的专业知识。
  • 开发人员必须能够为他们想要支持的每个平台构建代码,或者为终端用户提供适当的工具,由他们来完成这项工作。
  • 相比于相同的库绑定到本地应用程序,基于 JNI 的库性能通常较差。
  • JNI 充当了一个不透明的安全边界。JDK 并不知道库中的函数可能会调用什么,或者库中的代码是否会损害 JVM 的稳定或安全。

JNI 的问题可以通过在 JDK 中内建 FFI API 来解决。Java FFI 将更容易实现,而且不需要太多关于 JVM 内部原理和各种宿主平台的专业知识。FFI API 将提供下列特性:

  • 一个描述本地库调用和本地内存结构的元数据系统。
  • 发现和加载本地库的机制。
  • 基于元数据将库 / 函数或内存结构绑定到 Java 端点的机制。
  • 用于 Java 数据类型和本地数据类型之间编组和解组的代码。

JEP 191 还可能增加本地调用的 JIT 优化、GC 层可知的本地内存和选择取消已知不必要的 JNI 安全保护的机制。它还会包含基于 JRuby ffi-gen 库的工具,用于从本地库收集函数和内存的元数据。开发人员还可以设置安全策略,允许绑定到特定函数,而不是库级别的权限。

对 Java FFI 的需求已经产生了 JNA 和 JNR 库。JNA 库应用更广泛。JNR 库更全面,因为它实现了不同层次的抽象,提供了函数和内存元数据,对库和函数绑定进行了抽象。JNR 已经在 JRuby 项目中大量使用,它可能会成为 JEP 191 的基础。

查看英文原文:Java Foreign Function Interface

Java语言 & 开发架构