Java系スクリプト言語Groovy

Java系スクリプト言語Groovy at TECH

1:デフォルトの名無しさん
04/03/23 23:27
いいかげん無視できんから一応スレたてとくよ。

本家 URLﾘﾝｸ(groovy.codehaus.org)
JSR URLﾘﾝｸ(www.jcp.org)

2:デフォルトの名無しさん
04/03/24 00:05
そう思っているのは1だけ。

3:デフォルトの名無しさん
04/03/24 07:21
Groovyメモ
URLﾘﾝｸ(www.ncfreak.com)

4:デフォルトの名無しさん
04/03/24 14:49
なんか恥ずかしい名前ですね

5:デフォルトの名無しさん
04/03/24 16:15
正直ちょっといいかなと思ったJava+python愛好家。

6:デフォルトの名無しさん
04/03/25 00:53
おもしろそうだね。

で、何に使うの？

7:デフォルトの名無しさん
04/03/29 22:50
スクリプト言語といえばテキスト処理。
テンプレートエンジン使ったりとかだね。

8:デフォルトの名無しさん
04/04/04 16:57
正直、久しぶりに面白いスクリプト言語に出逢った気がする。

9:デフォルトの名無しさん
04/04/04 18:01
Groovy language submitted as JSR 241
URLﾘﾝｸ(www.theserverside.com)

10:デフォルトの名無しさん
04/04/15 15:19
Groovyで、seasarのコンテナを扱えるらしい
URLﾘﾝｸ(www.commentout.com)

11:デフォルトの名無しさん
04/04/15 20:28
まずはHellWorldを見せろ
話はそれからだ

12:デフォルトの名無しさん
04/04/15 23:14
println "Hello, World"

13:デフォルトの名無しさん
04/04/16 01:00
s1 = 'Hello'
s2 = 'World'
print "${s1},${s2}"

14:デフォルトの名無しさん
04/04/16 01:31
groovyMarkupだぞこら

15:デフォルトの名無しさん
04/04/16 01:47
>10
seasarのコンテナを扱うというよりかは
groovyでseasarのコンテナの設定ができる
、だな。

16:デフォルトの名無しさん
04/04/16 06:47
>>15
さんぷるも。
後、PicoのGroovyとどの辺が違うの。
コンテナが違うということ以外に。

17:デフォルトの名無しさん
04/04/16 14:18
名前が悠長すぎる！！！Groooooooooooooooobyってなんだよ！

18:デフォルトの名無しさん
04/05/07 11:53
グビレって言う日が来るのかね。

19:デフォルトの名無しさん
04/05/30 13:30
グルービーて何ですか？

20:デフォルトの名無しさん
04/07/02 10:20
URLﾘﾝｸ(itpro.nikkeibp.co.jp)

21:デフォルトの名無しさん
04/07/03 00:52
結局、スクリプト言語ってどれが良いのよ？

22:デフォルトの名無しさん
04/07/03 01:52
sh

23:デフォルトの名無しさん
04/07/04 21:02
n88-BASIC

24:デフォルトの名無しさん
04/07/11 01:21
なんかパッと見 ruby っぽいな

25:デフォルトの名無しさん
04/07/11 01:25
>>24
そりゃﾊﾟｸﾘなんだから当然だろ。既存のスクリプト言語のいいトコﾊﾟｸﾘ＋
JVM上で動く言語。Java自身に続き、商売で言語作成ﾔｯﾃﾙ連中の当然の発想
だよ。

26:デフォルトの名無しさん
04/07/11 01:30
Groovy - Java用スクリプト言語
URLﾘﾝｸ(www.kakutani.com)

27:名無しさん＠そうだ選挙に行こう
04/07/11 15:48
Groovyラボ
URLﾘﾝｸ(xpc.aa0.netvolante.jp)
FAQ (翻訳文書)
URLﾘﾝｸ(xpc.aa0.netvolante.jp)
ユーザガイド (翻訳文書)
URLﾘﾝｸ(xpc.aa0.netvolante.jp)
インストール (翻訳文書)
URLﾘﾝｸ(xpc.aa0.netvolante.jp)

Groovy wiki
URLﾘﾝｸ(www.wikiroom.com)
GroovyEclipse
URLﾘﾝｸ(www.wikiroom.com)
Eclipseから実行
URLﾘﾝｸ(www.wikiroom.com)

28:名無しさん＠そうだ選挙に行こう
04/07/11 16:21
この言語発音するのは人前でサタデーナイトフィーバーのあのポーズとるくらい恥ずかしい。

29:名無しさん＠そうだ選挙に行こう
04/07/11 16:36
>>28
織田信長？

30:デフォルトの名無しさん
04/07/16 04:27
groovy-1.0-beta-6が出ました。
２ヶ月ぶりのバージョン更新です。

Index of /groovy/distributions
URLﾘﾝｸ(dist.codehaus.org)
Change Log
URLﾘﾝｸ(jira.codehaus.org)

今後の予定は1.0-rc1、1.0-final、1.1となっています。

Groovy Road Map
URLﾘﾝｸ(jira.codehaus.org)

31:デフォルトの名無しさん
04/07/19 07:44
foreachの構文はtigerと同じにしてもらいたいものだが。

32:デフォルトの名無しさん
04/07/26 22:10
0 を何かで割ろうとすると反応が返ってこないんだけどなぜ？

例.
(10 .. 0).each { println it / 10 }

実行結果
1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1　<= ここで　stop

環境は
Version: 1.0-beta-6, JVM: 1.5.0-beta2-b51　です。

33:デフォルトの名無しさん
04/08/07 21:58
ほほう、ここがうわさの 32書き込み/4.5ヶ月のGroovy スレか。

34:デフォルトの名無しさん
04/08/08 03:15
これからだよ。これから。

35:デフォルトの名無しさん
04/08/09 00:54
少人数で開発できる案件はJavaよりスプリクト言語で開発するほうが
コーディングの工数が小さい事はしばしば指摘されます。
Groovyがソフトウェア業界の標準スプリクト言語になることを期待しています。

オブジェクト指向スクリプト言語Groovyの紹介
URLﾘﾝｸ(xpc.aa0.netvolante.jp)
>Groobyは言語設計においては独自の美学を持たず、
>「既存言語からの言語機能の良いとこどり」に徹し、
>「産業の言語」を目指しているように見えます。

