次世代Javaの動向　２

次世代Javaの動向　２ at TECH

1:デフォルトの名無しさん
06/05/18 01:03:42

前スレ
【Java】次世代Java・J2SE1.6の動向【Mustang】
ｽﾚﾘﾝｸ(tech板)

関連スレ
【JavaFive】C＃からJ2SE5.xへ進化【TigerShot】
ｽﾚﾘﾝｸ(tech板)

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

マルチタスク実現へJava言語改良
Sun幹部によると、2005年に一般リリース予定の「J2SE 1.6」には、
Javaバーチャルマシン（JVM）のアプリケーション共有を強化する「分離」機能が備わり、
ローカライズコンピューティング処理実行のための分離が可能になるという。

米Sun Microsystemsは、Javaバーチャルマシン（JVM）内部での
アプリケーションマルチタスク実現に向けてJava言語の改良に取り組んでいる。
カリフォルニア州サンノゼで開催のClusterWorld Conference & Expoで4月6日、同社幹部が明らかにした。

SunのJavaアーキテクト、ムラリ・カウンディンヤ氏によると、
今秋β版が登場し、2005年に一般リリース予定の「J2SE 1.6」には、
JVMのアプリケーション共有を強化する「分離」機能が備わる。
この機能によってローカライズコンピューティング処理実行のための分離が
可能になり、第2のJVMを要求することなくJVM内部でマルチタスクが行えるようになるという。

　またJ2SE 1.6では、Javaプログラム間の高速通信を可能にする
Sockets Direct Protocolのサポートが計画されている。カウンディンヤ氏によると、
J2SEに施された改良は、その後間もなくJ2EEにも組み込まれる予定。

2:デフォルトの名無しさん
06/05/18 01:05:40
トラックバック:ｽﾚﾘﾝｸ(tech板)

以下のスレは、埋まったら今度はこのスレを本スレとしませんか？
【JavaFive】C＃からJ2SE5.xへ進化【TigerShot】
ｽﾚﾘﾝｸ(tech板)

3:デフォルトの名無しさん
06/05/18 01:10:17
マ板のスレみたいな名前だからなぁ・・・

4:デフォルトの名無しさん
06/05/18 01:15:46
アンチ厨が群がってくると？

マ板とは区別できるだろうと期待したい。
馬鹿には馬鹿しか集まらないが、
知的な議論が交わされれば
オッサン共はこちらを荒らすことは無いだろう。
もしこっちがあれたらム板のC言語やC++スレ、C#スレまで
荒れることになる恐れがあるので。

5:デフォルトの名無しさん
06/05/18 03:23:27
現代から次世代、次々世代まで

Tiger JDK5.0
URLﾘﾝｸ(java.sun.com)
言わずもがな、リリース最新バージョン

Mustang JDK6.0
URLﾘﾝｸ(java.sun.com) [beta]
URLﾘﾝｸ(mustang.dev.java.net) [weekly binary snapshot]
URLﾘﾝｸ(java.sun.com)　[Version6 or 1.6?]
おお、JavaOne期間でロゴ変わってる

Dolphin JDK7
URLﾘﾝｸ(dolphin.dev.java.net)
まだ、できてない、2006年春スタート予定だったはず。

>>1 の話ってちょいと昔のかなぁ、と思いつつ・・・
BercelonaプロジェクトのMVMの話、どうなってんだろ、と思い出した
つ URLﾘﾝｸ(research.sun.com)
まだまだ研究レベルで、実際はDolphinで載ればいい方かな、と思ってんだけど。
Dolphinは、言語スペックに大幅改修入るみたいだし、なんとか一緒に入るのかな？
実現されればWebサーバ側で、JVMがデーモンのように上がってる、なんて事になったりして・・・

6:デフォルトの名無しさん
06/05/18 19:22:03
Mustang ベータ2が来月。リリースが9月だっけか。。
Dolphinは2008年半ばだそうな。

7:デフォルトの名無しさん
06/05/18 19:41:51
Windows Vistaへの対応が気になるところ。
Windows版だけ、6月無理とか、制限あったりとかしそうな悪寒。

8:デフォルトの名無しさん
06/05/18 20:02:09
Vista発売の方が延びるから問題ない。

9:デフォルトの名無しさん
06/05/18 20:03:17
Vista 対応って、具体的に何を期待してんだろ？

10:デフォルトの名無しさん
06/05/18 20:17:37
XP SP2上と同じように動くこと。
現状、Vista公開β候補版でボロボロなので。

11:デフォルトの名無しさん
06/05/18 22:17:28
URLﾘﾝｸ(journal.mycom.co.jp)
＞Mustangの次のバージョンのJava SEはDolphin(Java SE 7)である。DolphinではJavaプ
＞ラットフォームがエコシステムへと発展する方向での拡張を目指すという。具体的にど
＞のような拡張が行われるのかは現在議論が重ねられている最中だが、現時点では次
＞のような新機能の追加が発表されている。
＞
＞プロパティのサポート
＞メソッドリファレンスのレポート
＞クロージャのサポート
＞言語レベルでのXMLのサポート
＞JVM上で動作する動的言語のサポート
＞スクリプト言語サポートの拡張
＞モジュール化のサポート
＞Swingアプリケーション開発のためのツールの充実

Dolphinってこんなに変わるのかよ。プロパティ・サポートとかクロージャのサポートって、
かなり大きな変更のように思うが...

12:デフォルトの名無しさん
06/05/18 23:47:51
クロージャってC# 2.0の匿名メソッドみたいなｱﾌｫなものに
なるんだろうな。
URLﾘﾝｸ(d.hatena.ne.jp)

VM自体がクラス前提になっているから、猛烈にクソなものが平気で
出てくる。

13:デフォルトの名無しさん
06/05/19 00:00:07
>>12
なんでいきなり言い切ってるんだろうか....
C#がクソな実装したからってJavaがそうなるとは限らんだろうに。
実際、いままでJavaの実装で、このC#のようなクソな実装ってあったか？

おれはもしJavaで同じことやったら、実行速度上のデメリットがあっても、
ソースコードとの一致を取って、ループの度に匿名インスタンス生成を
選択するんじゃないかと思う。

