Sounds good to me.
/Erik
On 2018-12-10 05:19, Magnus Ihse Bursie wrote:
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.
Thoughts?
/Magnus
