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

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/09 23:17 / Filesize : 271 KB / Number-of Response : 965
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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/
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に
乗り遅れたことをも証明しているし。
504 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 00:04:27 ]: >>502
とは言え、行き過ぎると Vista や PS3 の二の舞になると思うよ。
505 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 00:42:46 ]: 国内だとキャリア（←こいつが一番無関係ｗ）、世界的にはハード屋が頂点か。
どちらにしてもオープン標準のJava仕様がないがしろにされてるな。

まあ、ソフト屋ですら飼いならされてる現状じゃ仕方ないか。
仕様の地位をもっとこうW3C勧告の仕様並みに出来んかねぇ？（IEの糞実装さえなくなれば平和だからなアッチは）

ハードの方は十分にパワフルだと思うけどな・・・
翌々考えたら昔はメモリ以外今の携帯以下のハードと糞ＯＳでJavaが動いてたんだから。
win95よりce5のが安定してるしｗ
国内携帯は無駄な機能に溢れ返ってるからそれにシステムリソースとコストと
開発期間が圧迫されて一ソフトウェアどころじゃないだろうな。
またしても仕様の地位不足か・・・

SUNの苦労体質全部をJavaが担ってる気がするｗ
506 名前：デフォルトの名無しさん [2007/02/25(日) 01:02:42 ]: >>505
パワフルな割には容量が足りないってどういう事なんだろうなあと思うよ。
メモリもっと増やすべき。でないととてもパワフルじゃないな。

現実問題として電力消費が激しいと言う問題があるそうだ。

しかし省エネ型DRAMのようなメモリがもっと普及すれば解決できるんだとか。

つうか、携帯電話会社は、余計な機能にエネルギーを無駄に費やさず
Javaの部分にエネルギーを費やして欲しいな。
あらゆる機能をJavaを中心に動かせるようにすれば水平ポータビリティを
維持できるし、どの携帯電話でも同じように動くアプリを簡単に作れるようになる。
507 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 01:23:02 ]: KDDIがBREWで水平ポータビリィティやろうとしてソフト屋・消費者から大ブーイング受けた結果
建前上JBlend on BREW（サービス名オープンアプリ/どこがオープン何だと小一時間・・・）のっけましたが？

Javaで水平ポータビリティ実現すればsunの当初の目的が実現するな。
その為にはベンダーに協力してもらわんとダメだが。

その前に日本の携帯ビジネスモデルを破壊しないと受け入れられないだろう。
4G携帯なんて出したらドコモが死守してソフトバンクが
嘘ばら蒔いてイーモバとウィルが歓迎するんだろうな。
KDDIはBREW動いて音楽と動画DL出来れば何でも良さそうだが。

ネイティブ開発は個人には不可能か敷居高いだろうしJava（MIDP）流行らんもんかね
508 名前：デフォルトの名無しさん [2007/02/25(日) 01:38:36 ]: つかネイティブ開発はCPの審査がウザイよ。
審査に金かかるわ時間もかかるわ。
509 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 06:56:24 ]: 今のケータイでJavaをやろうとすること自体が間違いなことに気づけ。
510 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 07:12:43 ]: て事は昔の、今の携帯以下のスペックで動かしてたJava自体間違いだったって事か
511 名前：デフォルトの名無しさん [2007/02/25(日) 10:59:44 ]: Javaで何をするかが問題。
今の技術では、携帯に望みすぎ。

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

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