Re: Classpath JNI changes - take 2

[Stephen Crawley]

> 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 thi
s make the JNI_EXTENSION related parts of your patch
> unnecessary?
> 
> http://java.sun.com/products/jdk/1.2/docs/guide/jvmpi/jvmpi.html

This is an interesting idea, and I think it would work.  On the
plus side, removing the need for non-standard extensions to the 
JNI function table is a good thing.  It also removes the problem
of tracking future changes coming from Sun.

On the down side, the call to GetEnv represents a small overhead.
If the native code is such that the cost of the GetEnv call cannot be 
amortised, this might conceivably be significant.  

Another theoretical problem is that Sun don't appear to endorse this
approach officially. JVMPI is still "experimental", and the JNI spec for
GetEnv does not state that it can be used this way ... especially to
support JVM specific extensions.  [But then again, hacking the JNI
function table is not endorsed by Sun either :-)]

Anyway, I'll have a go at implementing this idea and let you know.

-- Steve