我正在开发一个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库.)
解决方法
首先,这取决于你想做什么. JDK的静态连接背后的前提是提高实际JDK本身的可移植性.由于他们不能期望用户在其特定的操作系统上重新编译JDK,所以需要一种机制,使最终的二进制可移植.显然静态链接解决了这个问题.
接下来,关于JNI,首先你会调用C函数而不是C,我不相信JNI有任何类型的C绑定.所以,无论你想要使用什么C都需要被包装在C程序中以与Java进行交流.
接下来,C .so将动态地链接到操作系统,就像我正在猜测的一样.期望JNI例程不能与动态链接的操作似乎很恶劣,而C .so应该没有什么不同.而且,毫无疑问,C是如此受欢迎,似乎也是恶劣的,你将无法动态地链接到C .so.那么,无论是为了促进这一点而需要发生什么样的人,这是一个合理的假设,他们(tm)已经做了这样的工作来实现这一点.
也就是说,您一定不会期望任何C使用的都将与Java运行时的C运行时进行任何交互.理想情况下,它们只会和平共存.
鉴于这一点,假设这一切都有效,您的C将绝对会有ABI可移植性问题,因为它将是动态链接,并将受到OS安装的C运行时的怜悯.
所以,最后,我会给它一个裂缝,看看会发生什么.
