Re: Classpath JNI changes - take 2

[Stephen Crawley]

> >>>>> "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").

These are all good points.

WRT to the last one, this would imply that I should change configure.ac
to generate include/jni_md.h from a jni_md.h.in template file.
Alternatively I could get configure to substitute the #define flags via
the existing jni.h.in template.

Which approach is preferable?

-- Steve