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
SwingBuilder
MarkupBuilder
AntBuilder
JsonBuilder
Graffiti
GroovyEclipse/
GGTS
Geb
GroovyFX
gbench/
gprof
vert.x
GContracts
GVM Tool

Groovyエコシステム
4
Ratpack
Groovy++
SpockGORM
GExcelAPI
SwingBuilder
MarkupBuilder
AntBuilder
JsonBuilder
Graffiti
GroovyEclipse/
GGTS
Geb
GroovyFX
gbench/
gprof
vert.x
JGGUG G*Workshopで
ハンズオン実施予定
(5/17)
Androidアプリの公
式ビルドシステム
GContracts
GVM Tool

Groovyの歴史を簡単に
5
年リリーストピックス
2003 Groovy 開発開始
2004 Groovy 1.0-jsr-01 JSR 241
2007 Groovy 1.0
2007 Groovy 1.5(=1.1) Java5対応
2009 Groovy 1.6 AST変換導入
2009 Groovy 1.7
2011 Groovy 1.8
2012 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/dropWhile
Calendar.next/Previous
withDefault/withEagar
…

AST変換強化
コンパイラ設定
(CompilerConﬁguration)
Java SE 7対応
静的Groovy
Groovy 2.1
の新機能その他
CompileDynamic
GPars 1.0へのアッ
プグレード
@DelegatesTo
型チェッカの拡張
indyフル対応
スクリプト基底クラスの指定
コンパイラ設定スクリプト・ビルダ
メタアノテーション
コマンドラインから
jar://, ﬁle:// URLを実行

静的Groovy
since 2.0

静的型チェック/静的コンパイル
@TypeChecked: 静的型チェック
➡型を確定することでわかるエラー
をコンパイル時にチェック
@CompileStatic: 静的コンパイル
➡静的型チェックに加え、
型が静的に定まっていることを
前提としたコードを生成
(javacが生成するものに近い)
➡目的は性能向上
AST変換アノテーションとして実装されている
これらのアノテーションをクラスやメソッドに指定すると、そ
の範囲のメソッド内のコードが対象となる
9
この2者を
総称したも
のが
Groovy2で
の「静的
Groovy」

「静的Groovy」で何がどう変わるの?
変数・メソッド引数等に型宣言が必要となる
(その結果キャスト等が必要になる場合がある)
ただし型推論により型宣言は省略できる場合がある
genericsなどにも対応しておりかなり賢い
動的機能については対応不可
EMC,カテゴリ,インターセプタ等による動的メソッドや
プロパティ参照、マップ要素のプロパティ参照など
明示的なgetPropertyやinvokeMethodの呼び出し
で対応する…可読性が顕著に低下
もしくはアノテーション指定でメソッド個別にスキッ
10

静的型チェックにより検出されるエラー例
11
import
groovy.transform.TypeChecked
@TypeChecked
int
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/

例：静的Groovy
14
@CompileStatic
int
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

Cp:{int
it-‐>0},

Cw:{int
it-‐>half((int)map.get('Cn')(it))},

