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

在最近图灵公司总编刘江发布的一个博客中，提到 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 大旗？你的观点是什么？欢迎分享。