RFR: JDK-8200178 Remove mapfiles for JDK native libraries

[Magnus Ihse Bursie]

(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