RFR: JDK-8200178 Remove mapfiles for JDK native libraries (original) (raw)

Martin Buchholz martinrb at google.com
Thu Mar 29 06:16:18 UTC 2018

On Wed, Mar 28, 2018 at 3:14 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote:

On 2018-03-28 23:53, Martin Buchholz wrote:

I can't find any documentation for what JNIEXPORT and friends actually do. People including myself have been cargo-culting JNIEXPORT and JNICALL for decades. Why aren't they in the JNI spec? That surprises me. I'm quite certain that javah (or rather, java -h nowadays) generate header files with JNIEXPORT and JNICALL. As you can see in the jni.h and jnimd.h files, JNIEXPORT equals attribute((visibility("default"))) for compilers that support it (gcc _and friends), and declspec(dllexport) for Windows. This means, that the symbol should be exported. (And it's ignored if you use mapfiles aka linker scripts.) _As for JNICALL, it's empty on most compilers, but evaluates to stdcall on Windows. This defines the calling convention to use. This is required for JNI calls from Java. (Ask the JVM team why.) While it's not technically required for calling from one dll to another, it's good practice to use it all time to be consistent. In any way, it doesn't hurt us.

Sure, I can see how JNIEXPORT and JNICALL are implemented, but what do they mean?

For example, one might expect from the JNI prefix that these macros are exclusively for use by JNI linking, i.e. unsupported except in the output of javac -h. But of course in practice they are used with arbitrary symbols to communicate between components of user native code, not just to communicate with the JVM. Is that a bug?

More information about the build-dev mailing list