一旦決定在項目中實驗非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如何支持多種語言。