jni4net is much smaller (1.5 MB in binary size) and has a better print , but development probably stopped, and the project was abandoned since the last update of the repository was completed in November 2013, but it still remained at the Alpha stage, therefore immature. complicated, more work needs to be done to use it , BTW, jni4net used LGPL , so it will be very problematic if you want to use it in your commercial products.
IKVM.net, AFAIK, was an almost complete implementation of Java Runtime encoded in the CLR environment (since it implements OpenJDK and not Orcale Java, so it is a bit broken) the platform and JIT itself will compile Java bytecode in IL , and then execute him, it looks like QEMU, but there is another problem that we are faced with three levels, the first level is Java Runtime , then we came to the CLR and, finally, our own code , so it is very, very slow , and the other problem is the initial time is a problem.
For example, I wrote a Java program that would only print the famous quote “Hello World” and then exit, and then I would like to check how many milliseconds that IKVM.net and Orcale JVM (short for JVM) (I run both platforms in KVM windows environment with 2 cores of 3.4 GHz processor and 2G DDR3 memory), and my result: JVM was completed in 692 ms, using 9 MB of memory , and IKVM.net can use about 4923 ms, with a memory size of 19 MB to print the cool "Hello World!". quote only! If I compiled the Java class into a pre-compiled IL (ikvmc), I could reduce the time to about 1907 ms, and the memory usage would be the same as that of JIT .
In comparison, for JVM and IKVM.net (JIT), JVM led about 7 times and 2 times in memory against the opponent, and for JVM and IKVM.net (pre-compiled), JVM still led about 2.7 times and 1 , 11 times in memory against the opponent, while for IKVM.net (JIT) and IKVM.net (precompiled) this will give you a doubling in time and no differences in memory area , although they are still slower and thicker than JVM .
There is also another problem: the pre-compiled IKVM.net stub should carry the entire IKVM.net binary everywhere and it was about 41 MB in packet size increment, I know if I can delete some unused library, but in most cases we will we will not do it.
For jni4net, the amount of time it takes to print "Hello World" is about 1567 ms , from CLR to JVM, and what from JVM to CLR? It's strange that he used 2106 ms , I don’t know why the difference is huge, maybe it was because Java creates the CLR from scratch dynamically , and the CLR can directly P / invoke JNI statically .
To summarize, jni4net will most likely be a proxy between the CLR and the JVM - it does not implement the full Java environment and does not model the full CLR, instead it will create both the JVM and the CLR instance of existing resources. Although IKVM.net is more like a .Net encoded JVM, you can add Java code to the CLR, while you cannot encode .NET on the Java side , it is slow, but it does not require the JVM anymore , you can simply install the .NET Framework and enjoy the rest (but you can run Java SE).
To answer your question, there is no good solution - jni4net and IKVM.net, there were actually two completely different things at all , but if you want to conclude, I like to use IKVM.net - it is still active, powerful, expandable but fat and slow .