Per Bothner wrote: | | > 1. Use egcs/gcj to make native-method versions of everything, assuming that | > its output can conform to the JNI. | | I don't know what you mean by "conform to the JNI". For me it means | a performance-killer. Having a compiler generate native code that | uses the JNI to interoperate with the JVM sounds nice, because it | means the compiled code can be linked with any VM that supports JNI. | The problem is that the resulting code may well be slower than interpreted | code, which kills the point of compiling it. Perhaps this is true; it's been while since I've looked at the JNI. However, I notice that the native methods in kaffe/AWT are written to conform to the JNI - they takea JNIEnv* argument. So does BigInteger. Since I was looking at AWT code in detail, I assumed that all kaffe native methods were done to the JNI. But, jave.io.* and java.net.*, among others, use a simpler calling convention. Hmmm....