次世代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にも組み込まれる予定。 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ﾀﾝもそこをとても重視していたみたいだよ。ソースが見つからないがそんな こと言ってた。 386 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 23:19:53 ] genericsいらないって言っていた馬鹿は探せばいるだろ。 どんな馬鹿でもいるもんだから。 そんな馬鹿が手のひらを返してgenerics便利だと言ったところで一体なんだというのだ? 387 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 23:21:55 ] しかし今頃この話題が出てきたということは6が出そうなこの時期に やっと5.0つかった開発がスタートしはじめているということだろうか 388 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 23:24:02 ] >>386 何でもない いや、それがこの話の結論のはずなんだが それで納得できない暴れたい盛りのやんちゃ坊主がたくさんいてな・・・ 前向きでない議論は無駄。 現行Genericsの不備点を挙げて、こうなればいいのに・・・とかいう話ならまだ広がるんだが・・・ 389 名前：デフォルトの名無しさん mailto:sage [2006/06/11(日) 23:31:53 ] >>387 そろそろドカティもJava5に入り始めるんじゃない？ 390 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 00:03:01 ] >>389 ・)ﾉｼ 1.3で開発してるドカティが来ましたよ こんな太古のアプリ改造するくらいなら新規で作れよそもそも設計からして腐ってんだからさぁとか言いながらコード書いてますよ 5で書きたいよぅ>>377が言ってる問題にぶちあたりまくりで元からバグバグなコードいじる度にビクビクしなきゃならんのは嫌だ 391 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 00:18:57 ] >>390 そういうなおいらは去年ようやく1.1から1.4へのUpgradeに成功した 2年ほど前に出した見積がようやく日の目を見たって所だ 392 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 00:26:07 ] 保守的な奴らが居るとうんざりするときあるな 1.4.2で作ってるんだが、_??の部分までぴったり合わせるよう指定が来る いやいや、それってバグフィクスのバージョンだろと突っ込みたくでも突っこめない 仮にバグっててもそれのお陰でうまく動いてるのを当てにするんだろうな 393 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 00:27:19 ] >>391 なんか生き残れるのか心配になるようなローペースさだな。 394 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 00:50:10 ] >>389 J2SE5.0使ったシステム2つうけてるけど、ついていける人とついていけない人がやはり現れますな 勉強し理解する人は5.0すごくよくなってるといい、勉強しないで分からないというだけの人は なんでこんなバージョンにしたの?といってくる 知的労働者なんだからまったくついていけないようだったら首を切るのを勧めたほうがいいだろうね そういうのはだいたいCOBOLメンテしてきてVBやってる人に多いかと思えばそんなことはなく COBOLもしってCもやれてJavaもきっちりしってる人も割と多い 言語の得て不得手をしっかりと理解できているかどうかはが大事 逆にJavaやCでずっとWEBアプリ業務でやってきましたという人種でもかなり危険なやつらが多い 1メソッド数百行をスコープ範囲狭めることなく平気で書くのが特徴だから分かりやすいといえばそうなのだが 395 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 01:34:52 ] >>392 涙が出るほど共感を覚えるが、スレ違いではあるまいか 396 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 01:46:24 ] 雑談スレだし、いいんでないの？ 397 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 02:19:45 ] いったいいつから雑談スレに.....orz 398 名前：デフォルトの名無しさん [2006/06/12(月) 03:55:55 ] _XXを気にするなんて、まともな所なら常識だろ。 _XX変えたらテストやり直し。保守的とかじゃなくてブロの常識。 399 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 04:23:10 ] まともなところとかまともじゃないところとかは関係ないと思うな。 常識かどうかも。 そこまでの信頼性が求められるかどうかだと思われ。 信頼性もとめるなら、まだJava2SE5.0は使えないんじゃないかな。 400 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 04:32:56 ] ただ、障害が出たときのサポートと、サポート期間考えると最新使わないわけにもいかない 5年単位の利用期間に対して、それ以前にSUNのサポートが切れるJVM使うのもできないし・・・ 1.4.1のGCのバグで散々な目にあったよ・・・orz しかし、Tigerはそろそろ使えるようになってると思うんだが・・・ Mustangが出るってのに2世代前しか信頼できないって状況はないんじゃない？ というか、信頼性なんて自分たちで確かめるもんだし。 401 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 05:56:32 ] ハイエンドのサポートはSunだけじゃないからな。 自分達で確かめれる程度の信頼性なら、自分達で確かめればいいと思う。 402 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 06:13:52 ] 使う範囲で信頼できれば十分だからね。 403 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 10:58:35 ] >>398 それにかかるコストを誰が払っていると思っているんだ。 誰も払わなければやるだけ無駄でSunに踊らされているだけだろ。 ちょっとバージョンアップしたくらいでまたそのバージョンに 遭わせて無駄に過剰テストして無駄に管理を厳しくするのは コストの無駄。テストの自動化もできない奴がそういうことをしたがる。 404 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 11:09:35 ] 自分の常識が世の中全体の常識と思ってるヤツがいるな。 405 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 11:24:21 ] >>403 問題が出てからの対処で良いならその考え方もあるが 何でか知らないが開発会社に全てのコストを押し付ける顧客が多すぎるよな やって欲しいならそれに見合う金を払えってんだ 406 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 12:30:30 ] >>403 おまいは、安かろう(品質)悪かろうのシステムしか経験がないのかも知らんが、 それを一般化するなよ。>>399の言う通り、どこまで品質が求められるかどうかがポイント。 自分の基準で過剰テストだの無駄だの、安物PGにしか見えないからあまり言わない方がいいよ。 だいたい、テスト自動化となんの関係があるんだか…。 407 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 13:19:56 ] >>406 ひとこと言わせて貰うと、お前は考え方が古い。 20年くらい前のCOBOLerが大好きながむしゃら管理手法で やっている。 Java5でないとうごかない製品ももうすでにかなり出ている。 すでにJava5は実績としてはかなりのものだ。 408 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 13:39:06 ] もはや Generics の話題ですらないな。 説教したい/されたいならマ板でどーぞ。 409 名前：デフォルトの名無しさん [2006/06/12(月) 13:45:06 ] おれはJavaSE5が使えんとは書いてないが…。 運用トラブルリスクはそっちのけで安価・短期が最優先という考え方もアリだろう。 だが、システムの必要品質を確保するのに、古いも新しいもない。全然理屈になってないよ。 そんな事言ってると、底辺PGとバレるから気を付けた方がいいぞ。 というか、テスト自動化されてんなら、テストやり直しに何でファビョってんの？ 410 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 15:26:14 ] 商用アプリサーバのＳＥ５のサポートって 最近じゃない？ やっとベンダにとって、サポートコストがぺイするレベルに枯れてきたって事か。 411 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 15:34:32 ] どっちがファビョってるんだか。 たまにJavaすれにVBあがりのドトネト厨が 割り込んで来ることがあるけどそれ系の厨かなw 412 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 15:36:07 ] >>410 商用じゃなきゃ信用できない なんていったらLinuxがアップデートされるたびに 過剰テストにものすごく無駄に時間をかける羽目になるんだが。 Java5の枝番号が変わっただけでその都度細かいテストするのも まさに効率悪い。 413 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 16:19:10 ] 全員スレタイ見直してくれ・・・頼む・・・orz

---

---

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

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