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

Question

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

Answer 1

1. JNA不支持c ++类的映射，因此如果你使用的是c ++库，则需要一个jni包装器
2. 如果你需要大量的内存复制。 例如，您调用一个返回大字节缓冲区的方法，更改其中的某些内容，然后需要调用另一个使用此字节缓冲区的方法。 这将要求您将此缓冲区从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 2

回答这样一个普遍的问题很难。 我认为最明显的区别是，对于JNI，类型转换是在Java /本机边界的本机端实现的，而对于JNA，类型转换是用Java实现的。 如果你已经对使用C语言编程感到很舒服并且必须自己实现一些本机代码，我会认为JNI似乎不会太复杂。 如果您是Java程序员并且只需要调用第三方本机库，那么使用JNA可能是避免JNI可能不那么明显问题的最简单方法。

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

Answer 3

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

这只是我能想到的，尽管我不是一个沉重的用户。 如果你想要一个比他们提供的接口更好的接口，你似乎也可以避免使用JNA，但你可以在java中编写代码。

Answer 4

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

Answer 5

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

实际上，我当然认为我必须使用JNA而不是JNI，因为它确实看起来比JNI（它有一个无聊的开发过程）简单。 太糟糕了，JNA此时尚未发布。

Answer 6

如果您想要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 7

我实际上用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 8

我调查了JNI和JNA的性能比较，因为我们需要决定其中一个在项目中调用一个dll并且我们有一个实时约束。 结果表明，JNI的性能优于JNA（约40倍）。 也许有一个技巧可以在JNA中获得更好的性能，但对于一个简单的例子来说它很慢。

Answer 9

除非我遗漏了什么，JNA与JNI之间的主要区别不在于JNA你不能用本机（C）代码调用Java代码吗？