RFR: JDK-8200178 Remove mapfiles for JDK native libraries
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
> 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 jni_md.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
> 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
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 core-libs-dev