Groovy++：快速的、靜動兼修的Groovy增強版
自Groovy++問世，Groovy++就在極力避免成為Groovy分支，Groovy++到底是什么語言呢？且51CTO為您娓娓道來！
51CTO推薦專題：Groovy開發技術
靜態類型Groovy到底是什么？
大家都知道，用Java編程非常繁瑣、不便。Groovy則非常富于表達而且語法構造非常接近Java，因此學習曲線相當平滑。Groovy與Java之間可100%互操作，Groovy對象就是Java對象，反之亦然。
但是Groovy運行時很慢，我做過很多改善Groovy性能的工作，對這一點自然也是開誠布公。你會發現，有些計算或數據轉換用Java重寫會快3-5倍，有時會到8-12倍甚至更高。有些人因此認為不要用Groovy做計算和后臺處理……但是，我們為什么要把自己限制于簡單的Web頁面開發或處理上呢？
更糟的是，Groovy對多核計算機支持不好，用Groovy編譯的幾個線程執行代碼實際上會相互影響速度。有些人可能會認為這只是并行實現的缺陷，隨時間推移會得到改進。我卻不這么想，我覺得這些問題源自Groovy動態本質。如果你需要在任何地點動態改變任何調用行為的能力，那么就必須付出代價。這是自然法則。
好在我們并不總是需要動態行為。杰出的語言表達能力加上強大類型推斷，可以得到神奇的靜態編譯代碼。這就是靜態類型groovy的由來，我們應該區分要求高性能的代碼和那些要求完全動態特性的代碼。
這是否意味著我想達到好的性能還不用像Java那樣到處要標明類型？
是這樣，我們在類型推斷方面做得相當不錯。這里一個一般原則是API的開發者應提供足夠的類型信息（當然和Java比也算少的），API的使用者就不用提供太多類型信息了，編譯器會推斷出其余信息。
Groovy++的主要目標是，一方面富于表達，非常接近Java；另一方面，一部分代碼塊可以享用性能和編譯時類型檢查，而另一部分代碼則完全動態。
Groovy++是官方項目名稱嗎？是開源的嗎？
是的。其關系有點像C和C++。我們不是在創建一個新語言，而是對Groovy自身的擴展，以為該語言帶來新價值。Groovy++是增強Groovy而非替代它的。大家都知道，在Groovy社區，我們以前從未說過Groovy替代Java語言之類的話，這并不是因為我們不需要一個更好的語言或Groovy不夠好，而是因為Groovy太慢且不能提供編譯時檢查。有了Groovy++，一切改變了——富于表達、快速、動靜兼修、完全與Java可交互……這些不都是下一代Java的主要需求么。
Groovy++是開源的，一部分已經開源，另一部分很快也就開源了。該項目分兩部分：編譯器和標準類庫。標準類庫已經開源了，編譯器在未來幾個月會開源。
我們之所以沒有立即開源編譯器，因為其中用到了不少商業產品的技術，待將這些部分抽取并替換/重寫之后，就可以開源了。另外，我們與幾個知名廠商就對該項目投資事宜進行了洽談，在討論還未完成之前就最終定案開源軟件許可也沒太大意義。
Groovy++是Groovy分支嗎？
Groovy++不是Groovy分支，而是建立在Groovy 1.8.x之上，僅僅在其發行包中增加了一個jar文件而已。從***天起我們就盡量避免其成為Groovy的分支，即使現有Groovy編譯框架對我們的靜態編譯器來說并不是***的。幸運的是我們找到了所有正確的解決方法，甚至還回過頭對這些方法的bug進行了修正，這些方法在Groovy中并未廣泛使用。
Groovy++如何工作？
非常簡單，只需在代碼塊上加@Typed注解即可。Groovy中的AST轉換幫了大忙，我們可以把靜態和動態類型代碼任意組合。對靜態編譯部分，編譯器進行類型推斷及所有必要檢查，并產生運行效率高的字節碼。對動態代碼則使用普通Groovy編譯器，因此Groovy++并不會破壞你的Groovy代碼。
我個人比較喜歡所謂的混合編譯模式，這種模式下靜態編譯器盡其所能解析方法和屬性，但如果解析失敗則產生動態調用。這種方式將Groovy的動態特性與快速運算***程度的結合在一起。
為什么需要標準類庫？
我們的標準類庫是對Groovy的一個擴展。至于為什么需要標準類庫，有兩個原因：***，Groovy以動態分派方式實現其服務，而在Groovy++中則不然，Groovy++標準類庫出現并不是說Groovy標準類庫性能不佳，而是因為其缺乏類型信息，在靜態語言中使用不太合適；第二，由于Groovy++性能更優，提供附加的工具類也是有意義的，比如在多核機器上調度多任務或對集合提供函數型操作。
還有一點比較自豪，那就是這個Groovy++標準類庫全是用Groovy++編寫的，沒有一句是用Java寫的。
Groovy++當下還有什么缺點？
我只發現一個小小的不便——簡單的從動態代碼copy/paste到靜態代碼不一定行了。（因為可能需要額外的類型信息）。
和Scala/Clojure比，Groovy++如何？
Groovy++從它們吸取了很多有益思想（比如actor、trait），但是Groovy++更貼近900萬Java開發者。對他們來說學習曲線更平滑。
說說項目路線圖？
下兩到三個星期，我們想發布0.2版，其將包含全部功能的靜態編譯器，然后一兩個月全心解決bug、編寫例程、文檔和手冊。為四五月份出0.5做準備。同時我們還將改進標準類庫，以更好支持多線程及分布式編程。
在這一領域我們有很多想法——分布式actor以及數據緩存，軟件事務內存、erlang式的supervisor tree。現在還不好說其中哪些將進入標準類庫，哪些可能創建單獨項目，以及哪些病入其他項目如GPars。可以肯定的是，集表達力、性能和編譯時檢查于一身的Groovy++能夠成為解決復雜問題的候選語言，并使這些問題對普通開發者來說解決起來更加簡單。
IDE支持方面有什么計劃？
凡對Groovy支持不錯的IDE均可使用，不需要什么特定的IDE支持。
末了還有什么想法？
我有個夢想，有一天所有Java開發者都會將Groovy++作為其下一個項目的候選語言。同時，我希望每個人都試試Groovy++，讓我們也了解一下你們的感想。本項目的源代碼部分在Google Code上，還在初期因此也沒什么文檔，不過也快了。
【編輯推薦】
