Java系スクリプト言語Groovy

>>946
拡張子の短さ。
ちょっとしたスクリプトなのになんとか.groovyって長い。
.gでいいよ.gで。

確かに拡張子が長いのはちょっと面倒だな

grailsいいFWだと思うけどなー。Windowsだとコンソール周りがかなりウンコだけど。
PlayFW(javaソース)はだめ。ソースが増えるとガンガン重くなる。
scalaだとこんなことないんだろうか。

ソースを変更した後に自動でコンパイルするのはPlayの方に軍配が上がるな〜。あれって中身はsbtなのかな？
Grailsは何かそこの当りがもっさりしてる。
gvmもWindowsはcygwin入れとかないとダメだし、なんだか最近の開発環境はドンドンLinux/Unix系統
に偏ってきてるね〜。
特にWeb界隈の人たちのMac浸透率が半端じゃない。

ちなみにWindows7で、コマンドプロンプトからGrailsを起動すると
java.lang.NumberFormatException: For input string: "1B"
って例外が出力されて全く反応しなくなる。
IntelliJから起動すると大丈夫なんだけどかなりストレス。

Grailには確かに色々悩みがあるなぁ

>>956
Grailsだよ

Gradleで実行可能なJarを作るのが難しい
mainになってるクラスがJavaなら問題ないみたいだが
Groovyだと例外が出る
build.gradleも弄ってみたが何かが足りない

GradleはJava向け
Java系スクリプト言語向けの処理はおまけ

コンパイル言語として使用するGroovyから、Groovyスクリプトファイルを呼び出したい場合、
Javaから呼び出す時と同じようにGroovyShellやScriptエンジンなどを用いるのでしょうか？

それとも、GroovyスクリプトからGroovyスクリプトを呼び出す時と同じように
直接スクリプトファイル内の関数を呼んだり、インポートしたりしていいのでしょうか？

>>960
Groovyクラスと一緒
ほぼ同じように扱える

>>961
ありです！

動的型だとコード補完が働かないような状況でのコーディングが多くなると思うんですが
快適にコードを書くためのコツや、スペルミスをしない工夫などありますでしょうか？

>>963
Intellijを使う！
基本的に型の宣言をするくせをつけておくといいのかな〜
特にメソッドとかクロージャの引数には。

GGTSよりずっと補完の打率が良いよね > IntelliJ
Grails開発時にGSPファイルの中でも補完が効くのが快適すぎる。

IntelliJでGrailsのサポートを有効にするには有償版を買わなきゃいけないけど、他の言語やフレームワークにも抜群の開発効率の高さを発揮してくれるしね。
こんな便利なツールにはもっとお金を払いたい！っていうレベル。
素のIntelliJなら環境によるけどGroovyConsole起動より早いかも？

>>954-956
ありがとうございます、Intellij人気みたいですね

Netbeansでももうちょっとサポート強化してくれたらなぁ・・・

TIOBEでの転落が凄まじかったな
上がるときも早かったけど落ちるときも早かった

お前らさ、なんでエヴァンジェリストを差し置いてGroovyの話してるわけ？
まず俺のところに話持ってこいや！

ちょっと質問！
Serviceのメソッドの中で意図的にロールバックを発生させたい場合。

@Transactional
class MyService {
def hoge() {
// 何かいろいろ更新とか処理
// でもエラーが発生したから例外を投げてロールバックさせる。
throw new RuntimeException("hogehoge")
}
}

hoge()をコントローラのアクションメソッドから実行する場合、そのアクションメソッドに@Transactionを追加する必要がある。
RuntimeExceptionが起きるとちゃんとロールバックされる。
で、その例外はcatchできるんだけど、そのままビューの表示とかしようとすると
org.springframework.transaction.UnexpectedRollbackException
という例外が発生する。
どうにかこの例外をハンドリングできないかな？
というのは単純にロールバックしたよーというメッセージを画面に表示したいなと。
おそらく以下のstackoverflowがドンピシャな内容だと思うけどまだ良く理解できない。
http://stackoverflow.com/questions/13482103/grails-unexpectedrollbackexception-occurred-not-sure-why

withTransactionで手でロールバックして、そのときにフラグを立てるとか…？

indyって2.0のときは特別なオプションが必要だったけど
2.1からは標準で使われるようになってるんでしょうか？

>>972
ありがとう！
withTransactionが良く分かってないんだけど、イメージ的にはwithTransactionに渡すクロージャ自体が、Serviceのメソッドに該当する、っていうイメージで良いのかな？
でもこいつってドメイン自体のメソッドだよね？
そうなると、例えば
ADomain.withTransaction{
　new BDomain().save()
　aDomainObject.hoge = "hoge"
　aDomainObject.save()
}
見たいな感じになるのかな？
これだとなんでADomainの為のwithTransactionにBDomainの処理が入ってるんだよっていう感じでちょっと気持ち悪いかも・・・

>withTransactionに渡すクロージャ自体が、Serviceのメソッドに該当
なるほど、つまりローンパターンになってるという事か

やったあああ！解決できた！

>>972の助言どおり、withTransactionを使ってみても同じ状態だった。
こいつは何かおかしいぞ？ということでいろいろ試していた。

1.createコマンドでシンプルなコントローラとサービスを生成
2.そのサービスの中身は、>>971時点のものと同じ処理を記述
3.今回作ったコントローラからそのサービスのメソッドを叩き、正常時、ロールバック時ともに意図した動作が出来た。

つまり、ロールバックさせるために、サービス内で意図的にthrow new RuntimeExcepton()して、コントローラでその例外をキャッチして、それ以降の処理を自分で制御できた。
>>971の時でもコントローラでキャッチできたけど、キャッチ後に何をやろうとしても絶対に
org.springframework.transaction.UnexpectedRollbackException
がスローされてた。

