次世代Javaの動向　２

1 名前：デフォルトの名無しさん mailto:sage [2006/05/18(木) 01:03:42 ] 前スレ 【Java】次世代Java・J2SE1.6の動向【Mustang】 pc8.2ch.net/test/read.cgi/tech/1081698555/ 関連スレ 【JavaFive】C＃からJ2SE5.xへ進化【TigerShot】 pc8.2ch.net/test/read.cgi/tech/1094891986/ www.itmedia.co.jp/news/articles/0404/07/news018.html マルチタスク実現へ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にも組み込まれる予定。 285 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 12:35:22 ] >>261 なにも考えずに下手に導入するとC#やC++の二の舞となるぞ。 どうしてもそういう機能が欲しければ C++やC#で実装して貰うように頼むか自分で実装するという手もありだな 286 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 12:41:34 ] ああ、実引数の間違いね。 Closureを実装するにあたって、 JVMの仕様を変えるという話は出てきてないから、 ほとんどsyntax sugarみたいなもんなはずだけどね。 というかinner anonymous classがほとんどclosureみたいなもんだし。 finalが外れるとしても、primitive typeの扱いはどうするのか… 287 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 12:43:31 ] >>285 つーかクロージャができる今となっては>>268でいいでしょ。 拡張forは黒歴史だ。 288 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 12:51:02 ] >>286 JVMの仕様を変えないでも、「本物の」クロージャは実装できるよ。 あと、キャプチャされる変数がprimitive typeかどうかは、クロージャ 実装するにあたっては、特に関係無いはずだけど、何か問題ある？ 289 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 13:10:14 ] outer classのslotは、 closureに埋め込んだouter class instansの thisを介して参照すれば書き換え可能だけど、 引数はちょっと面倒じゃない? > primitive Method内でclosureが使われる時、 first class closureが外に持ち運び出されれて使われる時、 複数のclosureからprimitive typeが参照される時の扱いなど。 まあコンパイラが頑張れない問題ではないけれど。 そういうprimitive typeは、 別のinner anonymous classでwrappingすればいいんだから。 290 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 13:38:10 ] ローカル変数も基本型だとスタックフレームにあるから、 オブジェクトでラップしとかないといけないよね。 外に持ち出して複数のクロージャから参照されるかもしれないから。 291 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 19:17:14 ] >>289 それは、クロージャからouter classのフィールドを参照しているか outer scopeのローカル変数を参照するかによる違いであって、 primitive typeかどうかは関係無いのでは？クロージャから outer scopeのローカル変数を参照可能で、かつ、クロージャから その変数が変更可能なようにする場合、基本型かどうかに関わらず、 オブジェクトでラップする必要が生じると思うんだが。 292 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 19:54:33 ] >>283 あのースクリプト言語ってGroovyだけじゃないんですが・・・ スクリプト言語への対応って言語の定義はされてなくて、APIの定義なんですよ。 おそらくそこを勘違いされていますよね？ 今あるスクリプト言語だけじゃなくて将来出てくる言語もこのAPIに沿ってライブラリを 用意すれば使えるっていうフレームワークです。 293 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 19:57:25 ] 今までずっとコンパイル言語はデリゲート、スクリプトはクロージャって漠然と思ってたけど もしかしてもっと高尚な概念だったのか？ｗ 294 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 20:04:53 ] スコープがどこにあるかで変わるような気もするが デリゲートっていうのはクロージャーよりもっと大きな範囲を表すことばじゃないか？ 295 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 20:05:00 ] >>293 別に高尚というほどのものではないが、ある言語がコンパイル言語かスクリプト言語 かどうかと(この区別の仕方も問題大有りだがそれは置いとく)、その言語がクロージャ を持っているかどうかは全く関係が無いことは確か。あと、デリゲートってたぶんC#の デリゲートのことを言ってると思うんだが、あれはMS用語であって、C#のあの機能に 対する用語としては全く一般的じゃない。 296 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 20:09:16 ] D言語もdelegateだろ？そのうち次世代標準になると思うが 297 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 20:30:15 ] >>296 逆に言えばC#,Dしか無いんだと思うが。しかも、時系列からして、D言語で delegateって呼んでるのは、C#での呼称をまねたんだろう。次世代標準に なるかは知らないけど、delegateはあまりセンスがいい機能だとは思えん。 298 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 21:55:27 ] delegateといえばそんな名のproxyを思い出すのはもうおじちゃん世代なんでしょうか・・・ 299 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 22:47:03 ] >>291 outer scopeのローカル変数を参照している場合、 クロージャオブジェクトとは別のオブジェクトでさらにラップする必要があるでしょ。 複数のクロージャから共有される場合は必ず。 基本型じゃなければ、実はポインタが指しているわけだから、 複数のクロージャオブジェクトから共有するのは自然にできるけれど。 300 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 22:49:22 ] プログラミング言語で、"delegate"を最初に聞いたのは"actor"かな。 301 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 23:20:27 ] >>299 > outer scopeのローカル変数を参照している場合、 > クロージャオブジェクトとは別のオブジェクトでさらにラップする必要があるでしょ。 > 複数のクロージャから共有される場合は必ず。 これは特に異論を言ったつもりは無い。というか、クロージャのセマンティクスを 考えれば、至極当然だわな。 > 基本型じゃなければ、実はポインタが指しているわけだから、 > 複数のクロージャオブジェクトから共有するのは自然にできるけれど。 これはおかしい。クロージャから共有しているのは、ローカル変数その ものであって、変数の値じゃないのだから、ローカル「変数」に対する 変更をクロージャ間で共有するためには、基本型じゃなくても クロージャオブジェクトとは別のオブジェクトでラップする必要があるはず。 302 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 00:12:04 ] 「これはおかしい」以降が分かりません。 ヒープに浮いているオブジェクトを共有していれば十分かと。 303 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 00:38:40 ] >>302 クロージャによって共有されるのは、参照型変数が指している先の オブジェクトじゃなくて(もちろんオブジェクトも共有されるけど)、参照型変数 そのものなので、オブジェクトだけが共有されても変数そのものが共有されないと、 クロージャAで参照型変数aの指している先を変更した後(ここで、オブジェクトの 中身を書き換えるのではないことに注意)、別のクロージャBから同じ変数aを 参照したときに、クロージャAによって変更される前のaの参照先を指している、 というようなことになってしまう。 304 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 06:54:29 ] >>302 >>32 の int sum = 0; list.each(delegate(int i){ sum += i; }); で、sum が java.lang.Integer、クロージャの中が sum = new Integer(sum.intValue() + i); だった場合に、オブジェクト共有じゃだめでしょ。 305 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 08:13:48 ] Javaなら「クロージャいらね、無名クラスで十分」でお願いします。 そしてクロージャが実装されたあかつきには「やはりクロージャは便利だ、すばらしい」でお願いします。 306 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 08:21:39 ] まぁ、使ってみなきゃわからない便利さってのもあるしな 307 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 09:15:16 ] >>305 さすがにクロージャに関しては、無名クラスで十分というのは あり得ない気がする。特に無名クラスを制御構造の抽象化 (内部イテレータなど)に使うのは、冗長過ぎる。複数のメソッドを持っている オブジェクトの場合は、無名クラスの方がいい場合もあるとは思うけど。 308 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 09:16:38 ] >>305 あいかわらず分析力のないｗｗｗ 309 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 12:16:34 ] >>308 別に分析なんてしてないんじゃない？ Java vs ○○系のスレで何度も起きていることを そのまま書いただけでしょ。 310 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 13:29:23 ] は？　意味がわかりませんな あんたのいってることは 311 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 14:37:40 ] 分からないならレスしなくていいよ。 もうちょっと勉強してからどうぞ。 312 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 14:39:51 ] くだらん煽りだ 313 名前：デフォルトの名無しさん mailto:sage [2006/06/08(木) 14:40:54 ] >>312は>>310宛 314 名前：デフォルトの名無しさん mailto:sage [2006/06/09(金) 03:16:58 ] ★ネタは分かりやすく★ >>305 は Javaユーザが、Generics導入前には「いらね」と言っていたのに 導入されたら「Genericsネ申」と褒め立てるJavaユーザをクロージャにも当てはめ シニカルな笑いにしたネタ( ´ー｀)y-~~ >>308 は それをむしろJavaユーザの立場から自嘲的に笑いにしたネタ もしくは、単に>>305 の諧謔を理解せず笑ったﾉ(´д｀*) レス >>309 は それをJavaユーザに対する真っ向非難と受け止めた 瞬間湯沸かしレスヽ(`Д´)ﾉ >>310 もう喧嘩と聞いちゃ黙っちゃいられない江戸っ子レス (ﾟ∀ﾟ　)三　三(　ﾟ∀ﾟ) >>311 それに便乗した野次馬 (　´･∀･`)ﾔﾚﾔﾚｰ そんな感じですかね。 315 名前：デフォルトの名無しさん mailto:sage [2006/06/09(金) 08:43:32 ] >>314 つまり、TemplateイラネをGenericsイラネにいまだに脳内変換してるバカってことか。 だれもGenerics神とか言ってねぇし。 スマソ、>>314自体が、そういうバカを装ったネタだったか。 316 名前：デフォルトの名無しさん mailto:sage [2006/06/09(金) 10:13:17 ] >>313 いやどうみても>>311宛なんだが 317 名前：デフォルトの名無しさん mailto:sage [2006/06/09(金) 10:14:20 ] >>315 まさにその通りだ。 たまにこのスレにでてくる馬鹿はC#厨とかＣ言語厨とかの 類だろう 318 名前：デフォルトの名無しさん mailto:sage [2006/06/09(金) 13:15:36 ] Javaに要望されていたのはC++のtemplateじゃなくて、たんにparameterized typingじゃないの？ その意味でいえば、templateもgenericsも同じようなもんだけど。 あれか、templateイラネといっていた手前、genericsが導入されて引っ込みがつかないから 「genericsはtemplateとは違う、tempalteはいらないけどgenericsはマンセー」 といっしょうけんめい言ってるだけか。 大事なのは型引数がつかえることであって、コード生成なのかただのキャストなのかは あんまり関係ないんだけど。 319 名前：デフォルトの名無しさん mailto:sage [2006/06/09(金) 13:25:58 ] >>318 だから、導入したときにgenericsって名前にしたんだろ 320 名前：デフォルトの名無しさん mailto:sage [2006/06/09(金) 23:16:20 ] 俺の記憶じゃ、入れる前はどんなものか決まってなくて C++のtemplate「みたいなの」が入るってことになってて勝手にﾜｲﾜｲやってたと思い 321 名前：C++厨 mailto:sage [2006/06/09(金) 23:32:26 ] C++風なのは入れないというのが暗黙の合意だったと思われ あまり型システムは詳しくないけど、 Modula-3とかOberonの流れを汲むんじゃないの? 多重継承やオペレーターオーバーロードなし。特殊化なんてもちろんない。 322 名前：デフォルトの名無しさん mailto:sage [2006/06/09(金) 23:54:27 ] タイプセーフenumパターンによるenumの実装は俺からしてみれば懸命だったと思うけど ifよりswitchだみたいな風潮がまだあるのか、余り普及して内容に思える 323 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 00:05:13 ] タイプセーフenumの実現も可変長引数の実現も拡張forの実現も みなGenericsのお陰で可能になったことなんだよ。 Genericsを導入するまでこれら三つを導入するわけにはいかなかった。 324 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 00:06:11 ] >>322 どういうこと？ enumはswitchでかけるし 325 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 03:17:28 ] 次世代Javaスレなのに5.0で導入された機能の話ばっかりでつまらんので、 投下してみる。 JavaにContinuation（継続）機構は必要か？ blogs.sun.com/roller/page/gbracha?entry=will_continuations_continue 俺はあんまり良く知らないんだけど、SchemeとかRubyにはContinuationという 機能がある。これは言うなれば、メソッドを呼び出す時に「おまえ、自分の処理 が終わったらこれを呼べよな」とクロージャを渡してしまう感じだろうか。 もちろんクロージャは（ちょっと前に話題に出てたけど）その時のスタック状態 さえも保持してるので（スコープから外れても、クロージャ内ではまだローカル 変数にアクセスできる、とか）、一種のlongjumpとして働くってことですな。 （というか、そこまでしか分からんかった....） リターン値を見てから処理を決めて....という処理が不要になって、プログラムは シーケンシャルにどんどん突き進めるという利点と、呼び出し元じゃなくても一気に 復帰できる上に、その時のスタック状態まで復元してしまうという、いわば「スタック フレームごとあとで使うから保存しちゃえ」という強力な機能なんだってな。 なんだかContinuation-based Web Serverとかいうものもあるらしい。 で、この機能がJVM（JavaじゃなくてJVMだよ）に必要かどうかという議論。 リンク先ブログの人は、「ウェブアプリはAJAXとかで遷移の少ない方向へ移って いってる過渡期で、移行が完了したらContinuation-based Web Serverの利点は 過渡期の遺物になっちゃう可能性があるし、JVMの大改造が必要だしセキュリティ モデルに影響を与えるからイラネ」といってる模様。 いろんなサイト見て、Continuationは便利そうだが、正直分かりにくいし使いどころ が難しい気がするので、俺もｲﾗﾈ、という感じだな。 326 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 03:43:38 ] JVMみたいなスタックマシンには継続は辛い。 欲しい新機能は、switchの代替になるようなパターンマッチング。 ラベルにGOTOするんじゃなく、値を返す奴がいい。 int result = match<Integer>(obj) { 　A : execute(); return 0; 　B : return -1; 　default : return 1; } って感じの。 327 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 06:24:44 ] >>325 細かいところだけど、ちょっとツッコミをば。 > これは言うなれば、メソッドを呼び出す時に「おまえ、自分の処理 > が終わったらこれを呼べよな」とクロージャを渡してしまう感じだろうか。 これは、継続渡しスタイル(Continuation Passing Style)と呼ばれるテクニックで、SchemeとかのContinuation とは違う。SchemeとかRubyにある継続ってのは、call/ccと呼ばれるもので、1引数の関数を引数としてcall/cc を呼び出してあげると、その関数を「call/ccの呼び出しが終わった地点に制御を移動するような関数」を 引数として呼び出してくれるという感じ。Javaっぽい文法で書くと、大体下のような感じになる。 このプログラムっぽいものを実行すると、ABCBCと表示される。 Continuation process() { 　Continuation result = null; 　System.out.print("A"); 　call_cc(new Function(){ 　　public void call(Continuation c){ 　　　result = c; 　　} 　}); 　System.out.print("B"); 　System.out.print("C"); 　return result; } ... first = true; Continuation c = process(); if(first){ first = false; c.jump(); } System.out.println(); 328 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 10:34:32 ] その前にproper tail call optimization可能なVMかな。 329 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 10:57:52 ] >>324 コンパイラがifに展開するんだとさ int&switchによる高速さはenum&switchにはない 330 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 11:15:29 ] >>329 Enum.ordinal() 使ってint型にして switch するだけなんだけど。 この話も Mustang にも Dolphin にも関係ないね。 331 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 11:17:43 ] ん？実装が変わったのか？ 332 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 11:29:36 ] >>329 >>330 俺もifに展開してると思ってた(というか、記憶が正しければ、 1.5のαかβではほんとにifに展開してたはず)のだが、今の実装は 確かにswitchを使うみたいだね。下のコードをコンパイルして、 逆アセンブルしてみたら、確かにEnum.ordinal()を使ってswitchする コードに展開されてた。 public class TestEnum { 　enum AnEnum {A, B, C} 　public static void main(String[] args){ 　　AnEnum a = AnEnum.A; 　　switch(a){ 　　　case A: System.out.println("A"); break; 　　　case B: System.out.println("B"); break; 　　　case C: System.out.println("C"); break; 　　} 　} } 333 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 18:15:07 ] >>332 実際にどう実行されるかは JVM 側のオプションでも変わって来るんじゃなかったっけ? 334 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 18:43:02 ] >>323 >タイプセーフenumの実現も可変長引数の実現も拡張forの実現も >みなGenericsのお陰で可能になったことなんだよ。 なんで？ for (String str: list) { 　... } を for (Iterator $it = list.iterator(); $it.hasNext(); ) { 　String str = (String)$it.next(); 　... } に展開するだけだと思うんだけど、Generics関係なくね？ 335 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 18:59:16 ] >>324 おまえはtype safeという意味がわからんのか？ 336 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 18:59:49 ] >>320 おれの記憶だとparameterised typingが希望されてて、その例としてC++のテンプレートが挙げられていた。 C++のテンプレートそのままが欲しいやつっていたのかな。欲しかったのはあくまで型引数がつかえることじゃない？ でも昔はGenericsとかGeneric Programmingという言葉はあまり浸透してなかったから、 話としては「テンプレートみたいなのが欲しい」という表現がよく使われていた。 つまりC++のテンプレートが欲しいんじゃなくて、型引数が欲しかったということ。 だから >>172 >いっておくがC++のtemplateとJavaのgenericsとはまったく別もんだよ。 のようなのには、なんというか話がずれてるように思える。 どっちもparameterized typingなんだからおんなじじゃん？実現方法を問題にしてるんじゃないんだよ。 C++のtemplateは否定してJavaのgenericsは肯定してるやつらって。 まあいつものことか。 337 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 19:12:04 ] >>336 templateを否定してgenericsを肯定してるやつらは template固有の話を問題にしているんだから、 >>336と話が合うはずがないよ。 とｵﾓﾀ。 338 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 19:15:50 ] >>336 実現方法を問題にしてたんだよ。 339 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 19:18:29 ] 6.0って構文に関するなんかって変わるっけ？ 5.0と7の間にあるバージョンだから、印象が薄すぎて・・・ 340 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 19:23:50 ] 5と7の間だとなぜ薄いのかよく分からない 341 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 19:33:15 ] そらおまえ、GenericsだのXMLリテラルだのキモイ仕様てんこもりじゃないか 342 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 19:37:36 ] >>335 流れおかしくないか？ 343 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 19:44:29 ] >>340 5と7は変更が大きいからね。 6はもともと5.1になる予定だったわけだし。 344 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 19:55:18 ] 5.0は言語仕様の変更は大きいけどAPI的に1.4とくらべてたいした進化はない せいぜいコンカレントまわりくらい ６は結構大きい変更が多いので楽しみ 中でもSwingの大規模修正はびっくりなくらいでは？ 345 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 19:57:32 ] あのバタ臭い見た目は何とかして欲しいけどな。 346 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 20:22:20 ] デフォルトのLAFはSystemLAFでいいようなきがするな 347 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 20:22:49 ] お前はバタ子さんに恨みでもあるのか 348 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 23:06:59 ] >>344 Swingの大規模修正ってどんなの？ あんまり詳しくないので純粋に聞いてみる。 最近Swingに興味を持ったもので.... 349 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 23:50:35 ] >>334,335 foreachに関してはともかくtype safe enumは Genericsのおかげで「簡単になった」。 タイプセーフの実装は、自分で色々書けば出来たよ。 Effective Javaとか読んでみないか？ 350 名前：デフォルトの名無しさん mailto:sage [2006/06/10(土) 23:53:57 ] >>348 えーっと、漏れは>>344じゃなくて何が大きいか何とも言えないが、 個人的に助かってるのは ・GroupLayoutの搭載 ・WindowsLAFの改善 ・サブピクセルAAレンダリング あたりかな？中では最適化がかなりゴロゴリありそうだけどよくしらない。 351 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 00:05:12 ] >>349 type safe enumを定義するのに、Genericsはほとんど使わないわけだが・・・。 352 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 00:06:10 ] enum A{ ONE, TWO, THREE} のどこでGenericsがいるのだろうか。 353 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 00:19:01 ] >>351 >>352 Java 5.0のAPIドキュメント見ればわかるけど、列挙型の基底クラスである java.lang.Enumの定義自体にGenericsが使われているよ。 354 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 00:23:07 ] >>353 Effective Javaのtypesafe enumの実装みたことあるのか? 355 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 00:37:25 ] >>350 一番大きいのはAWTスレッドがとまっていてもウインドウが描画されることかと あとはJava2DでOpenGLパイプラインがLinux系でデフォになるようでクライアント分野も DirectX使ってるWindowsに速度的に追いつくかなと ただ、5.0のOpenGLサポート見てると非常に期待が出来ないのだけれども JOGL使ってるなら大丈夫かな つーかJOGL標準APIにしてください >>354 そういうこといってるわけじゃないだろ？たぶん 356 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 00:49:22 ] >>354 そりゃもちろん見たことある。というか、何故Effective Javaのtypesafe enumの 話になる？Java 5.0のtypesafe enumがEffective Javaのそれが元になっている のは知ってるが、全く同じというわけじゃない。 357 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 01:00:42 ] >>356 そりゃGenericsがなくてもtypesafe enumが作れるからだろ GenericsがないとJava 5.0と全く同じものはつくれないけど typesafe enum自体はつくれる Genericsのおかげで作れたなんて変だって話でしょ 358 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 01:18:45 ] >>357 いや、そりゃtypesafe enum自体はGenericsが無くても作れるけど、 Enum同士のcompareToによる比較などが型安全にできないでしょ？で、>>349は そういうのを指して > foreachに関してはともかくtype safe enumは > Genericsのおかげで「簡単になった」。 と言っていると思ったんだが。あ、もちろん>>323の言っている ことは変だと思ってるけど、>>351や>>352は>>349に対する言及 だと思ったので。 359 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 02:07:13 ] Generics とか enum とか、Tigerで追加された機能の話題はこっちでやったら？ 【JavaFive】C＃からJ2SE5.xへ進化【TigerShot】 pc8.2ch.net/test/read.cgi/tech/1094891986/ 360 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 02:50:30 ] いいんじゃないの？ここで。 361 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 03:31:27 ] Generics とかは現行世代の機能だから次世代スレでやるのは筋違いでしょ。 362 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 04:28:00 ] 流れってもんも大切だし、極端に筋違いなわけではないし、そもそもこのスレの「次世代」というのは、Mustangスレの次スレをTigerスレでやろうかという意見があったときに、じゃあ次世代Javaというスレをたててまとめてというのがあったわけだし。 363 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 04:29:13 ] それに、enumとかGenericsとかについて意見が食い違うという時点で、次世代ということにしてもいいと思うわけで。 364 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 08:59:34 ] >>358 compareTo以外に何かある？ 365 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 13:03:25 ] なんか一人genericsが嫌いなやつがいるようだな 366 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 15:11:08 ] >>325 それはWeakest Post Conditionという奴か？ ならば、Template Method パターンまたはアスペクト指向で 実現できまいか？ 367 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 15:15:06 ] >>334 展開する前の前処理にGenericsが関与してるに1バイト 368 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 15:23:10 ] >>351-352 EnumクラスのJavadocを見ると Enum<E extends Enum<E>> 使われて無くはない。 Genericsが使われているかいないかで Javaのenumの仕様がかなり異なってくる。 C/C++のようなtype unsafeなenumにするわけにはいかないから Genericsを導入するまでenumを導入するわけには いかなかった理由がよくわかる。 369 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 15:24:19 ] >>357 Genericsのお陰で作りやすくなった 以前より比較的正しいenum実装ができるように なった、とでも言うべきだろう。 370 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 15:29:58 ] >>364 equals(), clone(), hashCode(), toString(), valueOf() 371 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 15:47:30 ] >>362 そのMustangの話題ですらないわけだが。 372 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 15:55:01 ] 今後はもうベンチマークに期待できなくなってくるのかな Swing周りの改良は今後も進むかもしれないけど、業務では変わらない？ JVM統合の流れになっていくのかな 373 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 16:14:19 ] >>367 くわしく 374 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 17:15:01 ] >>372 業務でSwing使えばいいじゃない すでに社内システムはWEBアプリは衰退していてリッチクライアントが普及してきているよ 不特定多数ならWEBアプリだけど、開発効率が段違いにわるいので コスト増が問題になってるという感じ 375 名前：デフォルトの名無しさん [2006/06/11(日) 20:23:42 ] 今更であれだけど、Genericsっていいの？ コンテナに間違ったモノ突っ込むなんてバグはもとから経験無いけどなぁ。 376 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 20:50:16 ] キャストが要らないからそのままメソッド呼べたり、すっきりするってのが一番の恩恵でしょ。 377 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 20:58:09 ] 自分だけで作ってるとあまり恩恵はないね 他人の作ったコード呼ぶ部分でListとだけ書かれてると困るので助かる JavaDocとか整備されてないライブラリとかで泣きながらソースよんで苦労することが減った・・・ List<Map<Key,Value>>とか業務系だと頻繁に使うしね 大規模開発こそ結合部のドキュメント系が必要なのに整備されている率が低い傾向にあるのはどういうことだろう ウォーターフォールの出来上がってくる設計書類にそんなものがまったくないという 少人数でライトウェイトな開発していればまずインターフェース作りましょうとかドキュメントは 大事なところだけ書いてあとはJavaDocにガンガン記述していきましょうとかそういうのが多いな とりあえず何も考えなくてもよくなるEnumはかなり恩恵があるのは確かだが 378 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 21:09:27 ] >>370 valueOf はそうだけど、他は関係ないような気がするよ。 379 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 21:13:13 ] >>377 そのList<Map>構造の部分、今度はXMLになるかもね また構造わかんねｗｗｗｗ 380 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 21:16:08 ] >>375 例えばMapでキーや値の型を仕様変更した場合に、 根っこの一箇所変えれば コンパイルエラーがどこを直せばいいか教えてくれるのが楽。 ってのもある。 381 名前：デフォルトの名無しさん [2006/06/11(日) 21:18:59 ] >>372 JVM統合って何？ 382 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 21:23:26 ] -serverオプションが消えるとか 383 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 21:36:46 ] >>375 間違ってダウンキャストしなくて済むし いちいちドキュメントにこの型にはこれ以外入れるなとか 書かなくて済む。 384 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 21:38:12 ] >>378 Enumの中に入れ子になっているオブジェクトの型が一致しなかったら あれなのでequals()とか、hashCode()も重要 385 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 23:04:03 ] 業務系のソフトウェアでは、Mapの中にMapが入っていて、しかもそのMapの要素は Listが３つ、なんてざらにある。 で、そのListに何が入っているのかはドキュメント化されてないし、うっかりしてると Mapを入れるべきところにListを入れてしまったり....と、orzになる機会は山ほどある。 genericsについていろいろ言われているようだけど、Collectionフレームワークの型 安全性を高めるという点について「ｲﾗﾈ」と言ってたﾔﾂを俺はしらないな。 Goslingﾀﾝもそこをとても重視していたみたいだよ。ソースが見つからないがそんな こと言ってた。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef