Java本机接口(JNI)是否受到C ABI兼容性问题的影响？

我正在开发一个Java应用程序.我想使用Java Native Interface(JNI)来调用C库中的函数.我可以访问C库的代码,我可以重建它,但我可能需要. (例如,我可以静态链接C运行时.)

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

一个同事指着我这个博客文章：http://www.trilithium.com/johan/2005/06/static-libstdc/,它建议不要使用动态加载的C代码.

另一位同事指出了这个bug报告：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程序需要共享的错误).

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

那么再一次,也许ABI不兼容不再是问题了.博客文章超过六年.另一个stackoverflow问题的答案(GCC ABI compatibility)断言“由于gcc-3.4.0,ABI是向前兼容的.”有没有成功？

我会感谢有关这些问题的任何指导. (嘿,谢谢你阅读所有这一切！)

EDITS

我的问题变得很长,所以我没有给出所有的细节.要解决Will的意见：

>我只需要调用extern“C”函数. (例如,我使用javah生成C头文件.)
>我不需要与JVM中的C运行时交互. (我基本上只需要将字符串发送到C库.)