使用JNI而不是JNA调用本机代码？

Question

与 JNI 相比，JNA 似乎更容易用来调用本机代码。在什么情况下您会使用 JNI 而不是 JNA？

Answer 1

我实际上用 JNI 和 JNA 做了一些简单的基准测试。

正如其他人已经指出的，JNA 是为了方便。使用 JNA 时不需要编译或编写本机代码。 JNA 的本机库加载器也是我见过的最好/最容易使用的库加载器之一。遗憾的是，您似乎无法将它用于 JNI。 （这就是为什么我写 System.loadLibrary() 的替代方案，它使用 JNA 的路径约定并支持从类路径（即 jar）无缝加载。）

但是，JNA 的性能可能比 JNI 差很多。我做了一个非常简单的测试，称为简单的本机整数增量函数“return arg + 1;”。使用 jmh 完成的基准测试表明，对该函数的 JNI 调用比 JNA 快 15 倍。

一个更“复杂”的示例，其中本机函数对 4 个值的整数数组求和，仍然表明 JNI 性能比 JNA 快 3 倍。优势降低可能是因为您在 JNI 中访问数组的方式所致：我的示例创建了一些内容，并在每次求和操作期间再次释放它。

代码和测试结果可以在github。

Answer 2

如果您想要 JNI 性能但对其复杂性感到畏惧，您可以考虑使用自动生成 JNI 绑定的工具。例如，JANET（免责声明：我写的）允许您在一个单一的文件中混合 Java 和 C++ 代码源文件，例如使用标准 Java 语法从 C++ 调用 Java。例如，以下是如何将 C 字符串打印到 Java 标准输出：

native "C++" void printHello() {
    const char* helloWorld = "Hello, World!";
    `System.out.println(#$(helloWorld));`
}

然后 JANET 将反引号嵌入的 Java 转换为适当的 JNI 调用。

Answer 3

我研究了 JNI 和 JNA 进行性能比较，因为我们需要决定其中之一来调用项目中的 dll，并且我们有实时限制。结果表明，JNI 的性能比 JNA 更高（约 40 倍）。也许 JNA 中有一个可以提高性能的技巧，但对于一个简单的例子来说它非常慢。

Answer 4

除非我遗漏了一些东西，否则 JNA 与 JNI 之间的主要区别不就是使用 JNA 无法从本机（C）代码调用 Java 代码吗？

Answer 5

在我的具体应用程序中，JNI 被证明更容易使用。我需要从串行端口读取和写入连续的流——仅此而已。我没有尝试学习 JNA 中非常复杂的基础设施，而是发现使用专用 DLL 来构建 Windows 中的本机接口原型要容易得多，该 DLL 仅导出六个函数：

1. DllMain（与 Windows 交互所需）
2. OnLoad（仅执行 OutputDebugString ）所以我可以知道Java代码何时附加）
3. OnUnload（同上）
4. Open（打开端口，启动读取和写入线程）
5. QueueMessage（将数据排队以供写入线程输出）
6. GetMessage（等待并返回读取线程接收的数据，因为最后一次通话）

Answer 6

1. JNA 不支持 C++ 类的映射，因此如果您使用 C++ 库，
2. 如果需要大量内存复制，则需要 jni 包装器。例如，您调用一个方法，该方法返回一个大字节缓冲区，您更改其中的某些内容，然后您需要调用另一个使用该字节缓冲区的方法。这需要您将此缓冲区从 c 复制到 java，然后将其从 java 复制回 c。在这种情况下，jni 将在性能上获胜，因为您可以在 c 中保留和修改此缓冲区，而无需复制。

这些是我遇到的问题。也许还有更多。但一般来说，jna 和 jni 的性能差别不大，所以只要能使用 JNA 的地方，就使用它。

编辑

这个答案似乎很受欢迎。所以这里有一些补充：

1. 如果您需要映射 C++ 或 COM，JNAerator 的创建者 Oliver Chafic 有一个库，名为 BridJ。它仍然是一个年轻的库，但它有许多有趣的功能：
   • 动态 C / C++ / COM 互操作：调用 C++ 方法、创建 C++ 对象（以及来自 Java 的 C++ 类的子类！）
   • 直接的类型映射，充分利用泛型（包括更好的指针模型）
   • 完整的 JNAerator 支持
   • 适用于 Windows、Linux、MacOS X、Solaris、Android
2. 至于内存复制，我相信JNA支持直接ByteBuffers，因此可以避免内存复制。

所以，我仍然认为，只要有可能，最好使用 JNA 或 BridJ，如果性能至关重要，则恢复到 jni，因为如果需要频繁调用本机函数，性能损失会很明显。

Answer 7

很难回答这样一个笼统的问题。我想最明显的区别是，使用 JNI，类型转换是在 Java/本机边界的本机侧实现的，而使用 JNA，类型转换是在 Java 中实现的。如果您已经对 C 语言编程感到非常满意并且必须自己实现一些本机代码，那么我认为 JNI 看起来不会太复杂。如果您是一名 Java 程序员并且只需要调用第三方本机库，那么使用 JNA 可能是避免 JNI 可能不那么明显的问题的最简单途径。

尽管我从未对任何差异进行过基准测试，但由于设计原因，我至少假设在某些情况下使用 JNA 进行类型转换会比使用 JNI 执行得更差。例如，当传递数组时，JNA 会在每个函数调用开始时将这些数组从 Java 转换为本机，并在函数调用结束时再转换回来。使用 JNI，您可以在生成数组的本机“视图”时控制自己，可能只创建数组的一部分的视图，在多个函数调用中保留视图，最后释放视图并决定是否需要保留更改（可能需要将数据复制回）或放弃更改（无需复制）。我知道您可以使用 Memory 类在 JNA 的函数调用之间使用本机数组，但这也需要内存复制，这对于 JNI 来说可能是不必要的。差异可能不相关，但如果您最初的目标是通过在本机代码中实现部分应用程序来提高应用程序性能，那么使用性能较差的桥接技术似乎不是最明显的选择。

Answer 8

1. 您在几年前编写代码，当时还没有 JNA，或者目标是 1.4 版之前的 JRE。
2. 您正在使用的代码不在 DLL\SO 中。
3. 您正在编写与 LGPL 不兼容的代码。

这只是我能想到的，尽管我都不是这两者的重度用户。如果您想要一个比他们提供的接口更好的接口，那么您似乎可以避免使用 JNA，但您可以在 java 中围绕该接口进行编码。

Answer 9

顺便说一句，在我们的一个项目中，我们保留了非常小的 JNI 足迹。我们使用协议缓冲区来表示我们的域对象，因此只有一个本机函数来桥接 Java 和 C（当然，C 函数会调用一堆其他函数）。

Answer 10

这不是一个直接的答案，我没有使用 JNA 的经验，但是，当我查看 使用 JNA 的项目 并看到 SVNKit、IntelliJ IDEA、NetBeans IDE 等名称，我倾向于相信它是一个相当不错的库。

实际上，我绝对认为当我不得不这样做时我会使用 JNA 而不是 JNI，因为它确实看起来比 JNI 更简单（它有一个无聊的开发过程）。可惜当时JNA还没有发布。