オブジェクト指向スクリプト言語(for JVM)Groovy
URLﾘﾝｸ(www.kakutani.com)
>Groovyは職業Javaプログラマによる、
>職業Javaプログラマのためのスプリクト言語

36:デフォルトの名無しさん
04/08/09 02:19
捺印ナビリティの向上には激しく期待してるんですが、今度のプロジェクトでgroovy使いましょー、とはさすがに提案できないなぁ。言えるのは何年くらい先でしょうねぇ……。

37:デフォルトの名無しさん
04/08/09 11:22
納品物に使うんじゃなくて、テストとか、ちょっとした試行錯誤とかに使うんだよ。

38:デフォルトの名無しさん
04/08/09 13:26
そんなんだったら他のLLと同じやん……。

39:デフォルトの名無しさん
04/08/09 16:49
納品物に使わないなら開発効率の改善は限られた物になってしまいます。
GroovyをJava並に普及させるには納品物に使われることを目指す必要があります。

Groovyが普及するにはまずGroovyの仕様安定と欠点の解消が必要ですが、
それは本家の人達にがんばってもらう方が良いでしょうね。

外野として出来る事としては

１．Javaの小規模案件にGroovyを使えるようにするための環境整備
携帯電話用Javaを置き換える
しないでしょう。
標準スプリクト言語になるには納品物に使わえるようにする事が大事です。

40:デフォルトの名無しさん
04/08/09 17:17
実状は全然知らんのだけど、ドキュメント整備じゃないのか？
自分一人知ってたところでどうしようもないわけだし。

41:39
04/08/09 18:12
済みません、先ほど途中で書き込んでしまいました。

Groovyを納品物に使わないなら開発効率の改善は限られた物になってしまいます。
開発効率を根本的に改善するにはGroovyを納品物に使う必要があります。

Groovyが普及するにはまずGroovyの仕様安定と欠点の解消が必要ですが、
それは本家の人達にがんばってもらう方が良いでしょうね。
外野としては周辺を整備を行うという形で協力するのが良いのではないでしょうか。

１．Groovyが使われる分野を作り出す
　　日本では携帯電話用Java(iアプリ)が普及しています。
　　iアプリはサイズが小さく独立性も高いため他の言語に置き換えやすいと考えられます。
　　Groovyによるiアプリ開発環境があればGroovyの普及が進むでしょう。
　　iアプリ分野でGroovyの開発効率が知られるようになれば
　　Webアプリケーションにも食い込みやすくなります。

２．Javaのソースに変換出来るようにする
　　Javaはすでに納品物に使う言語として認知されているので
　　Groovy->JavaトランスレータがあればGroovy採用の障壁が減ります。
　　Groovyで開発し、Groovy認知まではJavaで納品するという手が使えます。

>>40
　　確かに知名度向上と知識共有のためにドキュメントはもっと欲しいですね。
　　公式ドキュメントについてはGroovyラボが日本語版を用意されていますが、
　　周辺ドキュメントはこれからですね。と、いうわけでもうひとつ追加します。

３．Groovy周辺ドキュメントを整備する
　　Groovyプログラマの助けになるドキュメントを書きましょう。
　　例えばGroovyによるデザインパターンの解説などが考えられます。

42:デフォルトの名無しさん
04/08/09 20:31
プロトタイピングとテストのためでも、十分開発効率は改善できるし。
iアプリは、静的検証の役割が大きいから、Groovyは採用しづらいだろう。というかできない。
Webが一番有力。
それでも、Java2se5のautoboxingや拡張forで、一番効率の悪かった部分は解消されるし、いろんなフレームワークでコーディング量が減ってるからそこまで効果があるかどうか。
結局は、Rubyも納品用のプロダクトじゃなくて簡単なフィルター作るために人気があるようだから
　foreach("somefile.txt"){
　　println it
　}
のようにファイルを読み込んで一行づつ処理する構文が一番望まれる。

43:デフォルトの名無しさん
04/08/10 13:15
前向きなレスが出ていて面白い。
が、MLはまだ19人。
URLﾘﾝｸ(www.freeml.com)

44:デフォルトの名無しさん
04/08/11 23:36
Groovy ってそのうち JDK に入るんじゃないっけ？

45:デフォルトの名無しさん
04/08/15 00:20
>>44
これ？

Groovy language submitted as JSR 241
URLﾘﾝｸ(www.theserverside.com)

JSR 241: The Groovy Programming Language
URLﾘﾝｸ(www.jcp.org)

46:デフォルトの名無しさん
04/08/15 01:15
JSRだからといって、SDK/JREに入るとは限らないと思うけど。

47:デフォルトの名無しさん
04/08/15 04:00
udagawaの日記
URLﾘﾝｸ(d.hatena.ne.jp)
udagawaの日記(groovyで検索)
URLﾘﾝｸ(d.hatena.ne.jp)
今年の２月から始まっているudagawaの日記を読むとGroovyの成長を実感できます。

JSR #241 The Groovy Programming Language JSR Review Ballot
URLﾘﾝｸ(www.jcp.org)
>Sun is happy to see Groovy proposed as a JSR.
>Having additional interesting languages for
>the Java platform seems like a Good Thing!
全員賛成投票しており、Sunはとても好意的なコメントをつけています。
JDK標準搭載にたどり着く可能性は高いのではないでしょうか。

JCP Approves Groovy Language JSR: Sun endorses language
URLﾘﾝｸ(www.theserverside.com)
Sunのコメントを受けて盛り上がっています。

オブジェクト指向スクリプト言語(for JVM)Groovy ライブバージョン
URLﾘﾝｸ(www.kakutani.com)
>>33はLightWeight Language Weekend 2004に参加したんですね。

48:デフォルトの名無しさん
04/08/17 13:37
J2SE6.0なのか7.0なのか文脈が読めないのだが、

>>言語に関しては "Groovy" (JSR-241) が入るそうです。
URLﾘﾝｸ(www5.airnet.ne.jp)

だって。

49:デフォルトの名無しさん
04/08/19 06:48
これって.NETの多言語戦略のパクリ？

50:デフォルトの名無しさん
04/08/19 16:45
>>49
違うと思うが。

@ITの記事
URLﾘﾝｸ(www.atmarkit.co.jp)

51:デフォルトの名無しさん
04/08/20 00:56
そもそもJVM上で動くJava以外の言語なんぞ、
COBOLからRubyまであるしな。
Sunは黙殺してたが。

52:デフォルトの名無しさん
04/08/23 23:35
Javaのあのくそ長いメソッド名は最初からスクリプト言語と相性悪い罠

