Java真的会因为RoR、python、PHP等动态语言的的流行而过时吗？目前在web开发主要应用在两个大的领域，互联网和企业应用，我们分别来看一下：
一、互联网领域
     互联网领域第一大动态语言是PHP，第二第三分别是ASP和Java。在中小型互联网应用当中，PHP的王者地位不容动摇，但在大型应用当中，Java是目前主流的选择，特别是电子商务类型的应用，例如阿里巴巴就从早期的PHP转变到Java，从前的eachnet也是如此。造成这样局面不是没有原因的：
     1、中小型互联网网站强调开发速度，维护成本，以及入门快速和部署成本，PHP是最合适的选择；用Java则显得过于笨拙，开发慢，维护成本高，入门周期长，部署麻烦；RoR开发速度最快，维护成本最低，但是RoR入门速度没有PHP快，部署成本比PHP高。因此中小型互联网网站主流还是PHP，但RoR能够占据一定的份额。
     2、大中型互联网站强调稳定性，性能，大规模代码的组织能力，而开发效率则退居次要地位，有些应用如电子商务对事务有很高的要求，显然Java是最合适的选择；PHP的代码组织能力最差，RoR次之。
    3、在互联网领域，Java从来就不是主流，并且Java的适用领域和RoR不太重合。我们甚至可以这样说，RoR现在在互联网领域取代的是那些原本不适合用Java，但是被错误的选择了Java的项目。
二、企业应用领域
     目前企业应用领域第一大语言是Java，dotnet其次。企业应用采用的技术和行业有很大关系：例如金融行业，电子政务行业一般只采用Java。dotnet发展了6年尚且没有进入企业高端的应用，RoR在短期之内也很难取代Java的地位。 在企业应用领域，Java是主流，并且Java的适用领域和RoR也不太重合。我们也可以这样说，RoR将来在企业应用领域要取代的是那些原本不适合用Java，但是被错误的选择了Java的项目。 至此，我想Java程序员大可以松一口气，RoR目前有哪些不适合的场合呢：
1、对事务要求非常高的场合
RoR还是很简单的单数据库事务控制，缺乏精细的事务控制功能，当然也不支持跨数据库的分布式事务。因此对于事务要求严格的大型电子商务网站，部署复杂的分布式数据库场景显得力不从心。当然也许有些plugin可以提供这些功能，但是从目前的功能完备性和成熟度来看，还不够。
2、处理大量遗留数据库的场合
ActiveRecord的威力很大程度上来自约定，大量命名糟糕的遗留数据库会对RoR造成比较大的障碍。
3、庞大的项目团队，对开发速度要求低的场合
例如日本外包项目，团队庞大，个体开发速度要求低。但是对于代码规范要求严格的项目。 虽然RoR不会取代Java，但不意味着作为程序员的你可以固步自封。即使在工作当中用不上RoR，多看一点新的技术，对于开阔个人视野也有很大的好处。 如果想把技术作为终身职业，那么对于技术人员的起码要求就是不能固步自封，要始终以开放的心态接受新技术。 打好基础知识固然重要(重要到根本无需你一遍又一遍的祥林嫂)，但是不接触新技术，新思路，新的理念，很快就会被淘汰掉。 当然学习新技术也不是盲目的什么都学习，什么流行学习什么，而是根据自身的需要，有选择的学习。例如Java Web框架有很多很流行的，Struts，Webwork，Spring MVC，Tapestry，JSF，主流的就有5个，盲目的学习者就是人家说什么他就学什么了。而聪明的学习者应该对这些东西都去接触一下，从中选择一个值得自己投资时间成本去学习的框架。例如对这五个框架我都涉猎过一遍，最终我把时间花在了Webwork上面，事实也证明我当初的投资是正确的。