それがMS一社で決めてるC#と、コミュニティで決めてるJavaの違いじゃ
ないかと。

14:デフォルトの名無しさん
06/05/19 00:27:05
それってruby の yield?
Genericsみたいにもめても、何とかなるんじゃない？

15:デフォルトの名無しさん
06/05/19 01:49:07
>>13
Generics

16:デフォルトの名無しさん
06/05/19 01:53:58
GenericsってJavaのほうが実装早いだろ

17:デフォルトの名無しさん
06/05/19 01:56:46
Genericsはそんなにクソでもないと思うがなあ。
イレイジャのこと言ってるんだけど、妥当な妥協ポイントだと思うよ。
おかげでcommonsとかそのまま使えてるわけで。

18:デフォルトの名無しさん
06/05/19 03:37:39
>>11
この新機能ってJSRで言うとどれなのかリストあるのかね?

19:(・∀・)ｷﾀｺﾚ!!
06/05/19 12:01:51
「あとは方法を検討するだけ」--サンがJavaのオープンソース化を約束
URLﾘﾝｸ(japan.cnet.com)

20:デフォルトの名無しさん
06/05/19 12:19:32
要は不良債権処理でしょ。マクネリもクビ切られるほどSunがヤバイ状況だから。

21:デフォルトの名無しさん
06/05/19 13:21:22
まくにーりーって会長職にいるんだけど・・・？

22:デフォルトの名無しさん
06/05/19 17:31:28
Linuxディストリにも標準バンドルされる、というのは良いことだな。

23:デフォルトの名無しさん
06/05/19 17:34:01
>>19
会場盛り上がったよ

>>21
明日出てくるよ

24:デフォルトの名無しさん
06/05/19 20:21:37
「JavaVMは汎用OS上で動かさない」---JRockitの開発マネージャにJavaVMの今後を聞く

---今，JavaVMにどんな機能が求められているのか
　環境の変化に対応しなければならない。それは「サーバー仮想化」という動きだ。
VMwareやXenなどのHypervisor技術に基づいた仮想化ソフトを利用するケースが増えている。
一つのハードウエア上で多くのアプリケーションを動作させることになるが，
単に動作させるだけでなく，アプリケーション間の干渉がないようにすることが求められている。
そのためにはアプリケーションごとにリソースを制御しなければならない。　

---リソースの割り当てはOSが担うのではないのか
　その通り。だが汎用OS（WindowsやLinuxなど）では力不足だ。実行時に（プロセスごとの）
優先順位を付けることはできるが，一定量の（メモリー，CPU，ネットワーク帯域などの）
リソースをアプリケーションに確実に割り当てることはできないのが実情だ。状況によっては，
メモリー上のデータがディスクに書き出されてしまうこともある。そうなれば性能は大きく低下する。

---そうした問題をどうすれば解決できるのか
　“汎用OSを利用しない”というアプローチがある。それを当社では進めている。ハード
ウエア上でHypervisor（技術に基づいたソフト）を動作させ，その上にJavaVM専用のOS
「Bare Metal」（開発プロジェクト名），さらにその上でJavaVMを動作させる。そのよう
な動作環境において，JavaVMごとにリソースを確実に割り当てるという方法だ。汎用OSを
利用しないので確実にリソースを割り当てることが可能だ。JavaVMから見るとBare Metal
はOSに見えるが，汎用OSの機能は備えず，一つのJRockitプロセスを動作させるのに必要
な機能のみ提供する。

URLﾘﾝｸ(itpro.nikkeibp.co.jp)

25:デフォルトの名無しさん
06/05/19 21:08:00
>>24
つまりどうなるの？
VMとOSの間に仮想化ソフトをかますってこと？？

26:デフォルトの名無しさん
06/05/19 22:31:44
JRockitって、いつの間に無償になってたんだ

27:デフォルトの名無しさん
06/05/19 23:05:29
>>12
>>13
なんかあちこちで勘違いされてるっぽいけど、C#2.0の匿名デリゲートの
仕様は、(レキシカル)クロージャとして妥当だよ。レキシカルクロージャは、
(実行時ではなく)生成時の環境をキャプチャするので、>>12のリンク先の
ような挙動は、極めて普通。Schemeのlambda式によるクロージャや、
RubyのProcオブジェクトによるクロージャの挙動と基本的には同じ。

28:デフォルトの名無しさん
06/05/19 23:22:58
あと、C#の匿名デリゲートの振る舞いについては、langsmith MLの197から
始まっている議論が参考になると思う。

29:デフォルトの名無しさん
06/05/19 23:32:53
そもそもレキシカルスコープというもの自体が、プログラマの感覚から
離れててコンピュータの都合に合わせているもののように思う。

30:デフォルトの名無しさん
06/05/19 23:53:35
>>29
そういう考え方ができないとは言わないけど、歴史的に見れば、逆だと思う。
プログラマの都合に合わせるためにできたのが、レキシカルスコープ。
初期のプログラミング言語のほとんどが、グローバルスコープしか無い
のに対して、最近の言語のほとんどがレキシカルスコープを採用している
のも、それを示していると思う。

31:デフォルトの名無しさん
06/05/20 00:00:49
レキシカルスコープだけに歴史・・・いやなんでもない

プロパティサポートとか次世代の話続けて

32:デフォルトの名無しさん
06/05/20 00:16:20
じゃあ、プロパティの話を。プロパティ自体は、そんなに大きな変更ではない
と思うけど、どうやって取り入れるんだろうね。簡単に考え付くのが、Groovy
みたいにx.hoge -> x.getHoge()、x.hoge = y -> x.setHoge(y)とコンパイラが
変換するというもの。これなら言語仕様の変更は最小限で済みそうだし、
Java VMも変更する必要が無い。ただ、プロパティと同名のフィールドが
あった場合にどちらを優先するか、とかいくつか考えることはあるが。

33:デフォルトの名無しさん
06/05/20 00:34:59
>>30
すまん、Perlでいえばlocalとmyを逆に考えて書いてしまった....
レキシカル＝ローカルだよな。

しかし>>12の例で言えば、
delegate { Console.Write ("{0} ", i); };
ってのは、ループカウンタ i の値をクロージャというもんのコンストラクタに渡したような
もんであり、 i という変数を渡したわけじゃないんじゃないか？

