敏捷Web开发向左，标准Java平台向右？

作者 霍泰稳 发布于 2008年4月15日 下午10时16分

社区

Ruby,

Java

主题

开放源代码,

Web框架,

动态语言,

JRuby

标签

编码标准,

争论,

LAMP,

标准化

在最近图灵公司总编刘江发布的一个博客中，提到PHP 3之后的主要语言开发者、Zend公司创始人Andi Gutmans向Java平台发难，说其已经失利于现代Web开发的这场战争，寄希望于JVM并不能挽回颓势。但社区似乎并没有完全支持Gutmans的这一观点。

根据Gutmans的表述，最终目的的不同是动态语言和Java平台选择不同道路的主要诱因。Java从所诞生的那一刻起就注定是为企业平台开发服务，而动态语言则好像是为Web开发量身打造，这一发展趋势仍然在延续：

[大型企业级项目团队中最优秀的人]恰恰忽视了Web，因此Java EE设计时并没有以Web为中心，而且关注在企业集成、事务管理和其他后端处理上。虽然Java EE通过Servlet和JSP支持Web开发也有不短的历史，但是掌握标准发展的大公司们忽视了Web的RESTful本质，仍然在向通用平台的方向上走。

而与此同时，建于C语言库和工具的生态系统之上的LAMP架构，则成了Web程序最流行的开发平台。其中最常用的语言是PHP。由于PHP专注于Web开发，而且为此不断演变，它简直就是为Web范型（paradigm）量身打造的，能够快速和容易地解决常见的Web问题，因此获得了最大的市场份额。

Java平台显然也注意到了Web开发的兴起，当包括CRM、ERP、报表、文档管理等业务应用程序也都转向了Web后，Java厂商开始支持各种标准和非标准的Java Web框架，比如JSF、Struts、Spring MVC等，以使得Java适应Web。但结果并不理想，Gutmans分析其原因是：

它们都无法解决Java在Web上的主要问题：由于严格的类型化和架构过度复杂，开发时间和开发人员的技能要求都更高，也就是说，总成本无法令人满意。

而且，大的Java厂商还什么都想占着。一方面想融入Web，一方面又不肯放弃自己已经在Java上建立起来的数十亿计的生意。甚至动态语言的广泛流行都未能显著改变他们的行为模式。

一直对技术社区保持关注的国内技术专家李锟对Java在面向互联网Web开发领域被边缘化，也给出了自己的见解：

Java在面向Internet的Web开发领域被边缘化已经不是新闻。在2005年Rails和Ajax崛起的时候，Java差不多就已经出局了。遗憾的是，Java社区的一些人仍然冥顽不化。一个典型的例子是Sun派了SOAP/WSDL等规范的主要制定者去掌管REST规范JSR 311委员会。这帮家伙完全无视REST与SOAP/WSDL在设计理念上的巨大差异，决定基于与SOAP/WSDL相同的理念来设计JSR 311。

拥抱REST是Java在Web开发领域挽回颓势的必要举措，这是一件非常紧急的事情，他们却陷入了争论和政治斗争的泥坑。Rod Johnson决定甩开这帮家伙，在Spring 3.0中提供全面的REST支持，无疑是一个明智之举。失去了Web，Java就失去了未来。企业应用的传统领地也会逐渐被蚕食的。

观察这一技术讨论背后的原因，“是否遵循标准”是答案之一。对于Java，由于有着大厂商的支持，在标准的遵循上要求比较严格，这也是其适合大型项目的一个原因。而Web开发更喜欢敏捷地变化，就如同开发这些动态语言的使用者的理念一样，他们的目的不是遵循标准，而是为了快速地搞定工作。

有开发人员表示，开源社区开发原生动态语言实现要超速发展，唯一的可能是该实现只是事实标准，而并没有稳定的标准定义。但标准定义真的很有意义吗，尤其是在Web开发开发领域？李锟表述说：

有些场合确实重要，例如要将Ruby移植到.NET上，但又因为与微软公司签订了协议，不能直接参考Ruby以GPL发布的源代码。没有标准，做这件事难度太大了。这正是IronRuby发展缓慢的原因。

不过对于普通的Rails开发人员，稳定的标准定义其实没有那么大的重要性。我们还是要实事求是地看待这个问题。Rod Johnson在《J2EE without EJB》中对待标准的态度是值得我们借鉴的。“委员会设计”的不成熟标准会扼杀创新和竞争，这在Java世界中已经一再出现过。

现在包括Sun在内的一些厂商竞相在JVM上提供动态语言，但其原因Gutmans归结为是“患得患失，怕失去对客户的控制”，他认为Java厂商应该抛开与Java绑定的很紧但对多语言又支持的很少的JVM，转向能够使客户两全其美的LAMP和Java技术松耦合的模型。在分析客户虽然会被动态语言的JVM实现所吸引，但市场依然会选择LAMP时，他列举了JVM的一个不足：

JVM最初设计时并没有考虑支持动态语言，因此在可见的将来，要满足实际需求，挑战非常大。像闭包、间接方法调用和类型juggling等动态特性就不容易解决，这从目前JRuby与Ruby的C版本的比较中可以看出。而且，硬件厂商是否有兴趣跟上也是有待观察的。而开源技术就没有这种问题。

但也有声音对Gutmans的看法表达了不同意见，Sun现在也在大力改进JVM对于动态类型语言的支持，当然这不是一件容易的事情，但是还是很值得期待的。在新发布的JRuby 1.1中对性能做了优化，参与开发的Charles Nutter在接受InfoQ的采访时表示“如果一段Ruby代码在JRuby中运行得不如在Ruby 1.8.6中快的话，我们就认为这中间出现了问题，于是我们就查找问题报告，来解决所有遗留的瓶颈问题。”据另一位开发人员Ola表示，JRuby还有进一步性能优化的余地。

在Web开发中，是选择JVM，还是高举LAMP大旗？你的观点是什么？欢迎分享。

1. 返回顶部

   还是JAVA

   2008年4月16日 上午3时9分 发表人 Hill Eric

   我没有听说LAMP可以做企业级应用

   回复

2. 返回顶部

   Re: 还是JAVA

   2008年4月16日 下午9时46分 发表人 Ran Xiang

   大哥,您看文章了么? 'Java从所诞生的那一刻起就注定是为企业平台开发服务，而动态语言则好像是为Web开发量身打造'

   回复

3. 返回顶部

   个人觉得语言跟web没有太多的关系

   2008年4月17日 下午10时37分 发表人 fuzhong chen

   如果企业级应用仅仅是增、删、改、查的话，动态语言确实很有优势。一个命令就从头到尾生成代码了，但企业级应用复杂是因为围绕这些基本功能的业务规则，这些业务规则需要我们分析、抽象到设计才能做出好的系统，而不是一个命令就可以搞定的。个人觉得语言跟web没有太多的关系。

   回复

4. 返回顶部

   Re: 还是JAVA

   2008年4月18日 上午2时41分 发表人 图灵 刘江

   你真的认为自己完全了解什么叫企业级应用么？Yahoo算不算？Wikipedia算不算？Google的很多应用算不算？成功的基于LAMP的大型数据密集型应用，现在太多了。

   回复

5. 返回顶部

   Re: 还是JAVA

   2008年4月21日 上午2时19分 发表人 fuzhong chen

   谢谢你的回复，我不敢说我对企业级应用有多么了解。每天做些编码的事（其实是增、删、改、查），下班就回家。而且用户经常更改需求，如果我们不面对用户的话怎么能做好呢。你们太转注于技术了。

   回复

• 更早的 >