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函数的强大功能一无所知。
闽公网安备 35060202000074号