On Wed, Mar 28, 2018 at 3:14 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@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 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
> 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?
