Java为什么不能动态部署，为什么没有PHP/RoR简单

彻不彻底取决于代码的编写者.只要是强类型的,编译器本身的验证还是非常鲁棒的.当然,这个还没有实现....

我现在认为：

诸如spring这种配置bean之间依赖关系的情况(实际上是指明java class之间的调用关系)，webwork这种配置Action之间依赖关系的情况(URL与java class之间的对应关系)的情况，即涉及到概览性描述class的情况，是非常适合使用Java语言本身去描述的。同样的情况还有struts-config.xml等等。这些情况是Jacn大展伸手的地方。

涉及到颗粒度很细的class自身内部的信息，则非常适合使用annotation去描述，例如Hibernate的hbm映射文件，Webwork Action的validation.xml文件等等，所幸的是，Hibernate和Webwork都提供了相应的annotation功能。

还有一种情况是不依赖与任何class的流程性，规则性描述，例如工作流定义，规则引擎的规则定义，ant的编译文件等等，这些东西非常适合与使用纯脚本去描述，因为他们本身带有比较强的程序逻辑性，却又抽象级别比较高，我认为非常适合使用groovy这样的脚本语言去描述(当然类似的脚本还有很多例如beanshell等等)

最后，我认为XML适合场合在于异构系统的整合，以及松散藕合的分布式调用上面，即web services适用的场合(XMLHTTP实际上也是某种程度上面的web services)，目前比较热门的商业词汇SOA描述的应用场景正是XML大显身手的地方。

综上所述，我认为XML在Java世界这么多年来，被严重误用了。看看Python配置文件多喜欢用py，Ruby配置文件多喜欢用yaml，我们要反思一下，并不是不能够用Java写配置文件的。

当然考虑到编译性语言的编译需要和语法的严谨性限制上，并不是什么配置都适合使用Java的，然而spring和webwork配置文件这种描述class之间关系的配置无疑不应该使用XML，也不应该使用脚本，而应该采用Java。

从其他语言看,动态类型的语言要获得重构支持比较困难.
groovy是动态的巴? 它的很多特性也是基于动态性的, 很难想象"可选静态类型"是什么样子. 而且就算groovy很慢,性能也不是主要问题,因为总可以直接用java改写瓶颈部分.

当初用groovy的原因也是这个，如果因为某些原因，就可以使用java来扩展它。
其实groovy可以做成一个动态强类型，并且允许特定类型声明的语言，现在的脚本语言中，python是动态强类型的，vbs是动态弱类型的，但都不支持特定类型声明。如果groovy能够成为第一个这样的语言，那么，很可能在某些方面集成了动态语言和静态语言的优点。对于重构的支持、编译期查错都能够比一般的动态语言要强。
现在groovy编译器实际上并没有对可以静态判定的类型在使用中的一致性进行检查。

如果真要搞需要类型声明的动态语言的话,从另一方面讲也同时继承了两边的弱点:类型声明的繁琐和动态语言缺乏编译期检查. 另外你想过既然是动态类型,怎么在设计期明确声明类型呢?编译期又能检查出什么呢?要真这么做那动态语言里的多态就恐怕要推倒重来了.

现在新的语言设计趋势是类型推断, 也就是不需要明确声明的静态类型. .net下的Boo就是这个设计思路,单论速度大概是ironpython的十倍. 不过有趣的是Boo是弱类型的: 1 + '1' = '11' ! 动态语言的重构支持也有成功的,就是smalltalk. 它的refactoring browser是重构工具的鼻祖, 那是因为smalltalk的设计期就是运行期.

唉,现在世界确实比较混乱了...

所以才要类型声明可选的动态语言啊。此时，编译器帮你自动搞定可以静态判断类型的。实际上，对于动态强类型语言的使用者而言，大多数情况下(如果不是全部的话)都知道所定义变量的类型。
不需要明确声明的静态类型是不自洽的。一旦有参数传递，那所有东西都不是静态可考了，只有在运行期才能确定真正的类型。
其实，如果没有出现ROR，ruby充其量也就是smalltalk那类小生境语言。现在的话，可能搞定php?

程序中的业务逻辑问题比类型问题严重的多，普通的测试覆盖率，就轻松地解决类型问题

程序员写程序的时候只要坚持好的习惯，例如不把同一个变量用于不同的目的，真正的类型错误很少会出现，考虑我们在Java1.4以前的集合类型就知道了，Java能在编译时检查出集合里面对象的类型吗,不能，谁经常在写集合代码的时候搞错类型了吗，没有，除非你思路混乱。而在一个普通的Java程序里，围绕着集合进行的代码占据了极高的比例。

就算不是TDD，只要坚持对每一个单元进行测试，类型错误出现的可能性是微乎其微。而不管是否静态动态语言,单元测试应该是一个非常基本的要求。

我不认为动态类型会有多少不安全或者会让程序员犯多少错误。代码行多少，代码阅读是否简单、易于理解才是可能产生错误多少的根本原因。

但是弱类型在这方面可怕得很，可是我们用了整整30多年C了。

对重新命名之类的重构可能工具会起到作用。

但是实际工作中的重要重构都是需要手工操作的。例如最常见的重构方法是抽取方法、抽取抽象类或成员在类之间的转移。很多时候抽取方法通常不能整段整段地进行，而是需要先从相互纠缠的代码整理出一段干净的单责任的代码，加上冗余的变量，然后先抽取一段成一个方法，进行测试。接下去再对剩余的代码重复上述过程。这个过程基本上工具是很少有用处的，除了一切都准备好以后抽取那一下，但就算这一下，很多工具也是不合意的。

实在，高度不一样。
从另外角度看确实不会

其实我对ruby最大的迷惑是没找到接口在哪里。虽然之前的动态语言确实是不需要接口的。
我一直觉得单元测试很难保证使用者按照类的编写者所设想的正当方式来使用那些方法，毕竟不是很多人都会去看着测试用例写调用代码。而接口可以被看成是契约的一种表示，并且它是抽象的，不会受到具体实现的困扰。
动态语言使用上的巨大灵活性，使我感到仅仅靠单元测试很有点力不从心。应该说，现有的测试工具对于广泛使用诸如closure之类结构的动态语言而言，存在着阻抗不匹配的现象。
对于重构，我赞同potian的看法，除了在涉及到包/类/方法重命名的时候，使用工具确实非常轻快之外，其它的很多场合，使不使用对效率并没有显著的影响。