Re: Classpath JNI changes - take 2

[Tom Tromey]

>>>>> "Stephen" == Stephen Crawley <address@hidden> writes:

Stephen> With that in mind, the attached classpath.diffs.gz files give my 
Stephen> revised proposal for changes to jni.h in Classpath.  Basicly, the
Stephen> changes allow the following:

I read this patch.

Stephen>   1  They define placeholders for the JDK 1.4 extensions to JNI

You might as well use the real definitions.  You can grab them from
the libgcj jni.h if you like.  I can email it to you if you want.

Stephen>   2  They allow JVM implementations to #include jni.h to avoid 
Stephen>      mismatched function tables.

We do this in the libgcj jni.h as well.  I think it is a good idea.

I don't understand the point of protecting code by _JNINATIVEMETHOD.

Defines like JNI_EXTENSION_TYPES, JNI_EXTENSION_FUNCTIONS and
_JNI_VM_INTERNAL_TYPES_DEFINED need to be documented somewhere.

I don't think you can include config.h in jni.h.  If you do that, then
you have to install config.h -- but that header isn't really suitable
for installation.

In libgcj we have a special sanitized config.h we use for this
purpose.  In Classpath historically this was the point of the
`jni_md.h' header ("md" is "machine dependent").

Tom