PHP 3之后的主要語言開發者之一、Zend公司的創始人之一Andi Gutmans最近在blog中直言不諱地批評了Java語言。他指出，目前Java廠商試圖在JVM上提供動態語言實現的路子根本不對，應該全面擁抱標準的動態語言。

由于Gutmans的特殊地位，他的這篇長文已經在技術界引發了強烈爭議。參見其blog上和TSS上的討論1，2。

下面是對全文的一個編譯版本，基本反映了原貌。其中對多核環境中多線程（JVM）與多進程（LAMP）的比較，C語言生態系統以及開源語言與Java等廠商語言和技術的比較，感覺都是非常有價值的。

翻譯上的問題，請多指教。


--------------------------------------------------------------------------------

Gutmans回憶自己幾 年前參與的一個基于IBM Websphere的大型企業級項目。項目團隊中無論開發還是架構人員都非常出色，但其中最優秀的人與Andi談起PHP和動態語言時，還是將之視為玩具 語言。這在當時正是Java界對動態語言的典型心態。但是，他們恰恰忽視了Web，因此Java EE設計時并沒有以Web為中心，而且關注在企業集成、事務管理和其他后端處理上。雖然Java EE通過servlet和JSP支持Web開發也有不短的歷史，但是掌握標準發展的大公司們忽視了Web的RESTful本質，仍然在向通用平臺的方向上 走。

而與此同時，建于C語言庫和工具的生態系統之上的LAMP架構，則成了Web程序最流行的開發平臺。其中最常用的語言是PHP。由于PHP專注于 Web開發，而且為此不斷演變，它簡直就是為Web范型（paradigm）量身打造的，能夠快速和容易地解決常見的Web問題，因此獲得了最大的市場份 額。根據Ajaxian.com的調查，大約50%的RIA開發人員都使用PHP。由于各種PHP程序如Wordpress, Drupal, mediaWiki, osCommerce, SugarCRM的流行，這種趨勢更加明顯。

隨著大多數業務應用程序包括CRM、ERP、報表、文檔管理等等也都轉向了Web，那些大的Java廠商都意識到，Java對Web范型的形成和 發展影響甚微，因此他們開始支持各種標準和非標準的Java Web框架（JSF、Struts、Spring MVC等等），要使Java適應Web。這些框架雖然有些也取得了一定成功，但是它們都無法解決Java在Web上的主要問題：由于嚴格的類型化和架構過 度復雜，開發時間和開發人員的技能要求都更高，也就是說，總成本無法令人滿意。

而且，大的Java廠商還什么都想占著。一方面想融入Web，一方面又不肯放棄自己已經在Java上建立起來的數十億計的生意。甚至動態語言的廣泛流行都未能顯著改變他們的行為模式。但是隨著微軟雄心勃勃的多語言運行環境.NET的出現，大勢又變了。

成功的動態語言包括PHP, Perl, Python和Ruby都是用C寫的，充分利用了C語言庫生態系統的廣泛性和深入性。而且它們都是社區驅動的，沒有什么正二八經的語言規范，發展不會被公 司政治所阻礙。這些語言都是由使用者自己開發的，他們只有一個目的：快速搞定工作。因此語言可能在小的版本更新時就加入重要的改進。這種敏捷本質正是適應 Web應用快速變化必需的。

而且，LAMP的部署方式有顯著的優勢。在多進程架構中，Web服務器和動態語言軟件中的故障一般不會使網站垮掉。雖然會有某個進程崩潰，但其他 服務Web請求的進程仍然可以繼續運行。這與JVM這種多線程的環境中軟件故障包括崩潰和死鎖通常都會使系統垮掉，形成了鮮明對比。 而且在特定時間后回收進程的能力能夠防止內存泄漏和內存碎片化這兩種常見的內存問題使軟件隨著時間推移性能降低。LAMP上軟件更新時，可以輕松和漸增地 推到服務器，無需冗長的構建和打包。雖然有時這會帶來不規范、不嚴格的問題，但是只要正確實施，開發人員和運營人員的日子都會好過得多。

