15

Java Native Interface (JNI) 是否受 C++ ABI 兼容性问题的影响？

我正在开发一个 Java 应用程序。我想使用 Java 本机接口 (JNI) 来调用 C++ 库中的函数。我可以访问 C++ 库的代码，并且可以根据需要重新构建它。（例如，我可以静态链接 C++ 运行时。）

我可以要求我的用户拥有 JRE 6 或更高版本，但我不能要求他们拥有任何特定的 C++ 运行时。

一位同事向我指出了这篇博客文章：http ://www.trilithium.com/johan/2005/06/static-libstdc/ ，它建议不要使用动态加载的 C++ 代码。

另一位同事向我指出了这个错误报告：http ://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4694590 ，其中详细说明了这些问题在 Java 1.4.2 中是如何解决的。

据我了解，问题的要点是 libstdc++ 的二进制接口经常发生变化。如果 C++ 应用程序加载使用不同编译器构建的 C++ 共享库，则两个不兼容的 libstdc++ 库将同时加载到内存中。

错误报告解释了 Java 1.4.2 的解决方案：“我们在 JDK 中静态链接 C++ 运行时并启用链接器脚本以隐藏 libstdc++ 和其他内部符号的符号。结果，这些符号对 JNI 代码变得不可见，并且当某些本机代码需要调用 C++ 运行时，调用将通过适当的 libstdc++.so 解析。仍然有两个 libstdc++.so 同时加载，但应该是良性的。”

我对此有几个问题。

首先，OpenJDK 是否继续采用这种方法？

[编辑：我在 OpenJDK 的 build-dev 邮件列表中提出了这个问题。答案是肯定的，HotSpot 仍然静态链接 libstdc++，但显然“大多数 Linux 发行版都对此进行了修补”。另一位开发人员指出，这甚至不需要补丁：“设置 STATIC_CXX=false 就足够了（默认为 true）。”]

其次，即使在这种情况下，同时加载两个不兼容的 libstdc++.so 真的是良性的吗？

第三，这种方法（隐藏 JDK 中的符号）是否解决了所有的兼容性问题？

上面引用的博客文章警告说“针对不同 ABI 编译的代码根本不兼容二进制”。后来，“语言运行时支持通常依赖于一些共享的数据，例如访问某种锁或全局数据结构（类似于 C 程序需要共享 errno）。”

这听起来像是问题无法解决。

再说一次，也许 ABI 不兼容不再是问题了。博客文章已有六年多的历史了。另一个 stackoverflow 问题（GCC ABI 兼容性）的一个答案断言“自 gcc-3.4.0 以来，ABI 是向前兼容的。” 那成功了吗？

我将不胜感激有关这些问题的任何指导。（嘿，感谢您阅读所有这些内容！）

编辑

我的问题变得很长，所以我没有提供所有细节。为了解决威尔的评论：

  1. 我只需要调用 extern "C" 函数。（例如，我使用 javah 生成 C 头文件。）
  2. 我不需要与 JVM 中的 C++ 运行时交互。（我基本上只需要将字符串发送到 C++ 库。）
4

1 回答 1

5

我不知道。但这从未阻止我。

首先，这取决于你想做什么。JDK静态链接背后的前提是提高实际JDK本身的可移植性。由于他们不能指望用户在他们的特定操作系统上重新编译 JDK，他们需要一种机制来使最终的二进制可移植。显然静态链接解决了这个问题。

接下来，关于 JNI，首先你将调用 C 函数而不是 C++，我不相信 JNI 有任何类型的 C++ 绑定。因此，无论您想使用什么 C++，都需要封装在 C 例程中才能与 Java 对话。

接下来，您的 C++ .so 将动态链接到操作系统，就像我猜测的正常情况一样。期望 JNI 例程不能与动态链接的 .so 一起使用似乎非常苛刻，而 C++ .so 应该没有什么不同。而且，毫无疑问，C++ 与它一样受欢迎，但您无法动态链接到 C++ .so 似乎同样严厉。因此，无论需要采取什么恶作剧来促进这一点，他们（tm）已经完成了让这种情况发生的工作，这是一个合理的假设。

也就是说，当然不应该期望您使用的任何 C++ 都会与 Java 运行时中的 C++ 运行时有任何交互。理想情况下，它们只会和平共处。

鉴于此，假设这完全可行，您的 C++ 肯定会有 ABI 可移植性问题，因为它将动态链接，并且将受操作系统安装的 C++ 运行时的支配。

所以，最后，我只是试一试，看看会发生什么。

于 2012-01-04T05:25:21.843 回答