New feature of Groovy2.0 G*Workshop

Groovy2.0
の新機能
疾きこと
CompileStaticのごとし
2012/10/26 JGGUG G*Workshop #24
NTTソフトウェア Grails推進室上原潤二

http://www.flickr.com/photos/mrhermit/3214708288/
12年10月27日土曜日

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

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

お品書き
Groovyの歴史を簡単に
Groovy1.8の新機能(おさらい)
Groovy2.0の新機能
静的Groovy
indy対応
ライブラリ強化
モジュール化
まとめ
Groovy 3.X

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

Groovyの歴史を簡単に
年リリーストピックス
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対応


静的Grovy
AST変換強化

Groovy 2.0
Java SE 7対応
の新機能その他



静的Grovy
AST変換強化

静的型チェック
静的コンパイル
Groovy 2.0
Java SE 7対応



静的Grovy
AST変換強化

静的型チェック NotYetImplemented
Groovy 2.0 TypeChecked, CompileStatic

Java SE 7対応



静的Grovy
AST変換強化


Java SE 7対応

モジュール化


静的Grovy
AST変換強化


Java SE 7対応

Project Coin対応モジュール化
二進リテラルライブラリ強化
リテラル中の下線
マルチキャッチ

indy対応


静的Grovy
AST変換強化


Java SE 7対応

Project Coin対応モジュール化
二進リテラルライブラリ強化
リテラル中の下線
マルチキャッチ Collection.inject()
Matcher.matchesPartially()
takeWhile/dropWhile
indy対応 Calendar.next/Previous
withDefault/withEagar
…

AST変換群
2.0新機能
Since Since Since
Groovy 1.6 Groovy 1.8 Groovy 2.0
Bindable ListenerList NotYetImplemented
Vetoable AutoClone TypeChecked
Category AutoExternalize CompileStatic
Delegate Canonical
Immutable EqualsAndHashCode
Lazy Field
Mixin IndexedProperty
Newify InheritConstructors
Singleton Synchronized
PackageScope ConditionalInterrupt
ThreadInterrupt
Since TimedInterrupt
Groovy 1.7 ToString
TupleConstructor
Grab
power assert WithReadLock / WithWriteLock
Commons / Log / Log4j / Slf4j

静的Groovy
http://www.flickr.com/photos/kaeru/501750/

静的型チェック/静的コンパイル 2.0新機能

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

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

変数・メソッド引数等に型宣言が必要となる
(その結果キャスト等が必要になる場合がある)
要はjavaといっしょだyo!!!
ただし型推論により型宣言は省略できる場合がある
変数への代入/初期化の右辺等により型を決める
型推論対象：
クロージャから参照されていないローカル変数やメソッド引数
型推論対象外(明示的型指定が必要)：
フィールドやバインディング変数
クロージャ引数(itなど)
クロージャから参照されているローカル変数やメソッド引数

他スレッドによる変数の値変更をコンパイラが把握できないため

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

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
}

GGTS 3.0.0から利用


フローセンシティブタイピング

def a = -3

a.abs()
a.toUpperCase()

a = "ABC"

a.abs()
a.toUpperCase()

aはint型と見なさ
れる
def a = -3

a.abs()
a.toUpperCase()

a = "ABC"

a.abs()
a.toUpperCase()

れる
def a = -3

a.abs()
a.toUpperCase()

a = "ABC" aはString型と見
なされる

a.abs()
a.toUpperCase()

れる
def a = -3
[Static type checking] -
a.abs() Cannot find matching method
java.lang.Integer#toUpperCas
a.toUpperCase() e()

なされる

a.abs()
a.toUpperCase()

れる
def a = -3
[Static type checking] -
a.abs() Cannot find matching method
java.lang.Integer#toUpperCas
a.toUpperCase() e()

なされる

a.abs()
[Static type checking] - Cannot
a.toUpperCase() find matching method
Slide # 12 JGGUG G*Workshop
java.lang.String#abs() rights reserved.
Copyright(C) 2012 NTT Software Corporation All

String foo(String s) {
s.toUpperCase()
}

@CompileStatic
String bar(String s) {
s.toUpperCase()
}


s.toUpperCase()
} public String foo(String s)
{
CallSite acallsite[] = $getCallSiteArray();
return
(String)ScriptBytecodeAdapter.castToType(acallsite[0].
call(s), java/lang/String);
}
@CompileStatic
s.toUpperCase()
}