i がそのまま参照として渡されたような印象をうけるC#の動作の方に違和感があるん
だけど。

34:デフォルトの名無しさん
06/05/20 00:36:55
またレキシカルの話題をかいちゃったので、プロパティの話も書くね。

おれはGroovyの@Propertyみたいなのを採用するのかな、と思う。
>>32のいうように、x.hogeとかいう部分はあくまでx.getHoge()のままで、
getter/setterの定義を「@Property hoge」みたいな感じで定義できる、
とかシンタックスシュガー的なもんなのかなあ、と。

35:デフォルトの名無しさん
06/05/20 00:40:53
モジュール化の話は詳細が出てたね。
共有ライブラリで、外部に提供する関数名を限定できるみたいに、
どのクラス、どのメソッドをエクスポートするか定義できるようになる
みたい。

パッケージにスーパーパッケージみたいなものを定義できて、そのなかに
複数のパッケージをまとめて、しかも外部から見えるのはこのクラスとこの
クラスね、とかやれるみたいだね。

Perlのモジュールと似たような感じかな？

一番よくわからん項目は「メソッドリファレンス」かなあ。これなんだろ。

おれは>>11に載ってる項目よりも、NIO2がいつになったら出るのかもう、
待ちくたびれるっつうの。はやくJavaからファイルのメタデータにアクセス
できるようにしてくれよ。

36:デフォルトの名無しさん
06/05/20 00:59:44
>>33
> delegate { Console.Write ("{0} ", i); };
> ってのは、ループカウンタ i の値をクロージャというもんのコンストラクタに渡したような
> もんであり、 i という変数を渡したわけじゃないんじゃないか？

レキシカルクロージャと言った場合、一般的には、まさにiという変数
そのものを渡すようなものを指す。もっと知りたい場合は、Schemeや
Rubyなどの、クロージャを持っている他の言語について調べてみると
良いと思う。

ちなみにこのような仕様になっていることによって、どんなメリットがある
かというと、例えば、次のような「制御構造」を抽象化したライブラリを
作れるという点が挙げられる。JavaやCなどの言語では、制御構造は
あくまで組み込みのものだけど、クロージャがある言語では、新しい
制御構造を提供するライブラリを簡単に作ることができる。

int sum = 0;
list.each(delegate(int i){
sum += i;
});
Console.WriteLine(sum);// listの要素の合計を出力

37:デフォルトの名無しさん
06/05/20 01:05:54
getとsetでプロパティがいいと思います

38:デフォルトの名無しさん
06/05/20 01:18:59
>>36
あ、なるほど、sumという外側のローカル変数そのものが渡っているというイメージね。
参考になったよ。逆に言えば、もともとアクセスできるものを引数で渡している>>12の
例が、ちょっと使い方を誤ってるということかな。

39:デフォルトの名無しさん
06/05/20 02:10:42
言語レベルでのXMLのサポートって、
E4Xみたいなもんが乗るのかな？

40:デフォルトの名無しさん
06/05/20 02:24:26
>>39
なんか、文字通りJavaのソースの中にXMLをそのままかけるらしいぞ。
イメージ的には

XML data = <test><dataset><key name="test"><value>test</value></key></dataset></test>

とかそのまま書けるって感じというか。
正直、まだ利点を見いだせない。シンプルなjavaを複雑にしてないだろうか？

41:デフォルトの名無しさん
06/05/20 02:28:51
VB9にも似たのがあった気が。
誰がつかうんだろう

42:デフォルトの名無しさん
06/05/20 02:29:20
Java的には、クロージャって引数の数によって識別されるRunnableが
あって、いままでいろんなものでそれぞれリスナを作ってたところを、
そういう共通的なRunnableを使って実装する、というイメージなのかな、

という気がした。

inputFile.eachLine( closure(String line) { 行の処理 });

ってなことだよね？

43:デフォルトの名無しさん
06/05/20 02:29:39
そんなん入れるならヒアドキュメント入れろ

44:デフォルトの名無しさん
06/05/20 02:31:34
>>40
またパ...

45:デフォルトの名無しさん
06/05/20 02:37:03
まあ

なんたら.execute(
new Runnable() {
public void run() {
ほげほげ
}
});

って長くてうざかったし、そのシンタックスシュガーを提供してくれる
だけでもうれしいかな。

Wicketだとこの手の書き方大量にするんで....
);

46:デフォルトの名無しさん
06/05/20 04:18:37
もうJavaの拡張はいいよーまた覚えることが増えるだけじゃん
こんなの初心者はついていけないぞ。教えきらん。

>>34
俺もそう思う。たんにgetter/setterの定義を書かなくて済むようになるだけで、
x.getXxx() が x.xxx と書ける訳じゃないと思う。そこまで気が利くとは思えん。

>>36
その例は「制御構造」とはいわないのでは？いうのかな？

>>40
はげどう。JSONサポートならほしいけど、XMLサポートはいらね。

>>43
うおー超はげどう。ヒアドキュメントはだれも要求しないのか？

47:デフォルトの名無しさん
06/05/20 04:46:50
>>46
いや、　 x.xxxだったらpublicのフィールドあったときかぶっちゃうじゃない記法ｗｗｗ

48:デフォルトの名無しさん
06/05/20 05:48:38
>>47
publicのフィールドがあればそっちをつかう、なければsetter/getterを使う、というルールでいいんじゃない？
あるいは逆に、setter/getterがあればそれをつかい、なければフィールドを探すか。
どっちにしろ、どうルールを決めるかの問題。
いらないけどね。

それより、配列や文字列の長さをELからも参照できるようになってほしい。
str.getLength()じゃなくてstr.length()だから、ELからはstr.lengthとは参照できない。
関数使わなきゃいけないのなんてかっこわるい。全然オブジェクト指向じゃない。

49:デフォルトの名無しさん
06/05/20 08:55:32
シンタックスシュガーでいいのでは？
だからべつにgetやsetをかくと重複していますというエラーがでればいい
isをどうするかは今でも同じ話だしな

互換性を考えればコレしかないかと

どのみちIDEの機能で意識はしてないけど、プロパティ扱いでまとめてくれると見やすいからね
折りたためるようになってくれればいい

