new features of groovy 2.0 and 2.1

Groovy2.Xの新機能

2013/05/11 JJUG CCC 2013 Spring [R2-5] #ccc_r25

JJUG/NTTソフトウェア Grails推進室上原潤二

13年5月11日土曜日

Slide # JGGUG G*Workshop Copyright(C) 2013 NTT Software Corporation All rights reserved.

自己紹介上原潤二(@uehaj)NTTソフトウェア株式会社Grails推進室JGGUG(日本Grails/Groovyユーザグループ)運営委員書籍執筆: プログラミングGROOVY(技術評論社), Grails徹底入門(翔泳社)ブログ「Grな日々」GroovyServ, Staticalizer, LispBuilder, GVM開発者



Groovyって何?Java仮想マシン上で動作する動的言語Javaとほぼ上位互換文法、冗長部分を省略でき、簡潔に書ける(一説によると記述量1/4～1/10)既存のJavaコードやライブラリをそのまま利用可能「RubyっぽいJava」

3

拡張性が高く、内部DSLとして用いることができ、ツール群・フーレームワーク群からなるエコシスムを構成



Groovyって何?Java仮想マシン上で動作する動的言語Javaとほぼ上位互換文法、冗長部分を省略でき、簡潔に書ける(一説によると記述量1/4～1/10)既存のJavaコードやライブラリをそのまま利用可能「RubyっぽいJava」

3

拡張性が高く、内部DSLとして用いることができ、ツール群・フーレームワーク群からなるエコシスムを構成

(動|静)的言語



Groovyエコシステム

4

Ratpack

Groovy++

SpockGORM

GExcelAPI

SwingBuilderMarkupBuilder

AntBuilder

JsonBuilder

Graffiti

GroovyEclipse/GGTS

Geb

GroovyFX

gbench/gprof

vert.x

GContractsGVM Tool



Groovyエコシステム

4

Ratpack

Groovy++

SpockGORM

GExcelAPI

SwingBuilderMarkupBuilder

AntBuilder

JsonBuilder

Graffiti

GroovyEclipse/GGTS

Geb

GroovyFX

gbench/gprof

vert.x

JGGUG G*Workshopでハンズオン実施予定

(5/17)

Androidアプリの公式ビルドシステム

GContractsGVM Tool



Groovyの歴史を簡単に

5

年リリーストピックス2003 Groovy 開発開始2004 Groovy 1.0-jsr-01 JSR 2412007 Groovy 1.02007 Groovy 1.5(=1.1) Java5対応2009 Groovy 1.6 AST変換導入2009 Groovy 1.72011 Groovy 1.82012 Groovy 2.0(=1.9) Java SE 7対応2013/1 Groovy 2.1.0



AST変換強化

ライブラリ強化

Java SE 7対応

静的Groovy

Groovy 2.0の新機能その他

NotYetImplemented

TypeChecked, CompileStatic

モジュール化

静的型チェック静的コンパイル

6

Project Coin対応

indy対応

二進リテラル

マルチキャッチ

リテラル中の下線Collection.inject()

Matcher.matchesPartially()

takeWhile/dropWhileCalendar.next/PreviouswithDefault/withEagar…



AST変換強化

コンパイラ設定(CompilerConfiguration)

Java SE 7対応

静的Groovy

Groovy 2.1の新機能その他

CompileDynamic

GPars 1.0へのアップグレード

@DelegatesTo

型チェッカの拡張

indyフル対応

スクリプト基底クラスの指定

コンパイラ設定スクリプト・ビルダ

メタアノテーション

コマンドラインからjar://, file:// URLを実行


静的Groovysince 2.0



静的型チェック/静的コンパイル@TypeChecked: 静的型チェック➡型を確定することでわかるエラーをコンパイル時にチェック

@CompileStatic: 静的コンパイル➡静的型チェックに加え、型が静的に定まっていることを前提としたコードを生成(javacが生成するものに近い)➡目的は性能向上AST変換アノテーションとして実装されている

これらのアノテーションをクラスやメソッドに指定すると、その範囲のメソッド内のコードが対象となる9

この2者を総称したものがGroovy2での「静的Groovy」



「静的Groovy」で何がどう変わるの?

