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