50:デフォルトの名無しさん
06/05/20 09:32:17
>>36
その例は「レキシカル」クロージャの有益な例にはなってないよね。
クロージャの有益な例というだけで。

>>30
それは少し極端かな。両方の理由があった。
効率のいい実装、デバッグしやすい意味など。

51:デフォルトの名無しさん
06/05/20 09:45:30
>>48
そのlengthもプロパティで解決だね。

>>35
メソッドリファレンスは、
単純な(doAction()のみなど)Listenerを設定する時に、
extends ～Listenerなクラスを定義しなくても、
既存のクラスのメソッドをそのまま指定できるんでしょ、たぶん。

C++でいうところのstd::mem_fun_refじゃないかと。
boost::signalsと一緒に使ったりする。

52:デフォルトの名無しさん
06/05/20 11:16:08
>>40
そいで for (XML d : test.dataset[0].key) { System.out.println(d.key.value); }
とかアクセスできたらまんまE4Xじゃないか。俺的には超OK。

53:デフォルトの名無しさん
06/05/20 11:59:47
>>50
36だけど、例として挙げたプログラムだと、レキシカルクロージャの特徴で
あるキャプチャされた変数が無限の寿命を持つという点を生かしてない
という話かな？確かにその通りではあるんだけど、それを生かしたプログラムは、
Schemeではよく出てくるけど、C#ではオブジェクトがあればほとんどの場合、
代用できてしまうので微妙かなと思う。

54:デフォルトの名無しさん
06/05/20 12:02:43
>>52
その例を見て思ったんだが、もしかして、プロパティの導入目的は、
言語レベルでのXMLのサポートを、より効果的に行うためなのかも。

55:デフォルトの名無しさん
06/05/20 13:00:54
>>53
そう。あとdynamic bindingでも、lexical bindingでも同じ意味。

Schemeのようなクロージャは強力すぎるけど、
C++の式テンプレートくらいの機能は欲しいなあ。

C#の匿名メソッドは、>>12のページにあるように、
引数に与えられた式を使ってクラスを定義するみたいだから、
変数や関数の参照は、名前呼び出し風って事になるのかな。ちょっと使いにくそう。

> オブジェクトがあればほとんどの場合、代用できてしまう

まさに式テンプレートですね。
Javaに式テンプレート入れると、型システムのルールが、
クロージャの引き数のところだけ変わるから無理そうだけれども…

56:デフォルトの名無しさん
06/05/20 15:32:18
>>55
>そう。あとdynamic bindingでも、lexical bindingでも同じ意味。

確かにそうだね。というわけで、dynamic bindingじゃできない例を作ってみた。
クロージャの話でよく出てくる古典的な例なので、またかよって思うかもしれんが、
そこは見逃してくれるとありがたい。Converterってのは、.NET Framework 2.0
で入ったdelegate型で、ある型を受け取って別の型(同じ型でもいいけど)を返す
メソッドを表す型ね。

using System;
class TestLexicalClosure {
/* カウンタを作って返すメソッド */
static Converter<int, int> Counter(int start){
return delegate(int n){ return start += n; };
}
static void Main(string[] args){
Converter<int, int> counter = Counter(0); //カウンタを作る
Console.WriteLine(counter1(1)); // => 1が表示される
Console.WriteLine(counter1(2)); // => 3が表示される
}
}

> 引数に与えられた式を使ってクラスを定義するみたいだから、
> 変数や関数の参照は、名前呼び出し風って事になるのかな。ちょっと使いにくそう。

これは意味がよくわからなかった。もうちょっと詳しく言ってくれるとありがたい。

57:デフォルトの名無しさん
06/05/20 15:34:32
ミスった。counter1って書いてあるところは、counterの間違い。

58:デフォルトの名無しさん
06/05/20 16:49:51
もう、マクロでよくね？