変数・メソッド引数等に型宣言が必要となる(その結果キャスト等が必要になる場合がある)ただし型推論により型宣言は省略できる場合があるgenericsなどにも対応しておりかなり賢い

動的機能については対応不可EMC,カテゴリ,インターセプタ等による動的メソッドやプロパティ参照、マップ要素のプロパティ参照など明示的なgetPropertyやinvokeMethodの呼び出しで対応する…可読性が顕著に低下もしくはアノテーション指定でメソッド個別にスキッ10



静的型チェックにより検出されるエラー例

11

import groovy.transform.TypeChecked

@TypeCheckedint foo(String s) { int i = s // [Static type checking] -‐ Cannot assign value of type java.lang.String to variable of type int String result = s.toUppperCase() // [Static type checking] -‐ Cannot find matching method java.lang.String#toUppperCase(). Please check if the declared type is right and if the method exists. return result // [Static type checking] -‐ Cannot return value of type java.lang.String on method returning type int}

型が違う!

そんなメソッド無い!

型が違う!



静的型のメリット・デメリット静的型のメリット:1.静的型情報に基づいた最適化による性能向上➡静的コンパイル

2.コンパイル時型チェックによる信頼性向上➡静的型チェック

3.作業効率向上(IDEによる入力補完機能、タイプミス早期検出）➡静的型チェック

4.ドキュメンテーションとしての型情報による保守性向上➡オプショナルタイピング(既存機能)デメリット: 面倒臭い、動的機能が利用できない

12

総合的にいって本当に向上するかは議論がある



例：動的Groovy(従来)

13

def calc(basePrice, passengers) { def map = [An:{it}, Ap:{0}, Aw:{half(map.An(it))}, Cn:{half(map.An(it))}, Cp:{0}, Cw:{half(map.Cn(it))}, In:{half(map.An(it))}, Ip:{0}, Iw:{half(map.In(it))}] def groups = passengers .collect{[it, map[it](basePrice)]} .groupBy{it[0][0]}.withDefault{[]} return (groups.A+groups.C+groups.I.sort{it[1]} .take(groups.I.size()-‐(groups.A.size()*2))) .sum{it[1]}}

「第9回オフラインリアルタイムどう書く」の問題(バス代の計算)よりhttp://nabetani.sakura.ne.jp/hena/ord9busfare/


http://nabetani.sakura.ne.jp/hena/ord9busfare/

http://nabetani.sakura.ne.jp/hena/ord9busfare/


例：静的Groovy

14

@CompileStaticint calc(int basePrice, List<String> passengers) { Map<String,Closure> map map = [An:{int it-‐>it}, Ap:{int it-‐>0}, Aw:{int it-‐>half((int)map.get('An')(it))}, Cn:{int it-‐>half((int)map.get('An')(it))}, Cp:{int it-‐>0}, Cw:{int it-‐>half((int)map.get('Cn')(it))}, In:{int it-‐>half((int)map.get('An')(it))}, Ip:{int it-‐>0}, Iw:{int it-‐>half((int)map.get('In')(it))}] Map<String,List> groups = passengers.collect{String it-‐>[it, map.get(it)(basePrice)]}.groupBy{List<String> it -‐>it[0][0]}.withDefault{[]} return ((groups.get('A')+groups.get('C')+groups.get('I').sort{ List<Integer> it -‐> it[1] }.take(groups.get('I').size()-‐(groups.get('A').size()*2))).sum{List<Integer> it -‐> it[1]}) as Integer}

メソッドの引数や戻り値の型指定、型キャスト、マップのプロパティ記法アクセス、クロージャの暗黙引数の指定の明示化、などの追記必要



例：Java8 Lambda版(おまけ)

15

int calc(int basePrice, List<String> passengers) { Map<String,Function<Integer,Integer>> map = new HashMap<>(); map.put("An",(Integer it)-‐> it); map.put("Ap",(Integer it)-‐> 0); map.put("Aw",(Integer it)-‐>half(map.get("An").apply(it))); map.put("Cn",(Integer it)-‐>half(map.get("An").apply(it))); map.put("Cp",(Integer it)-‐>0); map.put("Cw",(Integer it)-‐>half(map.get("Cn").apply(it))); map.put("In",(Integer it)-‐>half(map.get("An").apply(it))); map.put("Ip",(Integer it)-‐>0); map.put("Iw",(Integer it)-‐>half(map.get("In").apply(it))); Map<String,List<List>> groups =passengers.stream() .map(it -‐> Arrays.asList(it, map.get(it).apply(basePrice))) .collect(Collectors.groupingBy(it -‐> (((String)it.get(0)).substring(0,1)))); List<List> tmp = new ArrayList(groups.get("A")); tmp.addAll(groups.get("C")); long size = (long)(groups.get("I").size()-‐groups.get("A").size()*2); groups.get("I").sort((a, b)-‐>(Integer)(a.get(1))-‐(Integer)(b.get(1))); tmp.addAll(groups.get("I").stream().limit(size).collect(Collectors.toList())); return tmp.stream().mapToInt(it-‐>(Integer)it.get(1)).sum(); }



速度・コード量比較

16

所要時間(ms) コード量(bytes)Java 8 648 3847静的Groovy 1135 2234動的Groovy 1532 1613

0" 1000" 2000" 3000" 4000" 5000"

��Groovy"

��Groovy"

Java"8"

��(bytes)"

��(ms)"

動的Groovyを最大限活かしたコードを移植したものであり、フェアな比較ではないかもしれない。あくまで参考として。



余談: Java8 Lambda式とGroovy’s Closureいずれも実体は別オブジェクトのメソッド

17

Groovy’s Closure Java 8’s Lambda表記 {arg -> body }

{body it}(arg) -> {body}arg -> body

ローカル変数や引数のキャプチャ

リファレンス経由で変更可能

実質的final限定

コレクションAPIへのクロージャ操作の追加

GDKで既存JDK APIを拡張

デフォルト実装 or Stream経由

動的に設定可能な“this”

delegateプロパティ


indy対応since 2.0～2.1



indyとその利用方法

groovy/groovycコマンドから使う<GROOVY_HOME>/lib,embeddeable/配下の、-indy接尾辞のついたjarファイルを-indyなしにリネームgroovyコマンド、もしくはgroovycコマンドで--indyを指定

gradle(1.1以降)から使う

19

dependencies { groovy group: 'org.codehaus.groovy', name: 'groovy-‐all', version:'2.0.1', classifier:'indy'}compileGroovy { groovyOptions.optimizationOptions.indy=true}

indy…Java VM上での動的言語実行の効率化を目的とした機能拡張(JSR292)の通称。Java SE 7(JDK)から利用可


モジュール化since 2.0



モジュール化(1)

groovy-1.8.2.jar…5,529,556バイトgroovy-2.0.1.jar…3,270,730バイト➡切り出されたもの: groovy-ant, groovy-bsf, groovy-console, groovy-docgenerator,

groovy-groovydoc, groovy-groovysh, groovy-jmx, groovy-json, groovy-jsr223, groovy-servlet, groovy-sql, groovy-swing, groovy-templates, groovy-test, groovy-testng, groovy-xml

利用者(Groovyプログラマ)にはあまり影響ないmaven pomモジュールとしても分割されている依存性がきっちり定義されている

21

groovy-X.X.X.jarを「拡張モジュール」の集合として再構成

しゅりんく!



モジュール化(2)拡張モジュールは「カスタム拡張メソッド」を提供できるGDKメソッドのように既存クラスにメソッドを追加するカテゴリとは異なり、静的Groovy配下でも利用可能@Grabで取り込んだ場合でもカスタム拡張メソッドは有効。

拡張モジュールは誰でも作れ、実体は以下のような内容の「org.codehaus.groovy.runtime.ExtensionModule」ファイルをMETA-INF/services directoryに含めたJarファイル

22

moduleName=groovy-‐streammoduleVersion=0.5.1extensionClasses=groovy.stream.StreamExtensionstaticExtensionClasses=


@DelegatesToアノテーション

since 2.1.0



@DelegatesToアノテーションメソッド宣言におけるメソッド引数(クロージャ)に指定def foo(@DelegatesTo(<Class>) Closure c) { …}

24

このメソッドの引数に渡したクロージャが呼び出されるときにはdelegateプロパティ(動的なthis)に@DelegatesToに指定した型<Class>のインスタンスが代入されているということを、呼び出し側が判るように宣言する。



何ができるのか?delegateを用いて実装されたビルダーやDSLの静的型チェック、IDEでの補完が簡単にできる。「型チェッカの拡張」よりも簡単制約は比較的大きい。



つまりこういうこと(1)def foo(Closure c) { …}

foo {

toUpperCase() // String#toUpperCase()が呼び出される}



つまりこういうこと(2) def foo(@DelegatesTo(String) Closure c) { … }@TypeChecked // 静的型チェックのもとでfoo { // このクロージャ内では、delegateプロパティは // Stringインスタンスを保持していると仮定できる toUpperCase()}

27

静的型チェックもしくは静的コンパイルできる。(DelegatesToが無ければ静的型チェックエラー)



つまりこういうこと(3)def foo(@DelegatesTo(String) Closure c) { …}@TypeCheckedfoo { // delegateはStringインスタンスを保持 // していると仮定できる toooUpperCase()}

28

コンパイル時エラーになる



やってみた：静的HTMLビルダ静的型チェック可能なMarkupBuilderモドキ

29

@TypeCheckeddef test() { new HtmlBuilder().html { head { title "Groovy 2.1.0は凄い!" } body { p "Groovy 2.1.0は凄い!" ul { li "リスト1" ul "リスト2" //[Static type checking] -‐ Cannot find matching method a#ul(java.lang.String). } h1 "凄いわ!" } }}

https://gist.github.com/uehaj/4563201


https://gist.github.com/4563201

https://gist.github.com/4563201

型チェックの拡張since 2.1.0



型チェックの拡張とはGroovyコンパイラに介入し、コンパイル時型チェックを自分でカスタマイズ・拡張できる実は型チェックに限らずなんでもできるAST変換の応用例の1つ。Groovyコンパイラのオープン化の一環。@TypeChecked(extensions=”「型チェッカビルダ」で記述されるスクリプトを指定”)



型検査拡張でできること

32

コンパイル時チェックできるかも!Grailsのdynamic finderをDBスキーマを参照しチェックメソッドが存在しない場合、GroovyのモジュールをGrapeで追加ダウンロードしてメソッド追加呼び出そうとするメソッドが静的に存在しない場合、invokeMethod()を呼び出す(Groovy++のmixedモードコンパイル相当)sprintf()のフォーマットと引数型のチェック静的解析任意のチェッカ(コーディング規約チェックとか)文字列定数内のコードを、そのスコープで型チェックする：



やってみた：静的チェッカ

33

// staticCheck.groovy、チェッカコードbeforeVisitMethod { methodNode -‐> if (methodNode.name.startsWith("is") && methodNode.returnType != classNodeFor(Boolean) && methodNode.returnType != classNodeFor(boolean)) { addStaticTypeError("name starts 'is' but not boolean", methodNode) } else if (methodNode.name[0] =~ /[A-‐Z]/){ addStaticTypeError("Method name started with upper case character.", methodNode) }}

// チェック対象コード@TypeChecked(extensions="./staticCheck.groovy")class StaticCheckTest { String isTest(x) {} // [STC]-‐name starts 'is' but not boolean void Method() {} // [STC] - Method name started with upper case character.}


メタアノテーションsince 2.1.0



メタアノテーションとは複数のアノテーションを結合したアノテーションを定義する引数を与えたアノテーションに別名をつける上記により定義されるアノテーションのセマンティクスを定義するGroovyのアノテーションやAST変換はもとより、Javaのアノテーションを処理することもできる。AST変換としてコンパイル時に変形している。



やってみたimport groovy.transform.AnnotationCollectorimport org.junit.Afterimport org.junit.Before

@Before@After@AnnotationCollector@interface BeforeAndAfter {}

class ArithmeticTest { // JUnitのテスト定義 @BeforeAndAfter void foo() { println "setUpとtearDownの両方で実行される" }

}

@Beforeと@Afterを結合して新たなアノテーション

@BeforeAndAfterを作る


ライブラリの強化(時間が余れば)

since 2.0



injectのおさらい

38

[e1,e2,e3,e4,e5].inject(ini){acc,val-‐>式} → <結果>

assert [1,2,3,4,5].inject(0){a,b -‐> a+b} == 1513年5月11日土曜日



38


ini e1, e2, e3, e4, e5 ][




38

{acc,val-‐>式}


ini e1, e2, e3, e4, e5 ][




38

{acc,val-‐>式}

{acc,val-‐>式}


ini e1, e2, e3, e4, e5 ][




38

{acc,val-‐>式}

{acc,val-‐>式}

{acc,val-‐>式}


ini e1, e2, e3, e4, e5 ][




38

{acc,val-‐>式}

{acc,val-‐>式}

{acc,val-‐>式}

{acc,val-‐>式}


ini e1, e2, e3, e4, e5 ][




38

{acc,val-‐>式}

{acc,val-‐>式}

{acc,val-‐>式}

{acc,val-‐>式}

{acc,val-‐>式}


ini e1, e2, e3, e4, e5 ][




38

{acc,val-‐>式}

{acc,val-‐>式}

{acc,val-‐>式}

{acc,val-‐>式}

{acc,val-‐>式} → <結果>


ini e1, e2, e3, e4, e5 ][



初期値無しinject

39

e1

{acc,val-‐>式}

{acc,val-‐>式}

{acc,val-‐>式}

{acc,val-‐>式} → <結果>

[e1,e2,e3,e4,e5].inject{acc,val-‐>式} → <結果>

e2, e3, e4, e5 ][

assert [1,2,3,4,5].inject{a,b -‐> a+b} == 1513年5月11日土曜日


Matcher#matchesPartially()

40

(x=~p).matchesPartially()の結果

➡インタラクティブなバリデーションなどに使用可能

assert ("1" =~ /\d\d\d/).matchesPartially()assert ("12" =~ /\d\d\d/).matchesPartially()assert ("123" =~ /\d\d\d/).matchesPartially()assert !("12a" =~ /\d\d\d/).matchesPartially()assert !("1234" =~ /\d\d\d/).matchesPartially()

true …文字列xの末尾になんらかの文字列を追加したものは、パターンpにマッチする可能性がある

false …文字列xの末尾にどんな文字列を追加しても、パターンpにマッチすることは有り得ない



(List,CharSequence,Map,T[]).takeWhile{}

41

[e1,e2,e3,e4,e5].takeWhile{it-‐>式} → <結果>

リストの要素を順にたどり、クロージャを適用した結果が真である要素のみからなる先頭部分を返す。

assert [1,2,3,4,3].takeWhile{it<=3} == [1,2,3]

[ ]

][




41




[ ]

][

e1,

e1,

{it-‐>式}がtrue




41




[ ]

][

e1,

e1,

{it-‐>式}がtrue

e2,

e2,

{it-‐>式}がtrue




41




[ ]

][

e1,

e1,

{it-‐>式}がtrue

e2,

e2,

{it-‐>式}がtrue

e3,

{it-‐>式}がtrue

e3




41




[ ]

][

e1,

e1,

{it-‐>式}がtrue

e2,

e2,

{it-‐>式}がtrue

e4,

{it-‐>式}がfalse

e3,

{it-‐>式}がtrue

e3




41




e5

{it-‐>式}がtrue

[ ]

][

e1,

e1,

{it-‐>式}がtrue

e2,

e2,

{it-‐>式}がtrue

e4,


e3,

{it-‐>式}がtrue

e3



(List,CharSequence,Map,T[]).dropWhile{}

42

[e1,e2,e3,e4,e5].dropWhile{it-‐>式} → <結果>

リストの要素を順にたどり、クロージャを適用した結果が偽である初めての要素以降を返す。

assert [1,2,3,4,3].dropWhile{it<=3} == [4,5]

[ ]

][




42




[ ]

][

e1,

{it-‐>式}がtrue




42




[ ]

][

e1,

{it-‐>式}がtrue

e2,

{it-‐>式}がtrue




42




[ ]

][

e1,

{it-‐>式}がtrue

e2,

{it-‐>式}がtrue

e3,

{it-‐>式}がtrue




42




[ ]

][

e1,

{it-‐>式}がtrue

e2,

{it-‐>式}がtrue

e3,

{it-‐>式}がtrue

e4,


e4,




42




[ ]

][

e1,

{it-‐>式}がtrue

e2,

{it-‐>式}がtrue

e3,

{it-‐>式}がtrue

e4,


e4,

e5

{it-‐>式}がtrue

e5


Slide # JGGUG G*Workshop Copyright(C) 2013 NTT Software Corporation All rights reserved.43

まとめhttp://www.flickr.com/photos/limonada/214375219/


http://www.flickr.com/photos/limonada/214375219/

http://www.flickr.com/photos/limonada/214375219/


まとめ



まとめGroovy 2.0 … 「静的への回帰」「Better Java」としてのGroovy「今使えるJava 8」Project Lambda, TypeAnnotation(的な)



まとめGroovy 2.0 … 「静的への回帰」「Better Java」としてのGroovy「今使えるJava 8」Project Lambda, TypeAnnotation(的な)

44

Groovy 2.1…「動的と静的の融合」ビルダ、DSLなどの動的コードを静的チェック・補完DSL(フレームワーク、ツール)への適用Gradle,Spockは今のところ静観(?)



G*Magazine記事もどうぞG*Magazine Vol.6Groovy臨機応変(第一回)動中の静…Groovy 2.1.0の新機能その1

45

http://grails.jp/g_mag_jp/file/gmagazine_6.pdf







宣伝： JGGUG G*Workshop Z: Spockハンズオン

2013年05月17日(金) (来週の金曜日)9時00分 - 21時00分http://jggug.doorkeeper.jp/events/3872

Spock: Groovyを使用するBDDテスティングフレームワークSpockJava開発にも使用でき、可読性の高いテストコードを記述できる、高機能なテスティングフレームワークハンズオン: Spockの基本, データ駆動テスト, モックサポート, 機能拡張,(カスタム機能拡張,Grails連携,その他アドバンストピック)



参考URL・商標http://groovy.codehaus.org/Groovy+2.0+release+noteshttp://groovy.codehaus.org/Groovy+2.1+release+notes?nchttp://www.slideshare.net/glaforge/groovy-20-devoxx-france-2012http://www.infoq.com/jp/articles/new-groovy-20http://www.jroller.com/melix/entry/groovy_2_0_from_anhttp://docs.codehaus.org/display/GROOVY/Creating+an+extension+modulehttp://d.hatena.ne.jp/ksky/20100513/p1http://docs.codehaus.org/display/GroovyJSR/GEP+11+-+Groovy+3+semantics+and+new+MOPhttp://glaforge.appspot.com/article/minor-new-features-of-groovy-2-0http://glaforge.appspot.com/article/incomplete-string-regex-matchinghttp://docs.oracle.com/javase/specs/jvms/se7/jvms7.pdfhttp://melix.github.com/talks/s2gx-typechecking/slides.htmlhttp://m.infoworld.com/d/application-development/groovy-the-roadmap-the-popular-jvm-language-202990?page=0,1OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です


http://groovy.codehaus.org/Groovy+2.0+release+notes

http://groovy.codehaus.org/Groovy+2.0+release+notes

http://groovy.codehaus.org/Groovy+2.1+release+notes?nc

http://groovy.codehaus.org/Groovy+2.1+release+notes?nc

http://www.slideshare.net/glaforge/groovy-20-devoxx-france-2012

http://www.slideshare.net/glaforge/groovy-20-devoxx-france-2012

http://www.infoq.com/jp/articles/new-groovy-20

http://www.infoq.com/jp/articles/new-groovy-20

http://www.jroller.com/melix/entry/groovy_2_0_from_an

http://www.jroller.com/melix/entry/groovy_2_0_from_an

http://docs.codehaus.org/display/GROOVY/Creating+an+extension+module

http://docs.codehaus.org/display/GROOVY/Creating+an+extension+module

http://d.hatena.ne.jp/ksky/20100513/p1

http://d.hatena.ne.jp/ksky/20100513/p1

http://docs.codehaus.org/display/GroovyJSR/GEP+11+-+Groovy+3+semantics+and+new+MOP




http://glaforge.appspot.com/article/incomplete-string-regex-matching

http://glaforge.appspot.com/article/incomplete-string-regex-matching

http://docs.oracle.com/javase/specs/jvms/se7/jvms7.pdf

http://docs.oracle.com/javase/specs/jvms/se7/jvms7.pdf

http://melix.github.com/talks/s2gx-typechecking/slides.html#slide-12






new features of groovy 2.0 and 2.1

Technology