53:デフォルトの名無しさん
04/08/23 23:46
これはインタプリタ言語？

54:デフォルトの名無しさん
04/08/24 01:31
わざわざ別スクリプト言語用意して、evaれなかったら哂う。

55:デフォルトの名無しさん
04/08/24 08:43
中身は悪くないけど、ネーミングセンスが最悪だから
標準にはなれない。

56:デフォルトの名無しさん
04/08/24 16:13
すでにJSRなんだけども。

57:デフォルトの名無しさん
04/08/24 16:28
話がループしているようだ。

58:デフォルトの名無しさん
04/08/27 22:54
>>53
インタプリタ言語だけど、コンパイルしてクラスファイルにすることもできる。

59:デフォルトの名無しさん
04/08/28 08:54
標準化されたとして、どんな使い道があるんだろうか

60:デフォルトの名無しさん
04/08/28 16:00
Javaより若干遅いっていう評判だけど、
.class にコンパイルしても、やっぱり若干遅いの？

61:デフォルトの名無しさん
04/09/02 00:29
遅いよー(ちょっとは使ってみたら？) >> 60

62:デフォルトの名無しさん
04/09/02 18:36
>>59
すでにJavaが使える人には、あまり使い道がないけど、PHPとかからの乗り換えにいい。
ところで、7月からb6で止まってるんだけど、どうしたんだろうね。
rc待ち？
GSPはリンク切れだし。

63:デフォルトの名無しさん
04/09/19 12:22:11
luaみたいにアプリ内部の動作をgroovyから制御できる
ことって出来ますか？

64:デフォルトの名無しさん
04/09/20 21:44:45
↓グルービーでキャッチーでポップな一言

65:デフォルトの名無しさん
04/09/20 21:56:44
ぬるぽ

66:デフォルトの名無しさん
04/09/20 23:31:25
ｺﾞｯ！

67:デフォルトの名無しさん
04/09/23 21:00:15
鈍い音がした……

68:デフォルトの名無しさん
04/09/24 03:05:29
オリンピックの重量挙げの最中にそんな音が響き渡ったこともあったなあ。
いたそ。

69:デフォルトの名無しさん
04/09/25 09:14:19
alt.lang.jreコラム：Groovyに触ってみよう
URLﾘﾝｸ(www.atmarkit.co.jp)

70:デフォルトの名無しさん
04/09/25 10:19:01
JavaWorld11月号特集2「Groovyの魅力を探る」 (P50～P76)
URLﾘﾝｸ(www.idg.co.jp)
>Javaプログラマーのための次世代スクリプト言語
>Groovyの魅力を探る
>・・・関谷和愛／上原潤二

>開発サイクルが短くなる一方、仕様の追加／変更が頻発する今日の業務システム開発の現場においては、
>XP（Extreme Programming）をはじめとするアジャイルな開発手法に注目が集まっている。
>しかし、こうした“軽量”な開発手法を実践するには、JavaやXMLだけでは重厚すぎ、
>道具立てに欠けると感じたことはないだろうか。
>「Groovy」は、こうした背景から生まれた新世代のスクリプト言語である。
>本特集では、このGroovyの文法／使い方の基礎から応用までを詳細に解説する。
>それを通して、GroovyがJavaプログラマーにもたらすメリットを明らかにしたい。

>オーバービュー　Groovyの輪郭をつかむ
>基礎編　　　　　基本操作と必修イディオムを学ぶ
>応用編　　　　　定番処理にGroovyを組み込む

サンプル・ソース
fURLﾘﾝｸ(ftp.idg.co.jp)

71:デフォルトの名無しさん
04/09/25 16:40:46
軽量な開発手法ってJaclやTclBlendやjythonやrhinoではだめなのか？
そういった先達を無視してGroovyだけのの利点のように扱うのはどうかと思う。
Groovyだけの利点って何よ。

72:デフォルトの名無しさん
04/09/25 17:08:46
こいつを読むと「groovyってけっこういいじゃん」とおもたよ。

URLﾘﾝｸ(www.atmarkit.co.jp)

73:デフォルトの名無しさん
04/09/26 00:15:09
Groovyが特別、ほかのVM上で動くスクリプトより秀でているってことはないんじゃないかな。
Javaに文法が似てるってのは結構意義があるね。Javascript2.0もかなりJavaに似てると思うけど。

74:デフォルトの名無しさん
04/09/26 00:21:00
>>71
Java VM で Ruby っぽいことができる。
ついでに「先達を無視して○○だけのの利点」のように取り巻きが振る舞う
and/orメディアに取り上げられるのもまたRuby譲り、かなと。ｗ
まあ、だからアンチRuby とか、Ruby以外好きにゃあ、無用だね。

75:デフォルトの名無しさん
04/09/26 01:26:36
>>74
なぜにそこでRubyが話題に？
Ruby好きならJRubyにいくと思うけど・・・

76:デフォルトの名無しさん
04/09/26 05:03:16
Groovyのクロージャどうやって実現してんだろ？
Javaスタックは使えないよね？
もし独自に環境モデルでやってるなら遅そうだなー

77:デフォルトの名無しさん
04/09/26 07:36:28
クロージャか。delegateみたいなもんだな。
Javaはようやく全てクラスとして書くって思想が
重いって事に気づいたようだな。

78:デフォルトの名無しさん
04/09/26 09:38:49
>>77
Javaを擬人化するのはやめていただきたい
それにJavaが変わるわけでもないし

79:76
04/09/26 16:31:53
>>77
C#のdelegateみたいなのだったら実質javaの内部クラスと同様だからわかるんだけど
クロージャってコンテキストを持つじゃん？
どうやってんのかなー

80:デフォルトの名無しさん
04/09/26 17:01:45
Javaの内部クラスはいちおうfinalなローカル変数にはアクセスできますが？

そうだなぁ。
Javaで普通に作ると、内部クラスにHashmapかなんか持たせて、
アクセッサ用意してローカル変数をそっちに詰め込んで、
クロージャはそっちをアクセスするって感じじゃないの？

81:デフォルトの名無しさん
04/09/26 17:05:02
WebProg板でやれやアホども

82:デフォルトの名無しさん
04/09/26 17:08:24
なんでWebProg板？関係ないじゃん

83:デフォルトの名無しさん
04/09/26 17:13:06
たぶん言ってみたかっただけだよ。
なんか勘違いしてるだけかもしらんが。
馬鹿は処置なしです。