59:デフォルトの名無しさん
06/05/20 17:32:29
>>56
class TestLexicalClosure {
int _start;
/* カウンタを作って返すメソッド */
static Converter<int, int> Counter(int start){
_start = start;
return delegate(int n){ return _start += n; };
}
じゃなくてもいいの?

URLﾘﾝｸ(blogs.msdn.com)
URLﾘﾝｸ(ant0x.udap.jp)
URLﾘﾝｸ(www.divakk.co.jp)

とか読むとめまいしてくるんだけど…

結論としてはC#のanonymous methodと同じものならJavaにはいらない。

60:デフォルトの名無しさん
06/05/20 17:57:00
>>59
55のコードで大丈夫。実行して、ちゃんと動作することも確認した。
あと、59のコードだと、複数のCounter()を複数回呼んで、複数個の
カウンタを作っても、カウンタの値が共有されてしまうので、まずい。
ポイントは、匿名デリゲートから参照されている外側のローカル変数は、
それが宣言されたスコープを抜けても生きているということ。

>とか読むとめまいしてくるんだけど…

>結論としてはC#のanonymous methodと同じものならJavaにはいらない。

俺はむしろC#のanonymous method的な振る舞いじゃないと嫌だなあ。
あと、anonymous method(というかクロージャ)の振る舞いに関して、
どの辺がめまいがすると感じた？

61:デフォルトの名無しさん
06/05/20 18:39:43
あのコードみて問題ないと感じるのがすごいな
なぜそうなるかは実装側の都合という状態

62:デフォルトの名無しさん
06/05/20 18:43:16
一番内側のブロックがクラスに変換されるの? > 匿名メソッド@C#
>>59の二つ目のページ読むとそんな感じなんだが。
>>56では、Counter()が一番内側のブロックだから、
引数は変換されたクラスのメンバ変数になるってこと?

63:デフォルトの名無しさん
06/05/20 20:30:15
>>61

>>59の3番目のリンク先は、仕様書のバグということで問題だと
思うが、1番目と2番目のリンク先の挙動は、本当に問題無いよ。
実装側の都合でそうなっていると勘違いしているようだけど、
レキシカルクロージャになるように匿名delegateを実装したら
そのような実装になったというだけのこと。あと、1番目のリンク先
の人はレキシカルクロージャという概念を勘違いしてて、コメント
欄で突っ込まれまくってる。

>>62
実装としては、一番内側のブロックが…とかいうのではなく、匿名
デリゲートから匿名デリゲートの外側のローカル変数を参照していた
場合、参照されている変数をメンバ変数として持つクラスが生成される
ということ。

64:デフォルトの名無しさん
06/05/20 20:37:29
>>63
いや、なぜそうなるか、は昔からいわれてたけど
それが本当に書く人が理解でき照るかというのとは別だと思う

書いた本人ならまだしも、他人のコードをさらっと斜め読みして
結果を予想できるかという割れると厳しいかも

65:デフォルトの名無しさん
06/05/20 20:45:13
>>64
> それが本当に書く人が理解でき照るかというのとは別だと思う

それは確かにその通りだけど、このスレではなんか、匿名delegateの
セマンティクスが実装の都合だという風に誤解されてるようなので、
それは違うんだと言いたかった。

> 書いた本人ならまだしも、他人のコードをさらっと斜め読みして
> 結果を予想できるかという割れると厳しいかも

レキシカルクロージャという概念に馴染みの無いユーザが驚く可能性は
あるかもしれないけど、よっぽどトリッキーな使い方をしてない限り、
どう動くかというのは、簡単に予想できるんじゃないかなあ。

66:デフォルトの名無しさん
06/05/20 21:19:49
二つ目のページで、
static D[] F() {
D[] result = new D[3];
int x;
for (int i = 0; i < 3; i++) {
int y = i * 2;
x = i * 2;
result[i] = delegate { Console.WriteLine(x + y); };
}
return result;
}
だと、[4 6 8](=[0 2 4]+[4 4 4])なんだろ?
変換結果のILはどうなるんだ?

メソッドb__0()は、xとyをどうやってaccessするんだ?
別のインスタンス内にあるはずだが…(宣言のある場所で閉じ込めるインスタンス生成)
それとも「一番内側の」ブロックで生成するインスタンスに全部含めるのか?
そうすると[8 8 8]か?

67:デフォルトの名無しさん
06/05/20 21:48:53
delegate自体C#の構文はよくないねぇ

68:デフォルトの名無しさん
06/05/20 22:27:16
>>66
ILを含めると長くなるので、その辺は省略して、宣言だけ示すと、大体こんな感じになる。
DisplayClass3のフィールドとして、DisplayClass1のフィールドを持っているので、b__0(匿名
デリゲートのコード本体)からはxとy両方にアクセスできる。

class <>c__DisplayClass1 {
public int x;
}
class <>c__DisplayClass3 {
public DisplayClass1 <>8__locals2;
public int y;
void <F>b__0(){/* 匿名デリゲートの中身が入る */}
}

というわけで、結果は[4 6 8]で正しい

69:デフォルトの名無しさん
06/05/20 22:36:35
苦労じゃなんて使うんかい

70:デフォルトの名無しさん
06/05/21 03:36:44
おればかだから>>12,27,33,36の話がよくわかんなくて、groovyでコード
>>12の参照先とほぼ同じ書いてみてやっと分かった。

def closures = []
for( i in 0..10) {
closures[i] = { println i }
}
for( c in closures) {
c()
}

結果は同じように10がずらっと表示された。
これは、closuresに入っている各クロージャは、クロージャ外側の変数 i に
そのままアクセスできるわけだけど、実際に実行されるc()の段階では、
i は既に10になっちゃってるから、これがずらっと表示されると考えて
やっとしっくりきた。

>>56は
def makeCounter( start) {
return { n -> return start += n }
}
def closure = makeCounter(0)
println( closure(1))
println( closure(2))

ってな感じなんで、つまりクロージャから参照された変数 start は、変数自体がスコープを
越えてもクロージャ内では普通につかえるし、クロージャがある限り存在しつづける、と。
インナークラスがエンクロージングクラスのインスタンス変数にアクセスできるようなもん
だけど、クロージャにはクロージャのスコープがあるので、一度クロージャが使った変数は
クロージャ内で存在し続ける、ということか。

71:70
06/05/21 03:37:53
groovyでコード>>12の参照先とほぼ同じ書いてみて
↓
groovyで>>12の参照先とほぼ同じコード書いてみて

72:デフォルトの名無しさん
06/05/22 23:01:22
んで、結局Dolphinで対応されるのは
どういう機能なわけ。まだ曖昧にも決定してない？クロージャって単語だけが歩いてる？

73:デフォルトの名無しさん
06/05/23 03:13:41
匿名クラスのシンタックスシュガーには間違いなさそうだな。

74:デフォルトの名無しさん
06/05/25 06:26:42
嬉しい誤算発見
JavaでのサブピクセルAAレンダリングはJavaのレンダリング使うからか
リモートデスクトップ経由でも有効だね
ピクセルの構成が一致してないとつらいとは思うが

75:デフォルトの名無しさん
06/05/26 01:39:14
プロパティマンセー

obj.setWidth(obj.getWidth() + 1)) なんて書かなくてもよくなりてぇえええ

76:デフォルトの名無しさん
06/05/26 04:15:52
じゃ、
obs.width = obj.width +1 ;
になるわけか・・・・
なんか、VBのProcedureみたい。(VB4の知識で書いてます悪しからず)

77:デフォルトの名無しさん
06/05/26 06:14:57
>>75,76
ほんとにそうなるの？
おれはgetter/setterの定義を書かなくて済むようになるだけだと思ってた。
ソースきぼん。

78:デフォルトの名無しさん
06/05/26 08:33:46
>>77
むしろそっちがソースｷﾎﾞﾝ。
getter/setter だけなんて、中途半端じゃん。

79:デフォルトの名無しさん
06/05/26 09:09:56
>>78
いや、ソースはない。「プロパティがサポートされる」と聞いて、どうせgetter/setterが自動生成される程度で、getXxx()/setXxx()は使わないといけないのだろうと思った。それだけ。

80:デフォルトの名無しさん
06/05/26 13:25:01
>>79
getter/setterの定義よりも、それらにアクセスするコードを書く回数の方が
圧倒的に多いので、getter/setter自動生成だけだと、新しい言語機構を
導入するメリットが少なすぎる。だから、たぶんアクセスするときの便宜も
図られるんじゃないかなあ。

81:デフォルトの名無しさん
06/05/26 13:54:31
こんなんもいけるんかのう？
obs.width++;

