[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/ 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 ] 仕様も使用もダメな例だな 470 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 04:24:39 ] JDK7 build08 download.java.net/jdk7/changes/jdk7-b08.html download.java.net/jdk7/binaries/ サマリが何も出来ていない 変わってないのかっ と疑問も持ちつつUpdateする俺でした 471 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 05:02:19 ] マネージド○○って完全にわすｒｙ 472 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 06:35:41 ] CompilerAPIとRhino入れちゃったらこのノリでant入れそうで怖い。 最近標準化連中は仕様作り過ぎｗ C++のexportみたいにry コンパイル→テスト→ビルドの流れが全てプログラミング出来ます！ みたいにさ。 マジレスするとunsignedが欲しい。 static final unsigned byte の範囲の定数が欲しいのにって度々思う #Java書いてるとshortの存在を忘れてint使っちゃう俺 473 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 07:56:31 ] >>472 >static final unsigned byte の範囲の定数が欲しいのにって度々思う short や int じゃだめってこと？ ケータイJavaかなんかかな。 474 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 08:57:09 ] マイナス、負の値を使えばいい。 475 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 10:10:27 ] >>473 そうJ2MEなんかで何かのパーサ書いてるとステータス操作に丁度0-128を使うことがあったりして。 ビット操作中心なんで負数は使えんし、 そもそもMEで使わんディスクスペースとヒープを確保する余裕はない！ そもそもstatic finalなフィールドすら宣言する余裕なんて無いんだよ。 文字列定数の長さを気にする様な世界だ。 ややこしい・・・ 476 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 11:16:49 ] >丁度0-128を使う 嫌がらせだなｗ 477 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 11:19:44 ] >>475 ビット操作でも負数は使えるはずだが 478 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 12:33:58 ] まあ、負数使いたくないのは個人的理由でもあるｗ どうせ作ってたらサイズでかくなって定数をプリプロセッサやエディタの置換なんかで マジックナンバーに展開して定数フィールド排除、 クラス名・メソッド名・フィールド名・インターフェイス名何かをAとかBとかにして長さ短くしてそもそもOOP何か無視して設計して 昔はそれでもダメなんでバイナリエディタで無駄なバイトコード手作業で最適化してサイズ落としたよ。 （まあ、今は難読化だけで間に合うが） そんなんでshortとかintとかlongなんて無駄に使ってられませんｗ 少数も勿論固定少数点数ですｗ XML1.0とXML in Namespace 仕様フルサポートしたライブラリ書いてjarサイズが50K台じゃでか過ぎるって世界だぜ・・・orz 一般的にはCLDC用のXMLパーサって10K台だよ。 ＃つくづく趣味グラマで良かったと思うこの頃。 よくopera mini何て出来たもんだ 479 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 13:38:05 ] >>472 > CompilerAPIとRhino入れちゃったらこのノリでant入れそうで怖い。 > 最近標準化連中は仕様作り過ぎｗ > C++のexportみたいにry > コンパイル→テスト→ビルドの流れが全てプログラミング出来ます！ > みたいにさ。 > マジレスするとunsignedが欲しい。 > static final unsigned byte の範囲の定数が欲しいのにって度々思う > #Java書いてるとshortの存在を忘れてint使っちゃう俺 ラッパークラス作れ 480 名前：デフォルトの名無しさん [2007/02/23(金) 13:54:21 ] >>475 > >>473 > そうJ2MEなんかで何かのパーサ書いてるとステータス操作に丁度0-128を使うことがあったりして。 今はJ2MEではなくJava ME。 つうか、もうそろそろ、スペック問題解決してもいいのでは。 昔と比べ、容量は10倍以上になったんじゃないのか？ S!アプリももう何年か前から1MBアプリを作れるようになったし iアプリも903iからDoja5.0になって1MBにもなったし、今やダウンロード、スクラッチパッドの境界が 無くなって外部メモリも使えるようになって1MB以上のアプリも作れるようになったろ。 昔の10kB時代と比べたら全然気にしなくても良いようになってきたんではないのか？ 481 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 13:55:32 ] >>476 0-127に加えて-1か128を128替わり使えばいいのではと 482 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 13:56:13 ] >>478 とりあえず新たにデータ型作るってのはどうよ 483 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 13:57:12 ] >>478 jarsで圧縮率を上げればjarサイズが半分になるぜ 484 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 21:57:02 ] static final は普通に、コンパイラでインライン展開することが 言語仕様で決まってなかったっけ。 485 名前：デフォルトの名無しさん [2007/02/23(金) 22:04:07 ] 今のJava MEではGenericsやアノテーションは 使えるのか？ 486 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 22:05:35 ] >>484 決まってない。final で修飾されて、確実に定数式で初期化される変数だけ。 それに、ME とかの場合は static final な変数自体も節約したいんでしょ。 487 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 03:48:32 ] >>845 使えない。VM仕様がJITがオプション扱いでブートストラップクラスローダしかない1.4か1.3時代程度だったとオモ。 けどジェネリックスなんて使うケースないと思う。 MEじゃあるべき処理を平気でとっぱらうからアルゴリズムの使い回しとか不要。 他にも汎用データクラス作るんじゃなくて一つのクラスに全てのデータと処理をぶち込むからジェネリックスの立場がない・・・。 インターフェイスすら排除する世界だぜｗ ところでこんなリスト見つけた。VM仕様関連の情報らしい。 ttp://www.ingrid.org/java/vm/ 488 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 12:23:48 ] >>487 ジェネリクスはコレクションを手軽に扱うためだけとおもっても十分な効果が出るよ 489 名前：デフォルトの名無しさん [2007/02/24(土) 12:59:51 ] Java SE 5になってから大分高速化したのに携帯電話には まだ搭載できないでいるのか・・・ しかもまたまた1.3レベルとは。assertも使えぬのか。 アノテーションくらいはつかえたほうがいいとは思うのだが。 コンパイル時には無視できるタイプのアノテーションはとくにあったほうが便利だろう？ それに、いくつかクラスやメソッドが増えているし。 制約上全部は使えないとは思うけど、利便性を考えると、1.3レベルってつらそう。 490 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 13:32:37 ] >>487 > ttp://www.ingrid.org/java/vm/ 古いね。デッドリンク多いし。 491 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 15:42:08 ] >>489 高速化したのはSunのJava SE 5の実装で、Javaっていう規格じゃないだろ。 ケータイって、SunのJVMが主流なの？ 492 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 17:23:16 ] >>488 コレクションFWないよ？レガシーしか。 java.util.*はDataとCalenderが端末依存でGMTすら禄に扱えない。 端末毎に返ってくる値が違う事があるし端末の時計とは 別にＶＭが時計持ってて端末と時間違うし時計アプリなんて信頼できんよ？ UTCなんてない。 これでもちゃんとした仕様の範囲だから困りもんだ。 >>491 主流はアプレックスのJBlend。 一応どこもsunのRI参照してるけど遅いとか理由付けてとことん独自実装＋JITが無いんでベンダー独自のインタプリタ高速化技術なるものを実装してRIとは別物。 KDDIとかSBM専用のオプションパッケージの実体はcom.jblend.*パッケージが主でリンク用のスタブクラスとJavaDocをCPに公開してるだけ。 最近のSEの仕様の恩恵が受けられないのが保守性が悪い悪い・・・ ドコモキャリア仕様の端末以外例外投げると問答無用でVM落とすしエラー出力ないから酷い酷い・・・ クラスローダーがブートストラップのしかないんで動的リンクできんしJarサイズがデカクなるって言うんで汎用のFWは作れんから 再開発部分が多いだろうねぇ。 プリベリファイがSEに取り込まれたんだからMEに何かくれよｗ 493 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 17:52:22 ] >>492 CLDC 1.1 なら java.util.TimeZone が GMT をサポートするのは義務じゃなかったっけ？ TimeZone は GMT をサポートするけど、それを使っても GMT な時間が返ってくるとは限らないってオチはあるかもなー、とか思った。 そーいや、JSR-310 で Date and Time API ってのがあったような。 あれって、JDK7 の contents だっけか？ 494 名前：デフォルトの名無しさん [2007/02/24(土) 18:28:20 ] >>492 System.currentTimeMills()の値を引数にして DateやCalenderを作っても正確にならない？ 495 名前：デフォルトの名無しさん [2007/02/24(土) 18:31:30 ] >>492 > >>491 > 主流はアプレックスのJBlend。 > 一応どこもsunのRI参照してるけど遅いとか理由付けてとことん独自実装＋JITが無いんでベンダー独自のインタプリタ高速化技術なるものを実装してRIとは別物。 遅いとかではなく、かれらがハードウェアリソースをケチっているだけだと いってみたかったりする。 携帯電話をもう少し大型化して、JVMの部分を物理的に大きく専有するようにして、電池も 巨大化させれば携帯電話でも十分早くなるはずだ、と言ってみる。 ハードディスク搭載、とバッテリ寿命さえ延びれば、さらにその理屈もとおるはずだ、と言ってみる。 そして、連中は、独自実装で市場を独占したいだけに過ぎないのだ、 かつてのSonyがやってたような、独自製品で覆い尽くし、ライバル製品との 互換性をわざと奪うために標準Java実装から逃げているだけなのだ、と言ってみせる。 496 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 19:48:51 ] >>492 いやVectorとかでいいんだよ それでも十分使い勝手がいい 中に何を格納するべきなのかをドキュメントに書かないとわからないってのは面倒だったりする そういやJavaME用HotspotVMを開発したとかどっかのニュースみたな 携帯の用途だとhotspotよりはアーカイブ単位での丸ごとコンパイルのほうがよさそうだが 497 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 20:10:36 ] >>489 IBMのJavaME向けコンパイラ/オプティマイザみたいな商用系使ってると かなりのレベルまでstaticメソッドのインライン展開するし、 アサーションってMEの言語仕様で定めなくてもいいかなって気がするんだよね。 それよりも言語仕様のほうはシンプルにしてアプリケーションプログラマ のほうで適切にアサーションのutilクラスを書いた方が全体としてシンプルで融通効くと思う。 というかコンパイル時にstaticメソッドのインライン展開なくても >static final boolean DEBUG = false; >public void assert(...){ > if(DEBUG){ > System.err.println(...); > ... > } >} みたいなコードが書けるように1.3でも言語仕様上ifブロックでの到達不能性チェックに 例外が設けられていて、かつ実装系の方でもSunとかIBMとか大体のコンパイラは DEBUG=falseのときこの部分ごっそり削除してくれるし。 498 名前：497 mailto:sage [2007/02/24(土) 20:36:05 ] アサーションだから >static final boolean DEBUG = false; >public void assert(boolean flag, ...){ > if(DEBUG){ > if(!flag){ > ... > } > } >} みたいな感じか。細かいことだけど。 499 名前：デフォルトの名無しさん [2007/02/24(土) 20:52:52 ] なるほどー。 今ならAspectJでもっと効率よくできるかな？ 500 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 22:31:51 ] >>493 確か仕様上はGMTサポートしろゴルァだけどオチは >GMT な時間が返ってくるとは限らないってオチはあるかもなー だったかと・・・ >>495 仕様上は130K程度の不揮発性メモリ（KVM用）と30K程度の揮発性メモリ（コンフィグレーションライブラリロード用） と16/32bit CPU及び何らかの方法でのネットワーク接続方法。 結局はプロファイルとオプションのライブラリロードが居るんでSUNは160~500K程度のメモリ（揮発・不揮発問わず）を想定してるんだけど。 が仕様上の要求だけどねぇ。携帯電話はそれでもリソースケチるからな・・・。 >>496 いやジェネリックスが便利なのは認めてるんだけどMEだとVector使うかテストしまくって確実に足りる最小の固定長配列使うか悩むんだよ。 ホットスポットVMなら仕様上はCDC HIとCLDC Hotspotて感じのが一応ある。 CDC用はネフロのVMが実装してたな。 >>497 良いねそれ。eclipseのjavacで試してみよう。 まあ、MEも仕様上はEcmaScript並みに互換性あるけどベンダーの実装が変な事やってんだよね。 MS VMとネスケVMとSUN VMで互換性が無かった時代のように （厳密にはMS VMがネスケVMとSUN VMに互換性なかったんだけど。ライブラリのサポートも屑だったし） 学習能力が無いね日本の企業は。ブラウザ戦争とpureJava騒動であれだけカオスったのに。 501 名前：497 mailto:sage [2007/02/24(土) 22:46:46 ] >>500 IBMがつくったコンパイラは例えば 1. VisualAge for Java 2. j9c(後期型は4と同等) + jxelink 3. IBM JDKのjavac 4. Eclipse/JDT(ecj.jar) 5. jikes が挙げられる。497でstaticメソッドの展開が...って言ったのは 1のjxelink。厳密にはポストプロセッサ。 >良いねそれ。eclipseのjavacで試してみよう。 これが4のことを言っているのなら、1のjxelinkとは別物だよ。 502 名前：デフォルトの名無しさん [2007/02/24(土) 23:54:51 ] >>500 もうさ、メガアプリ限定にしてしまえばいいよ。 俺たちが作りたいソフトはこういうものだから、 ハードウェアをもっと強化しろ！ とハード屋に圧力をかけてさ。 マイクロソフトみたいに力がないと Vistaみたいな激重Windowsを開発してハードウェア屋が それに追従するってこと難しいかな。 今はハード基準で携帯電話開発を強いられているみたいだけど、 ソフト屋からハード屋になんとかして圧力かけられないかねえ。 「お前らハード屋がだらしないから携帯電話開発がしづらいんだ！ ハードのスペックを高めることを要求する！」 みたいにさ 503 名前：デフォルトの名無しさん [2007/02/24(土) 23:58:12 ] >>500 > >>496 > いやジェネリックスが便利なのは認めてるんだけどMEだとVector使うかテストしまくって確実に足りる最小の固定長配列使うか悩むんだよ。 java.nio.Bufferを実装したクラスを配列代わりに扱えば高速化するのでは？ と思ったら、あれJ2SE1.4からのものだった。 > >>497 > 学習能力が無いね日本の企業は。ブラウザ戦争とpureJava騒動であれだけカオスったのに。 SoftBankもまともじゃないし、KDDIもまともじゃないし、Docomoもどいつもこいつも 独占欲だけは高いからねえ。 ハードウェア重視でソフトウェアをなめてかかっているところが、だらしないよ。 日本の有名な大手家電メーカーがインターネット産業ろくに力を注がず、Web2.0に 乗り遅れたことをも証明しているし。

---

---

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

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