Java的劣勢在何處？與前些年相比，現在看的已經很清楚了，Java的劣勢就在於做Web表現層的開發。Web表現層開發需求變化頻繁，Java這類靜態類型的語言不夠敏捷，嚴重影響了開發的效率。
而JavaEE的一個最大的缺點，就是企圖在服務器端搞定一切，我將這種開發方式稱作“傳統集中式的開發方式”。標准的J2EE三層架構——Web表現層、業務層、持久層，也許對於傳統的基於HTML表單的Web應用來說是恰當的，但是現在已經顯得落伍了。JavaEE企圖在服務器端完全搞定Web表現層的開發，給自己制造了一個大麻煩。無論是從這門語言本身，還是從支持這門語言主要的公司Sun、IBM、BEA、Oracle來說，他們並不擅長此道。擅長此道的是哪些公司呢？Adobe/Macromedia、M$、Borland/CodeGear。
如果Web表現層必須要在服務器端開發，Ruby on Rails的優勢與JavaEE相比要明顯的多。RoR要比任何主流的JavaEE Web表現層框架和技術（Struts、WebWork、Spring MVC、JSF、Tapestry、etc.）更加靈活，學習成本更低，開發效率更高。
換個思路來思考，如果我們不再假設客戶端就是幾乎毫無智能的Thin Client將會如何？假設我們能夠充分利用客戶端的Ajax組件庫和各種RIA技術，將Web表現層完全或者絕大部分前推到客戶端來開發，並且通過REST風格的API來與服務器通信，那麼服務器的角色就變成了類似於Web服務提供者（注意：這裡和Web服務還是有很大的差別，因為REST在這裡是用於同一個應用內部的通信，即連接一個應用的客戶端和服務器端）的角色，這樣就能夠極大地簡化服務器端Java的開發工作，讓它從自己所不擅長的領域退出來，集中精力做自己最擅長的一些工作。
這個趨勢其實在3年多前我在JavaEye論壇中宣傳基於XMLHttpRequest的開發方式的時候就已經看到了，現在這個趨勢已經越來越明顯了，新一代Web開發方式的面貌已經逐漸浮出水面。Adobe AIR/Flex、M$ WPF/Silverlight都是這樣一類的開發方式，當然Ajax也可以以這種方式來做開發。我給這樣一類開發方式取名叫做“RIA+REST”。
在服務器端搞定一切當然也有好處，因為這樣可以獲得最佳的控制，安全問題解決起來也比較容易。但是其代價就是無法得到最佳的交互設計，強迫用戶不得不承受降級的使用體驗。如果這樣的用戶體驗是能夠接受的，那麼采用這種方式做設計和開發問題不大。但是如果這樣的用戶體驗是無法接受的，那麼就需要嚴肅地考慮RIA+REST的開發方式了。與傳統集中式的開發方式相比，這是一類新型的分布式的開發方式，在一些方面（交互設計、服務器端架構）得到了簡化的同時，也會使得一些方面（服務器端的控制能力、安全性）復雜化，所以要求架構師作出慎重的權衡。分布式應用必然會帶來很大的復雜性，但是REST無疑是基於Web的分布式應用的最理想的架構風格，在Web領域REST的優勢要比RPC和分布式對象等架構風格大的多。同時REST是簡練實用的，可以很大程度上降低分布式應用的巨大復雜性。
根據我的經驗，在絕大多數中小型項目中，Web表現層開發的工作量要比後面兩層的開發工作量的總和還要大，也就是占到項目開發工作量的一半以上。當用戶需要較為苛刻的使用體驗時，傳統集中式的開發方式完全無法滿足要求，而必須由Ajax來補充。然而，對於有復雜交互需求的應用來說，RoR應用的開發效率同樣也會受到基於DHTML的開發效率的拖累，而無法充分體現出其敏捷的優勢。
如果Java將做Web表現層開發的負擔卸掉，讓客戶端的RIA技術來承擔，那麼Java在服務器端開發中與Ruby相比的劣勢就不是那麼明顯了，甚至在很多方面還有優勢。從整體架構的開發效率來考慮，
RIA + REST + Java
RIA + REST + Ruby
兩種架構組合也許可以達到大致相同的級別，即使Java在開發效率上仍有劣勢，但是也不會像在傳統集中式的開發方式中那樣懸殊。有很多傳言說基於RoR開發的項目與基於Java開發的項目相比，開發效率能夠高出5-10倍。我雖然對於Java並不樂觀，但是對於RIA+REST這種新的開發方式，我估計開發效率的差距應該可以降低到2倍左右。不過開發效率只是一個方面，如果服務器端的代碼經過良好重構，重用性非常好，不會在半年之後就成為必須要拋棄的遺留代碼，那麼Ruby在開發效率方面的巨大優勢也許只會停留在最初的階段。隨著代碼的積累，這種開發效率的優勢會逐漸降低下來。
Ruby會不會擁抱RIA呢？RoR 2.0將會是完全基於REST設計的開發框架，他們現在擁抱REST，就是為將來擁抱RIA做准備。對於傳統集中式的開發方式來說，應用REST當然也會帶來很大的好處，但是我認為這並不是RoR的主要的目的。RoR擁抱REST，是希望使自己在將來的技術變遷過程中處於一個非常有利的位置。對於未來Web開發技術的發展，REST處在一個核心的位置，它是連接客戶端和服務器端的紐帶，REST也會極大影響客戶端架構和服務器端架構的設計和建模。“面向資源的Web應用”，將會是未來幾年的一個技術熱點。
Java在對於REST的支持這個方面行動要遲緩的多。官方正在制訂的JSR 311規范主要還是面向不同的應用之間的集成，也就是主要覆蓋SOAP所覆蓋的領域，而不是面向RIA+REST這樣一類新型的Web應用開發方式。不過，一些支持REST的Java框架已經存在，也可以基於Adobe的Flex框架（今年之內就會開源）來做設計，這些框架使得基於Java做REST設計和開發成為了一件比較容易的事情。我們不指望Sun已經有很多年了，日子不是一樣過來了嗎？Sun其實可以坦承：“我不做老大已經很多年了”。
綜上所述，我認為支持REST對於JavaEE而言，意義甚至要比RoR更大。是否能夠擁抱未來Web開發技術的發展趨勢，對於Java語言未來的命運來說是至關重要的。