82:デフォルトの名無しさん
06/05/26 15:16:13
>>78
ライトアクセスとリードアクセスを区別して grep できないのはやだなぁ。

83:デフォルトの名無しさん
06/05/26 18:35:27
>>82
呼び出し階層の検索でいけるんじゃないの？たぶん。
あ、ごめん、これはEclipseの話だな。。。

84:デフォルトの名無しさん
06/05/26 23:12:33
とはいえピリオドでやっちまうとメンバ変数のwidthとgetWidthメソッドとの判断が難しいよな

obs@widthとかobs->widthとかなんか特殊な構文が追加なのかも
getsetかかせるよりはいいけどね

85:デフォルトの名無しさん
06/05/26 23:26:41
>>84
C/C++ で使われてる -> よりは @ に賛成。
Character.isJavaIdentifierStart('@') も false 返すみたいだし、
やろうと思えばできるのかな？

あと、JSR 295 見ると、converter や validator 使って何かやるみたいね？
obs@width = "120"; とかやると勝手に StringToIntegerConverter を
使ったコードを挿入してくれるのかな？とか妄想してみる。

86:デフォルトの名無しさん
06/05/27 00:14:26
245なんかのProperty Resolver APIが言語に入るんでしょ。
operator.のoverload。
Property Binding API, Method Biding APIなんかも。

87:デフォルトの名無しさん
06/05/27 11:49:33
>>80
Java��にそんな気の利いたことを望んではいけない。
ヒアドキュメントすらない言語だ、「互換性」を楯にして、最小限の使用追加だけですませるだろう。

しかしほんとに後付けの機能がふえるよな。もうぜんぜんシンプルな言語じゃなくなった。

88:デフォルトの名無しさん
06/05/27 11:58:45
プロパティに関しても1.1での後付考えかただし1.0はアルファ品質だったしな
それでもプロパティはEODでは？
用意するほうはIDEがやってくれるけど使うほうが原始的杉

Genericsは開発効率がよくなりバグが大幅に減るすばらしいものだが
落ちこぼれるやつが多数いる

この程度でおちこぼれるのならそいつはこの業種向いてないとは思うのだが
ひとつの判断材料にはなるかも

lockはsynchronizedのように専用構文がないと厳しいような
なんでもそうだが資源解法でfinallyあてにするのは苦しいよな

89:デフォルトの名無しさん
06/05/27 12:01:11
いますでにgetXXX, setXXXの存在を前提として作られているフレームワークが
やまほどあるので、基本的にはシンタックスシュガーになるんだろうな。

obj.prop = xxx とか書くにしても、バイトコード上では setProp(xxx)になってるとか。

90:デフォルトの名無しさん
06/05/27 12:07:39
そりゃそうだろ

91:デフォルトの名無しさん
06/05/27 12:21:18
>>88
俺はC++も好きなタイプなので、
Javaの言語領域で機能増えるのは嬉しい気持ちもある反面、
やりすぎて失敗しないのを祈りたい気持ち。
既に十分複雑だからね。抱えているプログラマ層を考えると。

92:デフォルトの名無しさん
06/05/27 13:03:03
Perlがあんだけ使われてるのみると、記号が増える分には問題なさそうだ。

93:デフォルトの名無しさん
06/05/27 13:36:50
ヒアドキュメントって、国際化対応とかどうするの？

94:デフォルトの名無しさん
06/05/27 17:59:29
それでなくても、ヒアドキュメントなんか、めったに使わないからな。
めったに使わないもののためにコンパイラ作りにくくすることもない。

95:デフォルトの名無しさん
06/05/27 19:15:47
ヒアドキュメントはあかんでしょ
なんでヒアドキュメントかっていうと基本的に書く側の都合じゃない
そこに書きたいっていう。
視認性は悪くなるし文法なんて無茶苦茶。
あれを使いたくなる理由は、簡易テンプレートエンジンとして使えるからだと思うんだけど
テンプレート処理がしたいんだったらIDEとか開発ツールのアシストで
何とかなると思うんですけどね。
ScriptingAPIと同じ扱いでいいんじゃないかと思う。
あれも構造が類推できないスクリプト言語がソースにヒアドキュメント形式で生で埋め込まれてたらと思うとぞっとする・・・

96:デフォルトの名無しさん
06/05/27 19:54:22
>>94
ちょっとまて、ヒアドキュメントごときでなんでコンパイラが作りにくくなるのだ？
あんなの、字句解析部をちょこっといじれば済む機能だぞ。
おまえ、コンパイラの作り方もわかってないだろ。

>>95
ヒアドキュメントで済むことをIDEとか開発ツールのアシストを使わなきゃいけないということに疑問をもたないのか。
HTMLページをまるごと埋め込むのならアホだけど、テストデータとその期待値を埋め込むのなら
ヒアドキュメントはすごい便利なんだけど。

つーか、「そんな機能必要ない」「IDEのサポートがあれば十分」とかいってるやつらって、実際その機能が追加されたら「これはEoDを実現するすばらしい機能だ」とか言い出すんだろ。
Genericsだって、最初は「C++のテンプレートは複雑だから同じような機能はJavaには必要ない」とか揃っていってたくせに、いざ実装されるとみんなGenericsマンセーなんだよな。
プロパティだって、今までgetterとsetterはEclipseが自動生成してくれるから問題ないとか言ってたくせに、それが実装されると「これは便利だ」とか言い出すんだぜ、絶対。
Javaにない機能は「そんなの必要ない」と言い切り、実装されれば「すばらしい進化だ」と手のひらを返す。ほんと学習しねーよな。

>>93
なんで国際化が必要なん？ふつうにStringリテラルと同じ扱いでいいじゃん。

97:デフォルトの名無しさん
06/05/27 20:01:41
ヒアドキュメント作るとして、懸念があるとすれば改行記号の扱いぐらいかな？

98:デフォルトの名無しさん
06/05/27 20:02:14
>>96
だから当時「いらない」と言ってた人たちは恥ずかしくなって黙ってしまって、
今度は別の人が別の機能に「いらない」といってる、くらいの想像力はないのか？
実際まったく同じ人だったらキモイだろう。

