[mustang/Java SE 6] 次世代Javaの動向 4 [dolphin]

1 名前：デフォルトの名無しさん mailto:sage [2006/11/20(月) 10:38:16 ] 前スレ [mustang] 次世代Javaの動向 3 [dolphin] pc8.2ch.net/test/read.cgi/tech/1157227790/ 次世代Javaの動向　２ pc8.2ch.net/test/read.cgi/tech/1147881822/ 【Java】次世代Java・J2SE1.6の動向【Mustang】 pc8.2ch.net/test/read.cgi/tech/1081698555/ 2006年12月にMustang Java SE 6がリリース予定 Mustangの掲げる主な目標は以下の点にある。 * 互換性と安定性および品質の向上 * Easy of Developmentの実現 * WebサービスおよびXMLサポート機能の拡張 * リソース管理や診断機能の強化 * デスクトップ環境の強化 Java SE 6 じゃじゃ馬ならし www.javainthebox.net/laboratory/JavaSE6/ 369 名前：353 mailto:sage [2007/02/14(水) 15:23:15 ] いや、Java側から考えるのでなくて、 C++のコードがあるのですが、 GUI部分を１つ定義してWin、MAC、Linux全対応したいです。 そのときにC++側からSwing画面を開けるのかなー？、と。 370 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 15:26:58 ] JNIはC++ APIもあって、データのやりとりも出来るので、 GUIをSwingで作って、エントリとなるメソッドをC++から キックすればOK。 371 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 15:39:37 ] >>364 Java2以前ってことはSwingというよりJFC? XMLスキンは、恐らくSynthLookAndFeel >>353 やりたいのは、NeoOfficeのやってることだな GUI描画部分を、Javaにやらせるという 372 名前：353 mailto:sage [2007/02/14(水) 15:43:18 ] MACでもJNIを簡単に作れますか？ 373 名前：353 mailto:sage [2007/02/14(水) 15:45:00 ] NeoOffice見ましたが、MACのみ。 クロスＧＵＩとして使われてるわけじゃないんだ？ 374 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 16:34:17 ] MacOSXにおいてJavaは標準サポートされてるし、JNI関係のヘッダもツールも ある。C++コンパイラはg++。 製品バンドル版OSXなら一緒にg++を含んだ開発環境(Xcode)メディアも付いて くるし、無料でダウンロードも出来る。Java環境の最新バージョンは1.6.0。 antも入ってる。 375 名前：353 mailto:sage [2007/02/14(水) 16:42:45 ] じゃ、Javaで画面作って、C++コードはg++でコンパイルすれば宵ってことかぁ。 ”Java＆C++”の開発効率がちょっぴり不安。 376 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 17:04:19 ] >>366 Swingの勉強をする。 377 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 17:35:14 ] >>375 俺はやったけど、両方わかってりゃ大した事は無かった。 つーても、やっぱc++からjavaオブジェクトを返すのにJNIEnvを使う部分があるんで、そこはちょっと効率悪いかな。 あとJNI部分のデバッグが面倒なんで、c++でロジック書いてJNIで薄くラップしてやる感じ。 java側は、ちゃんとMVCに分けて、DAOをしっかり分離してやりゃOK。 テスト用DAOに差し替えて開発して、最終的にJNIを使ったDAOでテストする。 まー規模にもよるだろうが。 378 名前：353 mailto:sage [2007/02/14(水) 17:38:49 ] ｻﾝｸﾂ>>377 DLLコールと比べて、さらに効率悪いのかなぁ？ 出来上がったアプリはやっぱりモッサリ？ 379 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 17:51:13 ] 次世代Javaの動向と関係ない話題は他所いってやれ。 380 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 17:53:03 ] 次世代Java＝C++と連携 ですが、何か？ 381 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 17:54:42 ] ところで、次世代Javaというか有力候補のウィンドウライブラリって何？ Swingって落ち目な感じ？ 382 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 18:03:33 ] Swingは1.4以降実用レベルになってしまったから、 SWTとかの代替候補の立場が微妙になってるのが現状じゃね? 383 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 18:12:19 ] あ、SWTが落ち目なんだ知らなかった。 知らないうちに勢力図が変わるんですね。 それと、デファクトだったEclipseがＳ∪∩の開発環境（何だっけ？）に負けたんでしたっけ？ 384 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 18:20:25 ] 其処までは行ってない。 むしろ、SWTの活躍の場は、eclipseしかない、という感じ。 Netbeansは、Jackpotがどうなるか、か？ 誘導 Java 高速GUI SWT　3 pc10.2ch.net/test/read.cgi/tech/1164877399/ Java低速GUI Swing 5 pc10.2ch.net/test/read.cgi/tech/1161139809/ 【Java】NetBeans Part2【Sun】 pc10.2ch.net/test/read.cgi/tech/1154582593/ 385 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 18:27:26 ] オライリーだっけ 去年の勝ち組負け組みでEclipseを最初負け組みと書いて後で消したの 一番使われてるのに負け組みはおかしいといわれたそうだが 386 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 18:41:27 ] ふ〜ん じゃぁ、NetBeansとSwing使っとけば問題無いか。 Windows上だとちょっぴりモタツクだろうけど。 でも、モッサリドトネト（流行ってないくせにWinForms、WPFと２つあって最悪）よりかはましか。 387 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 18:42:36 ] ごめん、もう一つ教えて。 NetBeansがEclipseをやっつけたってことは、 JBuilderとかは無用の長物？ 388 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 18:50:15 ] ごめん、さらにもう一つだけ教えて下さい。 以前のSwingではレイアウトマネージャのおかげで、 思ったように画面作り難かったのですが、 今のSwingはポトペタしやすいですか？ 389 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 18:59:48 ] >>388 NetBeans(の5以降で導入されたMatisseというデザイナ)を使うと無茶苦茶ポトペタしやすい。 と、漏れは個人的には思っている。 390 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 19:11:20 ] >>380 JNI なんぞは、1.1 の頃には既にあったわけなんだが…… 誘導 ★お前らJavaはJNIで組もうぜ★ pc10.2ch.net/test/read.cgi/tech/1033795664/ 391 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 19:14:29 ] >>388 個人的には、GUIポトペタ(←(・∀・)ｲｲ!!)は、Netbeans。 ロジック書き書きは、eclipse。 両方使ってるよ。 NetbeansのSubversionプラグインは使いにくいし。 392 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 19:24:34 ] じゃ、Netbeans使います。 CVSはWinCVS（←もしかしてサイアク？）使ってるんで。 JNIもふつーに使われてますか？ 393 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 19:27:48 ] 誘導 【Java】NetBeans Part2【Sun】 pc10.2ch.net/test/read.cgi/tech/1154582593/ 394 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 19:57:46 ] 名前のないメソッドつくろうぜ。例えば、 public class ArrayList<E> { 　　public nameless E (int index) { return get(i); } 　　//その他省略 } のように書いて String s = list(2); //listはArrayListのインスタンス みたいにインスタンス名(引数)の形で呼び出す。 他にも、Mapなら public nameless E (K key);と書いて String s = map("key0");とか、 さらに、オーバーロード可能にすれば他にも使い方ができそうだ。 395 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 20:06:55 ] >>394 じゃあ標準出力はSystem("%d%d", 100, 200);でOK？ 396 名前：デフォルトの名無しさん [2007/02/14(水) 20:18:36 ] 関数呼び出しのときの表現を変えるのをアノテーションで定義するのはどうだろう @Alias(value = "ltgt" , type = "literal")//自作リテラル（ここでは<>） @Alias(value = "plus_equal" , type = "operator")//演算子オーバーロード これで実装するなら>>394は @Alias("nameless") ってとこか んで、呼び出す対象のフィールドの宣言時も@AliasUsingをつける。 まぁ設計がまずいのに無理やり使わされるのもあれだしね。 397 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 21:33:06 ] > それと、デファクトだったEclipseがＳ∪∩の開発環境（何だっけ？）に負けたんでしたっけ？ その文字を見たら昔のSunのCMを思い出した。 398 名前：デフォルトの名無しさん [2007/02/14(水) 21:45:16 ] 396だけど、だめだな。 細かい仕様を定義しようとすると複雑になるし、いかに丁寧に仕組みを作っても雑に使われたら困るもんな。 よく使われるやつだけ今のString型みたいにして、アノテーションで限定解除するだけでいいか。 399 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 22:40:43 ] >>394 >>396 次世代Javaの動向をヲチるスレであって、 勝手な妄想繰り広げるスレじゃないから。 400 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 22:48:56 ] >>394 C# の Indexerっぽい奴なら、>>249 とか >>250 とかで既に出てるけど。 演算子オーバーロード関連なら、他にも >>283 の一番上のリンクとかもあったし。 401 名前：ﾈｶﾏ由紀恵 mailto:sage [2007/02/14(水) 23:05:20 ] Groovy でやっていることは 入れなくても良いんじゃ・・？ 402 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 23:23:43 ] ていうか今時中身の処理が遅いからJNIなんてのは無いな。 特殊なデバイス叩かん限りpureJavaでいける。 実行速度なんて5.0 6.0で激変したしSwingも1.3→1.4以上でまともになったし。 joy pad使うとかしかJNIの存在理由が見当たらん・・・。 ここら辺は成熟してきたからこれ以上はOpenGLドライバの成熟待ちだろ。ATIもnVidiaも最近のドライバはOpenGLが糞。 そのせいで6.0でもsun.java2d.openglプロパティが使い物にならない。 Java側はドライバの対応を待つしかないからベンダと連携とって行くって言ってるし。 俺はあまり言語仕様を動的にするのには興味ないな。 仕様が複雑化してきてるし当初の仕様ポリシーから外れてきてる気がする。 個人的には値渡しの出来る構造体が欲しいかな。 一々データクラス定義してインスタンス化するのがちょっと・・・ 403 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 00:06:36 ] >>402 public type Hoge{ String hoge; int piyo; } 見たいな感じかな。でも予約語が・・・ JavaBeanを簡単に生成できるシンタックスシュガーが欲しいね。 404 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 00:36:38 ] >>402 そこで、エスケープ解析によるオブジェクトのスタック割り付けですよ。 405 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 01:23:08 ] >>391 NetBeansのSubversionは動作がよくおかしくなる というかAntとかもおかしい気がする JDKを5.0にすると安定するから6のVMバグかも >>392 CVSだったらNetBeans標準装備なんでそれ使えば楽 >>402 Swingは速度が目立つけど、実際は1.3で実用になるようなAPIが多数追加されて 5.0で目立つようなのが追加されていたりする 6も5.0と同じくsun.java2d.opengl使い物にならないね JOGL自体は安定してるんだがGLJPanelのほうがイマイチなのもなおらねぇ というかベータ時代はOpenGL有効にして動いてたような気がするのが気になる 406 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 01:34:56 ] >>400 その下の奴って構文解析できるのか？ class hoge{} class A { 　public static Object method(int arg){ return null; } 　public static int (int lh)method(int rh){ return lh + rh; } 　public static void main(String[] args){ 　　int hoge = 0; 　　(hoge)method(10); 　} } とかされたら面倒なよーな気がする。 407 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 07:18:52 ] >>399 昔は希望を書きまくっていた気もするが？ 408 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 08:40:38 ] >>402 遅いからJNIするんじゃなくて、Win用C++コードをMACに移すためにJNI検討中なんです。 CocoaとかいうやつはObjective-Cだったりして困るし。 409 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 08:51:30 ] >>407 希望なら言語仕様作ってる人達に見える形でで出した方が通りやすいよ。 ksl とかあるんだし。 https://ksl.dev.java.net/ 410 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 08:56:41 ] >>406 int Integer = 1; System.out.println( (Integer)+10 ); とかと同じ扱いにすりゃ良いんじゃないかと思ったけど…… 参照型へのキャストは 単項+ とか 単項- ついたらいかんのか。 つまり Integer って変数が宣言されてないときに System.out.println( (Integer)+10 ); がコンパイルエラーになるから参考にならんと。むぅ。 411 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 17:24:26 ] >>399 ヲチりながら、愚痴るんじゃないの？ 412 名前：402 mailto:sage [2007/02/15(木) 17:43:18 ] >>405 リペイントマネージャ乗っ取って全コンポーネントダーティーだと認識させればユーザーの操作に応じて常にスケーラブルでアジャスタブルなウェジェット組めるが流石にまだ重いだろうなｗ >ベータ時代は・・・ ttp://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6458746 これの応急処置だと思う。 JDialogに限らずOpenGL使ったコンポーネントが破壊される。 描画領域の破壊は-Dsun.java2d.opengl.fbobject=falseを指定すれば回避できるが・・・ FBO周り以外もバグがあるみたいでどうも-Dsun.java2d.opengl.fbobjectに関係なく-Dsun.java2d.opengl使った処理自体まずいみたい。 nVidiaのリグレッションバグなんだがOpenGL有効にしたらグラボ自体が不安定になって最悪システムクラッシュする。 グラボのドライバって既存アプリの描画に影響を与えるしな。リグレッションバグならそうそう戻す訳にはいかんだろうし。 >>408 結局JNI噛ます共有ライブラリ部分はネイティブなんだからリビルドするだろ？ てかwinのライブラリをmacで使おうって発想もな。 JNIにしたってネイティブ部分はプラットフォーム毎に用意するんだし。 J2MEはそれでカオスってるｗ 413 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 18:05:37 ] C++のコードをJavaに移植するほうが早そうだな 414 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 19:04:29 ] >>413ロジックのみならね。 Mac→WinだとMacしかないアプリのDLL使ったりして移植ゼロか、 Win→だとGUI周り以外はそうgdgdにならない？ 415 名前：デフォルトの名無しさん mailto:sage [2007/02/15(木) 19:11:21 ] あーJ2MEはJSR118-MR2からOpenGL実装したので専用チップ要求して更にカオスｗ MIDP2.1はハードウェアサポートが強化されてるしウェジェットも地味に強化（新たに取り込まれたオプションパッケージが目立つ）してSEのノウハウもフィードバックされて結構良いんだが・・・ 416 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 17:45:58 ] >>402 OpenGLといえばJava3Dを思い出した。 あちらも気が付けば大きな進展があるようだ。 JavaからOpenGLのライブラリを使えるようにするというやつ。 プラットフォーム非依存と呼ばれているJavaも3Dとなると そうもいかないケースがあるものだが、 今後のJava3Dは古臭い時代遅れなビデオカードでは動かなく なるか、(AWTのようにOS依存する)劣化表示 or (Java2Dを使用したSwingのように)超低速表示されることになるんだろうか。 417 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 17:48:15 ] >>405 > >>391 > NetBeansのSubversionは動作がよくおかしくなる > というかAntとかもおかしい気がする > JDKを5.0にすると安定するから6のVMバグかも EclipseでJava SE 6でAntを使っているがとくに問題ない。 おかしいってどんなエラーがでるのかね。 Subversionは不安なら、TortoiseSVNでコミットしてみるのはどうだろう。 > >>392 > CVSだったらNetBeans標準装備なんでそれ使えば楽 Eclipseと同じだな。しかしSubversion使ったらもうCVSには戻れない。 それだけ使い勝手が良いから。 418 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 20:23:44 ] そろそろ MFCのようにSwingをラップしたGUIフレームワークが標準でJDKに入らないかな 419 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 21:14:44 ] JSR 296: Swing Application Framework jcp.org/en/jsr/detail?id=296 これどうなるかねぇ。 420 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 21:17:41 ] >>416 JavaからOpenGL使うのはJOGL 去年1.0でたばっかりなのでこれからだと思うがOpenGL2.0がそのままラッピングされている 結果SWTのように汚いけど、これはCのコードのラップだからこれはこれでいいだろう 結果staticImportと相性がいい まぁJOGLはSwingとは直接関係ないけど >>417 Java6はVMがバグってるので演算結果がたまにおかしくなるというひどいバグがある 次のupdateでなおってるはずだけど最適化のバグっぽい まぁ5.0とは別次元の速度になってるんでこんなにVMに手を入れていいのだろうかと思ったけど 予想通りVMのコアにバグいれるとは はじめてオープンソースになった成果がこれってひどすぎ つまりsubversionだけじゃなくてNetBeans自体が不安定になる＞JDK6 それにトータスは使い物にならないよ バージョン管理ツーつってのはIDEと統合されてナンボだから >>418 Swingの時点でMFC以上にラッピングされてるのだが 421 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 21:21:08 ] Swing Application Frameworkのプロトタイプ実装らしい。 https://appframework.dev.java.net/ 見てみよっと。 422 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 21:55:57 ] SwingのラッパーはGroovyやRhinoから使うの便利そうだな 423 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 21:58:35 ] >>420 d.hatena.ne.jp/nowokay/20070113 で話題になってた bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512534 か？ J2SE 1.4.0 のときも、コードによっては 1.3.1 より遅くなって処理完了まで 2倍時間かかったり、とかあったしなぁ。個人的にはいつもの事だと思うんだけど。 ってか、JDK6 は既に現行世代だと何度言えば…… 424 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 22:20:15 ] >>421 SessionStorage.WindowState って最大化状態サポートせんのか？ と思って users@appframework.dev.java.net に検索かけたら https://appframework.dev.java.net/servlets/ReadMsg?list=users&msgNo=129 で、最大化状態は保持してるみたい？ 最大化した状態で close(exit)した場合、最大化解除した状態のサイズは持ってないって事かな？ 425 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 22:30:55 ] >>424 最大化解除したサイズって、どっかのメソッドで取れたっけか？ 常に Frame のサイズ保存しておきながら WindowEvent おっかけて、 Frame#getExtendedState が MAXIMIZED になったら、 直前のサイズを最大化解除したサイズとして保存するとか、 Windows と他の OS で最大化する時の WindowEvent の届き方が違うので 面倒くさくて Windows だけしか対応しないとか、そんな記憶が…… 426 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 22:44:31 ] >>423 いつものことの上、 修正コードが手早く手にはいるようになっただけで 大助かりですよね。 うまく動かなくなるバグなんて、1.4の頃ですが GC周り突っつけばすぐ出てきましたよ。 バグ報告しても、US SUNまで訴えても直らないバグがあったりしたもんです。 直るにしても、次のリリースまで待たなきゃ駄目だしね。 427 名前：デフォルトの名無しさん mailto:sage [2007/02/16(金) 22:55:57 ] とはいえ今はJDK7で自分で治せて配布できるようになったのは大きいかも 428 名前：デフォルトの名無しさん mailto:sage [2007/02/17(土) 00:06:11 ] >>420 んなの初めて聞いた。バグ修正もてえへんだろうなあ。 TortoiseSVNは結構良いと思うけどなあ。ファイルの移動を するときもわざわざ右クリックでめんどいことしないといけないけどさ。 429 名前：デフォルトの名無しさん mailto:sage [2007/02/17(土) 00:10:08 ] >>427 直すのかなり難解だと思うが・・・。 Swingが新しくなるということは、SWTやM$のGUIよりも使い勝手がよいAPIを 作れるのだろうか。 430 名前：デフォルトの名無しさん mailto:sage [2007/02/17(土) 00:11:12 ] そもそも新しくなるの? 431 名前：デフォルトの名無しさん mailto:sage [2007/02/17(土) 00:18:35 ] NetBeansのSubversionは修正がされているかどうかがわざわざ再表示押さないと反映されないのがカス コミットする前に最新状態取得しないとだめってあふぉか CVSクライアントのほうは問題なし というかSubversionはCVSのように自前で実装してないからなぁ CVSモジュールに依存してるし NetBeans3.6だったかあの時代のCVSサポート並のへっぽこさ だから標準実装されてないのだろうね 432 名前：デフォルトの名無しさん mailto:sage [2007/02/17(土) 01:02:26 ] >>424 > で、最大化状態は保持してるみたい？ 保持してないんじゃね？単に最大化したbounds持ってるだけで。 ってか、WindowStateだしな。getExtendedState使えるのFrameだし…… 433 名前：デフォルトの名無しさん mailto:sage [2007/02/17(土) 02:32:28 ] >>431 SVNはCVSにそんなに依存していたっけか。 434 名前：デフォルトの名無しさん mailto:sage [2007/02/17(土) 08:40:54 ] >>433 NetBeansのsubversionモジュールはCVSモジュールに依存している 435 名前：デフォルトの名無しさん mailto:sage [2007/02/17(土) 19:04:07 ] SE 6てOSSにしてからコードの提供あったの？ ６で異常な進化遂げてるし、ないならないでただのコミニュティー潰しにしか見えん。 あの超進化マジックは何？ ヒープの割当・インクリメンタルＧＣのアルゴリズム変更だけであそこまで変わるとは思えん。 ＃まあ日本じゃ未だに1.4.2主流だしse7も迷走中だけど。 そろそろstaxとrhinoが使われだしても良いと思うんだ・・・ 436 名前：デフォルトの名無しさん mailto:sage [2007/02/17(土) 19:13:41 ] >>434 なんだ、そういうことか。 CVS嫌いなSubversion開発者は自分のSVN開発を批判する者に 対してかなり起こっていたからな。 「すでにCVSがあるのに、なんで独自に開発するんだ？」と質問された ことについてもう反論していた気がする。 437 名前：デフォルトの名無しさん mailto:sage [2007/02/17(土) 20:01:54 ] >>435 インクリメンタルGCの変化あったの? 5.0のときにトレインアルゴリズムつかわなくなってコンカレントGCになったけど またかわったの？ 速度は強度の最適化がクライアントVMでかかってるのがわかる。 演算系でサーバーVMとほぼ同じ速度が出たのはわらえた。 だからサーバーVM同梱してないのだなと。 438 名前：デフォルトの名無しさん mailto:sage [2007/02/18(日) 18:07:24 ] レジスタ割付アルゴリズムが Linear Scan Register Allocation とかいうものに変更されたとは聞いているが、そんなに効果があったのかー Linear Scan Register Allocation www.research.ibm.com/jalapeno/papers/toplas99.pdf 439 名前：デフォルトの名無しさん mailto:sage [2007/02/18(日) 19:25:03 ] 従来のバイナリをいじらずおおむね2、30%速度向上してるんだよね 440 名前：デフォルトの名無しさん [2007/02/19(月) 12:35:31 ] そろそろABAPみたいにSQLをネイティブに書けるようになると思うんだ。 441 名前：デフォルトの名無しさん mailto:sage [2007/02/19(月) 12:59:36 ] >>437 インクリメンタルGCが、コンカレントGCに置き換えられたのは6からじゃなかったっけ？ 5の段階では、Xinc使うなって言われてて・・・・ 何か自信ないけど、パフォーマンスアップは、GCだけじゃないってのは賛成。 むしろ、Hotspot系だと思うな。 エスケープ分析効いてないかな？ というか、JDK7で盛り込むJVMの改良ってどっかで話題になってる？ JVMの機能強化ってJCPに乗らないと思うし・・・ 442 名前：デフォルトの名無しさん mailto:sage [2007/02/19(月) 13:03:38 ] 5.0からだよ、コンカレントGCにかわったのは 1.4.1だったかあたりからインクリメンタルGCは採用する価値のないものだったからいい変更だと思ったけどね トレインアルゴリズムを使いたかったらXXオプションで指定すれば5.0でも使えた GCの性能アップだけじゃパフォーマンスが落ちるのを防ぐだけであって性能は上がらないからGC以外が主なパワーアップだろう ６でのGCチェックはまだしてないけど、5.0でGCが10、20%性能上がってたのは有名かと 443 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 19:28:14 ] Lucidaフォントに日本語を追加する事ってできるの 444 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 15:02:25 ] 可能だけど莫大な金と人材と時間と日本語を熟知したフォントデザイナが必要だからsunだけじゃ不可能。 フォントならIPAフォントが抱き合わせライセンスじゃなかったら最強だと思うんだけどな。 所でJavaってGCが勝手にメモリガリガリやってるから メモリの断片化をプログラマで制御出来ないよな？ 長期間不眠不休なサーバーとかメモリ空間少ないJ2MEが辛いと思うんだけど、 今後ここら辺の解決策はないの？ 緩和でも・・・J2MEのプリベリファイは良い案だったと思うんだ。 ＃そういやse6でもプリベリファイ採用してるからそれが実行速度に献上してるかもな。 今思い出したｗ 445 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 16:32:00 ] >>444 System.GCしか今のところコントロールする方法はない。 あとはVMの実行時パラメータでヒープやアルゴリズムの調整でカバー。 ただ、System.GCはほとんどの実装でFullGC動くので実質使っちゃダメ。 System.newGCとかがあればかなり変わるんだろうけど。 ゲームとかにしろ常にシビアなタイミングがあるわけじゃなくて、今は100μsも遅れるとまずいけど このタイミングなら10msは大丈夫とかあるからね。 1フレームに1回殿堂入りさせない新世代GCが指定できればそれでおけ。 どうもsunはここ数年リアルタイムJavaに力を入れてるんだけれども、 常にリアルタイム性が必要な用途ってのは少ないと理解してないっぽい。 446 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 17:33:20 ] > 所でJavaってGCが勝手にメモリガリガリやってるから > メモリの断片化をプログラマで制御出来ないよな？ ↑出来る処理系ってあるの？ 447 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 17:47:52 ] >>446 C/C++だとメモリ管理は自分でするから確保も解放も 自分のタイミングで出来るって程度の意味だ。 勝手なタイミングでガンガンGCされるより断片化起こらないよねって話な。 448 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 18:01:42 ] >>447 それはおかしい 断片化と解放とは別の話だろ それにC++だってアロケートしなおししないと同じだし JavaのGCはそのタイミングをコントロールできないという点だけが問題 449 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 20:44:23 ] >>445 -XX:+ExplicitGCInvokesConcurrent で、Java6なら完全停止は回避できる、のかな？ ttp://java.sun.com/javase/ja/6/docs/ja/technotes/guides/vm/cms-6.html 450 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 23:45:23 ] >>448 mallocなりOS依存のシステムコールで、でかいメモリとってきて、その中に placed newでオブジェクト作れば、制御できると思う。 制御できるだけで、断片化しないメモリ確保戦略はプログラマ任せになるが。 451 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 23:50:06 ] >>444 GC でコンパクションが発生するのに断片化って??? 452 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 23:53:01 ] なんか、全然次世代じゃない話で盛り上がってるな。 453 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 23:57:03 ] >>452 いつもの事だ。 454 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 00:01:05 ] >>445 > >>444 > System.GCしか今のところコントロールする方法はない。 java.lang.ref.SoftReferenceを使えば間接的にコントロールすることもできる。 455 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 00:02:05 ] >>445 > >>444 > どうもsunはここ数年リアルタイムJavaに力を入れてるんだけれども、 > 常にリアルタイム性が必要な用途ってのは少ないと理解してないっぽい。 彼らがJavaを作った目的は家電制御なんだけどな。 彼らはサーバを発電所のように使うものを想定している。 456 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 00:04:13 ] >>446 Bufferインタフェースを使って 巨大な配列を確保すれば 擬似的に管理できないこともないぞｗ C/C++はメモリ全体を巨大な配列として扱えるようになっているのだから。 Javaでも巨大な配列をBufferで作れば似たようなことはできなくもないw 457 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 00:05:52 ] java.lang.refでオブジェクトの「到達可能性」をコントロールできる 香具師はいないのね 458 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 00:14:10 ] >>457 そりゃ、居ないだろ。 あれは到達可能でなくなった事を知るためのもので、 到達可能でなくす事を可能にしてくれるわけじゃない。 459 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 01:27:33 ] >>454 それ定期的に出てくるけどぜんぜんコントロールできねーよ 460 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 13:56:01 ] いつの世代でもGCは永遠の謎なのだ。 461 名前：デフォルトの名無しさん [2007/02/22(木) 21:22:26 ] GCなしの方がよかったかもな〜 462 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 00:09:49 ] GCなしなんていまさらありえんだろ 463 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 00:26:43 ] C++に逆戻りか？ 464 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 00:27:32 ] C++0xの使用をみたが、期待はずれだった。 あんな仕様では当分Javaには勝てないことがわかった。 D言語やC#のほうが全然魅力的だった。 465 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 00:31:08 ] もう使用されているとは 466 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 01:51:35 ] なんで、C++はそんなに使用を拡張していくんだろうねぇ…。今でも十分じゃん。 467 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 01:57:48 ] そうだよな。 チンコの仕様に優れていても、使用に優れてない奴とかいるし。 468 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 02:01:08 ] チョンの仕様かと思ったw チョンのチンコの仕様は9cmで世界一ミクロ 469 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 02:06:38 ] 仕様も使用もダメな例だな

---

---

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

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