Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Mon Dec 10 13:19:09 UTC 2018
I propose that we introduce a new define, available to all JDK native
files (Hotspot included), called JDK_EXPORT. The behavior of this symbol
will be very similar (as of now, in fact identical) to JNIEXPORT;
however, the semantics will not.
Currently, we "mis-use" the JNIEXPORT define to mark a function for
exporting from the library. The problem with this is that JNIEXPORT is
part of the JNI interface, and is supposed to be used when C programs
interact with Java. And, when doing this, the function should be fully
decorated like this: "JNIEXPORT foo JNICALL".
We do have many such JNI exports in our native libraries, but we also
have a lot of other, non-JNI exports, where one native library just
provides an interface to other libraries. In these cases, we have still
used JNIEXPORT for the functionality of getting the function exported,
but we have not been consistent in our use of JNICALL. This has caused
us way too much trouble for something that should Just Work<tm>.
I therefore propose that we define "JDK_EXPORT", with the same behavior
as JNIEXPORT (that is, flagging the function for external visibility in
the resulting native library), but which is *not* supposed to be
exported to Java code using JNI, nor supposed to be decorated with
JNICALL. All current instances of JNIEXPORT which is not pure JNI native
functions should be changed to use JDK_EXPORT instead.
I further propose that this macro should reside in a new file "jdk.h",
placed in the new directory src/java.base/share/native/include/internal.
This header file path will automatically be provided to all native
libraries, but not copied to the JDK being built. (The existence of a
"include/internal" directory with this behavior has been discussed
before. There are more files that ought to be moved there, if/when it is
created.) I believe in many cases the #include "jni.h" can be just
modified to #include "#jdk.h", since most native code will not require
"jni.h" unless actually doing JNI calls -- most have included this file
to get the JNIEXPORT macro, which would explain the pervasive use of
#include "jni.h" in our code base.
More information about the core-libs-dev