The JVM needs a mechanism for trusted code to make direct use of native (foreign) functions and data structures.

1. JVM languages like JRuby are often built on top of associated utility libraries written in C and encapsulated more or less safely. It should not be prohibitively complex or slow for the JVM to integrate with such libraries, at least for standalone emulation of their associated language. Requiring hand-written JNI wrappers is often prohibitive.

2. The JVM would make a useful container for legacy libraries, if it could be integrated easily with those libraries and their APIs. Again, the need to engineer JNI middleware disqualifies the JVM from such a role, on grounds of cost.

3. Small intrinsic functions like SIMD vector operations are too lightweight for JNI overhead, which means that Java has no way to program with them that corresponds to simdx86.sourceforge.net. Short of engineering them into the optimizing compiler, we need a way to call them directly from Java code in order to make use of them.

4. System-specific services, such as file system attributes, or Windows registry data, or Mac OS events, do not always make sense under generic Java APIs, yet mature well-ported applications (like NetBeans) often need to work with them. The engineering cost of such integration would go down if there were a more direct and dynamic way for Java code to access system-specific APIs.

5. The internal implementation code of the JVM is also complicated by JNI middleware, which must be hand implemented, hand maintained, and deployed as additional DLL code. If there were a more direct way to call system services, the shim code (if any) could be written and maintained in Java, lowering costs of maintenance, deployment, and innovation.

Note that all of these use cases of a direct native connection are consistent with a model which confers higher performance on trusted native interfaces, while preventing untrusted Java code from accessing those interfaces. Giving JVM users a new trade-off in their management of C code would make the JVM useful in more places, such as those described above.

The key JVM feature required is a dynamically linked symbolic representation of the shape of each API element (especially functions) which the JVM interprets correctly to form calls to the system interface. Such representations are easy to generate with a tool like SWIG.

For an example of such a direct native interface on an earlier managed runtime, see Rose & Muller, "Integrating the Scheme and C Languages", ACM L&FP 1992, http://homepage.mac.com/rose00/work/esh.html .