In:{int

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

map.put("Cp",(Integer
it)-‐>0);

map.put("Cw",(Integer
it)-‐>half(map.get("Cn").apply(it)));

map.put("In",(Integer

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
ローカル変数や引
数のキャプチャ
リファレンス経由
で変更可能
実質的ﬁnal限定
コレクション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-‐stream
moduleVersion=0.5.1
extensionClasses=groovy.stream.StreamExtension
staticExtensionClasses=

@DelegatesTo
アノテーション
since 2.1.0

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

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

つまりこういうこと(1)
def foo(Closure c) {
…
}
foo {
toUpperCase() // String#toUpperCase()が呼び出
される
}
26

def foo(@DelegatesTo(String) Closure c) {
…
}
@TypeChecked // 静的型チェックのもとで
foo {
// このクロージャ内では、delegateプロパティは
// Stringインスタンスを保持していると仮定できる
toUpperCase()
}
27
静的型チェックもしくは静的
コンパイルできる。
(DelegatesToが無ければ静
的型チェックエラー)

def foo(@DelegatesTo(String) Closure c) {
…
}
@TypeChecked
foo {
// delegateはStringインスタンスを保持
// していると仮定できる
toooUpperCase()
}
28
コンパイル時エラーになる

やってみた：静的HTMLビルダ
静的型チェック可能なMarkupBuilderモドキ
29
@TypeChecked
def
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

型チェックの拡張
since 2.1.0

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

型検査拡張でできること
32
コンパイル時チェックできるかも!
Grailsのdynamic ﬁnderを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.AnnotationCollector
import
org.junit.After
import
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}
==
15

38
→
<結果>
ini e1, e2, e3, e4, e5 ][
assert
[1,2,3,4,5].inject(0){a,b
-‐>
a+b}
==
15

38
{acc,val-‐>式}
→
<結果>
ini e1, e2, e3, e4, e5 ][
assert
[1,2,3,4,5].inject(0){a,b
-‐>
a+b}
==
15

38
{acc,val-‐>式}
{acc,val-‐>式}
→
<結果>
ini e1, e2, e3, e4, e5 ][
assert
[1,2,3,4,5].inject(0){a,b
-‐>
a+b}
==
15

38
{acc,val-‐>式}
{acc,val-‐>式}
{acc,val-‐>式}
→
<結果>
ini e1, e2, e3, e4, e5 ][
assert
[1,2,3,4,5].inject(0){a,b
-‐>
a+b}
==
15

38
{acc,val-‐>式}
{acc,val-‐>式}
{acc,val-‐>式}
{acc,val-‐>式}
→
<結果>
ini e1, e2, e3, e4, e5 ][
assert
[1,2,3,4,5].inject(0){a,b
-‐>
a+b}
==
15

38
{acc,val-‐>式}
{acc,val-‐>式}
{acc,val-‐>式}
{acc,val-‐>式}
{acc,val-‐>式}
→
<結果>
ini e1, e2, e3, e4, e5 ][
assert
[1,2,3,4,5].inject(0){a,b
-‐>
a+b}
==
15

38
{acc,val-‐>式}
{acc,val-‐>式}
{acc,val-‐>式}
{acc,val-‐>式}
{acc,val-‐>式} →
<結果>
→
<結果>
ini e1, e2, e3, e4, e5 ][
assert
[1,2,3,4,5].inject(0){a,b
-‐>
a+b}
==
15

初期値無し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}
==
15

Matcher#matchesPartially()
40
(x= p).matchesPartially()の結果
➡インタラクティブなバリデーションなどに使用可能
assert
("1"

=~
/ddd/).matchesPartially()
assert
("12"

=~
assert
("123"

=~
assert
!("12a"

=~
assert
!("1234"
=~
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
→
<結果>
assert
[1,2,3,4,3].takeWhile{it<=3}
==
[1,2,3]
[ ]
][
e1,
e1,
{it-‐>式}
がtrue

41
→
<結果>
assert
[1,2,3,4,3].takeWhile{it<=3}
==
[1,2,3]
[ ]
][
e1,
e1,
{it-‐>式}
がtrue
e2,
e2,
{it-‐>式}
がtrue

41
→
<結果>
assert
[1,2,3,4,3].takeWhile{it<=3}
==
[1,2,3]
[ ]
][
e1,
e1,
{it-‐>式}
がtrue
e2,
e2,
{it-‐>式}
がtrue
e3,
{it-‐>式}
がtrue
e3

41
→
<結果>
assert
[1,2,3,4,3].takeWhile{it<=3}
==
[1,2,3]
[ ]
][
e1,
e1,
{it-‐>式}
がtrue
e2,
e2,
{it-‐>式}
がtrue
e4,
{it-‐>式}
がfalse
e3,
{it-‐>式}
がtrue
e3

41
→
<結果>
assert
[1,2,3,4,3].takeWhile{it<=3}
==
[1,2,3]
e5
{it-‐>式}
がtrue
[ ]
][
e1,
e1,
{it-‐>式}
がtrue
e2,
e2,
{it-‐>式}
がtrue
e4,
{it-‐>式}
がfalse
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
→
<結果>
assert
[1,2,3,4,3].dropWhile{it<=3}
==
[4,5]
[ ]
][
e1,
{it-‐>式}
がtrue

42
→
<結果>
assert
[1,2,3,4,3].dropWhile{it<=3}
==
[4,5]
[ ]
][
e1,
{it-‐>式}
がtrue
e2,
{it-‐>式}
がtrue

42
→
<結果>
assert
[1,2,3,4,3].dropWhile{it<=3}
==
[4,5]
[ ]
][
e1,
{it-‐>式}
がtrue
e2,
{it-‐>式}
がtrue
e3,
{it-‐>式}
がtrue

42
→
<結果>
assert
[1,2,3,4,3].dropWhile{it<=3}
==
[4,5]
[ ]
][
e1,
{it-‐>式}
がtrue
e2,
{it-‐>式}
がtrue
e3,
{it-‐>式}
がtrue
e4,
{it-‐>式}
がfalse
e4,

42
→
<結果>
assert
[1,2,3,4,3].dropWhile{it<=3}
==
[4,5]
[ ]
][
e1,
{it-‐>式}
がtrue
e2,
{it-‐>式}
がtrue
e3,
{it-‐>式}
がtrue
e4,
{it-‐>式}
がfalse
e4,
e5
{it-‐>式}
がtrue
e5

まとめ
44

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

まとめ
Groovy 2.0 … 「静的への回帰」
「Better Java」としてのGroovy
「今使えるJava 8」
Project Lambda, TypeAnnotation(的な)
44
Groovy 2.1…「動的と静的の融合」
ビルダ、DSLなどの動的コードを静的チェック・補完
DSL(フレームワーク、ツール)への適用
Gradle,Spockは今のところ静観(?)

G*Magazine記事もどうぞ
G*Magazine Vol.6
Groovy臨機応変(第一回)
動中の静…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テスティングフレー
ムワークSpock
Java開発にも使用でき、可読性の高いテストコード
を記述できる、高機能なテスティングフレームワーク
ハンズオン: Spockの基本, データ駆動テスト, モック
サポート, 機能拡張,(カスタム機能拡張,Grails連携,
その他アドバンストピック)
46

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

New features of Groovy 2.0 and 2.1

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a New features of Groovy 2.0 and 2.1

Semelhante a New features of Groovy 2.0 and 2.1 (20)

Mais de Uehara Junji

Mais de Uehara Junji (16)

Último

Último (9)

New features of Groovy 2.0 and 2.1