次世代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にも組み込まれる予定。 552 名前：デフォルトの名無しさん mailto:sage [2006/08/21(月) 23:20:07 ] よーするに、中途完了する匿名クロージャは、 値を返すクロージャと型の互換性が無いと拙いって事では無いかと。 値を返すメソッドを持った interface を書いて、 実際には必ず例外投げる匿名クラスを作りたいとする。 匿名クラスの場合は戻り値型があるから良いけど、 匿名クロージャは明示的に戻り値型を書けないっぽいので。 戻り値型を null にしておけば、どんな戻り値型のクロージャとも 互換性ができるのでは無いかと思う。たぶん。 仮にそーだとすると、null は void の上位クラスって感じになるのかな？ 553 名前：デフォルトの名無しさん mailto:sage [2006/08/21(月) 23:25:47 ] void の上位クラスっつーか、null は void と Object の上位クラスって感じか…… 554 名前：デフォルトの名無しさん mailto:sage [2006/08/21(月) 23:38:53 ] >>545には、そんな難しい事書いてない。 値nullが存在する限り、値nullには型が必要ってだけ。 closureの文法では陽に書く場合があるので、これを機会に導入。 もともと型推論的には必要だったもの。 555 名前：デフォルトの名無しさん mailto:sage [2006/08/22(火) 03:54:04 ] >>553 その辺はSubtypingのところに書いてあるな。 > A function type T is a subtype of function type U iff all of the following hold: > ・Either > 　・The return type of T is either the same as the return type of U or > 　・Both return types are reference types and the return type of T is a subtype of the return type of U, or > 　・the return type of U is void. （以下、引数型や例外に関しての条件が続く） 以下の条件の全てをみたすなら関数型Tは関数型Uの下位型である。 ・以下の何れか 　・Tの戻り型がUの戻り型と同じ 　・二つの戻り型が共に参照型であり、Tの戻り型がUの戻り型の下位型である 　・Uの戻り型がvoidである （以下、引数型や例外に関しての条件が続く） 556 名前：デフォルトの名無しさん mailto:sage [2006/08/22(火) 04:20:12 ] Referencing names from the enclosing scope のところ見ると、 匿名クラスの時みたいに final 付けろって書いてあるね。 557 名前：デフォルトの名無しさん mailto:sage [2006/08/22(火) 12:30:17 ] >>556 逆、逆。 匿名クラスのように、finalを*付けなくていい*と書いてある テキトーに訳してみると >> We do not propose a rule that requires referenced variables be final, >> as is currently required for anonymous class instances. 現在、匿名クラスのインスタンスに対して要求されているような、参照される 変数がfinalでなければならないという制約は提案しない >> The constraint on anonymous class instances is also relaxed to allow >> them to reference any local variable in scope. また、匿名クラスに対する制約も緩和され、スコープ内のどんなローカル変数も 参照できるようになる 558 名前：デフォルトの名無しさん mailto:sage [2006/08/22(火) 12:35:56 ] >>545 > 例えば Runnable と似たようなインターフェイス > interface MyInterface{ void method(); } があったときに > void() closure = (){ System.out.println("test"); > Runnable r = closure; > MyInterface m = closure; > とかされた時どーすんのかな？ とか思った。 closureをラップするクラスをそれぞれの代入に対して、自動生成すればいいんでない？ 　Runnable r = new Runnable_closure_bridge(closure); 　MyInterface m = new MyInterface_closure_bridge(closure); みたいな感じで 559 名前：デフォルトの名無しさん mailto:sage [2006/08/22(火) 19:35:52 ] >>557 あ、本当だ。嘘ついてすまん。 このスレの >>12 とかでも話題になってる変数の扱いとか、 どーなるんだろね？ 後は VM に変更なしで実装できるんか？とか。 560 名前：デフォルトの名無しさん mailto:sage [2006/08/22(火) 21:36:40 ] >>559 基本的には、ほとんどの機能はVMに変更なしで、コンパイラのみで 実装できると思う(ただし、クラスファイルフォーマットの変更は必要か？) ただ、クロージャの中からそれを囲む関数をreturnする機能 (Non-local transferの部分)はVM変更なしでやるのはつらそう 簡単に実装するには、例外を使えばいいだろうけど、それだと性能出ないだろうし 561 名前：デフォルトの名無しさん mailto:sage [2006/08/22(火) 21:38:12 ] >>560 自己レス > クロージャの中からそれを囲む関数をreturnする機能 クロージャの中からそれを囲む関数の外側へreturnする機能、の間違いだ 562 名前：デフォルトの名無しさん mailto:sage [2006/08/22(火) 22:11:08 ] Non-local transferは、p.5-6に記述がある。 その中でも>>560が心配しているケースはUnmatchedNonlocalTranser例外になる。 563 名前：デフォルトの名無しさん mailto:sage [2006/08/23(水) 17:50:22 ] journal.mycom.co.jp/articles/2006/08/23/java7closuer/ Javaにクロージャだって。 564 名前：デフォルトの名無しさん mailto:sage [2006/08/23(水) 17:57:58 ] 上を見てみろ 565 名前：デフォルトの名無しさん mailto:sage [2006/08/23(水) 18:05:27 ] ('A`) 566 名前：デフォルトの名無しさん mailto:sage [2006/08/23(水) 18:49:28 ] 苦労じゃ 567 名前：デフォルトの名無しさん mailto:sage [2006/08/23(水) 19:07:55 ] くだらん 568 名前：デフォルトの名無しさん mailto:sage [2006/08/23(水) 19:49:51 ] で、結局このクロージャ内からローカル変数は参照できるの？ それとも引数渡し？ 569 名前：デフォルトの名無しさん mailto:sage [2006/08/23(水) 22:18:36 ] 馬も出てないのになぜjdk7の仕様を気にするのか・・ 570 名前：569 mailto:sage [2006/08/23(水) 22:23:10 ] あ、ごめんここ次世代スレだった スレ間違った 571 名前：デフォルトの名無しさん mailto:sage [2006/08/23(水) 22:29:11 ] ん？なんでスレ違い？Java6はもうすぐ出るしここでもいいような・・・ 572 名前：デフォルトの名無しさん mailto:sage [2006/08/24(木) 00:48:51 ] Java6は、メンテナンスリリース色が高いからな。 今後も、偶数バージョンは小変更、奇数バージョンは大変更という感じになるみたい 573 名前：デフォルトの名無しさん mailto:sage [2006/08/24(木) 01:01:50 ] だが、あいかわらず5.0update8でエンバグとかやらかしてるからなんとも・・・ Java2DのOpenGLがWin環境でもちゃんと動作するようになってるかが見もの 574 名前：デフォルトの名無しさん mailto:sage [2006/08/24(木) 17:32:21 ] Java7でクロージャの導入か。 いまいちクロージャって理解できていないのだが、 「外側のメソッドのローカル変数にfinal がついていなくてもアクセス可能な匿名クラス」 が仮に認められたら、これはクロージャ？ 575 名前：デフォルトの名無しさん mailto:sage [2006/08/24(木) 20:48:36 ] >>574 ちょっと違うとおもう。 それよりもマルチスレッド下でローカル変数束縛するとスタック上の実体をコピーで解決するつもりだったらアウトだし ローカル環境を生かしておくとGCでメモリ断片化激しくなりそうとか厭な考えがよぎっちゃうんだけど、どういう風にするつもりなんだろう？ HotSpotがSelf由来だと考えればなにか考慮されているのだろうけど、関連論文とか乗っかっている書き込みとか見かけた人いる？ 576 名前：デフォルトの名無しさん mailto:sage [2006/08/24(木) 21:00:11 ] スコープを変数化するのがクロージャって感じかな。 ECMAScript触ってると特にそう思う。 577 名前：デフォルトの名無しさん mailto:sage [2006/08/24(木) 21:03:03 ] クロージャからのローカル変数のアクセスは暗黙的に排他すんじゃないの？ それよりスレッドにクロージャを渡すような使い方は俺はしたくねーな 578 名前：デフォルトの名無しさん mailto:sage [2006/08/24(木) 21:19:25 ] スタックを保存してヒープにもってくとかそんな感じ？よーわからんなぁ。 スクリプトだとthisの扱いがいつでもmixinって感じで使いにくいから クロージャ使わないとデリゲートにならないんだよな 579 名前：デフォルトの名無しさん mailto:sage [2006/08/24(木) 21:52:28 ] 文書読んでみたが、並行性については特に何もやる気ないみたいだね 必要なら今まで同様プログラマが対処しろって感じ 580 名前：デフォルトの名無しさん mailto:sage [2006/08/24(木) 22:47:06 ] Java in the BoxさんとこにJava 6では 「Server VM と Client VM の動的な変更」がサポートされるとあるんだけど これってSwingとかで文字列置換メソッドは Server VMでJITコンパイルできるとかそんなん？ 581 名前：デフォルトの名無しさん mailto:sage [2006/08/24(木) 23:46:44 ] クロージャはifやforの{}が引数と戻り値持った感じだと思う >>577 Rubyやってると割と普通な気がするんだが、どの辺がいやなの？ 582 名前：デフォルトの名無しさん mailto:sage [2006/08/25(金) 00:13:18 ] 匿名クラスでコンストラクタ定義できればそれだけでいいんだけどな。 583 名前：デフォルトの名無しさん mailto:sage [2006/08/25(金) 00:23:38 ] そんなことより、Genericsの仕様、 さらなる変化は無いのか？ パラメタライズドクラスを作るのが大変なんだが。 タイプセーフなため、配列と違って、List<Integer>はList<Number>のサブクラスにはできんし。 <>の中にさらに<>を入れ子に書いてとクラス設計が難しい。 パラメタライズされたクラスの継承でのパラメータの扱いといい、 慣れるのが大変。 584 名前：デフォルトの名無しさん mailto:sage [2006/08/25(金) 01:32:15 ] 解ってないんだけど、ローカル変数ってもともとスレッド毎でしょ？ マルチスレッドで、何の問題があるの？ スコープ抜けたときにスタックからヒープにコピーすればいいだけじゃん？ 585 名前：デフォルトの名無しさん mailto:sage [2006/08/25(金) 03:48:23 ] クロージャってC++にも追加されるんでしょ？ 流行ってるね 586 名前：デフォルトの名無しさん mailto:sage [2006/08/25(金) 06:38:13 ] >>584 そのスレッドで、Runnableなオブジェクトを作って クロージャを引き渡したらどうなると思う？ そういうこと。 また、今のListener系のような使い方をした場合、 マルチスレッドになるのは目に見えてる。 ただ、先の文書ではそこらへんは保証しないみたい。 主張を読むと、そういう場合は、今まで通り匿名クラスを使うか、 Javaで既に用意されてる並行性の仕組みを使えってこと。 なぜなら、そんなのを必要としない大多数の開発者には パフォーマンスが落ちるだけで有り難迷惑だから。 587 名前：デフォルトの名無しさん mailto:sage [2006/08/25(金) 06:47:06 ] >>583 つワイルドカード 　List<Integer> ints = new ArrayList<Integer>(); 　... 　List<? extends Number> nums = ints; //OK 588 名前：デフォルトの名無しさん mailto:sage [2006/08/25(金) 10:19:17 ] >>587 List<T extends Number> nums = ints; はだめなのか 589 名前：デフォルトの名無しさん mailto:sage [2006/08/25(金) 10:25:11 ] >>588 public <T> void aMethod() { List<T extends Number> nums; // } とかならTが型パラメータと分かるので可能だが、そうでなく唐突に Tが出ても未定義シンボルになる。 590 名前：デフォルトの名無しさん mailto:sage [2006/08/25(金) 10:26:20 ] と思ったら出来なかったorz 591 名前：デフォルトの名無しさん mailto:sage [2006/08/25(金) 10:45:45 ] >>582 いや、普通にできるが。 592 名前：デフォルトの名無しさん mailto:sage [2006/08/25(金) 21:40:02 ] インスタンスイニシャライザではダメなんですたぶん 593 名前：デフォルトの名無しさん mailto:sage [2006/08/25(金) 21:52:34 ] >>589 うーむ。Tの定義ってメソッドの頭かクラス宣言の後だったんだね。 継承使うとき、どうりで変だと思った class A<T> implements SuperA {} という表記はうまくいっても class A implements SuperA<T> {} はうまくいかず未定義といわれる。 当然、 class A implements SuperA<T extends Number> { は怒られる class A implements SuperA<?> { も怒られる。 594 名前：デフォルトの名無しさん mailto:sage [2006/08/25(金) 23:08:22 ] 変なのはおまいの頭だと思うよ… 595 名前：デフォルトの名無しさん [2006/08/25(金) 23:21:55 ] いきなりむかつくこといいやがったなおめえ。 確かにgenericsにはまだまだ慣れていないが、 情報が少なすぎていつもGenericsで悪戦苦闘して こっちは大変なんだよ。 しかし、Genericsでパラメタライズされたクラスを 作ってる奴は少ないんだな。 2chでも稀なほうか。 C++Templateとは似てるようで違うためか、 使いこなせない奴も多いもんだな。 596 名前：デフォルトの名無しさん mailto:sage [2006/08/25(金) 23:34:05 ] >>595 情報とか言う以前に仕様書を読めよ。 あと class A implements SuperA<T> {} なんか A を使うときにどうやって T が型パラメタか 普通のクラスか見分けるんだよ。少なくとも class A<T> implements SuperA<T> {} とやらないとパラメタ指定できないだろ。 597 名前：しろうと [2006/08/25(金) 23:59:55 ] ちょっと質問なんですが、クロージャが実現できると、何がウレシイのでしょうか？ 実行時評価するわけじゃなくて匿名インナークラスのSyntaxSugar＋α程度のもの でしかないのなら、別にどっちでもいいんじゃねえのとおもうんだが。 ここのところ、大々的に言語仕様かえるといっといて、結局やってることは プリコンパイラにどっちでもいいだろという機能を追加してる程度のケース が多いようなのだけど、どういう圧力からそういう結論になるのでしょうか。 後方互換を保つために妙な妥協して、あるべき論と掛け離れた中途半端な仕様 を差し込むくらいなら、何もしないほうがいいと思うのは私だけデスカ？ 598 名前：しろうと [2006/08/26(土) 00:09:24 ] >>595 別に無理に使わなくても、ちょっと頑張れば同じことができてたから じゃないの。 おいらの場合、コードがコンパイラ依存になるのが嫌なので、当分セ コセコデリゲートクラスとか自作して頑張ってくつもりです。 599 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 00:15:01 ] 関数型のメリットは多いよ ・delegateの実装が楽（クロージャ） ・スクリプトフレームワークの拡張がしやすくなる ・継承では補いきれない差分プログラミングが可能（保守性向上） 600 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 00:17:08 ] >>597 > どういう圧力からそういう結論になるのでしょうか VMにでかい機能を追加すると遅くなるだろ。 しかしGenericsの仕様はいくらなんでもあれだが。 601 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 00:20:42 ] >>598 Javaは私企業のプロダクトだから結局C#対抗な訳よ マイクロソフトに負けたくないっていうSunの言語ｵﾀの意地とｵﾅﾆｰ 602 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 00:22:15 ] .classみたいな感じで.methodってできるようになったら良くない？ ってとっくに議論され、破棄されたんだろうが。。。 いまでもリフレクションでできるけど面倒なんだよね。 メソッドにアノテーションつけた時に参照するのも obj.getClass().getMethod("method1").getAnnotation(anno); とかだぜ。タイプセーフの意味がない。 これが method1.method.getAnnotation(anno); となりすっきり。。。 603 名前：しろうと mailto:sage [2006/08/26(土) 00:24:17 ] >>601 Javaもめでたくオプソになるらしいし、そのうちC#コンパイラとか 出るんでねえのかなとか思う毎日。…って、APIのサポートがむずいかな。 604 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 00:26:39 ] ECMA標準のC#なら余裕だろ SUNもJava VMを.NET化させるつもりだし 605 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 00:29:14 ] Sunっていつも後手後手だよね 606 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 00:30:09 ] 夏休みもそろそろ終わりなのになぁ。。。 607 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 00:32:42 ] >>605　？？？ 夏だな 608 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 00:36:37 ] もうJavaもおわりだなと感じる今日この頃 609 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 00:37:49 ] JavaOneの聴講者数は年々増加の一途なのだが 610 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 00:38:56 ] >>608 そう思われる様になってからが華 611 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 00:40:26 ] >>609 それに比例して、馬鹿がますます増えてきたな。 612 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 00:41:08 ] Java人口の増加と先進性は反比例 613 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 00:42:48 ] >>602 Hoge.classがClass.forName("Hoge")の言語糖衣だと知った時はショックでした。 614 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 00:47:55 ] >>597の感想はもっともだよな 後方互換を気にしながらC#の後追いしてるくらいなら 新たな言語環境を提案してくれないかな もっともSunにもIBMにも無理そうだな 615 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 00:49:30 ] >>613 ちがくないか？ Class<Hoge> c = Hoge.class; と Class<?> c = Class.forName("Hoge"); でしょ？オレが間違って覚えてるのか。。。？ 616 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 00:49:58 ] > 新たな言語環境を提案してくれないかな 100%ぽしゃるから。今の時代はライブラリ＞言語仕様 617 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 00:58:11 ] >>615 日本語は間違って覚えてるね。 618 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 01:00:31 ] >>615 でそのGenericsも糖衣な訳だが 619 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 01:02:44 ] Javaの欠点はGUIライブラリの貧弱さ 620 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 01:04:00 ] >>619 Swingの実装感は.NETのライブラリとたいして変わらんと思うが。 問題は性能なのか？ 621 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 01:06:06 ] >>618 そういえばそうか でも.classリテラルはforName()とは使用場面が異なると思うんだが それでも糖衣っていうのか。 622 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 01:08:42 ] >>621 Hoge.classはコンパイラ通すとClass.forName("Hoge")に コンパイルされるってこったよ。 623 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 01:11:59 ] >>620 クライアントアプリを作るにはまだまだ たとえるならXToolkitレベル 標準のFontChooserとかGridControllerとかなんで出てこないんだろ 624 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 01:13:48 ] >>623 目指すはVBなわけですな…かくてまた馬鹿が増えるのかorz 625 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 01:15:39 ] バッドノウハウとグッドラッパーの話だなこりゃ 626 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 01:19:50 ] 目指すはVBてか、GUIはある程度統一されるべきな訳よ GnomeやKDEのようにね あるアプリで選択した色やフォントは、別なアプリでも使いたい そのためにはJavaももうVMだけじゃなくて バックグランドで常駐するサービスレイヤーが必要だと思うのね 627 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 01:21:54 ] >>626 >バックグランドで常駐するサービスレイヤー Java6ってそれじゃなかったっけ。 628 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 01:22:08 ] >>622 syntax sugar ではあるが Class.forName("Hoge") にコンパイルされるわけではない。 >>623 Swing って SWT/JFace の対応で言う SWT の方 (基本機能) であって 高機能なコンポーネントは自作するorどっかからライブラリを探してくるor買う もんだと思うんだが。 629 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 01:22:19 ] ブラウザがAPIいっぱつでデフォルトをぽんって出すから そのうちメーラーとかコンパネとかフォントダイアログとか そういうのもネイティブで出るんじゃないか 630 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 01:22:22 ] >>622 しつこいようだが、なんでジェネリックスだけ違うのかわからん。 Class<Hoge> c = Class.forName("Hoge"); がコンパイルしないのは何故？.classだとokなのに。 eraserとかってやつ関係かな？ 631 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 01:26:57 ] >>623 それだといつまでたっても統一環境ができない アプリは自作でいいが、サービス層はもっと充実させるべき 632 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 01:29:16 ] >>630 そういう場合こんな感じじゃなかったっけ Class<Hoge> c = Class.<Hoge>forName("Hoge"); 633 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 01:31:05 ] >>629 ブラウザが基盤だという発想には違和感感じっぱなしの私。 あれは明らかにアプリでしょうに… 634 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 01:33:30 ] >>632 よくわかんないけど forName使う意味なくない？ forNameはコンパイル時にはclassが見えない時につかうんじゃね？ Hogeが手元に無い時とかさ。 635 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 01:37:21 ] >>634 そこは一応名前と実際のクラスは別もんということで、、、 クラスローダによってはほんとに別にできると思うけど 636 名前：このネタ書いた人 mailto:sage [2006/08/26(土) 01:48:59 ] 正直どうでもいいんだけど Class hoge = Hoge.class を含むクラスをSunJDKのjavacでコンパイルして、javap -c してみると、 invokestatic Method java/lang/Class.forName:(Ljava/lang/String;)Ljava/lang/Class; になるわけなんだが、俺なんか勘違いしてる？ 637 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 02:03:04 ] まあGUIについてはJavaは約20年遅れてる ってことでおやすみ 638 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 02:06:03 ] >>636 バージョンは？ 確かにどーでもよいが。 639 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 02:08:48 ] >>638 手元のJDKは1.4.2_10。5.0は持ってないのでどうなるかシラン。 640 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 02:12:02 ] >>639 1.4までは.classは.forNameと同等 1.5からは扱いが変わったってことかな？ なんでかえる必要があったのか、というのは考えない事にします。 641 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 02:35:30 ] どうでもいいことだが、 1.5 からはクラスリテラルではクラスが初期化されない。 642 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 03:13:55 ] >>599 自分も、スクリプトフレームワーク側からの要請が 結構でかいんじゃないかと思う。 .NETなIronPythonは結構速いみたいだし、JythonとRhinoも速くなって欲しいな。 643 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 03:19:24 ] >>601 というけど、C#のようにはならんと思う。 C#とくらべかなりTypesafeだと思われ。 それだけにGenericsではパラメタライズされたクラスを 実装するのが難しいが。そのかわりタイプセーフが保証されるので パラメタライズドクラスを便利に、かつ安心して使うことができる。 マイクロソフトに負けたくないってのとはちょっと違う。 っていうかJavaはもうSun私企業のプロダクトじゃなくなってるよ Java Community ProcessによってだれでもJavaの変更について参加できる。 実際に変更するかどうかはゴスリングあたりが決めるが。 それも、JavaがC++の二の舞にならないようにするためさ。 644 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 03:20:37 ] >>604 > ECMA標準のC#なら余裕だろ > SUNもJava VMを.NET化させるつもりだし それは初耳。ソースはどこにある？ .NET化というのは.NETと共用するの間違いではないかと予想する。 645 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 03:21:39 ] >>614 ？　ゴスリングが新しい言語を作りたいとかいってなかったけか？ 646 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 03:23:52 ] >>611 JavaOne聴講者に馬鹿が増えたと？ 去年JavaOneTokyo2005に行ったときはそうでもなかったが。 綺麗な設備に恵まれた東京国際フォーラムを全部貸し切って、 金のかかったイベントだなって気がしたけど。 647 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 03:24:08 ] >>612 夏っぽい発言だね 648 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 03:25:30 ] >>620 >>619は古い時代のSwingのことを言ってるだけかもしれないよ。 649 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 03:27:08 ] >>624 ちょっと違うな。 Java Studio CreatorがVB屋向けっていうけど あれはなんだか、Dreamweaverに似てる。 デザイナにJavaを憶えさせたいという無謀な考えがSunに あったのだろうか。 それでもCreatorの完成度は高いけどね。 しかしメモリ食うしかなり重たい・・・ 650 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 06:47:46 ] なんか開発環境と実行環境がごっちゃになってる香具師がいるようだが？ 651 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 06:49:35 ] >>648 では聞くけど新しい時代のSwingって何？ 652 名前：デフォルトの名無しさん mailto:sage [2006/08/26(土) 11:25:56 ] >>651 Java5とかJava6のSwingじゃね？ もしかしたらJava1.4.2かも知れんが。 少なくともJava1.2やJava1.3のSwingでないことは確か。

---

---

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

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