Patch: Add JNICALL/JNIEXPORT attributes to JNI functions in jni.h/jni.cc

[Tom Tromey]

>>>>> "Ranjit" == Ranjit Mathew <rmathew@hotmail.com> writes:

Ranjit> The following patch proposes to add missing JNICALL and
Ranjit> JNIEXPORT attributes to the JNI function and function pointer
Ranjit> declarations in jni.h and function definitions in jni.cc.

Wow, thanks.

Ranjit> I've tried to be consistent with Sun's JDK as much as
Ranjit> possible, even if, AFAICT, it is not quite right.  For
Ranjit> example, a declaration for an exported function in a DLL
Ranjit> should have a JNIIMPORT attribute while a definition for the
Ranjit> same should have the JNIEXPORT attribute - Sun's jni.h uses
Ranjit> JNIEXPORT everywhere *except* for
Ranjit> JNI_GetDefaultJavaVMInitArgs( ), JNI_CreateJavaVM( ) and
Ranjit> JNI_GetCreatedJavaVMs( ), where a _JNI_IMPORT_OR_EXPORT_
Ranjit> #define-kludge is used that gets mapped to JNIIMPORT or
Ranjit> JNIEXPORT depending on whether _JNI_IMPLEMENTATION_ has been
Ranjit> defined (presumably by the JNI implementation sources just
Ranjit> before including jni.h).

I think we should do whatever will have the desired effect on the
user's build.  Perhaps Sun's header has bugs, I don't know.  If
JNIIMPORT in jni.h gets us the effect we need, then let's do that.

We can do the import-or-export trick too if need be.  We already do
something similar in jni.h; search for __GCJ_JNI_IMPL__.

Ranjit> Most of the JNI functions like "static int _Jv_JNI_FooBar(
Ranjit> ...)" in jni.cc have been redefined as "static int JNICALL
Ranjit> _Jv_JNI_FooBar( ...)"  *except* for those that return pointers
Ranjit> - here I've had to define them as "static JNICALL int *
Ranjit> _Jv_JNI_FooBar( ...)" to avoid compiler errors.

What did you try for the pointer-returning ones?  (Putting it between
the `int' and `*' probably won't work...)  In any case sometimes there
are oddities with attributes; this is the source of an occasional
minor flame war on the gcc list.

Ranjit> Or should I consistently use the latter form throughout?

Consistency, though reportedly a hobgoblin, can still make code more
readable.  If it isn't much trouble, please do that.

Tom