Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT

[Magnus Ihse Bursie]

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