Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT

[Erik Joelsson]

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
>