ヒアドキュメントはあれば便利だと思う。
一方でコンパイルされたバイトコードの中（つまりはclassファイル）の中に
そのヒアドキュメントの内容が埋め込まれるんだったらダサすぎなのでペケかな。

99:デフォルトの名無しさん
06/05/27 20:04:24
>>96
> 最初は「C++のテンプレートは複雑だから同じような機能はJavaには必要ない」とか
そんな阿呆な事言ってた奴は居るのか？

少なくとも俺は聞いたこと無いぞ。
erasure よりマシな実装方法もあったんじゃないの？って話なら結構聞いたけど。

100:98
06/05/27 20:07:46
あ、しかしまあ、String document = ""が自動生成されると考えると
さほどヘンでもないか。

しかし一方で、ヒアドキュメントってドキュメント中に変数値を簡単に
埋め込めないとあまり使い道がないと思うんだがどうだろうね。
式言語っぽく${変数名}なんてのを採用すると、式言語パースが必要に
なるかな。

101:デフォルトの名無しさん
06/05/27 20:15:06
Stringで生成されるなら%dとか%sでいいだろ
何のためのフォーマッタだ

102:デフォルトの名無しさん
06/05/27 20:25:12
それだとあとから変数をセットしなくちゃいかんじゃないか。

103:デフォルトの名無しさん
06/05/27 20:43:44
>>102
そういうことなら、ドキュメントの生成とその中の文章の埋め込みまで
やっちゃわないと駄目ね
>>96
そのアホが出てくるからコードのメンテナンス性が落ちちゃうんだよなぁ
でもそれは、コーディング規約でやらないようにさせるっていうのなら
ツール用意して・・・・っていう話と比べてもどっちもどっちだと思うが
他の言語で利用されて便利なヒアドキュメントのいいところだけをＪａｖａらしく取り込んでくれれば
いいとは思う。

特殊なコメント記法を入れて、コメントを識別子つけて参照できるようにするってのはどうかな？
/***
<html><body>
ほげひげは、${age}歳です
*/
あ、名前つけんのどうしよう

それよりは、特殊な改行付き文字列定義をかけた方がいいか・・・・
String document = '''
<html>ほべー
げれげれー
</html>''';
うーん、ターミネータがきめうちなだけのヒアドキュメントになったぞ。

104:デフォルトの名無しさん
06/05/27 23:11:41
>>96
> なんで国際化が必要なん？ふつうにStringリテラルと同じ扱いでいいじゃん。

そりゃそうだよね。
javacのソースの文字コード、
Shift_JISがディフォールトなのそろそろやめてくれないかな…

105:デフォルトの名無しさん
06/05/27 23:13:48
>>104
なにいってるの？

106:デフォルトの名無しさん
06/05/27 23:40:47
javacのソースの文字コードのデフォルトは、プラットフォームのデフォルトと
一致している予感。

107:デフォルトの名無しさん
06/05/27 23:41:29
>>104
LANG=ja_JP.UTF-8
export LANG

108:デフォルトの名無しさん
06/05/27 23:59:04
>>107
どこのJDKよ?

109:デフォルトの名無しさん
06/05/28 00:09:32
馬鹿が涌いてるな。

110:デフォルトの名無しさん
06/05/28 00:13:00
>>99
そうだね。Genericsに関しては、初期の頃からJavaプログラマの間でも、
Javaの欠点として言われていたし、Javaを拡張してGenericsを導入して欲しいという
提案も比較的初期の頃からあった。まあ、最近になってJavaにかぶれた人で、
ひょっとしたらそういう人は居るかもしれんが、ごく少数だろう。

111:デフォルトの名無しさん
06/05/28 00:47:29
オプションつければええやん
仕事でコード書くときは、普通レポジトリ中のロケール合わせて
ビルドオプションにもそれ入れておくでしょ？

まぁあの書き方からして>>106をしてるっぽいんだが・・・・

>>110
複雑でいらねっていわれてたのは、ポインタと演算子のオーバオードだという記憶だねぇ
それが、今度はとうとう . 演算子をオーバロードすることになるわけか・・・

112:デフォルトの名無しさん
06/05/28 01:26:57
Parameterized typeもいらないって言っていたヤツいたけど、総じて馬鹿だった。

113:デフォルトの名無しさん
06/05/28 01:46:46
演算子のオーバーロードまではいかないんじゃない？
Java 5がでたときのインタビューかなんかでも、演算子のオーバーロードは
Javaを複雑にするので入れたくない、とSunの誰かが答えてたはず（ソース見つからず）

プロパティを obj.prop = value で設定できるようになったとしても、それはオーバーロード
とは言わんと思うし（シンタックス・シュガーだよね）

Dolphinでオーバーロードをサポートするとか言う発表があったんだっけ？

114:デフォルトの名無しさん
06/05/28 03:11:55
>>99
Gosling自身が「いらない」と言っていたんだけど。Bill Joyは「parameterized typeがあればどんなにいいだろう」といってたけどな。
つか、ほんとに聞いたことないのか。それはいくらなんでも世界狭すぎだろ。
あれか、恥ずかしい過去はなかったことにしたがってる連中か。
EJBのときとかわんねーな。あれも推進派だった連中が今は「やっぱりEJB2は複雑だったよな、アノテーションマンセー」だもんな。自分たちがどれだけEJBを押し付けてきたのか忘れたらしい。
foreach文もそうだよな。foreach文なんていらね、Iteratorパターン最高といってたヤシばかりだったのにな。
ほんと恥ずかしい過去はなかったことにしたいらしい。

115:デフォルトの名無しさん
06/05/28 03:23:36
foreachは聞いた事ないけど

116:デフォルトの名無しさん
06/05/28 03:48:27
いやいくらなんでもEJB2が複雑じゃないなんて話は聞いたことがない。
EJB2じゃないけど、Strutsだって「あれは壮大なネタだろ」とか言ってたくらいで、全般的に
冗長なフレームワークは嫌われてたように思うが。

genericsでは何度か見たが、一方でMapがタイプセーフでないことに苦しめられたって
意見もあったわけで、バランスは取れてただろ。

Java言語をシンプルなままにしておきたいという希望は俺にもある。一方で、書くのが楽に
なって欲しいという希望もある。一人の中でもせめぎ合いがあるんだから、スレ内でどっちの
意見が出たって不思議には思わんがね。