相比之下，Java廠商受困于與Java綁定太緊對多種語言的支持很少的JVM。他們并沒有轉向能夠使其客戶兩全其美的LAMP和Java技術松 耦合的模型，而是患得患失，怕失去對客戶的控制，競相在JVM上提供動態語言。無論是微軟這個強敵，還是Java中互相競爭的廠商，都在實施自己的動態語 言策略。

現在，Sun正在其Java EE解決方案上支持JRuby和Jython而投入；IBM Websphere集團則認識到Java EE平臺運行現代Web應用的無效，在Project Zero上大力投入，該項目的目的是使IBM在Web 2.0世界中也能有一席之地，目前支持Groovy和PHP；BEA也有一些孵化項目，但是被Oracle并購后，這些項目是否能有結果目前不明。Project Zero的 首席架構師是IBM公司里最先公開承認Java現在可以認為只是一種系統語言而不適合構建RESTful Web應用的幾個人之一。而構建RESTful Web應用正是Project Zero的目的。Java堡壘花了10年多時間才承認Java在Web上投資回報不佳，而目前的趨勢，將有更多的客戶做出更明智的選擇。動態語言將有大的 提升。與大型機一樣，Java已經在企業級IT和關鍵業務應用中根深葉茂，因此不會很快消失。但是在Web應用上，Java語言很可能會在市場份額上急劇 下降。

問題在于，非微軟的Web市場是會采用動態語言的JVM實現，還是容納這些語言事實標準實現的LAMP架構。雖然我認為會有客戶被前者吸引，但是市場主流還是會選擇LAMP。原因在于：

1. 標準實現更新速度很快，而JVM版本總是滯后，會帶來兼容性問題。這與Mono跟不上.NET的問題類似。

2. JVM最初設計時并沒有考慮支持動態語言，因此在可見的將來，要滿足實際需求，挑戰非常大。像閉包、間接方法調用和類型juggling等動態特性就不容易解決，這從目前JRuby與Ruby的C版本的比較中可以看出。而且，硬件廠商是否有興趣跟上也是有待觀察的。而開源技術就沒有這種問題。

3. 現代Web的可伸縮需求對Web層的處理強度的要求越來越大。基于C的架構更可能與操作系統底層（原文為primitives）最有效地互操作，提供高 效、內存占用小的架構，滿足這種強度。高性能的Web服務器比如lighttpd, Zeus, IIS 7，高性能的緩存系統比如Facebook等最大的網站使用的memcached，還有其他性能關鍵的子系統比如內存管理，都是例子。

4. 多核系統非常適合LAMP架構的多進程方式。隨著芯片業現在把主要精力都放在了多核而不是超線程技術上，JVM這樣的多線程環境的優點在今天的硬件上將無法充分發揮。而多進程方式將提供更多穩定性和可靠性。

5. 由于LAMP的簡單性，它對于開發人員而言進入門檻非常低，而又能夠提供很好的伸縮性，包括Yahoo和Facebook這樣的大規模產品系統。

總而言之，越來越清楚的是，動態語言將逐漸成為Web開發的標準。微軟和Java廠商都認識到這個趨勢，現在正在各自的軟件平臺之大力投入，給出 解決方案。但是，因為主要動態語言社區都是在.NET CLR和Java JVM軟件平臺之外發展起來的，這些廠商如果只是想依靠將成功的動態語言復制到自己的平臺上而反敗為勝，他們將處于困難的境地。有些廠商已經意識到這一情 況，采用了一些混合策略，同時為客戶提供動態語言的標準實現，雖然還沒有完全與其解決方案組合配合起來。微軟在PHP上的投入就是如此，Sun也開始為客 戶提供原生的Ruby和PHP實現。我相信雖然JVM向動態語言拋出的橄欖枝可能會吸引一些Java客戶，但是這無法跟上開源社區開發原生動態語言實現的 步伐。JVM的動態語言實現對于Java廠商與時俱進是不夠的，它們需要全面地擁抱原生的事實標準的社區驅動的動態語言。?

轉載于:https://www.cnblogs.com/tenking/archive/2008/04/15/2075368.html

總結

以上是生活随笔為你收集整理的PHP语言教父Gutmans炮轰Java：已经输掉Web之战的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。