自Groovy++問世，Groovy++就在極力避免成為Groovy分支，Groovy++到底是什么語言呢？且為您娓娓道來！

在隨縣等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站制作、成都網(wǎng)站建設(shè) 網(wǎng)站設(shè)計制作按需搭建網(wǎng)站,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站制作,成都營銷網(wǎng)站建設(shè),成都外貿(mào)網(wǎng)站建設(shè)公司,隨縣網(wǎng)站建設(shè)費用合理。

推薦專題：Groovy開發(fā)技術(shù)

靜態(tài)類型Groovy到底是什么？

大家都知道，用Java編程非常繁瑣、不便。Groovy則非常富于表達而且語法構(gòu)造非常接近Java，因此學(xué)習(xí)曲線相當平滑。Groovy與Java之間可100%互操作，Groovy對象就是Java對象，反之亦然。

但是Groovy運行時很慢，我做過很多改善Groovy性能的工作，對這一點自然也是開誠布公。你會發(fā)現(xiàn)，有些計算或數(shù)據(jù)轉(zhuǎn)換用Java重寫會快3-5倍，有時會到8-12倍甚至更高。有些人因此認為不要用Groovy做計算和后臺處理……但是，我們?yōu)槭裁匆炎约合拗朴诤唵蔚腤eb頁面開發(fā)或處理上呢？

更糟的是，Groovy對多核計算機支持不好，用Groovy編譯的幾個線程執(zhí)行代碼實際上會相互影響速度。有些人可能會認為這只是并行實現(xiàn)的缺陷，隨時間推移會得到改進。我卻不這么想，我覺得這些問題源自Groovy動態(tài)本質(zhì)。如果你需要在任何地點動態(tài)改變?nèi)魏握{(diào)用行為的能力，那么就必須付出代價。這是自然法則。

好在我們并不總是需要動態(tài)行為。杰出的語言表達能力加上強大類型推斷，可以得到神奇的靜態(tài)編譯代碼。這就是靜態(tài)類型groovy的由來，我們應(yīng)該區(qū)分要求高性能的代碼和那些要求完全動態(tài)特性的代碼。

這是否意味著我想達到好的性能還不用像Java那樣到處要標明類型？

是這樣，我們在類型推斷方面做得相當不錯。這里一個一般原則是API的開發(fā)者應(yīng)提供足夠的類型信息（當然和Java比也算少的），API的使用者就不用提供太多類型信息了，編譯器會推斷出其余信息。

Groovy++的主要目標是，一方面富于表達，非常接近Java；另一方面，一部分代碼塊可以享用性能和編譯時類型檢查，而另一部分代碼則完全動態(tài)。

Groovy++是官方項目名稱嗎？是開源的嗎？

是的。其關(guān)系有點像C和C++。我們不是在創(chuàng)建一個新語言，而是對Groovy自身的擴展，以為該語言帶來新價值。Groovy++是增強Groovy而非替代它的。大家都知道，在Groovy社區(qū)，我們以前從未說過Groovy替代Java語言之類的話，這并不是因為我們不需要一個更好的語言或Groovy不夠好，而是因為Groovy太慢且不能提供編譯時檢查。有了Groovy++，一切改變了——富于表達、快速、動靜兼修、完全與Java可交互……這些不都是下一代Java的主要需求么。

Groovy++是開源的，一部分已經(jīng)開源，另一部分很快也就開源了。該項目分兩部分：編譯器和標準類庫。標準類庫已經(jīng)開源了，編譯器在未來幾個月會開源。

我們之所以沒有立即開源編譯器，因為其中用到了不少商業(yè)產(chǎn)品的技術(shù)，待將這些部分抽取并替換/重寫之后，就可以開源了。另外，我們與幾個知名廠商就對該項目投資事宜進行了洽談，在討論還未完成之前就最終定案開源軟件許可也沒太大意義。

Groovy++是Groovy分支嗎？

Groovy++不是Groovy分支，而是建立在Groovy 1.8.x之上，僅僅在其發(fā)行包中增加了一個jar文件而已。從***天起我們就盡量避免其成為Groovy的分支，即使現(xiàn)有Groovy編譯框架對我們的靜態(tài)編譯器來說并不是***的。幸運的是我們找到了所有正確的解決方法，甚至還回過頭對這些方法的bug進行了修正，這些方法在Groovy中并未廣泛使用。

Groovy++如何工作？

非常簡單，只需在代碼塊上加@Typed注解即可。Groovy中的AST轉(zhuǎn)換幫了大忙，我們可以把靜態(tài)和動態(tài)類型代碼任意組合。對靜態(tài)編譯部分，編譯器進行類型推斷及所有必要檢查，并產(chǎn)生運行效率高的字節(jié)碼。對動態(tài)代碼則使用普通Groovy編譯器，因此Groovy++并不會破壞你的Groovy代碼。

我個人比較喜歡所謂的混合編譯模式，這種模式下靜態(tài)編譯器盡其所能解析方法和屬性，但如果解析失敗則產(chǎn)生動態(tài)調(diào)用。這種方式將Groovy的動態(tài)特性與快速運算***程度的結(jié)合在一起。

為什么需要標準類庫？

我們的標準類庫是對Groovy的一個擴展。至于為什么需要標準類庫，有兩個原因：***，Groovy以動態(tài)分派方式實現(xiàn)其服務(wù)，而在Groovy++中則不然，Groovy++標準類庫出現(xiàn)并不是說Groovy標準類庫性能不佳，而是因為其缺乏類型信息，在靜態(tài)語言中使用不太合適；第二，由于Groovy++性能更優(yōu)，提供附加的工具類也是有意義的，比如在多核機器上調(diào)度多任務(wù)或?qū)咸峁┖瘮?shù)型操作。

