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语言未来的命运来说是至关重要的。