この事から、どうやら問題はコントローラにあるぞ、ということが予想できた。

問題のコントローラには、@Transactional(readOnly = true)がクラス自体に宣言されていた。
そのコントローラは、SpringSecurityCoreが生成したのユーザ用ドメインから、Grailsのgenerate-allで生成したもの。
generate-allで生成されたコントローラには@Transactional(readOnly = true)が自動的に付けられるのね。

で、>>971の時には、クラス自体の@Transactional(readOnly = true)は残しつつ、アクションメソッドに@Transactionを付与していた状態。
問題のコントローラから全アノテーションを削除して、cleanしてから再度実行してみるとちゃんと動作した。
アノテーション削除とcleanを続けて実行してから確認してしまったので、アノテーションのみの問題だったのか、cleanでそれ以外の何か変なキャッシュが消えたのかが判然としないが・・・

ググってもそれっぽい物が全くヒットしなかったので特殊な状態だとは思うけど、もし同じような状態に嵌ってしまう人が居た時の為にご報告！

>>973
Indy（InvokeDynamic？）は詳しくない上に、英語力が最低なので良く分からないけど、2.1で変化があったのは間違いないみたい。
http://groovy.codehaus.org/Groovy+2.1+release+notes
http://groovy.codehaus.org/InvokeDynamic+support

まだ目を通していないんだけど、Groovy2.1.4でIndyで遊ぼう！っていう記事が最新のG*Magazine（第７号）に載ってるみたいだから目を通してみるといいかも？
http://grails.jp/g_mag_jp/


ちなみに2.2でも何か変化があったっぽいけど多分関係ない。
http://groovy.codehaus.org/Groovy+2.2+release+notes

答えを提示出来なくて申し訳ない。

GroovyでAndroidアプリって開発出来ないの？

GroovyのスクリプトファイルってInputStreamから直接実行できないのでしょうか？
一度メモリ上でStringに置き換えないとダメですか？

すみません、Reader見落としてました。余裕ですね！

うちの会社でも、取引先のアイツでもいいからさっさとgroovy/grails導入しろやー。
javaだとダルいって何年も前から言っとるやろがー。

こんな過疎スレで981とっちゃってまあｗ
もうお別れだね（ニコ

ってかそんなカスみたいレスでスレ落とそうとしたのかよ
恐ろしいわｗ

ん？どういうこと？

前に話題に上がってた次スレのテンプレをまとめてみた。追記等あればよろしく。

【JVM】プログラミング言語 Groovy #2【Grails】
「Groovy」
http://groovy.codehaus.org/
http://groovy.codehaus.org/Japanese+Home

「Grails」Webフレームワーク
http://grails.org/
http://grails.jp/

「Gradle」 Groovy製ビルドツール
http://www.gradle.org/

「gvm」Groovy関連のパッケージ管理ツール
http://gvmtool.net/

「Geb」 Webテストツール
(p)http://www.gebish.org/

「GPars 」並列処理ライブラリ
(p)http://gpars.codehaus.org/

「Griffon」デストップアプリ用フレームワーク
http://griffon.codehaus.org/

ごめん、ゴミが混じってたので再投稿

【JVM】プログラミング言語 Groovy #2【Grails】

「Groovy」
http://groovy.codehaus.org/
http://groovy.codehaus.org/Japanese+Home

「Grails」Webフレームワーク
http://grails.org/
http://grails.jp/

「Gradle」Groovy製ビルドツール
http://www.gradle.org/

「gvm」Groovy関連のパッケージ管理ツール
http://gvmtool.net/

「Geb」Webテストツール
http://www.gebish.org/

「GPars 」並列処理ライブラリ
http://gpars.codehaus.org/

「Griffon」デストップアプリ用フレームワーク
http://griffon.codehaus.org/

あとこんなのも。

日本語コミュニティ
http://www.jggug.org/
http://grails.jp/

Groovyファミリーに関する情報(Grails Diaryの翻訳)
http://grails.jp/news/index.html

その他個人サイト
http://orangeclover.hatenablog.com/
毎月Groovy関連のブログ記事やTwitterのつぶやきをまとめてくれてる。

http://d.hatena.ne.jp/mottsnite/
Grailsがアップデートするたびに変更点などをまとめてくれてる。

GGTS, STSも入れておけば?

Groovy/Grails Tool Suite (Groovy/Grails統合開発環境・Eclipseプラグイン)
http://spring.io/tools/ggts

個人的にはGGTSからIntelliJに移行したけど・・・

あれ？980過ぎても落ちないのかここ

最近仕様が変わったらしいよ

次スレの立て時が難しいぜ

いやもう立てていいだろ
いるなら

10年越しの次スレか胸圧。

あれから10年も、この先10年も

だったらうめてやんぜ〜
だったらうめてやんぜ〜
だったらうめてやんぜ〜
ずっつったらったたったたたら

980過ぎても落ちない〜
980過ぎても落ちない〜
980過ぎても落ちない〜
新時代突入〜
ずっつっちゃらったた

1000とりの価値をなくして
990後半でさまようスレ達
そんな哀れなスレを〜

ずんずんちゃらちゃっちゃっ！

だったらうめてやんぜ〜
だったらうめてやんぜ〜
だったらうめてやんぜ〜

う〜め〜て〜や〜〜〜〜んん〜〜〜〜〜ぜ〜〜〜〜

ふぃりぃんぐるぅぶぃ〜

だらら　ら〜ら〜ら〜ら〜

ふぃりぃんぐるぅぶぃ〜＾＾

１０００！

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。