[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Classpath JNI changes - take 2

From: Stephen Crawley
Subject: Re: Classpath JNI changes - take 2
Date: Tue, 10 Dec 2002 00:08:17 +1000

> >>>>> "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.
> _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
to generate include/jni_md.h from a template file.
Alternatively I could get configure to substitute the #define flags via
the existing template.

Which approach is preferable?

-- Steve

reply via email to

[Prev in Thread] Current Thread [Next in Thread]