Groovy 增強版 Groovy++
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支持。