第7章讨论过多语言编程金字塔和编程语言的三个层次，我们在图13-1中再次重复一下。
图13-1 多语言编程金字塔
Java位于稳定层，所以它的所有Web框架也属于这一层。作为一门流行而又成熟的语言，Java中有很多种Web框架，比如：
- Spring MVC
- GWT
- Struts 2
- Wicket
- Tapestry
- JSF（及其他与Faces相关的类库）
- Vaadin
- Play
- 以前那些普通的JSP/Servlet
在这一领域，Java没有公认的领头羊，并且源于Java的这一分支根本就不是Web快速开发的理想选择。Struts 2曾经流行一时，该项目的前任领导者说过这样一段话：
我堕落了:-)，我现在更喜欢用Rails——因为前面提到的简洁性，因为我再也不用“构建”和“部署”了。兄弟姐妹们，我要提醒你们，如果你们想吸引Rails开发人员......或者要避免像我这样的“背叛Java的Web开发人员”流失:-)，这类事情是你们必须克服的障碍。
——Craig McClanahan，2007年10月23日
（http://markmail.org/thread/qfb5sekad33eobh2）
本节会谈到Java为什么不是Web快速开发的理想选择。我们先来看看编译型语言为什么会在开发Web应用时拖后腿。
13.1.1 Java编译为什么不好
Java是编译型语言，这就是说你每次修改代码，都必须重复下面的步骤：
- 重新编译Java代码；
- 停止Web服务器；
- 把改过的应用重新部署到Web服务器中；
- 启动Web服务器。
这会浪费大量的时间！特别是有很多小修改时，比如修改控制权的目标或界面的微调。
注意 应用服务器和Web服务器之间的界限已经变得模糊了。这是因为JEE 6的出现（可以在Web容器内运行EJB），也因为大多数应用服务器都是高度模块化的。我们提到的“Web服务器”是指任何有Servlet容器的服务器。
如果你是一位经验丰富的Web开发人员，应该知道有些技术可以解决这个问题。其中大多数都是不用停止和启动Web服务器就能应用代码修改，也被称为热部署。热部署或者把全部资源（比如整个WAR文件）都换掉，或者只选其中几个（比如单个JSP页面）资源进行替换。但热部署不是100%可靠（因为类加载的限制和容器中的bug），并且大多数情况下，Web服务器仍然需要执行昂贵的代码重编译操作。
用JRebel和LiveRebel执行热部署
如果你必须要用Java Web框架，我们强烈向你推荐JRebel和LiveRebel（http://www.zeroturnaround.com/jrebel/）。JRebel确实具备一些惊艳的JVM技巧，它处在IDE和Web服务器之间，源码发生变化时能自动将这些变化反应到正在运行的Web服务器上（LiveRebel用于生产环境的部署）。这种热部署基本没什么问题，并且这些工具实际上是解决热部署问题的行业标准。
一般来说，Java Web框架为代码修改而产生的周转时间太长。但这不是唯一的问题，另外一个拖慢Web开发速度的不利因素是语言的灵活性，这是静态类型系统的弱项。
13.1.2 静态类型为什么不好
在开发新产品或新功能的早期阶段，保持用户展示层设计的开放性（对于类型而言）通常都是明智之举。对于用户来说，要求数值精确到小数位，或让书单变成图书和玩具混合的清单都是非常合理的要求。静态类型可能会成为这类需求的巨大障碍。如果你必须把一个Book对象列表变成BookOrToy1对象的列表，则只能在代码中把这个静态类型全改掉。
1 小心！如果你的域对象中有Or或And这样的字眼出现，那你很可能违反了我们在第11章讨论的SOLID原则。
尽管在容器类里能用基本类型（比如Java的Object类）作为对象的类型，但这肯定不是最佳实践——这简直是一下子回到了泛型。
因此，选择基于动态层语言编写的Web框架无疑是个有效选项。
注意 Scala当然是静态类型语言。但由于其先进的类型推断能力，它能规避很多由Java静态类型实现方式引发的问题。也就是说，Scala可以是、也确实是可用的Web层语言。
在你继续深入研究和选择Web开发的动态语言之前，我们先后退一步，让视野更开阔一点。想一想优秀的Web快速开发框架应该符合哪些标准。