s.toUpperCase()
} public String foo(String s)
{
CallSite acallsite[] = $getCallSiteArray();
return
(String)ScriptBytecodeAdapter.castToType(acallsite[0].
call(s), java/lang/String);
}
@CompileStatic
s.toUpperCase()
}
public String bar(String s)
{
return s.toUpperCase();
}


ベンチマーク(CompileStatic)
1.2##

1.0##

0.8##
CompileStatic

0.6##
Groovy#1.8.2#

0.4## Groovy#2.0.1#

Groovy#2.0.1#CompileSta<c#
0.2## Java#SE#1.7.0u6#

0.0##
]#

#

)]#

#

]#

)]#

]#

#
]#

#
a]

f)]

g]
rt]
es

y)

m
ch

ry

#i f

in
st

c#i

so
ar

or
re

ku

ce
na
a

dR
a<

rn

ck

lN
[F
y#T

nn

an
er

ea
#te

ui
( st

ra
ar

c#t
a

st

[Q

hr
ct
[F

ce
ib

(i n
in

a<

pe

[T
[F

an
[B

ib
( st

[S
st

[F
ib

(i n
[F

ib
[F

https://github.com/alextkachman/fib-benchmark をベースに計測。
グラフはJavaを1としたときの実行時間の比率(大きいほど速い)。


静的型のメリット・デメリット
静的型のメリット:
総合的にいっ
1.静的型情報に基づいた最適化による性能向上て、本当に向上
するかは議論の
➡静的コンパイル余地がある
2.コンパイル時型チェックによる信頼性向上
➡静的型チェック
3.作業効率向上(IDEによる入力補完機能、タイプミス早期検出）
➡静的型チェック
4.ドキュメンテーションとしての型情報による保守性向上
➡オプショナルタイピング(既存機能)
デメリット: 面倒臭い・字数が増える・多態コード・動的機能
(EMC,Builderやマルチメソッドなど)が利用できない


@CompileStatic適用の実際
既存のGroovyコードを静的コンパイルするために必要なのは、
@CompileStaticをつけて回るだけの簡単な作業・・・
ではない!(少なくともGroovy 2.0.0では。)
静的コンパイルを通すための修正(例)：型宣言を省略していたところを補う(def, 引数, it
を型指定して宣言)／Closure#call()の返り値はキャストする／nullを適宜キャストする／引数の動的型に基いたメソッド
選択(マルチメソッド)を使用していた場合、静的に型が確定しているならキャストで。していなければ、Java的にダブルデ
ィスパッチで実装しなおす／ダックタイピングは複数メソッドに展開するかinterfaceを導入

➡規模が大きいと書き換えは相当面倒
以下は対応不可
EMC、カテゴリ、invokeMethod()などによる動的メソッド追加(結果とし
てのBuilder周り)
メソッド引数でのSpread/Spread map operator (*)の使用
アクセス修飾(private,protected,package private)が効いてアクセス不可

➡@CompileStatic(TypeCheckingMode.SKIP)で逃げる

CompileStaticとアクセス修飾
静的コンパイルで生成されるコードはJavaのアクセス
修飾子による制限に支配される
他クラスのprivateメソッドは呼べない(Javaでは当たり前)
ただし、Groovyで定義した(GroovyObjectを継承した)クラスに
対して、フィールドに関してはブリッジメソッド経由でアクセス可

class
Target
{

private
int
field ちなみに@TypeCheckedではエラ

private
void
method(){} ーにならないのが仕様らしいが
}
(GROOVY-5677)
@groovy.transform.CompileStatic
class
StaticCompiledClass
{

void
foo(Target
t)
{

t.method()

//
Cannot
call
private
method
Target#method

"ABC".value[0]
=
"x"
//
[STC]
-‐
Access
to
java.lang.String#value
is
forbidden

t.field
=
3

//
OK

}
}


余談:Grails 2.2での状況
Grails 2.2ではGroovy 2.Xが採用される予定
Grailsの最新ソースを「CompileStatic」で
grepしてみる
%
grep
-‐r
CompileStatic
.
./grails-‐bootstrap/src/main/groovy/grails/util/
BuildSettings.groovy:import
groovy.transform.CompileStatic
./grails-‐bootstrap/src/main/groovy/grails/util/BuildSettings.groovy:

@CompileStatic

@CompileStatic

@CompileStatic

@CompileStatic

@CompileStatic

:
%
grep
-‐r
CompileStatic
.
|
wc

124

247

13863


Groovy++と静的Groovy
Groovy++ Groovy 2.0
2009∼2011(開発完) 2011∼

コードベースの継続性はない
@Typedアノテー @TypeChecked
ションによる静的型チェック
静的Groovy @CompileStatic

mixedモードコンパイル、
末尾再帰最適化、traits..
などの先進的な機能
対応物は今のところ
無し


ベンチマーク(vs. Groovy++)
1.2##
Grroovy++
1.0##

0.8##
Groovy#1.8.2#
0.6##
Groovy#2.0.1#

0.4## Groovy#2.0.1#CompileSta<c#

Java#SE#1.7.0u6#
0.2## Groovy#2.0.1#indy#

Groovy++0.9.0/1.8.2#
0.0##
]#

#

)]#

)]#

]#

)]#

]#

#
]#

#
a]

g]
rt]
es

y)

m
ch

ry

f

#i f

in
st

c#i

so
ar

or
re

ku

ce
na
a

dR
a<

rn

ck

lN
[F
y#T

nn

an
er

ea
#te

ui
( st

ra
ar

c#t
a

st

[Q

hr
ct
[F

ce
ib

(i n
in

a<

pe

[T
[F

an
[B

ib
( st

[S
st

[F
ib

(i n
[F

ib
[F


indy対応
http://www.flickr.com/photos/tdar/6330565982/

indyとその利用方法 2.0新機能

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

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

groovy
group:
'org.codehaus.groovy',
name:
'groovy-‐all',

version:'2.0.1',
classifier:'indy'
}
compileGroovy
{

groovyOptions.optimizationOptions.indy=true
}

ベンチマーク(indy)
1.2##

1.0##

0.8##

0.6## Groovy#1.8.2#

Groovy#2.0.1#
0.4##
Groovy#2.0.1#CompileSta<c#

Java#SE#1.7.0u6#
0.2##
Groovy#2.0.1#indy#
0.0##
]#

#

)]#

)]#

]#

)]#

]#

#
]#

#
a]

g]
rt]
es

y)

