IKVM.net,AFAIK,几乎完全实现了在CLR中编码的Java Runtime(因为它实现了OpenJDK,而不是Orcale Java,因此它有点破坏)平台,JIT本身会将Java字节码编译成IL,然后执行它,这类似于QEMU,但还有另一个问题,我们遇到了三层,第一层是Java Runtime,然后我们来到CLR,最后是本机代码,因此它非常非常慢,并且另一个问题是初始时间问题.

例如,我编写了一个Java程序,只打印着名的“Hello World”引用然后退出,然后我想测试一下,IKVM.net和Orcale JVM(缩短到JVM)可以做多少毫秒(我在KVM Windows环境中运行两个平台,具有2个通用3.4 GHz cpu和2G DDR3内存),我的结果是,JVM在692ms完成,内存使用量为9MB,而IKVM.net,可以使用大约4923毫秒,内存占用19MB,打印出一个很酷的“Hello World！”仅报价！如果我将Java类编译成预编译的IL(ikvmc),可以将时间量减少到大约1907ms,并且内存使用量与JIT相同.

相比之下,对于JVM和IKVM.net(JIT),JVM在竞争对手中的引用时间约为7倍,内存占2倍,对于JVM和IKVM.net(预编译),JVM仍然领先于对抗竞争对手的内存是2.7倍和1.11倍,而对于IKVM.net(JIT)和IKVM.net(预编译),它将为您提供双倍的提升,并且内存占用没有差异,尽管它们仍然比JVM更慢更胖.

还有一个问题,预编译的IKVM.net存根必须随处携带整个IKVM.net二进制文件,那个包大小增加了41MB,我不知道是否可以删除一些未使用的库,但在大多数情况下,我们不会这样做.

对于jni4net,用于打印“Hello World”的时间大约是1567ms,从CLR到JVM,从JVM到CLR呢？有点奇怪,它使用了2106ms,我不知道为什么差别很大,也许是因为Java是从头开始动态创建一个CLR实例,而CLR可以直接在静态P / Invoke JNI.

总而言之,jni4net更可能是CLR和JVM之间的代理 – 它不是实现完整的Java环境,也不是模拟完整的CLR,而是通过现有资源创建JVM和CLR实例.虽然IKVM.net,它更像是伪装成.Net编码的JVM,但你可以将Java代码注入到CLR中,而你不能在Java端编写.Net,它很慢,但它不再需要JVM,你可以安装.Net Framework并享受其余的(但你只能运行Java SE).

为了回答你的问题,根本没有好的解决方案 – jni4net和IKVM.net,实际上两个完全不同,但如果你想强制结论,我想使用IKVM.net – 它仍然活跃,强大,可扩展,但又肥胖又缓慢.