Edit Question - KnowledgeHub

Title Body

Is the Java Native Interface (JNI) affected by C++ ABI compatibility issues? I am developing a Java application. I would like to use the Java Native Interface (JNI) to call functions in a C++ library. I have access to the code for the C++ library, and I can rebuild it however I may need to. (For example, I can statically link the C++ runtime.) I can require my users to have JRE 6 or greater, but I can't require them to have any particular C++ runtime. A coworker pointed me to this blog article: http://www.trilithium.com/johan/2005/06/static-libstdc/ which advises against using dynamically loaded C++ code. Another coworker pointed me to this bug report: https://bugs.java.com/bugdatabase/view_bug?bug_id=4694590 which details how these issues were addressed back in Java 1.4.2. The gist of the problem, as I understand it, is that the binary interface of libstdc++ often changes. If a C++ application loads a C++ shared library that was built with a different compiler, two incompatible libstdc++ libraries will be loaded into memory at the same time. The bug report explains the solution for Java 1.4.2: "We statically link the C++ runtime in JDK and enabled linker script to hide symbols from libstdc++ and other internal symbols. As the result, those symbols become invisible to JNI code, and when some native code needs to call into C++ runtime, the call will be resolved with the appropriate libstdc++.so. There are still two libstdc++.so being loaded at the same time, but it should be benign." I have a few questions about this. First, does OpenJDK continue to take this approach? [ EDIT: I asked this question on OpenJDK's build-dev mailing list. The answer is yes, HotSpot still statically lin

Tags (comma-separated) Cancel