還有一點比較自豪，那就是這個Groovy++標準類庫全是用Groovy++編寫的，沒有一句是用Java寫的。

Groovy++當下還有什么缺點？

我只發(fā)現(xiàn)一個小小的不便——簡單的從動態(tài)代碼copy/paste到靜態(tài)代碼不一定行了。（因為可能需要額外的類型信息）。

和Scala/Clojure比，Groovy++如何？

Groovy++從它們吸取了很多有益思想（比如actor、trait），但是Groovy++更貼近900萬Java開發(fā)者。對他們來說學(xué)習(xí)曲線更平滑。

說說項目路線圖？

下兩到三個星期，我們想發(fā)布0.2版，其將包含全部功能的靜態(tài)編譯器，然后一兩個月全心解決bug、編寫例程、文檔和手冊。為四五月份出0.5做準備。同時我們還將改進標準類庫，以更好支持多線程及分布式編程。

在這一領(lǐng)域我們有很多想法——分布式actor以及數(shù)據(jù)緩存，軟件事務(wù)內(nèi)存、erlang式的supervisor tree。現(xiàn)在還不好說其中哪些將進入標準類庫，哪些可能創(chuàng)建單獨項目，以及哪些病入其他項目如GPars?？梢钥隙ǖ氖?，集表達力、性能和編譯時檢查于一身的Groovy++能夠成為解決復(fù)雜問題的候選語言，并使這些問題對普通開發(fā)者來說解決起來更加簡單。

IDE支持方面有什么計劃？

凡對Groovy支持不錯的IDE均可使用，不需要什么特定的IDE支持。

末了還有什么想法？

我有個夢想，有一天所有Java開發(fā)者都會將Groovy++作為其下一個項目的候選語言。同時，我希望每個人都試試Groovy++，讓我們也了解一下你們的感想。本項目的源代碼部分在Google Code上，還在初期因此也沒什么文檔，不過也快了。

【編輯推薦】

1. Groovy 1.7.3發(fā)布 值得關(guān)注的新功能
2. 基于Groovy 加速Google App Engine開發(fā)
3. JVM流行動態(tài)語言Groovy 1.7發(fā)布
4. 比較與分析Groovy與Java
5. Jython和JRuby，以及Groovy：Java平臺的統(tǒng)一認識模型

分享名稱：Groovy++：快速的、靜動兼修的Groovy增強版
文章地址：http://uogjgqi.cn/article/dphpghe.html