Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT
erik.joelsson at oracle.com
Mon Dec 10 17:25:57 UTC 2018
Sounds good to me.
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
> 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
> 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