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