>>>>> "Stephen" == Stephen Crawley <[EMAIL PROTECTED]> 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
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