我学习ruby on rails有很现实的需要，其实即便抛开现实的需要，我也认为如果有空，Java开发人员有必要学习一下，原因是：
1、ruby语言和rails框架的社区力量正在以惊人的速度增长，甚至已经进入爆炸式繁荣的前夜，这不是昙花一现的现象，而是一个时代开始的象征。
2、从我这段时间学习的情况来看，ruby语言有足够的学习深度，我原来以为自己一个很快速的上手，然后就很精通了，但是ruby不像PHP那种方便面，其知识的广度和深度都让我感觉这是一个完整的知识体系。也正因为如此，ruby生命力会很长。
3、 ruby和rails是非常非常Unix-like的东西，经常和操作系统提供的功能有深度的依赖，这和Java这种不依赖操作系统，什么基础设施都自己卷起袖子自己创造的理念相比，非常非常的不同。这样做会带来一个很大的好处，很多在Java里面解决方案很复杂的问题，在ruby方案中就很简单可以搞定，相比之下，让Java显得颇为大而无当。 不过ruby和rails也树立起了一堵墙，这堵墙就是Unix操作系统，要学好我，你就先跨越Unix这堵墙吧。呵呵，这也是为什么rails core team清一色的MacOSX的原因了。
Java成为企业应用开发主流的原因？
Java编程语言的语法非常简单，规范比较严密，这样规范化带来的好处就是，一旦程序员具有比较良好的面向对象编程基础和设计模式的掌握，那么编写出来的代码几乎是大同小异的。 为什么优秀的Java开源框架的源代码我们读起来都比较容易呢？为什么Java那么容易写出来无二义性，相似度那么高的代码风格呢？为什么用Java做同样一件事情，往往只有一种最优的写法呢？为什么Java很难搞出来奇技淫巧呢？为什么Java语言一直被人认为是大巧若拙呢？我们再想想，为什么JDK5.0引入的技巧颇高的泛型编程到现在也有三年，为什么还是没有被广泛采用？再想想Java语言被设计出来是用在什么场合的呢？ 想清楚这些问题，那么我们就会发现Java成为企业应用开发主流的一个内在原因(外因也很多，这里不谈)，因为Java语言足够死板！ 所以写Java程序没有什么花巧，所以为了弄出来点花巧，逼的Java社区搞出来动态反射，搞出来AOP，抄袭了泛型，其目的都是增加Java语言的灵活性。
那么Java这种死板而简单的语言有什么好处呢？好处就是适合作为工业语言！ 那么我们分析一下工业语言在语法上面有着什么样的要求呢？
1、语法足够简单而且强壮
2、语法足够死板、做同样的事情，只有一种最优解
3、足够的语法障碍，抑制你的随意发挥，给我规规矩矩的编码
工业语言为什么有这种内在的要求呢？
1、团队协作的需要
大规模的项目需要几十人以上的协作，甚至是异地协作。这种大规模的团队协作要求程序员的代码风格必须高度一致，并且代码块之间的依赖性降到最低。显然死板而容易解藕的Java非常的合格
2、批量生产的需要
现在的软件外包产业体现的尤为明显！不需要你的创意，不需要你的设计，就需要你的coding，而且coding风格，功能已经规定死了。Java显然又非常合适。
好了，上面分析了从语法特点角度，为什么Java成为了工业语言，那么再分析一下为什么ruby不能成为工业语言：
1、ruby的语法过于灵活，发挥的余地太大，导致每个人的代码风格迥异
      我刚开始学习ruby的时候非常不适应，被ruby五花八门的语法糖衣搞晕了，同样的一件事情，你有无数种做法，笨拙的，普通的，聪明的，天才的，各式各样，甚至有本《ruby quiz》的书专门讲解ruby编程的各种奇技淫巧。ruby这种内在语法特性直接造就了ruby on rails奇迹。  在ruby on rails框架里面，有无数的ruby magic，好用之极又让你惊喜万分，没有ruby这么多灵活的语法支持，rails变不出来这么多魔术。 但是ruby的语法灵活性恰恰是成为工业语言的一大障碍！Java绝顶高手和Java普通高手的代码在风格上不会有大的差别(我就不觉得Rod Johnson代码比我高明到哪里去)，但是ruby绝顶高手和ruby普通高手的代码简直判若云泥！高下立判！绝顶高手如DHH把ruby用的出神入化叹服之余，也让你我之辈根本无法写出来符合DHH风格的ruby代码。 在我们网站开发中，也出现了这种问题，两个人写的ruby代码，互相之间理解起来存在困难。而由于做一件事情有很多ruby写法，不同性格的人甚至都会选择不同的实现方法，在一个团队中，要统一编码风格，实在难乎其难！而在Java项目中，基本可以杜绝此类问题。 由于代码风格难以统一，因此在大规模的团队中使用ruby编程，会造成合作上面的障碍！
2、ruby on rails会导致你的代码藕合度非常高，不利于团队协作开发
     由于rails规定死你的代码框架，不论是横向的功能解藕，还是纵向的分层解藕，都比较困难。
首先来说纵向的分层解藕，这是Java大规模项目常用的办法，但是在ruby on rails中基本不可能。因为ruby on rails各层之间的隐式约定太多了，你不可能分层开发。目前ruby on rails项目都是建议横向功能解藕，不建议纵向分层解藕的。
再说横向功能解藕：首先每个人必须承担足够大颗粒度的功能模块，不能拆分的太细了。因为rails的一个Controller文件就代表一大块功能了。 例如整个forum就只有一个controller，整个blog也就只有一个controller。当然你惊叹，整个forum代码就一个文件搞定了啊，代码太少了！但是反过来，你也可以说，论坛这个功能只能交给一个人来做了，没有办法再拆分功能了。这就带来了一个问题，团队协作变的困难了，如果两个人同时做论坛模块，就会出现经常性的该controller文件冲突合并。即使妥协一下，每个人只负责一个大功能块，但是底层的model代码都是互相关联在一起的。又难以避免的并发修改和文件冲突合并。 但是Java不存在这个问题，为什么呢？因为Java把一个Controller分解成为了无数个小Action，把一个Model分解成为了PO，DAO，Service，进行了充分的功能职责的解藕，每个人的工作基本不会互相干扰，那么团队协作的问题就好办了。
jerry有个观点我非常赞同，他认为目前我们没有找到合适的团队协作方法是因为现在的软件开发方法都不适合ruby on rails开发团队。而真正适合ruby on rails的软件开发方法究竟是什么样子，现在还没有出现，恐怕需要人们的探索了。ruby on rails流行必须伴随着适合ruby on rails的软件开发方法一起出现才行。
     因此在人们总结出来这种适合ruby on rails的软件开发方法之前，ruby on rails仍然会被局限在web2.0开发领域，在这个领域，ruby on rails的所有优点将发挥的淋漓尽致，而缺点将会被回避开。不过一旦涉及到企业应用开发领域，我们将面临这些问题。 因此，我的结论就是ruby on rails目前尚且不适合企业应用项目的开发。当然如果有适合ruby on rails的软件开发指导方法的出现，或者企业应用本身的定义已经发生了彻底的改变，那么我的结论也就不复存在了。
用一句话来总结就是：
ruby on rails是武林高手的绝世宝剑，却不是两军对垒中士兵使用的常规作战武器,Java却是这种常规武器。