84:デフォルトの名無しさん
04/09/26 17:45:16
>>75-80
適当な推測で語ってないで groovyc でスクリプトを
class ファイルにコンパイルしてから逆コンパイルしてみろ。
見当違いなこといってると恥ずかしいぞ。

85:デフォルトの名無しさん
04/09/26 18:28:29
処理系すら手元にありませんが何か？

86:76
04/09/26 20:26:13
>>84
すまんおれもインストールすらやる気なし
知ってんなら教えて
逆コンパイルで簡単に仕組みわかるぐらいなら内部クラスか？
finalつけないといけない制限どうすんだ？
推測三昧だわ

87:デフォルトの名無しさん
04/09/26 20:28:45
ｽﾏｿ実は俺も処理系なし。
自前のフレームワークに取り込むかどうか思案中だけど、、、。

88:デフォルトの名無しさん
04/09/26 20:29:26
実は俺もダウンロードすらしていない。

89:デフォルトの名無しさん
04/09/26 23:42:03
俺漏れも

90:デフォルトの名無しさん
04/09/27 01:30:14
ｲﾝｽｺすんのﾏﾝﾄﾞｸｻ('A`)

91:デフォルトの名無しさん
04/09/27 04:07:57
>>90
べつに、ダウンロードして解凍するだけですよ。
フルパスでコマンド打ち込むのがいやならパス通せばいいだけの話。

92:76
04/09/28 00:57:22
>>91
それが面倒だっつってんだろが
おれの気持ちもわかってくれよ
まぁいいよ
Groovyはローカル変数を独自の環境フレームに確保する
なのですげー遅いウンコ言語
というわけで脳内解決したから興味なくなった

93:デフォルトの名無しさん
04/09/28 00:59:31
すげー遅いのは確かだけど独自の環境フレームには確保しないよ。

94:デフォルトの名無しさん
04/09/28 01:13:32
>>92
わかってるよｗ
起動がめんどくさかったら、自分でレジストリいじくってダブルクリック起動すればいいだけの話でもある。

95:デフォルトの名無しさん
04/09/28 01:21:28
Groovyの読み方を教えてください

96:デフォルトの名無しさん
04/09/28 01:30:44
URLﾘﾝｸ(members.jcom.home.ne.jp)

97:デフォルトの名無しさん
04/09/28 09:05:32
>>95
ぐRuby

98:76
04/09/29 01:52:18
やっぱり環境フレームつくってるじゃねーか
適当なこと言うんじゃねーよ、ボケが

99:デフォルトの名無しさん
04/09/29 02:03:51
ハア？

100:76
04/09/29 03:42:13
お前だろが、見当違いなこと言って恥ずかしいやつってのは
しりもしないくせに見栄はっちゃってよ
えらそうに言ってるわりに何にもわかってねーじゃん
てか低脳

101:デフォルトの名無しさん
04/09/29 11:46:41
>>99
どうやら76は84のことを怒っているものとおもわれ。

102:デフォルトの名無しさん
04/09/29 14:08:33
>100
ABC

103:デフォルトの名無しさん
04/09/29 16:03:49
環境フレームっつーと、LISPやSchemeでおなじみのアレか。
処理系独自のフレーム管理になるから、
JavaVMのスタック命令使えなくて遅くなるのかもしれないけど、
あれは便利だよね。
スクリプト言語はこうじゃなくちゃいけない。
これと比べてしまうと、gccの関数内関数拡張なんてゴミに等しい。

104:デフォルトの名無しさん
04/09/29 17:10:16
>>100
お
し
え
て

何故、ここで縦読み

105:デフォルトの名無しさん
04/10/01 17:03:51
なんかむちゃくちゃ遅いって噂流れてますが、マジ？

106:デフォルトの名無しさん
04/10/01 17:43:28
まじ

107:デフォルトの名無しさん
04/10/01 18:36:44
使い捨てプログラムの場合、書く時間 >> 実行時間だから書く時間が短くなれば、実行時間が少々増えたところで、思い立ってから結果が出るまでの時間が短い、という考え方。
結果が得られることがわかってから、Javaに持っていけばいい。

108:デフォルトの名無しさん
04/10/01 20:42:44
まだ実験段階だから、最適化を全くしてないらしいが。

109:デフォルトの名無しさん
04/10/01 23:07:31
ボウズ、最適化は仕様が固まってからだろ

110:デフォルトの名無しさん
04/10/01 23:19:01
短所を探すよりも長所を伸ばしましょう

111:デフォルトの名無しさん
04/10/02 19:31:46
漏りあがってるねぇ。
おくればせながら>>70を買ってきた。
なんかすごいページ数なんですけど。しかも記事がマニアックだ。
>>71
そんな風によみとれる表現があるの？

112:デフォルトの名無しさん
04/10/02 20:43:18
71は日ごろから被害妄想に悩んでる人なんだよ

113:デフォルトの名無しさん
04/10/02 21:37:00
>>75
おまえJRuby使ったことないだろ

114:デフォルトの名無しさん
04/10/02 23:08:28
"c:\\rtest"が c:\キャリッジリターンtest と評価される
nやtで始まってもダメなんだろうな
お陰でFile.separatorを初めて活用した

115:デフォルトの名無しさん
04/10/03 00:17:06
今夜はグルービーナイト

116:デフォルトの名無しさん
04/10/03 04:19:32
なんか懐かしいこと言ってくれるじゃないの！

117:デフォルトの名無しさん
04/10/04 01:04:03
groovyをインストールしてgroovyshは動いたけど、groovyConsoleを起動しようとすると

Exception in thread "main" java.lang.ClassNotFoundException: groovy.ui.Console
........

というエラーが出る。どうすればよいの？

118:デフォルトの名無しさん
04/10/04 08:27:00
>>117
環境変数設定してる？

119:117
04/10/04 10:10:29
>>118
実はJavaの経験が無いので、よくわかっていませんが、
JAVA_HOME, JAVA_FONTS, GROOVY_HOMEは設定しています。

groovyshは動くので、大筋ではあっていると思うのですが。

120:デフォルトの名無しさん
04/10/04 22:58:05
>>117
groovy-1.0-beta-7.jarにgroovy.ui.Console.*が入ってないですね。
ビルドのミスでしょうか？

groovy-1.0-beta-7\src\main\groovy\ui (beta-7ソースファイル)
Console.groovy　<-これがコピー、コンパイルされるはず
ConsoleSupport.java
GroovyMain.java
GroovySocketServer.java
InteractiveShell.java
package.html
ShellCompleter.java

groovy-1.0-beta-7.jar\groovy\ui (beta-7 jarファイル)
ConsoleSupport.class
GroovyMain.class
GroovySocketServer$GroovyClientConnection.class
GroovySocketServer.class
InteractiveShell.class
ShellCompleter.class

groovy-1.0-beta-6.jar\groovy\ui (beta-6 jarファイル)
（前略）
Console.class　<- コンパイル
Console.groovy　<- コピー
ConsoleSupport.class
GroovyMain.class
InteractiveShell.class

121:デフォルトの名無しさん
04/10/04 23:11:16
>>120
なんてこったい・・・・

122:デフォルトの名無しさん
04/10/05 01:31:44
URLﾘﾝｸ(jira.codehaus.org)

123:デフォルトの名無しさん
04/10/20 00:31:18
　　　　　　　　　　　　　　　　＼　│　／
　　　　　　　　　　　　　　　　　／￣＼　　／￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　─（ﾟ ∀ ﾟ）＜　くっちゃらはぴはぴ！
　　　　　　　　　　　　　　　　　＼＿／　　＼＿＿＿＿＿＿＿＿＿
　　　　　　　　　　　　　　　　／　│　＼
　　　　　　　　　　　　　　　　　　　 ∩ ∧　∧　　／￣￣￣￣￣￣￣￣￣￣
￣￣￣￣￣￣￣￣＼∩ ∧　∧　＼（ﾟ∀ﾟ）＜　くっちゃらはぴはぴ！
Ｐｙ厨～～～～！　　＞（ﾟ∀ﾟ）/ ｜　　　　/　＼＿＿＿＿＿＿＿＿＿＿
＿＿＿＿＿＿＿＿／｜　　　〈　｜　　　｜
　　　　　　　　　　　　　 /　／＼_」　/　／＼」　　　　　　　　　　　　　￣　　　　 / ／

124:76
04/10/20 22:55:40
気が向いたので84の言うとおりにgroovyc でスクリプトを
classファイルにコンパイルしてから逆コンパイルしてみた。
結果憶測は完全に正しかった。
ローカル変数はpropertyという名前で自前の環境フレームにて管理されてる。
84わかったか？

125:デフォルトの名無しさん
04/10/20 23:58:04
>>124
粘着ｳｾﾞ

126:デフォルトの名無しさん
04/10/21 00:40:49
そもそも環境用意しないでクロージャ実現なんてできるん？

127:デフォルトの名無しさん
04/10/21 10:35:09
>>124
ほら、やっぱりやれば出来る子じゃないの
お母さんもそう言ってたでしょ？

128:デフォルトの名無しさん
04/11/01 23:20:34
>95
ぐるるるるるぅ�hぃ

129:デフォルトの名無しさん
04/11/04 18:43:11
グルーなルビー？

130:デフォルトの名無しさん
04/11/12 23:38:10
java上で動くperlはないものか。

131:デフォルトの名無しさん
04/11/12 23:42:46
　　　　　　　　　　　　　　　　＼　│　／
　　　　　　　　　　　　　　　　　／￣＼　　／￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　─（ﾟ ∀ ﾟ）＜　くっちゃらはぴはぴ！
　　　　　　　　　　　　　　　　　＼＿／　　＼＿＿＿＿＿＿＿＿＿
　　　　　　　　　　　　　　　　／　│　＼
　　　　　　　　　　　　　　　　　　　 ∩ ∧　∧　　／￣￣￣￣￣￣￣￣￣￣
￣￣￣￣￣￣￣￣＼∩ ∧　∧　＼（ﾟ∀ﾟ）＜　くっちゃらはぴはぴ！
Ｐｙ厨～～～～！　　＞（ﾟ∀ﾟ）/ ｜　　　　/　＼＿＿＿＿＿＿＿＿＿＿
＿＿＿＿＿＿＿＿／｜　　　〈　｜　　　｜
　　　　　　　　　　　　　 /　／＼_」　/　／＼」　　　　　　　　　　　　　￣　　　　 / ／

132:デフォルトの名無しさん
04/11/12 23:46:43
>>130
あるよ。

133:デフォルトの名無しさん
04/11/12 23:47:48
普通にJavaを使えば良いと思うんだが…。
遅くなるだけだろ？

134:デフォルトの名無しさん
04/11/13 05:44:02
再利用しないコードを手っ取り早く書くには便利だよ。
速度が遅くても早く書けることのほうが重要なケースってあるし。

135:デフォルトの名無しさん
04/11/13 16:01:52
海外でははやっているようなんだが、日本ではまだかな。
日本語のドキュメントが足りないんだろうな。

136:デフォルトの名無しさん
04/11/13 18:08:40
>>134
RubyやPerl等の言語と比べても手っ取り早いの？
ぐるぅびぃは使ったことないからわからんのよ

137:デフォルトの名無しさん
04/11/13 18:13:12
自分で調べろ。

138:デフォルトの名無しさん
04/11/13 18:14:57
>>136
変わらんけど、RubyやPerlはJavaに組み込んで使えないでしょ？

139:デフォルトの名無しさん
04/11/13 18:30:42
RubyもPerlもPythonもTclもJavaScriptもJVM実装がある

140:デフォルトの名無しさん
04/11/13 18:34:51
仮想マシンの上で動くJavaのそのまた上で動くスクリプト？いみね。

141:デフォルトの名無しさん
04/11/13 18:58:01
PerljのJVM実装って名前なに？

142:デフォルトの名無しさん
04/11/13 19:01:20
perl JVM って B-JVM-Jasmin かな？

143:デフォルトの名無しさん
04/11/13 19:14:28
>>139
そういう意味じゃなくて、Javaアプリケーションの中に組み込んで使えるかどうか。

144:デフォルトの名無しさん
04/11/13 19:16:32
使えるよ

145:デフォルトの名無しさん
04/11/13 19:20:17
JavaScriptは確か組み込みのがあったね。
PerlやRubyは初耳だな。

146:デフォルトの名無しさん
04/11/13 19:50:35
好きなもん使えよ。どれも大して変わらんから。

147:デフォルトの名無しさん
04/11/13 20:00:37
perljvm - The Perl to Java Virtual Machine ( JVM ) Compiler
URLﾘﾝｸ(www.ebb.org)

はてな JAVA言語以外の言語をJAVAバイトコードにコンパイルできるコンパイラ
URLﾘﾝｸ(_______________________________________________________________.hatena.ne.jp)

148:デフォルトの名無しさん
04/11/13 20:31:31
Javaのクラスを透過的に使えるかどうかじゃないの？

149:デフォルトの名無しさん
04/11/13 20:37:39
JVM=Javaと思ってるんだろうな。

150:デフォルトの名無しさん
04/11/13 20:52:50
JVMで動くRubyがあったと思ったけど、Rubyで動くJVMのことだった。orz

151:デフォルトの名無しさん
04/11/13 20:55:23
>>148
Javaのクラスが透過的に使えないとでも？
寝言は寝て言え。

152:デフォルトの名無しさん
04/11/13 20:55:55
>>150
JVMで動くRubyもあるよ。

153:デフォルトの名無しさん
04/11/13 21:07:08
>>151
JVMで動くGroovy以外のスクリプト言語で？

154:デフォルトの名無しさん
04/11/13 21:44:12
perlでJavaクラス呼び出しか。萌える。

155:デフォルトの名無しさん
04/11/13 21:48:52
なにこのJVMで動くスクリプト言語総合スレ

156:デフォルトの名無しさん
04/11/13 21:56:05
>>154
それより、Javaのクラスを継承したクラスをPerlで定義とか。

157:デフォルトの名無しさん
04/11/13 22:03:48
>>151
例えば、Perlで$valueに文字列を代入して、
　$value = "Hello Perl!";

Javaでそれを使用することは出来る？
　System.out.println(value);

逆はどうかな？

158:デフォルトの名無しさん
04/11/13 23:20:09
ｸﾞﾙｰﾋﾞｨｱｰﾁｪ

159:デフォルトの名無しさん
04/11/13 23:49:52
JythonはJavaのクラス継承できるよ。

160:デフォルトの名無しさん
04/11/13 23:55:12
>>157
JythonでもJaclでもできるよ。
Java版Perlは使ったことないからしらないけどできないと思う理由がない。

161:デフォルトの名無しさん
04/11/14 00:23:55
え、Javaのソースの中にJythonのコードを一つのソースファイルに混ぜて書いて、
コンパイルしてクラスファイル作れるってこと？
たとえばJPerlなら.plファイルからクラスファイルを作れるだけじゃないの？
PerlからJavaのクラスを使用する事はできるだろうが、ソースファイルにPerlと
Javaの文法ごちゃまぜに書いたりはできないんじゃないか？

162:デフォルトの名無しさん
04/11/14 00:28:40
それぞれ使ったことがないものについて話をしているのが笑える。

163:デフォルトの名無しさん
04/11/14 00:35:25
Pythonコードの文字列をJavaソースに含めることを「一つのソースファイルに混ぜて書いて」に含めるならそれもできるよ。
逆に聞くけどGroovyではそれ以上のごちゃまぜができんの？
Javaコンパイラのシンタクスに手を入れるような裏技を使ってるとか？

164:デフォルトの名無しさん
04/11/14 01:02:17
Javaコンパイラは使っていないと思うが。

165:デフォルトの名無しさん
04/11/14 01:22:24
最初に出て来たPerlとRubyはどこに行った。

166:デフォルトの名無しさん
04/11/14 03:01:17
>>161,163
たしかGroovyはJavaの文法を完全に含んでるはず。
C++とCの関係みたいなもん。

だからGroovyとJavaの文法をごちゃまぜという事態は発生しない。

167:デフォルトの名無しさん
04/11/14 05:05:19
>>166
forEachと拡張for

っていうか、なんでみんな憶測で断定するんだ？

168:デフォルトの名無しさん
04/11/14 06:02:27
>> C++とCの関係

嘘吐くな

169:デフォルトの名無しさん
04/11/16 03:06:17
自作アプリの拡張用にGroovy使ってるんだけど、便利だよ。
パフォーマンスはイマイチだけどね。

170:デフォルトの名無しさん
04/11/18 00:53:42
じゃ、イラネ・・・
ていうかJavaランタイムないと動かんのでしょ？
問題外だわ

171:デフォルトの名無しさん
04/11/18 00:59:45
Java みててもわかるように速度は後から改善できても、
言語仕様はなかなか変えられない。
どっちを優先すべきかは自明。

172:デフォルトの名無しさん
04/11/18 01:38:57
JREさえあればプラットフォームに依存せず動くというのはとても便利。
PythonだってRubyだってOS標準で入ってるわけじゃないのはJavaと条件は一緒。

173:デフォルトの名無しさん
04/11/18 03:12:26
>170 はアセンブラ厨ということで。

174:デフォルトの名無しさん
04/11/18 03:39:01
>>170のような考え方でよくスクリプト言語のスレ見る気になったよな

175:デフォルトの名無しさん
04/11/19 00:17:43
groovyって

cat 20041111.log | ./hoge.groovy
みたいなパイプを使った処理って出来ますか？

groovy パイプとかでぐぐっても見つけられません

教えてえらい人

176:デフォルトの名無しさん
04/11/19 01:48:47
拡張子長！

標準入力から読めばいいんじゃね？

177:デフォルトの名無しさん
04/11/19 17:42:18
$ cat A.groovy
class Foo {
myGenerator(yield) {
yield "A"
yield "B"
yield("C")
}
static void main(args) {
foo = new Foo()
foo.myGenerator { println "Called with ${it}" }
}}

$ groovyc A.groovy
$ ls
A.groovy
Foo$2.class
Foo$_main_closure1.class
Foo.class

としてから

$ java Foo

を実行したのですが、java.lang.NoClassDefFoundError ...
と言われ怒られてしまいます。 groovy-version/lib 内にある幾つかの *.jar ファイルを CLASSPATH に
入れればいいのはわかっているのですが、なにしろ20個近くのjarファイルがあるので、どれが
ランタイムに関わっているのかわかりません。

だれか、実行するのにインクルードされるべき jar ファイルを教えていただけませんか？

178:デフォルトの名無しさん
04/11/19 20:40:30
全部含めればいいじゃないか。

179:デフォルトの名無しさん
04/11/19 20:46:46
>>178
classpathが長すぎるとantがエラーはく。
だからやだ。

180:デフォルトの名無しさん
04/11/19 21:27:42
hibernate+spring+velocityで25くらいのjarをクラスパスに含めてるけど、そういうことに陥ったためしがないんだが。

181:デフォルトの名無しさん
04/11/19 21:28:56
ant使ってるのにclasspathにパス指定してるとか？
いまどきシステムのclasspath使うなよ。

182:デフォルトの名無しさん
04/11/19 22:53:36
Groovyもスクリプト言語なのにクラスパスとかJavaのめんどくささを継承してるってことだよね

183:デフォルトの名無しさん
04/11/19 23:02:07
どんなスクリプト言語でもライブラリのパスは設定する必要があるわけだが。

184:デフォルトの名無しさん
04/11/19 23:03:48
素直にJava使えよ。

185:デフォルトの名無しさん
04/11/19 23:04:25
>>183
> どんなスクリプト言語でもライブラリのパスは設定する必要があるわけだが。

全部一つのjarファイルにまとめればよい。
そうすればパス指定は1つで楽にすむ。

186:デフォルトの名無しさん
04/11/19 23:05:09
>>184は同時に一言語しか覚えられない奴か

187:デフォルトの名無しさん
04/11/19 23:05:56
>>184
> 素直にJava使えよ。

java でのプログラムはtedious。誰もがそれを認めている。

188:デフォルトの名無しさん
04/11/19 23:07:00
>>185
で、jakartaだけでもいろいろなバージョンの組み合わせで10000とおりくらいのjarの中からひとつ選ぶようになるわけか。

189:デフォルトの名無しさん
04/11/19 23:09:13
>>187
それはオマエが単純な部分しか任されないチームに隔離されてるから。

190:デフォルトの名無しさん
04/11/19 23:37:33
> で、jakartaだけでもいろいろなバージョンの組み合わせで10000とおりくらいのjarの中からひとつ選ぶようになるわけか。

log n で済むわけなんだが。

191:デフォルトの名無しさん
04/11/19 23:40:51
>>189
> >>187
> それはオマエが単純な部分しか任されないチームに隔離されてるから。

おまえの「単純な部分」の定義がわからんのだが。。。
大体、スクリプト言語での仕事 => 単純な部分
という大胆すぎる inference は考慮がたりなさすぎる

192:デフォルトの名無しさん
04/11/19 23:43:30
はい、スレ違いなのは他でやってね。

193:デフォルトの名無しさん
04/11/20 01:05:29
>>191
よくわからんが、あなたが任されてるtediousな部分。
tediousな部分しかやってないチームにいるからjavaはtediousと思って、周りの誰もがそれを認めてるんでしょ。
あぁ、Javaじゃなくてスクリプト言語を任されてるんだね。

194:デフォルトの名無しさん
04/11/20 01:06:13
>>190
> log n で済むわけなんだが。

どうやったら？

195:デフォルトの名無しさん
04/11/20 01:21:42
>>193
> >>191
> よくわからんが、あなたが任されてるtediousな部分。
> tediousな部分しかやってないチームにいるからjavaはtediousと思って、周りの誰もがそれを認めてるんでしょ。
> あぁ、Javaじゃなくてスクリプト言語を任されてるんだね。

ハァ？俺はプログラムの内容じゃなくてシンタックスが記述的に「tedious」と述べた
だけなんだけど。。。

>>194
> どうやったら？
jarを想像してみ。シンプルなツリー構造になるだろ？

196:デフォルトの名無しさん
04/11/20 01:26:15
>>195
>> どうやったら？
>jarを想像してみ。シンプルなツリー構造になるだろ？

で、それがバージョンごとの可能な組み合わせを考えなくていい理由になるのか？

197:デフォルトの名無しさん
04/11/20 01:38:44
いやまあ、俺は何でそこで「tedious」なんて英単語を持ち出す必要があるのか
分からんかった。
「長ったらしくてつまらん」でいいだろ？

198:デフォルトの名無しさん
04/11/20 01:42:13
>>197
log nとか、nが少なかったら何の意味もなさない書き方してるし、そういうことでしか賢さを示せない方では？

199:デフォルトの名無しさん
04/11/20 01:53:42
groovyでクラスパスの設定するのに、いちいち環境変数使ってるの？
$GROOVY_HOME/conf/{command}-classworld.conf使ったほうがよくない？

アプリごとにconfファイル用意して、
バッチファイルをいじれば好きなアプリ毎に自由にクラスパスの設定の切り替えができる。
（シェルスクリプトのほうは修正しなくても最初からそうなっている）

慣れればこっちのほうが便利だと思うけどな～

200:デフォルトの名無しさん
04/11/20 08:51:21
>>177

libじゃなくて、展開したディレクトリの直下にgroovy-1.0-beta-*.jarとかが置かれてない？
多分これ１つでOKだったと思った。

201:デフォルトの名無しさん
04/11/20 11:46:31
Javaの仕組みが同じディレクトリにjarがあったら全部拾ってくれるようになってればいいんだよ。
WindowsのDLLってそうじゃないか。

202:デフォルトの名無しさん
04/11/20 12:45:42
>>201
うっとおしい。ただ、classpathに指定したディレクトリのjarはすべて含むようにとかはして欲しかった。
けど、もうどうでもいい。
classpathなんか設定しないし。

203:デフォルトの名無しさん
04/11/22 10:29:13

204:デフォルトの名無しさん
04/11/29 15:10:35
JDK5.0にGroovyは対応しているのでしょうか？
JDK1.4x以上とあるのは1.4V内での話しなのか
ホントに以上なのかがイマイチよくワカリマセン。
日経ソフトウェアの今月号にはお奨め言語と
なっていました。SqeakのeToyと「ひまわり」と
一緒に。

205:デフォルトの名無しさん
04/11/29 16:06:25
自分で聞いて自分で回答するのも
なんですが、うまく行くようです。

206:デフォルトの名無しさん
04/11/29 22:24:25
まあJ2SE 5.0はJ2SE 1.4の上位互換があると言ってるから、groovycで
コンパイルしたバイトコードは動くだろうね。

207:デフォルトの名無しさん
04/12/01 21:13:43
>>205
自作自演Q&A乙。こういうのは役に立つのでこれからも自作自演を続けてくれい。

208:デフォルトの名無しさん
04/12/05 13:07:34
>>207
芸が細かい自作自演Q&A乙

209:デフォルトの名無しさん
04/12/12 18:21:52
自作自演Q&A Hey!
Beta8がもうすぐReaseされるタイミングです。
大体２ヶ月ピッチ？
前回は９月だからして…。
ひょっとするとBetaが省かれて1.0
になる可能性もあるらしいが。

210:デフォルトの名無しさん
04/12/12 18:26:04
>>209
ひょっとしてAranskが復活したりしてね。
関数型言語からスクリプト言語に宗旨替えしてさぁ。
HPやBlogも最近頻繁に書き換えているようだし…。
今まで何しとったん？

211:デフォルトの名無しさん
04/12/13 05:43:57
>>210
自作自演Q&A乙。こういうのは役に立つのでこれからも自作自演を続けていれくい

212:Aransk
04/12/18 15:44:28
Groovy Beta 8が12月17日付けで発表されました。
Beta7から、どこがどう変わったのかさっぱり
分かりません。要はインストールして
自分で試せと言うことらしい。

213:Aransk
04/12/20 10:22:02
このGroovyスレって盛り上がらないねぇ。
Ruby,Pythonのいい所取りだから仕方ないかもね。
ある面スクリプト系言語の閉塞状況を示して
いるのかも知れない。

214:デフォルトの名無しさん
04/12/20 10:25:50
正式版が出てないから、これ以上盛り上がりようが。

215:デフォルトの名無しさん
04/12/20 11:55:12
Javaでしか使えないからもリあがらないんだよ。

216:デフォルトの名無しさん
04/12/20 12:04:27
Rubyにあらゆる点で劣っているしな。

217:デフォルトの名無しさん
04/12/20 13:55:53
>>216
そういう煽りにはもう飽きちゃった。

218:デフォルトの名無しさん
04/12/20 16:12:08
>>216
巡回ご苦労様です。

219:デフォルトの名無しさん
04/12/20 19:53:07
仕様も固まっていないし。

220:デフォルトの名無しさん
04/12/21 00:31:28
きょうのすれは、まれにみる盛況ぶりだったな

221:デフォルトの名無しさん
04/12/21 06:22:09
Groovy 1.0b8の主な改良点
URLﾘﾝｸ(docs.codehaus.org)

・groovyConsoleとstreaming buildersがディストリビューションに復活
・groovyshでのエラーメッセージ表示が少なくなった（スタックトレース無しよ）
・JDK 5.0上での動作を改善
・GroovyShellで数千ものスクリプトを実行すると発生していたメモリリークが解消
・MarkupBuilderが<a href="groovy">stuff</a>を生成できるようになった
・Windowsでclasspathフラグが働いてなかったことがあったのを修正
・antで特別なtaskdefをしないでもgroovy namespaceを使えるようにした（翻訳自信無し）

222:Aransk
04/12/21 18:35:48
>>214ー221
>芸が細かい自作自演Q&A乙
かも知れんが、孤独感はかなり癒された。
GroovyのHPにある言語仕様はまだ誰も訳して
ないようなんで全てダウンロードして
意訳＝＞異訳＝＞違約を試みております。
単なる言語仕様じゃなく、「重点」をこんなことが
出来て嬉しい！実例に置きたい。
が、しかし、そんな嬉しい実例があったら
とっくにRuby本でやってるはずだとも
思いつつ…。

223:デフォルトの名無しさん
04/12/21 19:06:04
自分的にはGroovy HPのFeaturesセクションが
「こんなことが出来て嬉しい」にヒットしまくり。

224:デフォルトの名無しさん
04/12/21 19:55:06
名前がダサすぎ

225:デフォルトの名無しさん
04/12/22 05:18:17
シェル上で実行できるスクリプト言語としては当たり前のことなんだが、
1行目に #! を書いて動いたのがなんだか嬉しかった。

#!/usr/bin/env groovy
n = 0
for (k in args) {
　n++;
　println("Argument " + n + " : " + k)
}

226:Aransk
04/12/22 18:41:44
>>224
ダサいとは思わないが長いとは思う。
出来れば３文字、長くて４文字程度が望ましい。
.groovyってのはー＞.gvyでも.gryでも良さそうに
思える。

227:デフォルトの名無しさん
04/12/22 19:20:02
「ぐびー」で。

228:デフォルトの名無しさん
04/12/22 19:44:43
Groovy
ぐるーびぃ
ぐるーびぃ
ぐるびぃ
ぐるびぃ
GRuby
GNU Ruby???

229:デフォルトの名無しさん
04/12/23 02:31:19
>>226
.grvを希望。できれば.gだけで。

230:Aransk
04/12/23 16:03:20
groovyのforeachは
for ( i in array )
と書き
今回JDK5.0で追加されたjavaの
foreachは
for (i : array)
となった。
この「in」と「:」の差異は何なんで
しょうねぇ？

231:デフォルトの名無しさん
04/12/23 16:04:19
prologの x:xsと通じるものがあるのかもしれない

232:デフォルトの名無しさん
04/12/23 16:05:05
しまった
Aransk と同じ時を過ごしてしまった

233:デフォルトの名無しさん
04/12/23 16:24:03
inというキーワードを追加したら、inという名前の変数を定義してたりする
コードが動かなくなるから。

234:デフォルトの名無しさん
04/12/23 20:56:27
>>231
prologは、[X|XS]
x:xsはML

235:デフォルトの名無しさん
04/12/23 21:46:55
>>233
java.lang.System.inが……

236:デフォルトの名無しさん
04/12/23 21:48:22
あぁ、だからenumは容赦なくキーワード認定されたのか。

237:choix ◆pnCm4bpG3Y
04/12/24 01:16:59
>>230
Python慣れしたユーザーにアピールするためにinを採用したとか？

238:デフォルトの名無しさん
04/12/24 02:08:15
>>234
ML は x::xs
x:xsは Haskell
まあどっちみち関係ないし。

個人的には in は Ruby っぽい気がするが、 Python でもあるだろうし、それ
を言い出したら、元を辿るとシェルになる気もする。

239:Aransk
04/12/24 10:31:02
今回のJDK5.0言語仕様変更担当者の話では
従来のfor構文との整合性をとったとのことです。
つまり意地でもforeachという単語を付加したく
なかった。
ここからは筆者の推測です。
groovyも基本的にはこの路線を走っていた。
しかしinだけはスクリプト感覚的に利用して
しまった。
その後同じJava言語開発陣が傍流のgroovyごときに
追随する訳には行かなかった、が、しかし、
機能的にはgroovyで既に実現している部分なので
手を抜きたかった。
そこでinを：に変更し、面目だけは保った。
つまり「write once,run anywhere」は
今回の文法変更により成立しなくなっているです。
従ってJava開発陣としてのプライドだけが
「：」に込められているのではないでしょうか？

次ページ