Does JNI really need an interface pointer to provide multiple versions of JNI function tables
The JNI spec says:
The JNI is organized as a C ++ virtual function table or COM interface. The advantage of using an interface table rather than hard-coded function entries is that the JNI namespace becomes separate from native code. The VM can easily provide multiple versions of JNI function tables. For example, a virtual machine can maintain two JNI function tables:
one performs rigorous illegal argument checks and is suitable for debugging; the other performs the minimum amount of validation required by the JNI specification and is therefore more efficient.
But is it really necessary? After all, an interface pointer is a pointer to a pointer. This calls for a higher recession in productivity.
source to share
No, they (the Sun) could have come up with a different design. This JniEnv is with us for historical reasons and does drive up JNI costs, albeit never mind.
The idea was to let the Java side control whether a set of runtime debugging features should be used for a thread. I don't believe this idea has ever helped anyone debug their own code.
Note that the C ++ wrapper reduces the number of problems significantly (of course, this is just syntax, no overhead).
source to share