一旦决定在项目中实验非Java语言，就要先把项目中的各个工作域分清楚：哪些属于稳定层、哪些属于动态层或特定领域层。表7-2中给出了分属各层的工作。
表7-2 适合稳定层、动态层或特定领域层的项目域
如你所见，这些备选语言的使用范围非常广泛。但确定用备选语言解决哪项工作只是开始，接下来还要评估用备选语言是否合适。下面是帮我们选择技术的一些标准。
- 是否为项目里的低风险区。
- 备选语言跟Java的交互操作是否容易。
- 备选语言是否有工具支持（如IDE支持）。
- 语言学习难度。
- 招聘这门语言的开发人员的难度。
我们会逐一深入探讨这些标准。对于自己应该回答的问题，你得做到心中有数。
7.4.1 低风险
假设你有一个核心的支付处理规则引擎，每天要处理一百万笔交易。这是一个大概运行了七年、稳定的Java软件，但并没做过太多测试，代码里有大量死角。对于引入新语言来说，支付处理引擎显然是高危区，更不用说它本来跑得好好的，而且测试没做到全面覆盖，开发人员也还没完全弄明白它是怎么回事儿。
但系统不可能只有核心部分。比如更完善的测试明显会对系统有帮助。Scala有一个非常好的测试框架：ScalaTest（我们会在第11章介绍），可以用来测试Java或Scala代码。开发人员能用它写出跟JUnit相似但简洁得多的测试代码。所以一旦度过了ScalaTest的学习曲线，开发人员就能非常高效地增加测试覆盖面。而且ScalaTest对于逐步在代码库中引入行为驱动开发这样的概念很有办法。在将来要对核心的某些部分进行重构或替换时，不管最终新的处理引擎是用Java还是用Scala写，能用上现代测试特性真的很有帮助。
或者假设你需要建一个Web控制台，以便操作员能管理支付处理系统后台一些不太重要的静态数据。开发人员都知道Struts和JSF，可对这两种技术都提不起兴趣。这是另外一个试用新语言和技术栈的低风险区。Grails是个很抢眼的选择（基于Groovy的Web框架，受Ruby on Rails启发）。开发人员在经过一些研究后（Matt Raible也做过一个非常有趣的调研），一致认为Grails是生产率最高的Web框架。
因为是集中在低风险区的有限试点上做实验，如果所尝试的技术栈不适合自己的团队或系统，经理可以随时终止项目，不用中断太久就可以转移到不同的交付技术上。
7.4.2 与Java的交互操作
你肯定不想把原来写的那些Java代码弃之不用！很多组织都是因为这个原因迟迟不肯引入新的编程语言。但因为备选语言是跑在JVM上的，所以可以充分发挥原有代码的作用，这样问题变成了怎么让已有代码库的价值最大化，而不是抛弃正在使用的代码。
JVM上的备选语言跟Java之间的互操作简单利落，当然也能部署到原先的环境中。在讨论这个问题时一定要请管理生产环境的同仁到场参与。在把非JavaJVM语言加入到系统中时，你需要充分运用他们的专业经验。这也有助于消除他们对支持新方案的担忧，还能降低风险。
注意 DSL一般都是用动态层语言构建的（某些情况下也有稳定层语言），所以它们大多数是通过其内置语言运行在JVM上。
有些语言跟Java交互操作起来更容易。我们发现最流行的JVM备选语言（比如Groovy、Scala、Clojure、Jython和JRuby）都跟Java互操作得很好（而且其中某些语言的集成做得非常棒，几乎天衣无缝）。如果你确实是个谨小慎微的人，可以先做几个实验，很快，也很容易，而且你肯定能明白集成是如何工作的。
我们以Groovy为例。在Groovy代码里可以用我们熟悉的import语句直接导入Java包。用基于Groovy的Grails框架可以快速搭建一个网站，而引用对象仍然是Java模型对象。反过来说，在Java代码里调用Groovy代码也非常容易，有各种各样的办法，得到的也是熟悉的Java对象。比如从Java里调用Groovy代码处理JSON数据，并让它返回一个Java对象。
7.4.3 良好的工具和测试支持
大多数开发人员一旦习惯了已有环境，就会低估他们能节省的时间。有强大的IDE和构建工具、测试工具帮他们快速生产出高质量的软件。Java开发人员多年来受益于优秀的支持工具，所以一定要记得其他语言的成熟度可能还没达到相同的水平。
有些语言（比如Groovy）在编译、测试和最终结果部署方面长期以来都有IDE的支持。而其他语言的工具可能羽翼未丰。比如说Scala的IDE就不像Java的那么好用，但Scala粉觉得它的强大和简洁完全可以弥补当前IDE的不足。
还有个相关的问题，当备选语言社区开发出供自己使用的强大工具（比如Clojure的构建工具Leiningen）后，可能不太好调整它去处理其他语言。这就是说开发团队要认真考虑该如何分配项目，特别是在部署各自独立但又相互关联的组件时。
7.4.4 备选语言学习难度
学一门新语言总归需要时间，而且如果开发团队不熟悉该语言的范式，时间会更长。如果新语言是面向对象的，并有类C的语法（比如Groovy），那大多数Java开发团队都能轻松掌握。
可如果偏离了这一范式，偏离程度越大，Java开发人员觉得越难学。Scala试图在面向对象和函数式两个世界之间架起一座桥梁，但这种融合对于大规模软件项目是否可行仍然没有定论。在特别流行的几种备选语言中，Clojure可能会带来不可思议的好处，但开发团队在学习Clojure的函数式属性和Lisp语法时，也需要非常多的再培训工作。
还有一种选择是看看重新实现已有语言的JVM语言。Ruby和Python都是非常成熟的语言，有大量的材料可供开发人员学习。这些语言的JVM替身对于想采用易学的非Java语言的开发团队来说，是不错的起点。
7.4.5 使用备选语言的开发者
组织必须考虑现实情况：他们不可能总能雇到前2%的人（不管他们在广告里怎么忽悠），而且开发团队的成员也不会整年一成不变。某些语言，比如Groovy和Scala，已经足够成熟了，所以有相当的开发人员可以招募。但像Clojure这样还在想办法推广自己的语言，要找到优秀的Clojure开发人员仍然不太容易。
警告 对重新实现的语言的警告：比如说，很多现有的用Ruby写的包和应用程序，只在原始的基于C的实现下测试过。这就是说要在JVM上使用它们可能会有问题。在选择平台时，如果你计划采用整个用重新实现的语言编写的技术栈，那就应该把额外的测试时间考虑在内。
重新实现的语言（JRuby、Jython等）在这个问题上很可能再一次发挥作用。简历上有JRuby的开发人员可能很少，但因为它就是JVM上的Ruby，而Ruby开发人员非常多（熟悉C版本的Ruby开发人员很容易掌握在JVM上运行导致的差异）。
要理解备选JVM语言的设计选择及限制，你要先理解JVM如何支持多种语言。