Java能为应用程序提供统一的平台吗？
Java作为一种成熟的语言，同时作为一种优秀的平台，已被广为接受。很多的程序员对Java技术很精通。如果说在进行软件开发的时候，把Java这个平台抛掉或对之置若罔闻，对现在的开发者来说，这是一件忍痛割爱的事情。不管是为了更好的提高程序的性能或是稳定性，还是看中了Java非常丰富的类库，非Java应用程序在JVM上运行已经吊足了程序员的胃口。那么，Java可以为应用程序提供统一的运行平台吗？JVM能承担这一艰巨的任务否？
一、 引言
最近笔者读到一篇”Use Java to Improve Drupal's
Scalability”的文章。作者（Geert
Bevin）在使用Drupal（一套采用GPL授权的开放源码软件，它可以让个人或社区使用者很容易地发表、管理并组织一个网站里大量且多样的内容，已经有许多个人和组织采用Drupal来建立各种不同的网站）时遇到了程序稳定性方面的瓶颈。由于Drupal使用数据库作为缓存，而PHP在跨越Request时是不会保存对象的状态信息的，所以他决定使用Terracotta——一个JVM级的开源群集框架，能提供：HTTP
Session复制，分布式缓存，POJO群集，跨越群集的JVM来实现分布式应用程序协调。使用这一替代方案后，尽管他也遇到了一些别的小问题，但稳定性的问题最终得以解决。同时，将PHP在Java下运行，还可以得到更加安全的运行环境。
上面的例子，我们可以看出，应用程序虽然采用了非Java的技术来构建，但最终在Java的环境下运行，并通过JVM来提高应用程序的稳定性和性能。而且，非Java编写的程序可以在JVM上更加快速的运行，这是非常有意思且有意义的事情。而在不久之前，也许三年或四年前，程序员经常报怨，一种语言编写的程序往往只能在特定的环境下运行。当然，这也包括Java本身。
当然，如今而言，这听上去有点不够人性化。因为不管是PHP应用程序，Ruby
on
Rails应用程序，或是.NET应用程序，似乎都可以在Java环境下运行了。更有甚者宣称，这三种应用程序在Java环境下的运行效率比他们在各自特定的环境下运行的效率还要高。
不管是为了更好的提高程序的性能或是稳定性，还是看中了Java非常丰富的类库，非Java应用程序在JVM上运行已经吊足了程序员的胃口。那么，Java可以为应用程序提供统一的运行平台吗？JVM能承担这一艰巨的任务否？
二、
在JVM中运行.NET依旧能保证性能
Mainsoft公司最近发布了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、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可伸缩性
，在RPS方面几乎是线性增长的；在各种经过测试的负载情况下，都提高了至少4%的响应时间；在重负载情况下，RPS提高了至少5%
。
从客户的角度来看这的确是一种很好且很吸引人的技术，比如客户已经倾向于J2EE的解决方案，而对原有的某些采用.NET实现的系统，假期再采用J2EE来重写，其中的人力物力的浪费可想而知。此外.NET和J2EE平台现在来很难说谁优谁劣，各有所长，如果能够发挥各自的优势岂不是非常妙的事情。
通常要实现.NET与J2EE之间的互操作只能通过高层接口，如WebService等，效率比较低，此外必须部署和维护不同的操作系统等问题，现在可以把.NET的程序编译成JVM
Bytecode，如此一来，两类程序可以融合在一块。不过互操作还是得通过高层接口才能实现，不知道Mainsoft在他们之间的互操作上有什么好方法。这方面有JIntegra的产品，ArcGIS用的就是这个产品。
三、
Ruby on JVM
Ruby on
JVM就是说把Ruby放到JVM上运行，换句话说，在JVM这个平台上可以去运行Ruby，为什么会把Ruby放到JVM上运行呢？因为很多人最奇怪的这一个问题就是，Ruby有它自己的平台，它为什么就会放到JVM上运行？实际上，广大的程序员们已经知道，Java本身是已经被大家广为接受的一个平台，已经有很多的程序员非常熟悉Java技术知识，所以说Java这个平台本身已经得到了大家的一个认可，那么，如果在开发的时候把Java这个平台去抛掉不利用，对Java开发者来说，这是一件不可能的事情。
Ruby可能现在受程序员所关注，可能主要是由于Ruby
on rails的兴起，而Ruby on rails带给大家的是什么呢？最主要的体现是开发效率的提升。有媒体宣称Ruby on
Rails可以给软件开发带来十倍开发效率的提升，当然这不排除炒作的成分。即便抛去这个广告因素来说，可能也确确实实有几倍的效率提升。而人们总是愿意用这种最少的力量去干尽可能多的事情，那既然有像Ruby这么好的开发语言，人们则希望能把Ruby运用在自己的实际的工作之中。如果把Ruby这样好的语言编写的程序，和Java这样一个比较成熟的平台，两者结合起来的话，则能把二者的优势结合起来，对程序员来说也是一个非常好的选择。
Ruby的优点就是它开发效率高，而Java的优点就是它资源非常丰富。而在企业级应用，已经有大量且成熟的Java
EE解决方案，这样两者可以互补。如果把Ruby放到JVM这个平台上，在Ruby的代码里就可以使用Java的类库。而Java已经有很多现成的且做得很好的类库及解释方案，都可以在Ruby代码中得到复用；另外一方面，可以把Ruby的应用部署到JVM上。
要使Ruby运行在JVM上，主要的方式有两种。第一，因为Ruby是一种解释性的语言，利用Java开发一个Ruby的解释器，然后让Ruby的应用程序运行在JVM平台上，而这也确确实实是现在可能比较主流的方式——JRuby；那另外一种方式，除了解释的方式外，还可以采用编译的方式，把Ruby的代码编译成Java
Bytecode，然后让Bytecode去运行在JVM的平台上——XRuby。
四、
JVM——高层次的OS
在这样的一场游戏中，我们似乎可以把Java看作为构建于OS（操作系统）之上高层次的OS——可以为应用程序或框架提供重要的底层服务及功能。但这些服务及功能非一般的普通OS技术能提供，例如普通的OS可能有：内存管理；线程，处理及同步；执行本地程序或解释Shell脚本。而JVM这层OS，可提供：简易的垃圾回收；在应用程序中对内存进行安全管理；即时编译技术（JIT，Just
In
Time）执行动态代码。
在Windows程序设计领域处于发展初期时，Windows程序员可使用的编程工具唯有API函数。这些函数在程序员手中犹如“积木块”一样，可搭建出各种界面丰富、功能灵活的应用程序。不过，由于这些函数结构复杂，所以往往难以理解，而且容易误用。而随着软件技术的不断发展，在Windows平台上出现了很多优秀的可视化编程环境，程序员可以采用“所见即所得”的编程方式来开发具有精美用户界面和功能的应用程序。这些可视化编程环境操作简便、界面友好，比如：Visual
C++，Delphi，Visual
Basic等等。在这些工具中提供了大量的类库和各种控件，它们替代了API的神秘功能。事实上，这些类库和控件都是构筑在Windows
API的基础上的，但它们使用方便，加速了Windows应用程序的开发，所以受到程序员的普遍采用。有了这些类库和控件，程序员们便可以把主要精力放在
整体功能的设计上，而不必过于关注具体细节。不过，这也导致了非常多的程序员在类库面前“固步自封”，对下层API函数的强大功能一无所知。
一、 引言
最近笔者读到一篇”Use Java to Improve Drupal's
Scalability”的文章。作者（Geert
Bevin）在使用Drupal（一套采用GPL授权的开放源码软件，它可以让个人或社区使用者很容易地发表、管理并组织一个网站里大量且多样的内容，已经有许多个人和组织采用Drupal来建立各种不同的网站）时遇到了程序稳定性方面的瓶颈。由于Drupal使用数据库作为缓存，而PHP在跨越Request时是不会保存对象的状态信息的，所以他决定使用Terracotta——一个JVM级的开源群集框架，能提供：HTTP
Session复制，分布式缓存，POJO群集，跨越群集的JVM来实现分布式应用程序协调。使用这一替代方案后，尽管他也遇到了一些别的小问题，但稳定性的问题最终得以解决。同时，将PHP在Java下运行，还可以得到更加安全的运行环境。
上面的例子，我们可以看出，应用程序虽然采用了非Java的技术来构建，但最终在Java的环境下运行，并通过JVM来提高应用程序的稳定性和性能。而且，非Java编写的程序可以在JVM上更加快速的运行，这是非常有意思且有意义的事情。而在不久之前，也许三年或四年前，程序员经常报怨，一种语言编写的程序往往只能在特定的环境下运行。当然，这也包括Java本身。
当然，如今而言，这听上去有点不够人性化。因为不管是PHP应用程序，Ruby
on
Rails应用程序，或是.NET应用程序，似乎都可以在Java环境下运行了。更有甚者宣称，这三种应用程序在Java环境下的运行效率比他们在各自特定的环境下运行的效率还要高。
不管是为了更好的提高程序的性能或是稳定性，还是看中了Java非常丰富的类库，非Java应用程序在JVM上运行已经吊足了程序员的胃口。那么，Java可以为应用程序提供统一的运行平台吗？JVM能承担这一艰巨的任务否？
二、
在JVM中运行.NET依旧能保证性能
Mainsoft公司最近发布了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、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可伸缩性
，在RPS方面几乎是线性增长的；在各种经过测试的负载情况下，都提高了至少4%的响应时间；在重负载情况下，RPS提高了至少5%
。
从客户的角度来看这的确是一种很好且很吸引人的技术，比如客户已经倾向于J2EE的解决方案，而对原有的某些采用.NET实现的系统，假期再采用J2EE来重写，其中的人力物力的浪费可想而知。此外.NET和J2EE平台现在来很难说谁优谁劣，各有所长，如果能够发挥各自的优势岂不是非常妙的事情。
通常要实现.NET与J2EE之间的互操作只能通过高层接口，如WebService等，效率比较低，此外必须部署和维护不同的操作系统等问题，现在可以把.NET的程序编译成JVM
Bytecode，如此一来，两类程序可以融合在一块。不过互操作还是得通过高层接口才能实现，不知道Mainsoft在他们之间的互操作上有什么好方法。这方面有JIntegra的产品，ArcGIS用的就是这个产品。
三、
Ruby on JVM
Ruby on
JVM就是说把Ruby放到JVM上运行，换句话说，在JVM这个平台上可以去运行Ruby，为什么会把Ruby放到JVM上运行呢？因为很多人最奇怪的这一个问题就是，Ruby有它自己的平台，它为什么就会放到JVM上运行？实际上，广大的程序员们已经知道，Java本身是已经被大家广为接受的一个平台，已经有很多的程序员非常熟悉Java技术知识，所以说Java这个平台本身已经得到了大家的一个认可，那么，如果在开发的时候把Java这个平台去抛掉不利用，对Java开发者来说，这是一件不可能的事情。
Ruby可能现在受程序员所关注，可能主要是由于Ruby
on rails的兴起，而Ruby on rails带给大家的是什么呢？最主要的体现是开发效率的提升。有媒体宣称Ruby on
Rails可以给软件开发带来十倍开发效率的提升，当然这不排除炒作的成分。即便抛去这个广告因素来说，可能也确确实实有几倍的效率提升。而人们总是愿意用这种最少的力量去干尽可能多的事情，那既然有像Ruby这么好的开发语言，人们则希望能把Ruby运用在自己的实际的工作之中。如果把Ruby这样好的语言编写的程序，和Java这样一个比较成熟的平台，两者结合起来的话，则能把二者的优势结合起来，对程序员来说也是一个非常好的选择。
Ruby的优点就是它开发效率高，而Java的优点就是它资源非常丰富。而在企业级应用，已经有大量且成熟的Java
EE解决方案，这样两者可以互补。如果把Ruby放到JVM这个平台上，在Ruby的代码里就可以使用Java的类库。而Java已经有很多现成的且做得很好的类库及解释方案，都可以在Ruby代码中得到复用；另外一方面，可以把Ruby的应用部署到JVM上。
要使Ruby运行在JVM上，主要的方式有两种。第一，因为Ruby是一种解释性的语言，利用Java开发一个Ruby的解释器，然后让Ruby的应用程序运行在JVM平台上，而这也确确实实是现在可能比较主流的方式——JRuby；那另外一种方式，除了解释的方式外，还可以采用编译的方式，把Ruby的代码编译成Java
Bytecode，然后让Bytecode去运行在JVM的平台上——XRuby。
四、
JVM——高层次的OS
在这样的一场游戏中，我们似乎可以把Java看作为构建于OS（操作系统）之上高层次的OS——可以为应用程序或框架提供重要的底层服务及功能。但这些服务及功能非一般的普通OS技术能提供，例如普通的OS可能有：内存管理；线程，处理及同步；执行本地程序或解释Shell脚本。而JVM这层OS，可提供：简易的垃圾回收；在应用程序中对内存进行安全管理；即时编译技术（JIT，Just
In
Time）执行动态代码。
在Windows程序设计领域处于发展初期时，Windows程序员可使用的编程工具唯有API函数。这些函数在程序员手中犹如“积木块”一样，可搭建出各种界面丰富、功能灵活的应用程序。不过，由于这些函数结构复杂，所以往往难以理解，而且容易误用。而随着软件技术的不断发展，在Windows平台上出现了很多优秀的可视化编程环境，程序员可以采用“所见即所得”的编程方式来开发具有精美用户界面和功能的应用程序。这些可视化编程环境操作简便、界面友好，比如：Visual
C++，Delphi，Visual
Basic等等。在这些工具中提供了大量的类库和各种控件，它们替代了API的神秘功能。事实上，这些类库和控件都是构筑在Windows
API的基础上的，但它们使用方便，加速了Windows应用程序的开发，所以受到程序员的普遍采用。有了这些类库和控件，程序员们便可以把主要精力放在
整体功能的设计上，而不必过于关注具体细节。不过，这也导致了非常多的程序员在类库面前“固步自封”，对下层API函数的强大功能一无所知。
