Is the Java Native Interface (JNI) affected by C ABI compatibility issues?

Is the Java Native Interface (JNI) affected by C ABI compatibility issues?

I am developing a Java application I want to use Java Native Interface (JNI) to call functions in C library I can access the C library code, I can rebuild it, but I may need it (for example, I can statically link the C runtime.)

I can ask my users to have JRE 6 or later, but I can't ask them to have any specific C runtime

A colleague pointed to my blog post: http://www.trilithium.com/johan/2005/06/static-libstdc/ , it recommends against using dynamically loaded C code

Another colleague pointed out the bug report: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4694590 , Java 1.4.0 is introduced in detail How to solve these problems

According to my understanding, the point of the problem is that the binary interface of libstdc often changes If a C application loads a C shared library built with different compilers, two incompatible libstdc libraries will be loaded into memory at the same time

The error report explains Java 1.4 2: "we statically link the C runtime and enabled link description files in JDK to hide symbols from libstdc and other internal symbols. As a result, these symbols are invisible to JNI code. When some native code needs to call C runtime, the call will be parsed with the corresponding libstdc. So. At the same time, two libstdc. So are loading, but it should be benign

I have a few questions

First, does openjdk continue this approach?

[editor: I raised this question in the build dev mailing list of openjdk. The answer is yes. Hotspot still statically links libstdc, but obviously "most Linux distribution patches". Another developer pointed out that this does not even require a patch: "setting static_cxx = false should be enough (the default is true)."]

Second, even in this case, two incompatible libstdcs are loaded at the same time Is so really reasonable?

Third, this method (hiding symbols in JDK) solves all compatibility problems?

The blog post mentioned above warns that "the code compiled for different ABIS is not binary compatible at all." Since then, language runtime support usually relies on some shared data, such as accessing some kind of lock or global data structure (similar to the error that C programs need to share)

It sounds like an unsolvable problem

So again, maybe ABI incompatibility is no longer a problem Blog posts for more than six years The answer to another stackoverflow question (GCC ABI compatibility) asserts that "due to gcc-3.4.0, ABI is forward compatible." Did you succeed?

I would appreciate any guidance on these issues Hey, thanks for reading all this

EDITS

My question became very long, so I didn't give all the details To address will's comments:

>I just need to call the extern "C" function (for example, I use javah to generate C header files.) I do not need to interact with the C runtime in the JVM (I basically just need to send the string to the C library.)

Solution

I don't know. But it never stopped me

First, it depends on what you want to do The premise behind the static connection of JDK is to improve the portability of the actual JDK itself Because they cannot expect users to recompile JDK on their specific operating system, they need a mechanism to make the final binary portable Obviously, static linking solves this problem

Next, about JNI, first you will call C functions instead of C. I don't believe that JNI has any type of C binding So whatever you want to use, C needs to be wrapped in C programs to communicate with Java

Next, C So will be dynamically linked to the operating system, as I'm guessing It seems bad to expect that JNI routines cannot be dynamically linked, while C So should be no different Moreover, there is no doubt that C is so popular and seems bad that you will not be able to link to C dynamically so. So, no matter what kind of people need to happen to promote this, it is a reasonable assumption that they (TM) have done such work to achieve this

That is, you must not expect any C used to interact with the C runtime of the Java runtime Ideally, they would only coexist peacefully

In view of this, assuming all this works, your C will definitely have ABI portability problems, because it will be dynamically linked and will be pitied by the C runtime installed by the OS

So, finally, I'll give it a crack and see what happens