(pruning cc-list somewhat)
On 2018-03-29 08:16, Martin Buchholz wrote:
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?
I think I see your point. JNIEXPORT currently has a dual role in
OpenJDK. The primary role is as part of the JNI interface, as generated
by javac -h. Since we have multiple native libraries definiting JNI
entry points from Java, this is a proper usage. As such, it is "well
defined", at least in the sense that the code is generated by javac, and
can be assumed to be correct and not subject to user modifications.
But we also use JNIEXPORT for symbol visibility for native
library-to-native library calls, including calling the JVM. While this
"works", it would be more proper to define a separate symbol for this
use, e.g. JDK_EXPORT. Then JDK_EXPORT would have a well-defined meaning,
and be used only internally in the OpenJDK project.
If this is what you mean, I agree. I'm not sure I'm willing to put the
time into separating between these two issues, however, but if you get
backing from the rest of the project, and chose to persue this, I'll
support you. :-)
/Magnus