m
ch

ry

f

#i f

in
st

c#i

so
ar

or
re

ku

ce
na
a

dR
a<

rn

ck

lN
[F
y#T

nn

an
er

ea
#te

ui
( st

ra
ar

c#t
a

st

[Q

hr
ct
[F

ce
ib

(i n
in

a<

pe

[T
[F

an
[B

ib
( st

[S
st

[F

Groovy 2.0.1 -indy
ib

(i n
[F

ib
[F


ライブラリ
強化
http://www.flickr.com/photos/aloudnoise/5133172272/

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

assert
[1,2,3,4,5].inject(0){a,b
-‐>
a+b}
==
15
25

→
<結果>

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

assert
[1,2,3,4,5].inject(0){a,b
-‐>
a+b}
==
15
25

→
<結果>

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

{acc,val-‐>式}

assert
[1,2,3,4,5].inject(0){a,b
-‐>
a+b}
==
15
25

→
<結果>

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

{acc,val-‐>式}
{acc,val-‐>式}

assert
[1,2,3,4,5].inject(0){a,b
-‐>
a+b}
==
15
25

→
<結果>

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

{acc,val-‐>式}
{acc,val-‐>式}

{acc,val-‐>式}

assert
[1,2,3,4,5].inject(0){a,b
-‐>
a+b}
==
15
25

→
<結果>

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

{acc,val-‐>式}
{acc,val-‐>式}

{acc,val-‐>式}

{acc,val-‐>式}

assert
[1,2,3,4,5].inject(0){a,b
-‐>
a+b}
==
15
25

→
<結果>

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

{acc,val-‐>式}
{acc,val-‐>式}

{acc,val-‐>式}

{acc,val-‐>式}
{acc,val-‐>式}

assert
[1,2,3,4,5].inject(0){a,b
-‐>
a+b}
==
15
25

→
<結果>

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

{acc,val-‐>式}
{acc,val-‐>式}

{acc,val-‐>式}

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

assert
[1,2,3,4,5].inject(0){a,b
-‐>
a+b}
==
15
25

初期値無しinject 2.0新機能

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

e1 [ e2, e3, e4, e5 ]

{acc,val-‐>式}
{acc,val-‐>式}

{acc,val-‐>式}

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

assert
[1,2,3,4,5].inject{a,b
-‐>
a+b}
==
15
26 Slide # JGGUG G*Workshop Copyright(C) 2012 NTT Software Corporation All rights reserved.

Matcher#matchesPartially() 2.0新機能

(x= p).matchesPartially()の結果
true …文字列xの末尾になんらかの文字列を追加したものは、
パターンpにマッチする可能性がある
false …文字列xの末尾にどんな文字列を追加しても、
パターンpにマッチすることは有り得ない

assert
("1"

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

=~
assert
("123"

=~
assert
!("12a"

=~
assert
!("1234"
=~

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

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

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

[ ]

[ ]

リストの要素を順にたどり、クロージャを適用した結果が
真である要素のみからなる先頭部分を返す。
assert
[1,2,3,4,3].takeWhile{it<=3}
==
[1,2,3]


→
<結果>

[ e1, ]

{it-‐>式}
がtrue

[ e1, ]

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


→
<結果>

[ e1, e2, ]

{it-‐>式} {it-‐>式}
がtrue がtrue

[ e1, e2, ]

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


→
<結果>

[ e1, e2, e3, ]

{it-‐>式} {it-‐>式} {it-‐>式}
がtrue がtrue がtrue

[ e1, e2, e3 ]

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


→
<結果>

[ e1, e2, e3, e4, ]

{it-‐>式} {it-‐>式} {it-‐>式} {it-‐>式}
がtrue がtrue がtrue がfalse

[ e1, e2, e3 ]

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


→
<結果>

[ e1, e2, e3, e4, e5 ]

{it-‐>式} {it-‐>式} {it-‐>式} {it-‐>式} {it-‐>式}
がtrue がtrue がtrue がfalse がtrue

[ e1, e2, e3 ]

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

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

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

[ ]

[ ]

偽である初めての要素以降を返す。
assert
[1,2,3,4,3].dropWhile{it<=3}
==
[4,5]


→
<結果>

[ e1, ]

{it-‐>式}
がtrue

[ ]

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


→
<結果>

[ e1, e2, ]

{it-‐>式} {it-‐>式}
がtrue がtrue

[ ]

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


→
<結果>

[ e1, e2, e3, ]

{it-‐>式} {it-‐>式} {it-‐>式}
がtrue がtrue がtrue

[ ]

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


→
<結果>

[ e1, e2, e3, e4, ]

{it-‐>式} {it-‐>式} {it-‐>式} {it-‐>式}
がtrue がtrue がtrue がfalse

[ e4, ]

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


→
<結果>

[ e1, e2, e3, e4, e5 ]

{it-‐>式} {it-‐>式} {it-‐>式} {it-‐>式} {it-‐>式}
がtrue がtrue がtrue がfalse がtrue

[ e4, e5 ]

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

モジュール化
http://www.flickr.com/photos/aplumb/3890003295/

モジュール化(1) 2.0新機能

groovy-X.X.X.jarを「拡張モジュール」の集合とし
て再構成
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モジュールとしても分割されている
依存性がきっちり定義されている


モジュール化(2)
拡張モジュールは「カスタム拡張メソッド」を提供できる
GDKメソッドのように既存クラスにメソッドを追加する
カテゴリとは異なり、静的Groovy配下で利用可能
@Grabで取り込んだ場合でもカスタム拡張メソッドは有効。
拡張モジュールは誰でも作れ、実体は以下のような内容の
「org.codehaus.groovy.runtime.ExtensionModule」
ファイルをMETA-INF/services directoryに含めたJarフ
ァイル
moduleName=groovy-‐stream
moduleVersion=0.5.1
extensionClasses=groovy.stream.StreamExtension
staticExtensionClasses=


Groovyの今後(1)
Groovy 2.1
遅くとも2012年中
invokedynamicバイトコード命令サポートを完成させる
DelegateTo(DSLに対する静的型サポート)
言語レベルの改良も継続的に行っている

Groovy 3.0
2013年
GEP11 - Groovy 3 semantics and new MOPとして検討
invokedynamicを前提としたMOP(Groovyの動的コア)の全面見直し
invokedynamicサポートから最大の利点を得る
Groovy自体をもっとGroovy自身で書き直す


まとめ
静的Groovyは2.0の目玉ではあるものの、誰
もが使わなければならないものでもない
実開発への適用はもうちょっと待った方が良いかも
Grailsでの採用を経て鍛錬されることを期待
indy対応はまだまだですね
今後は、非標準拡張モジュールによるエコシ
ステム成長(プラグイン化)が期待される


参考URL・商標
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 及びその子会社、関連会社の米国及びその他の国にお
ける登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合がありま
す。
記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です

New feature of Groovy2.0 G*Workshop

More Related Content

New feature of Groovy2.0 G*Workshop