117:デフォルトの名無しさん
06/05/28 03:56:09
>>96
ヒアドキュメントがあると、文脈自由文法じゃなくなってしまうからJavaCCとかのパーサージェネレータで作りにくくなるよ。

118:デフォルトの名無しさん
06/05/28 05:33:15
>>116
EJB2が複雑という意見はあった。しかし、それは一部の開発者のみ。EJBを推進する連中のほうがずっと多かった（理由は「それが標準だから」だとさ）。
Strutsだって同じだろ。雑誌記事みればわかるじゃん。どれもEJBマンセー、Strutsマンセー。
EJBやStrutsを明確に批判したのはRodやTateなどごく一部。日本じゃ皆無。

>>117
単純なヒアドキュメントは字句解析だけで実現できる。パーサはいじる必要ない。

つうかな、これだけ機能がごちゃごちゃ増えてるのに、ちょっと文法たすだけなのがなんで問題なんだ。
今のJavaはコンパイラ作るのがすごい面倒な言語になったけど、それは機能が増えたせいで構文解析よりあとが大変になったからだろ。
それにくらべたら、構文解析までなんて簡単。ヒアドキュメントの追加ぐらいわけない。
ほかにずっと大きな問題があるのを見ないふりして、「パーサジェネレータで作りにくくなる」なんてささいな問題をとりだすなよ。

119:デフォルトの名無しさん
06/05/28 06:11:10
>>118
少なくとも、ヒアドキュメントは「ずっと大きな問題」じゃないな。

120:デフォルトの名無しさん
06/05/28 06:38:50
>>118
つ URLﾘﾝｸ(mustang.dev.java.net)
時代は貴方を求めています。言い出しっぺの法則ってことでﾖﾛﾋﾟｸ

121:デフォルトの名無しさん
06/05/28 08:04:10
俺はforeachいらねーわ。

122:デフォルトの名無しさん
06/05/28 09:46:04
>>114
GoslingがGenericsをいらないと言っていたというのは、信じがたいのだが。ソース希望。
Java House MLのアーカイブやその他の場所で引用されていた過去のGoslingの発言を見る限りでは、
Genericsの導入には前向きだったように思える。

あと、世界狭すぎなのは自分の方なのかも、って考えは無いのかね。

123:デフォルトの名無しさん
06/05/28 09:53:24
>>118
Rubyにあるような、式を埋め込めるヒアドキュメントはパーザをいじる必要があるけどな。
実際のところ、ヒアドキュメントはあれば便利だろうし、使うだろうけど、そこまでこだわる
程の機能か？あと、そんなにヒアドキュメントが本当に欲しければ、こんなところで
ぐちぐち言ってるよりも公式に提案した方が良いかと。Genericsやその他の言語拡張だって、
要望が多かったから取り入れられたわけだし、ヒアドキュメントも場合によっては取り入れられる
こともあるかもしれん。

124:デフォルトの名無しさん
06/05/28 10:07:39
Goslingが否定的だったのは、
C++のtemplateの特殊化やC++,CLOSなどのgeneric functionだろ。
operator overloadはかなり初期から批判的。

Bill JoyとGoslingが"暴力沙汰"になりそうになったのは、
Billがgenericsはゆっくり考えることにして、generics抜きでJavaをshippingしようとしたから。
Goslingは、進行はJCP任せだけど、collectionのreliabilityを増すと積極的。
C/C++に対する大きなアドバンテージと考えているから。> reliability

URLﾘﾝｸ(www.gotw.ca)

125:デフォルトの名無しさん
06/05/28 10:24:43
>>124
本題からはずれるのだが、C++のgeneric function(=テンプレート関数のことか？)
とCLOSのそれ(=マルチメソッド)は全く意味合いが異なるのでは。前者は静的に
呼び出しが決定され、後者は動的に呼び出しが決定されるので。

126:デフォルトの名無しさん
06/05/28 10:44:44
性的か童的か違うと「全く意味合いが異なる」のか?
「関数テンプレート」が正式名称な。C++03で間違っている部分も修正。

127:デフォルトの名無しさん
06/05/28 10:51:28
>>126
全くというと言いすぎだったかもしれんが、少なくとも意味が異なるのは事実。
Javaのメソッド **オーバーロード** とメソッド **オーバーライド** が異なるのと同じ。
関数テンプレートが正式名称というのは、知らんかった。すまん。

128:デフォルトの名無しさん
06/05/28 10:56:49
>>124は、わざわざ"generic function"って書いているんだから、
クラスに属さない多相型の関数のことを言っているのは自明だよ。
性的なw特殊化はわざわざ別に書いているし。

129:デフォルトの名無しさん
06/05/28 12:10:38
>>128
言いたいことがよくわからないのだが、C++には関数テンプレートとは
違う、"generic function"があって、それは、CLOSのように、実行時に
オブジェクトの型に応じて、動的にディスパッチしてくれるのか？

130:デフォルトの名無しさん
06/05/28 12:49:01
"generic function"をCLOSの意味に制限して、
意味不明って言っても仕方ないじゃないの?

一般名詞としての"generic function"は、C++のWGでも出ているよ。
例えば、URLﾘﾝｸ(www.research.att.com)
generic programmingで使うparametric polymorphismを持った関数が"generic function"。

知らないのはよっぽどうとい人だと思われ。

131:デフォルトの名無しさん
06/05/28 18:45:57
>>130
いや、"generic function"をCLOSの意味に制限したいわけ
じゃなくて、CLOSのそれとC++のそれは意味が異なる機能なのに、
124が
> C++,CLOSなどのgeneric function
と、C++とCLOSのgeneric functionが同じ機能かのように言っていたので、
つっこんだだけ。

132:デフォルトの名無しさん
06/05/28 22:01:40
>>123
ヒアドキュメントはあくまで例のひとつ。
「そんな機能いらね」といってたくせにそれが実装されると意見を180度変えるJava屋さんが多すぎてうざいというのが主張内容。
JCPに提案しろとかポイントはずれてる。

133:デフォルトの名無しさん
06/05/28 22:29:35
>>131
> C++とCLOSのgeneric functionが同じ機能かのように言っていたので、

FUDかよw

次ページ