RFR: JDK-8200178 Remove mapfiles for JDK native libraries

[Martin Buchholz]

On Tue, Apr 3, 2018 at 6:04 AM, Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> (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. :-)
>

Yes, I think we're in agreement.
Even if JNIEXPORT is a purely internal mechanism - there should be some
documentation.
Since there is no other convenient mechanism in the C sources for creating
"public native library symbols", it was probably inevitable that JNIEXPORT
got repurposed.

JNI support in the JDK needs a lot of love, but I'm already overcommitted
elsewhere.