把.net程序编译成java字节码在jvm上运行？

       从GoogleGroup上看到一篇文章《 Java能为应用程序提供统一的平台吗？》觉得很有意思，说的是……
**在**JVM**中运行**.NET**依旧能保证性能***

Mainsoft <http://www.mainsoft.com/>公司最近发布了2.0版本的Mainsoft for Java EE（原名Visual
Mainwin），同时发布的还有一份有趣的白皮书 。据该白皮书称，一个基于.NET的应用程序，若是借助于Mainsoft for Java EE
技术交叉编译之后运行于Java EE平台上，那么在某些方面的性能甚至会强于原有的.NET应用程序。

交叉编译引擎将.NET Framework生成的Microsoft Intermediate Language（MSIL）交叉编译成Java
的字节代码。然后基于Java的.NET Framework实现即可支持应用程序运行于Java平台之上。不但如此，Visual Studio
扩展还能够允许开发者在Java EE平台上编写、编译、部署以及调试Web或服务器应用程序。

因为代码的交叉编译发生于字节码级别，所以其过程并不需要源文件转换——这就意味着开发者仍旧可以使用Visual Studio.Net
作为他们可移植程序的开发环境。Mainsoft还使用Java重新实现了很大的一部分.NET
Framework，包括ASP.Net<http://en.wikipedia.org/wiki/ASP.NET>
、ADO.Net <http://en.wikipedia.org/wiki/ADO.NET>以及Web Service API等。不过因为Mainsoft
for Java EE主要专注于Web以及服务器应用程序方面，所以类似Windows Form的组件则没有提供。

图1. 将ASP.NET和.NET Server部署在Java EE上示意图

迁移后的Java EE应用程序可以运行于IBM WebSphere、BEA WebLogic和Apache Tomcat
之上。在完全相同的硬件条件下，迁移后的Java EE应用程序（运行于WebSphere之上）：每秒处理请求数（Requests Per Second，
RPS）比原有.NET应用程序提高了8%；具有更好的CPU可伸缩性 <http://en.wikipedia.org/wiki/Scalability>
，在RPS方面几乎是线性增长的；在各种经过测试的负载情况下，都提高了至少4%的响应时间；在重负载情况下，RPS提高了至少5% 。

从客户的角度来看这的确是一种很好且很吸引人的技术，比如客户已经倾向于J2EE的解决方案，而对原有的某些采用.NET实现的系统，假期再采用J2EE
来重写，其中的人力物力的浪费可想而知。此外.NET和J2EE平台现在来很难说谁优谁劣，各有所长，如果能够发挥各自的优势岂不是非常妙的事情。

通常要实现.NET与J2EE之间的互操作只能通过高层接口，如WebService等，效率比较低，此外必须部署和维护不同的操作系统等问题，现在可以把
.NET的程序编译成JVM Bytecode，如此一来，两类程序可以融合在一块。不过互操作还是得通过高层接口才能实现，不知道Mainsoft
在他们之间的互操作上有什么好方法。这方面有JIntegra的产品，ArcGIS用的就是这个产品