[mustang/Java SE 6] 次世代Javaの動向 4 [dolphin]
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2006/11/20(月) 10:38:16[mustang] 次世代Javaの動向 3 [dolphin]
http://pc8.2ch.net/test/read.cgi/tech/1157227790/
次世代Javaの動向 ２
http://pc8.2ch.net/test/read.cgi/tech/1147881822/
【Java】次世代Java・J2SE1.6の動向【Mustang】
http://pc8.2ch.net/test/read.cgi/tech/1081698555/
2006年12月にMustang Java SE 6がリリース予定
Mustangの掲げる主な目標は以下の点にある。
* 互換性と安定性および品質の向上
* Easy of Developmentの実現
* WebサービスおよびXMLサポート機能の拡張
* リソース管理や診断機能の強化
* デスクトップ環境の強化
Java SE 6 じゃじゃ馬ならし
http://www.javainthebox.net/laboratory/JavaSE6/
0357デフォルトの名無しさん
2007/02/14(水) 08:53:48http://api.openoffice.org/docs/DevelopersGuide/ProfUNO/ProfUNO.xhtml
0358デフォルトの名無しさん
2007/02/14(水) 10:40:15（＞＜；） なんにもわかんないんです！＞＜
/つと ﾉ
しー-Ｊ
0359デフォルトの名無しさん
2007/02/14(水) 13:57:37クロスGUIつーかSwingのLnFが何やってるか知ってるか？
0360デフォルトの名無しさん
2007/02/14(水) 14:12:15/つと ﾉ
しー-Ｊ
0361デフォルトの名無しさん
2007/02/14(水) 14:28:01あれはC++だろ。
0362デフォルトの名無しさん
2007/02/14(水) 14:28:44普通に考えて
Double Click + able
ダブルクリック可能って意味になるだろ
0363デフォルトの名無しさん
2007/02/14(水) 14:30:45http://e-words.jp/w/E383ABE38383E382AFEFBC86E38395E382A3E383BCE383AB.html
http://ja.wikipedia.org/wiki/LnF
0364353
2007/02/14(水) 14:47:38今のSwingってXMLのスキンとかいうやつですか？
そのUIから、実行ファイルみたいなのをキック？
それともJNIコール？
0365デフォルトの名無しさん
2007/02/14(水) 15:03:35言ってる意味がわからないが
勝手に言ってることを予測して答えてみる。
今のSwingは性能が良い。
スキン変更はJavaプログラムで可能。
そのためWinXPのルナスキンを利用可能。ただしこれはWin
意外のOSで使うと著作権侵害になるのでWinのとき専用。
MacのときはMacのスキンも使える。
よって見た目は綺麗。XAMLやCAMLやXULみたいな、
XMLでスキンを変えられるかどうかということについてはよく知らない。
キック？ については、これも推測すると。
恐らく、Java Web Startの事を言っているのかと推測。
SwingアプリをJava Web Startに対応させるには、拡張子がjnlpという
XMLファイルを作って、そこの決められたフォーマットでSwingアプリの
main()メソッドがあるクラスへのリンクや
バージョン情報、必要なJREのバージョンなどを記述する。
すると、ブラウザ上で拡張子jnlpファイルを見つけると、まさにキックされ、
MIMEタイプを確認し、JREが入っているかどうかを確認し、バージョンチェックされ、
Java Web Startが起動し、Swingアプリのバージョンをチェックされ
Swingアプリが起動し実行される。
Java Web Startは、JNIは一切関係が無い。
0366353
2007/02/14(水) 15:09:13で、処理部分はC++を使いたいです。
0367デフォルトの名無しさん
2007/02/14(水) 15:10:08そのときの知ってる人はもう少ないな
あの当時とはもはや別物だと思っていい
WebStartは今はデスクトップやプログラムメニューなどのショートカットに対応
つまり2回目からはブラウザの起動すら必要はない
そしてプログラムの追加と削除でもアンインストールができるようになってる
もちろん今までどおりコントロールパネルのJavaキャッシュからの削除なども出来る
0368デフォルトの名無しさん
2007/02/14(水) 15:18:38かったか?
もしかしてMetalでない各プラットフォームで固有LnFにしたいってだけの
話なら、
String sysLnfClassName = UIManager.getSystemLookAndFeelClassName();
UIManager.setLookAndFeel(sysLnfClassName);
0369353
2007/02/14(水) 15:23:15C++のコードがあるのですが、
GUI部分を１つ定義してWin、MAC、Linux全対応したいです。
そのときにC++側からSwing画面を開けるのかなー？、と。
0370デフォルトの名無しさん
2007/02/14(水) 15:26:58GUIをSwingで作って、エントリとなるメソッドをC++から
キックすればOK。
0371デフォルトの名無しさん
2007/02/14(水) 15:39:37Java2以前ってことはSwingというよりJFC?
XMLスキンは、恐らくSynthLookAndFeel
>>353
やりたいのは、NeoOfficeのやってることだな
GUI描画部分を、Javaにやらせるという
0372353
2007/02/14(水) 15:43:180373353
2007/02/14(水) 15:45:00クロスＧＵＩとして使われてるわけじゃないんだ？
0374デフォルトの名無しさん
2007/02/14(水) 16:34:17ある。C++コンパイラはg++。
製品バンドル版OSXなら一緒にg++を含んだ開発環境(Xcode)メディアも付いて
くるし、無料でダウンロードも出来る。Java環境の最新バージョンは1.6.0。
antも入ってる。
0375353
2007/02/14(水) 16:42:45”Java＆C++”の開発効率がちょっぴり不安。
0376デフォルトの名無しさん
2007/02/14(水) 17:04:19Swingの勉強をする。
0377デフォルトの名無しさん
2007/02/14(水) 17:35:14俺はやったけど、両方わかってりゃ大した事は無かった。
つーても、やっぱc++からjavaオブジェクトを返すのにJNIEnvを使う部分があるんで、そこはちょっと効率悪いかな。
あとJNI部分のデバッグが面倒なんで、c++でロジック書いてJNIで薄くラップしてやる感じ。
java側は、ちゃんとMVCに分けて、DAOをしっかり分離してやりゃOK。
テスト用DAOに差し替えて開発して、最終的にJNIを使ったDAOでテストする。
まー規模にもよるだろうが。
0379デフォルトの名無しさん
2007/02/14(水) 17:51:130380デフォルトの名無しさん
2007/02/14(水) 17:53:03ですが、何か？
0381デフォルトの名無しさん
2007/02/14(水) 17:54:42Swingって落ち目な感じ？
0382デフォルトの名無しさん
2007/02/14(水) 18:03:33SWTとかの代替候補の立場が微妙になってるのが現状じゃね?
0383デフォルトの名無しさん
2007/02/14(水) 18:12:19知らないうちに勢力図が変わるんですね。
それと、デファクトだったEclipseがＳ∪∩の開発環境（何だっけ？）に負けたんでしたっけ？
0384デフォルトの名無しさん
2007/02/14(水) 18:20:25むしろ、SWTの活躍の場は、eclipseしかない、という感じ。
Netbeansは、Jackpotがどうなるか、か？
誘導
Java 高速GUI SWT 3
http://pc10.2ch.net/test/read.cgi/tech/1164877399/
Java低速GUI Swing 5
http://pc10.2ch.net/test/read.cgi/tech/1161139809/
【Java】NetBeans Part2【Sun】
http://pc10.2ch.net/test/read.cgi/tech/1154582593/
0385デフォルトの名無しさん
2007/02/14(水) 18:27:26去年の勝ち組負け組みでEclipseを最初負け組みと書いて後で消したの
一番使われてるのに負け組みはおかしいといわれたそうだが
0386デフォルトの名無しさん
2007/02/14(水) 18:41:27じゃぁ、NetBeansとSwing使っとけば問題無いか。
Windows上だとちょっぴりモタツクだろうけど。
でも、モッサリドトネト（流行ってないくせにWinForms、WPFと２つあって最悪）よりかはましか。
0387デフォルトの名無しさん
2007/02/14(水) 18:42:36NetBeansがEclipseをやっつけたってことは、
JBuilderとかは無用の長物？
0388デフォルトの名無しさん
2007/02/14(水) 18:50:15以前のSwingではレイアウトマネージャのおかげで、
思ったように画面作り難かったのですが、
今のSwingはポトペタしやすいですか？
0389デフォルトの名無しさん
2007/02/14(水) 18:59:48NetBeans(の5以降で導入されたMatisseというデザイナ)を使うと無茶苦茶ポトペタしやすい。
と、漏れは個人的には思っている。
0390デフォルトの名無しさん
2007/02/14(水) 19:11:20JNI なんぞは、1.1 の頃には既にあったわけなんだが……
誘導
★お前らJavaはJNIで組もうぜ★
http://pc10.2ch.net/test/read.cgi/tech/1033795664/
0391デフォルトの名無しさん
2007/02/14(水) 19:14:29個人的には、GUIポトペタ(←(・∀・)ｲｲ!!)は、Netbeans。
ロジック書き書きは、eclipse。
両方使ってるよ。
NetbeansのSubversionプラグインは使いにくいし。
0392デフォルトの名無しさん
2007/02/14(水) 19:24:34CVSはWinCVS（←もしかしてサイアク？）使ってるんで。
JNIもふつーに使われてますか？
0393デフォルトの名無しさん
2007/02/14(水) 19:27:48【Java】NetBeans Part2【Sun】
http://pc10.2ch.net/test/read.cgi/tech/1154582593/
0394デフォルトの名無しさん
2007/02/14(水) 19:57:46public 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");とか、
さらに、オーバーロード可能にすれば他にも使い方ができそうだ。
0395デフォルトの名無しさん
2007/02/14(水) 20:06:55じゃあ標準出力はSystem("%d%d", 100, 200);でOK？
0396デフォルトの名無しさん
2007/02/14(水) 20:18:36@Alias(value = "ltgt" , type = "literal")//自作リテラル（ここでは<>）
@Alias(value = "plus_equal" , type = "operator")//演算子オーバーロード
これで実装するなら>>394は
@Alias("nameless")
ってとこか
んで、呼び出す対象のフィールドの宣言時も@AliasUsingをつける。
まぁ設計がまずいのに無理やり使わされるのもあれだしね。
0397デフォルトの名無しさん
2007/02/14(水) 21:33:06その文字を見たら昔のSunのCMを思い出した。
0398デフォルトの名無しさん
2007/02/14(水) 21:45:16細かい仕様を定義しようとすると複雑になるし、いかに丁寧に仕組みを作っても雑に使われたら困るもんな。
よく使われるやつだけ今のString型みたいにして、アノテーションで限定解除するだけでいいか。
0399デフォルトの名無しさん
2007/02/14(水) 22:40:43>>396
次世代Javaの動向をヲチるスレであって、
勝手な妄想繰り広げるスレじゃないから。
0400デフォルトの名無しさん
2007/02/14(水) 22:48:56C# の Indexerっぽい奴なら、>>249 とか >>250 とかで既に出てるけど。
演算子オーバーロード関連なら、他にも >>283 の一番上のリンクとかもあったし。
0401ﾈｶﾏ由紀恵
2007/02/14(水) 23:05:20入れなくても良いんじゃ・・？
0402デフォルトの名無しさん
2007/02/14(水) 23:23:43特殊なデバイス叩かん限りpureJavaでいける。
実行速度なんて5.0 6.0で激変したしSwingも1.3→1.4以上でまともになったし。
joy pad使うとかしかJNIの存在理由が見当たらん・・・。
ここら辺は成熟してきたからこれ以上はOpenGLドライバの成熟待ちだろ。ATIもnVidiaも最近のドライバはOpenGLが糞。
そのせいで6.0でもsun.java2d.openglプロパティが使い物にならない。
Java側はドライバの対応を待つしかないからベンダと連携とって行くって言ってるし。
俺はあまり言語仕様を動的にするのには興味ないな。
仕様が複雑化してきてるし当初の仕様ポリシーから外れてきてる気がする。
個人的には値渡しの出来る構造体が欲しいかな。
一々データクラス定義してインスタンス化するのがちょっと・・・
0403デフォルトの名無しさん
2007/02/15(木) 00:06:36public type Hoge{
String hoge;
int piyo;
}
見たいな感じかな。でも予約語が・・・
JavaBeanを簡単に生成できるシンタックスシュガーが欲しいね。
0404デフォルトの名無しさん
2007/02/15(木) 00:36:38そこで、エスケープ解析によるオブジェクトのスタック割り付けですよ。
0405デフォルトの名無しさん
2007/02/15(木) 01:23:08NetBeansの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有効にして動いてたような気がするのが気になる
0406デフォルトの名無しさん
2007/02/15(木) 01:34:56その下の奴って構文解析できるのか？
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);
}
}
とかされたら面倒なよーな気がする。
0407デフォルトの名無しさん
2007/02/15(木) 07:18:52昔は希望を書きまくっていた気もするが？
0408デフォルトの名無しさん
2007/02/15(木) 08:40:38遅いからJNIするんじゃなくて、Win用C++コードをMACに移すためにJNI検討中なんです。
CocoaとかいうやつはObjective-Cだったりして困るし。
0409デフォルトの名無しさん
2007/02/15(木) 08:51:30希望なら言語仕様作ってる人達に見える形でで出した方が通りやすいよ。
ksl とかあるんだし。
https://ksl.dev.java.net/
0410デフォルトの名無しさん
2007/02/15(木) 08:56:41int Integer = 1;
System.out.println( (Integer)+10 );
とかと同じ扱いにすりゃ良いんじゃないかと思ったけど……
参照型へのキャストは 単項+ とか 単項- ついたらいかんのか。
つまり Integer って変数が宣言されてないときに
System.out.println( (Integer)+10 );
がコンパイルエラーになるから参考にならんと。むぅ。
0411デフォルトの名無しさん
2007/02/15(木) 17:24:26ヲチりながら、愚痴るんじゃないの？
0412402
2007/02/15(木) 17:43:18リペイントマネージャ乗っ取って全コンポーネントダーティーだと認識させればユーザーの操作に応じて常にスケーラブルでアジャスタブルなウェジェット組めるが流石にまだ重いだろうなｗ
>ベータ時代は・・・
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はそれでカオスってるｗ
0413デフォルトの名無しさん
2007/02/15(木) 18:05:370414デフォルトの名無しさん
2007/02/15(木) 19:04:29Mac→WinだとMacしかないアプリのDLL使ったりして移植ゼロか、
Win→だとGUI周り以外はそうgdgdにならない？
0415デフォルトの名無しさん
2007/02/15(木) 19:11:21MIDP2.1はハードウェアサポートが強化されてるしウェジェットも地味に強化（新たに取り込まれたオプションパッケージが目立つ）してSEのノウハウもフィードバックされて結構良いんだが・・・
0416デフォルトの名無しさん
2007/02/16(金) 17:45:58OpenGLといえばJava3Dを思い出した。
あちらも気が付けば大きな進展があるようだ。
JavaからOpenGLのライブラリを使えるようにするというやつ。
プラットフォーム非依存と呼ばれているJavaも3Dとなると
そうもいかないケースがあるものだが、
今後のJava3Dは古臭い時代遅れなビデオカードでは動かなく
なるか、(AWTのようにOS依存する)劣化表示
or
(Java2Dを使用したSwingのように)超低速表示されることになるんだろうか。
0417デフォルトの名無しさん
2007/02/16(金) 17:48:15> >>391
> NetBeansのSubversionは動作がよくおかしくなる
> というかAntとかもおかしい気がする
> JDKを5.0にすると安定するから6のVMバグかも
EclipseでJava SE 6でAntを使っているがとくに問題ない。
おかしいってどんなエラーがでるのかね。
Subversionは不安なら、TortoiseSVNでコミットしてみるのはどうだろう。
> >>392
> CVSだったらNetBeans標準装備なんでそれ使えば楽
Eclipseと同じだな。しかしSubversion使ったらもうCVSには戻れない。
それだけ使い勝手が良いから。
0418デフォルトの名無しさん
2007/02/16(金) 20:23:44MFCのようにSwingをラップしたGUIフレームワークが標準でJDKに入らないかな
0419デフォルトの名無しさん
2007/02/16(金) 21:14:44http://jcp.org/en/jsr/detail?id=296
これどうなるかねぇ。
0420デフォルトの名無しさん
2007/02/16(金) 21:17:41Javaから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以上にラッピングされてるのだが
0421デフォルトの名無しさん
2007/02/16(金) 21:21:08https://appframework.dev.java.net/
見てみよっと。
0422デフォルトの名無しさん
2007/02/16(金) 21:55:570423デフォルトの名無しさん
2007/02/16(金) 21:58:35http://d.hatena.ne.jp/nowokay/20070113 で話題になってた
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512534 か？
J2SE 1.4.0 のときも、コードによっては 1.3.1 より遅くなって処理完了まで
2倍時間かかったり、とかあったしなぁ。個人的にはいつもの事だと思うんだけど。
ってか、JDK6 は既に現行世代だと何度言えば……
0424デフォルトの名無しさん
2007/02/16(金) 22:20:15SessionStorage.WindowState って最大化状態サポートせんのか？ と思って
[email protected] に検索かけたら
https://appframework.dev.java.net/servlets/ReadMsg?list=users&msgNo=129
で、最大化状態は保持してるみたい？
最大化した状態で close(exit)した場合、最大化解除した状態のサイズは持ってないって事かな？
0425デフォルトの名無しさん
2007/02/16(金) 22:30:55最大化解除したサイズって、どっかのメソッドで取れたっけか？
常に Frame のサイズ保存しておきながら WindowEvent おっかけて、
Frame#getExtendedState が MAXIMIZED になったら、
直前のサイズを最大化解除したサイズとして保存するとか、
Windows と他の OS で最大化する時の WindowEvent の届き方が違うので
面倒くさくて Windows だけしか対応しないとか、そんな記憶が……
0426デフォルトの名無しさん
2007/02/16(金) 22:44:31いつものことの上、
修正コードが手早く手にはいるようになっただけで
大助かりですよね。
うまく動かなくなるバグなんて、1.4の頃ですが
GC周り突っつけばすぐ出てきましたよ。
バグ報告しても、US SUNまで訴えても直らないバグがあったりしたもんです。
直るにしても、次のリリースまで待たなきゃ駄目だしね。
0427デフォルトの名無しさん
2007/02/16(金) 22:55:570428デフォルトの名無しさん
2007/02/17(土) 00:06:11んなの初めて聞いた。バグ修正もてえへんだろうなあ。
TortoiseSVNは結構良いと思うけどなあ。ファイルの移動を
するときもわざわざ右クリックでめんどいことしないといけないけどさ。
0429デフォルトの名無しさん
2007/02/17(土) 00:10:08直すのかなり難解だと思うが・・・。
Swingが新しくなるということは、SWTやM$のGUIよりも使い勝手がよいAPIを
作れるのだろうか。
0430デフォルトの名無しさん
2007/02/17(土) 00:11:120431デフォルトの名無しさん
2007/02/17(土) 00:18:35コミットする前に最新状態取得しないとだめってあふぉか
CVSクライアントのほうは問題なし
というかSubversionはCVSのように自前で実装してないからなぁ
CVSモジュールに依存してるし
NetBeans3.6だったかあの時代のCVSサポート並のへっぽこさ
だから標準実装されてないのだろうね
0432デフォルトの名無しさん
2007/02/17(土) 01:02:26> で、最大化状態は保持してるみたい？
保持してないんじゃね？単に最大化したbounds持ってるだけで。
ってか、WindowStateだしな。getExtendedState使えるのFrameだし……
0433デフォルトの名無しさん
2007/02/17(土) 02:32:28SVNはCVSにそんなに依存していたっけか。
0434デフォルトの名無しさん
2007/02/17(土) 08:40:54NetBeansのsubversionモジュールはCVSモジュールに依存している
0435デフォルトの名無しさん
2007/02/17(土) 19:04:07６で異常な進化遂げてるし、ないならないでただのコミニュティー潰しにしか見えん。
あの超進化マジックは何？
ヒープの割当・インクリメンタルＧＣのアルゴリズム変更だけであそこまで変わるとは思えん。
＃まあ日本じゃ未だに1.4.2主流だしse7も迷走中だけど。
そろそろstaxとrhinoが使われだしても良いと思うんだ・・・
0436デフォルトの名無しさん
2007/02/17(土) 19:13:41なんだ、そういうことか。
CVS嫌いなSubversion開発者は自分のSVN開発を批判する者に
対してかなり起こっていたからな。
「すでにCVSがあるのに、なんで独自に開発するんだ？」と質問された
ことについてもう反論していた気がする。
0437デフォルトの名無しさん
2007/02/17(土) 20:01:54インクリメンタルGCの変化あったの?
5.0のときにトレインアルゴリズムつかわなくなってコンカレントGCになったけど
またかわったの？
速度は強度の最適化がクライアントVMでかかってるのがわかる。
演算系でサーバーVMとほぼ同じ速度が出たのはわらえた。
だからサーバーVM同梱してないのだなと。
0438デフォルトの名無しさん
2007/02/18(日) 18:07:24とかいうものに変更されたとは聞いているが、そんなに効果があったのかー
Linear Scan Register Allocation
http://www.research.ibm.com/jalapeno/papers/toplas99.pdf
0439デフォルトの名無しさん
2007/02/18(日) 19:25:030440デフォルトの名無しさん
2007/02/19(月) 12:35:310441デフォルトの名無しさん
2007/02/19(月) 12:59:36インクリメンタルGCが、コンカレントGCに置き換えられたのは6からじゃなかったっけ？
5の段階では、Xinc使うなって言われてて・・・・
何か自信ないけど、パフォーマンスアップは、GCだけじゃないってのは賛成。
むしろ、Hotspot系だと思うな。
エスケープ分析効いてないかな？
というか、JDK7で盛り込むJVMの改良ってどっかで話題になってる？
JVMの機能強化ってJCPに乗らないと思うし・・・
0442デフォルトの名無しさん
2007/02/19(月) 13:03:381.4.1だったかあたりからインクリメンタルGCは採用する価値のないものだったからいい変更だと思ったけどね
トレインアルゴリズムを使いたかったらXXオプションで指定すれば5.0でも使えた
GCの性能アップだけじゃパフォーマンスが落ちるのを防ぐだけであって性能は上がらないからGC以外が主なパワーアップだろう
６でのGCチェックはまだしてないけど、5.0でGCが10、20%性能上がってたのは有名かと
0443デフォルトの名無しさん
2007/02/20(火) 19:28:140444デフォルトの名無しさん
2007/02/21(水) 15:02:25フォントならIPAフォントが抱き合わせライセンスじゃなかったら最強だと思うんだけどな。
所でJavaってGCが勝手にメモリガリガリやってるから
メモリの断片化をプログラマで制御出来ないよな？
長期間不眠不休なサーバーとかメモリ空間少ないJ2MEが辛いと思うんだけど、
今後ここら辺の解決策はないの？
緩和でも・・・J2MEのプリベリファイは良い案だったと思うんだ。
＃そういやse6でもプリベリファイ採用してるからそれが実行速度に献上してるかもな。
今思い出したｗ
0445デフォルトの名無しさん
2007/02/21(水) 16:32:00System.GCしか今のところコントロールする方法はない。
あとはVMの実行時パラメータでヒープやアルゴリズムの調整でカバー。
ただ、System.GCはほとんどの実装でFullGC動くので実質使っちゃダメ。
System.newGCとかがあればかなり変わるんだろうけど。
ゲームとかにしろ常にシビアなタイミングがあるわけじゃなくて、今は100μsも遅れるとまずいけど
このタイミングなら10msは大丈夫とかあるからね。
1フレームに1回殿堂入りさせない新世代GCが指定できればそれでおけ。
どうもsunはここ数年リアルタイムJavaに力を入れてるんだけれども、
常にリアルタイム性が必要な用途ってのは少ないと理解してないっぽい。
0446デフォルトの名無しさん
2007/02/21(水) 17:33:20> メモリの断片化をプログラマで制御出来ないよな？
↑出来る処理系ってあるの？
0447デフォルトの名無しさん
2007/02/21(水) 17:47:52C/C++だとメモリ管理は自分でするから確保も解放も
自分のタイミングで出来るって程度の意味だ。
勝手なタイミングでガンガンGCされるより断片化起こらないよねって話な。
0448デフォルトの名無しさん
2007/02/21(水) 18:01:42それはおかしい
断片化と解放とは別の話だろ
それにC++だってアロケートしなおししないと同じだし
JavaのGCはそのタイミングをコントロールできないという点だけが問題
0449デフォルトの名無しさん
2007/02/21(水) 20:44:23-XX:+ExplicitGCInvokesConcurrent
で、Java6なら完全停止は回避できる、のかな？
ttp://java.sun.com/javase/ja/6/docs/ja/technotes/guides/vm/cms-6.html
0450デフォルトの名無しさん
2007/02/21(水) 23:45:23mallocなりOS依存のシステムコールで、でかいメモリとってきて、その中に
placed newでオブジェクト作れば、制御できると思う。
制御できるだけで、断片化しないメモリ確保戦略はプログラマ任せになるが。
0451デフォルトの名無しさん
2007/02/21(水) 23:50:06GC でコンパクションが発生するのに断片化って???
0452デフォルトの名無しさん
2007/02/21(水) 23:53:010453デフォルトの名無しさん
2007/02/21(水) 23:57:03いつもの事だ。
0454デフォルトの名無しさん
2007/02/22(木) 00:01:05> >>444
> System.GCしか今のところコントロールする方法はない。
java.lang.ref.SoftReferenceを使えば間接的にコントロールすることもできる。
0455デフォルトの名無しさん
2007/02/22(木) 00:02:05> >>444
> どうもsunはここ数年リアルタイムJavaに力を入れてるんだけれども、
> 常にリアルタイム性が必要な用途ってのは少ないと理解してないっぽい。
彼らがJavaを作った目的は家電制御なんだけどな。
彼らはサーバを発電所のように使うものを想定している。
0456デフォルトの名無しさん
2007/02/22(木) 00:04:13Bufferインタフェースを使って
巨大な配列を確保すれば
擬似的に管理できないこともないぞｗ
C/C++はメモリ全体を巨大な配列として扱えるようになっているのだから。
Javaでも巨大な配列をBufferで作れば似たようなことはできなくもないw
■ このスレッドは過去ログ倉庫に格納されています