
Java 22 正式引入了 Foreign Function & Memory API, 简称 FFM API, 它源自于 Project Panama, 旨在用来替代 JNI, 提供更安全,健壮的本地动态库调用方式。之前在一文 Java 22 新特性学习 中跳过了对它的体验, 因为直接用 FFM API 来调用本地代码的话,写起来比 JNI 还更复杂,更别提和 JNA 对比,性能上 FFM API 大致与 JNI 相当,但总比 JNA 要好些, 原因是 JNA 使用了一个与系统相关的中间层动态库。像这种调用本地代码的场景,性能的差异基本体现在本地代码上,调用过程的性能差异一般可以忽略不计.
那时没深入 FFM API 的原因是它用起来过于复杂,这种复杂性应该由第三方库来屏蔽,可是自 Java 22 于 2024-03-19 发布以来目前仍未找到一款类似于 JNA 屏蔽了 JNI 那样的基于 FFM 的第三方库。所以还是事先来体验一下 FFM API 的开发过程,现在可以借助 AI 来引导学习, 并在后面与 JNA 作个性能对比, 只供参考。
Read More
还是很 久很久以前,当初有 Java 调用本地动态库需求的时候,尝试过用 javah/native 原生的方式在 Java 中使用动态库,再就是小试了 JNative,它调用动态库只需 Java 端的动作, 它最后的更新日期是 9 年前 2013-04-26,基本是应该选择放弃了。
关于 JNative 的使用写过两篇
如今想继续发掘下是否有别的更好的调用本地库的 JNI 组件,找到有- JNIWrapper:居然是一个收费的,而且价格不菲,不作绍
- BridJ:也是 7 年前才有过代码的更新
- JNA(Java Native Access): 也就它稍为活跃一点点
- JNR-FFI:最近几个月也有更新,不知道使用体验如何
Read More- 记得以前 Java 要调用C/C++写得动态库都是用的 JNI 方式,还需要自己写不少 C/C++ 代码。比如说要在Java中调用已有的动态库,如 Windows 的 user32.dll 的方法 MessageBoxA,具体步骤是 Java 中声明一个 native 方法,然后用 javah 命令生成JNI样式的头文件,再自己实现头文件中声明的方法,在实现方法中装载动态库 user32.dll,调用 MessageBoxA 方法,需要把自己写的这部分 C/C++ 代码封装成一个动态库,如Sample.dll,最后在 java 中装载 Sample.dll,然后执行其中所声明的本地方法。
可见,用老实的JNI方式,我们在调用一个已知动态库的时候还需要额外生成一个符合JNI规则的动态库作为桥梁,显得有点多余了。 Read More