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