Re: Classpath JNI changes - take 2

[Brian Jones]

Stephen Crawley <address@hidden> writes:

> Third (and I hope final) take.  This round I've done the following:
> 
>   *  added the JNI 1.4 methods in stead of placeholders
> 
>   *  removed the _JNINATIVEMETHOD #ifdef'ing.  [This is no longer 
>      necessary for Kissme, which now uses a different struct to
>      hold native methods internally.]
> 
>   *  removed the #include of config.h, and modified configure.in
>      to directly substitute the "#define JNI_EXTENSION" into jni.h
> 
>   *  commented the JNI_EXTENSION macros

I like this version much better.  I have still just one problem with
the idea (not the implementation at this point).  It would help me to
understand what you think of this counter proposal before proceeding.

As mentioned before privately, the extra functions a VM might want to
expose to JNI do not need to be in this JNI function table.  An
example from Sun used for the JVMPI, which I'm interested in trying to
make it easier for free VMs to support, uses a structure to define a
function call interface accessed via JNI through GetEnv.  Would
something like this make the JNI_EXTENSION related parts of your patch
unnecessary?

http://java.sun.com/products/jdk/1.2/docs/guide/jvmpi/jvmpi.html

Brian
--
Brian Jones <address@hidden>
http://www.haphazard.org/~cbj/