[mustang/Java SE 6] ..
357:デフォルトの名無しさん
07/02/14 08:53:48
ググレカス
URLﾘﾝｸ(api.openoffice.org)
358:デフォルトの名無しさん
07/02/14 10:40:15
>>357
（＞＜；） なんにもわかんないんです！＞＜
/つと ﾉ
しー-Ｊ
359:デフォルトの名無しさん
07/02/14 13:57:37
>>356
クロスGUIつーかSwingのLnFが何やってるか知ってるか？
360:デフォルトの名無しさん
07/02/14 14:12:15
（＞＜；） Swingを使った事はありますがLnFわかんないんです！
/つと ﾉ
しー-Ｊ
361:デフォルトの名無しさん
07/02/14 14:28:01
>>353
あれはC++だろ。
362:デフォルトの名無しさん
07/02/14 14:28:44
>>356
普通に考えて
Double Click + able
ダブルクリック可能って意味になるだろ
363:デフォルトの名無しさん
07/02/14 14:30:45
>>360
URLﾘﾝｸ(e-words.jp)
Wikipedia項目ﾘﾝｸ
364:353
07/02/14 14:47:38
Java2より前のSwingしか使った事無いのですが、
今のSwingってXMLのスキンとかいうやつですか？
そのUIから、実行ファイルみたいなのをキック？
それともJNIコール？
365:デフォルトの名無しさん
07/02/14 15:03:35
>>364
言ってる意味がわからないが
勝手に言ってることを予測して答えてみる。
今の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は一切関係が無い。
366:353
07/02/14 15:09:13
OOoのような画面をクロス環境（Win、MAC、Linux）で使いたかったらどうすれば良いのでしょうか？
で、処理部分はC++を使いたいです。
367:デフォルトの名無しさん
07/02/14 15:10:08
Java2より前ってことはオプショナルパッケージのころか
そのときの知ってる人はもう少ないな
あの当時とはもはや別物だと思っていい
WebStartは今はデスクトップやプログラムメニューなどのショートカットに対応
つまり2回目からはブラウザの起動すら必要はない
そしてプログラムの追加と削除でもアンインストールができるようになってる
もちろん今までどおりコントロールパネルのJavaキャッシュからの削除なども出来る
368:デフォルトの名無しさん
07/02/14 15:18:38
OooでJavaを使うのは、文書にJavaアプレットを埋めたりするくらいじゃな
かったか?
もしかしてMetalでない各プラットフォームで固有LnFにしたいってだけの
話なら、
String sysLnfClassName = UIManager.getSystemLookAndFeelClassName();
UIManager.setLookAndFeel(sysLnfClassName);
369:353
07/02/14 15:23:15
いや、Java側から考えるのでなくて、
C++のコードがあるのですが、
GUI部分を１つ定義してWin、MAC、Linux全対応したいです。
そのときにC++側からSwing画面を開けるのかなー？、と。
370:デフォルトの名無しさん
07/02/14 15:26:58
JNIはC++ APIもあって、データのやりとりも出来るので、
GUIをSwingで作って、エントリとなるメソッドをC++から
キックすればOK。
371:デフォルトの名無しさん
07/02/14 15:39:37
>>364
Java2以前ってことはSwingというよりJFC?
XMLスキンは、恐らくSynthLookAndFeel
>>353
やりたいのは、NeoOfficeのやってることだな
GUI描画部分を、Javaにやらせるという
372:353
07/02/14 15:43:18
MACでもJNIを簡単に作れますか？
373:353
07/02/14 15:45:00
NeoOffice見ましたが、MACのみ。
クロスＧＵＩとして使われてるわけじゃないんだ？
374:デフォルトの名無しさん
07/02/14 16:34:17
MacOSXにおいてJavaは標準サポートされてるし、JNI関係のヘッダもツールも
ある。C++コンパイラはg++。
製品バンドル版OSXなら一緒にg++を含んだ開発環境(Xcode)メディアも付いて
くるし、無料でダウンロードも出来る。Java環境の最新バージョンは1.6.0。
antも入ってる。
375:353
07/02/14 16:42:45
じゃ、Javaで画面作って、C++コードはg++でコンパイルすれば宵ってことかぁ。
”Java＆C++”の開発効率がちょっぴり不安。
376:デフォルトの名無しさん
07/02/14 17:04:19
>>366
Swingの勉強をする。
377:デフォルトの名無しさん
07/02/14 17:35:14
>>375
俺はやったけど、両方わかってりゃ大した事は無かった。
つーても、やっぱc++からjavaオブジェクトを返すのにJNIEnvを使う部分があるんで、そこはちょっと効率悪いかな。
あとJNI部分のデバッグが面倒なんで、c++でロジック書いてJNIで薄くラップしてやる感じ。
java側は、ちゃんとMVCに分けて、DAOをしっかり分離してやりゃOK。
テスト用DAOに差し替えて開発して、最終的にJNIを使ったDAOでテストする。
まー規模にもよるだろうが。
378:353
07/02/14 17:38:49
ｻﾝｸﾂ>>377
DLLコールと比べて、さらに効率悪いのかなぁ？
出来上がったアプリはやっぱりモッサリ？
379:デフォルトの名無しさん
07/02/14 17:51:13
次世代Javaの動向と関係ない話題は他所いってやれ。
380:デフォルトの名無しさん
07/02/14 17:53:03
次世代Java＝C++と連携
ですが、何か？
381:デフォルトの名無しさん
07/02/14 17:54:42
ところで、次世代Javaというか有力候補のウィンドウライブラリって何？
Swingって落ち目な感じ？
382:デフォルトの名無しさん
07/02/14 18:03:33
Swingは1.4以降実用レベルになってしまったから、
SWTとかの代替候補の立場が微妙になってるのが現状じゃね?
383:デフォルトの名無しさん
07/02/14 18:12:19
あ、SWTが落ち目なんだ知らなかった。
知らないうちに勢力図が変わるんですね。
それと、デファクトだったEclipseがＳ∪∩の開発環境（何だっけ？）に負けたんでしたっけ？
384:デフォルトの名無しさん
07/02/14 18:20:25
其処までは行ってない。
むしろ、SWTの活躍の場は、eclipseしかない、という感じ。
Netbeansは、Jackpotがどうなるか、か？
誘導
Java 高速GUI SWT 3
ｽﾚﾘﾝｸ(tech板)
Java低速GUI Swing 5
ｽﾚﾘﾝｸ(tech板)
【Java】NetBeans Part2【Sun】
ｽﾚﾘﾝｸ(tech板)
385:デフォルトの名無しさん
07/02/14 18:27:26
オライリーだっけ
去年の勝ち組負け組みでEclipseを最初負け組みと書いて後で消したの
一番使われてるのに負け組みはおかしいといわれたそうだが
386:デフォルトの名無しさん
07/02/14 18:41:27
ふ〜ん
じゃぁ、NetBeansとSwing使っとけば問題無いか。
Windows上だとちょっぴりモタツクだろうけど。
でも、モッサリドトネト（流行ってないくせにWinForms、WPFと２つあって最悪）よりかはましか。
387:デフォルトの名無しさん
07/02/14 18:42:36
ごめん、もう一つ教えて。
NetBeansがEclipseをやっつけたってことは、
JBuilderとかは無用の長物？
388:デフォルトの名無しさん
07/02/14 18:50:15
ごめん、さらにもう一つだけ教えて下さい。
以前のSwingではレイアウトマネージャのおかげで、
思ったように画面作り難かったのですが、
今のSwingはポトペタしやすいですか？
389:デフォルトの名無しさん
07/02/14 18:59:48
>>388
NetBeans(の5以降で導入されたMatisseというデザイナ)を使うと無茶苦茶ポトペタしやすい。
と、漏れは個人的には思っている。
390:デフォルトの名無しさん
07/02/14 19:11:20
>>380
JNI なんぞは、1.1 の頃には既にあったわけなんだが……
誘導
★お前らJavaはJNIで組もうぜ★
ｽﾚﾘﾝｸ(tech板)
391:デフォルトの名無しさん
07/02/14 19:14:29
>>388
個人的には、GUIポトペタ(←(・∀・)ｲｲ!!)は、Netbeans。
ロジック書き書きは、eclipse。
両方使ってるよ。
NetbeansのSubversionプラグインは使いにくいし。
392:デフォルトの名無しさん
07/02/14 19:24:34
じゃ、Netbeans使います。
CVSはWinCVS（←もしかしてサイアク？）使ってるんで。
JNIもふつーに使われてますか？
393:デフォルトの名無しさん
07/02/14 19:27:48
誘導
【Java】NetBeans Part2【Sun】
ｽﾚﾘﾝｸ(tech板)
394:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/02/14 20:06:55
>>394
じゃあ標準出力はSystem("%d%d", 100, 200);でOK？
396:デフォルトの名無しさん
07/02/14 20:18:36
関数呼び出しのときの表現を変えるのをアノテーションで定義するのはどうだろう
@Alias(value = "ltgt" , type = "literal")//自作リテラル（ここでは<>）
@Alias(value = "plus_equal" , type = "operator")//演算子オーバーロード
これで実装するなら>>394は
@Alias("nameless")
ってとこか
んで、呼び出す対象のフィールドの宣言時も@AliasUsingをつける。
まぁ設計がまずいのに無理やり使わされるのもあれだしね。
397:デフォルトの名無しさん
07/02/14 21:33:06
> それと、デファクトだったEclipseがＳ∪∩の開発環境（何だっけ？）に負けたんでしたっけ？
その文字を見たら昔のSunのCMを思い出した。
398:デフォルトの名無しさん
07/02/14 21:45:16
396だけど、だめだな。
細かい仕様を定義しようとすると複雑になるし、いかに丁寧に仕組みを作っても雑に使われたら困るもんな。
よく使われるやつだけ今のString型みたいにして、アノテーションで限定解除するだけでいいか。
399:デフォルトの名無しさん
07/02/14 22:40:43
>>394
>>396
次世代Javaの動向をヲチるスレであって、
勝手な妄想繰り広げるスレじゃないから。
400:デフォルトの名無しさん
07/02/14 22:48:56
>>394
C# の Indexerっぽい奴なら、>>249 とか >>250 とかで既に出てるけど。
演算子オーバーロード関連なら、他にも >>283 の一番上のリンクとかもあったし。
401:ﾈｶﾏ由紀恵
07/02/14 23:05:20
Groovy でやっていることは
入れなくても良いんじゃ・・？
402:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/02/15 00:06:36
>>402
public type Hoge{
String hoge;
int piyo;
}
見たいな感じかな。でも予約語が・・・
JavaBeanを簡単に生成できるシンタックスシュガーが欲しいね。
404:デフォルトの名無しさん
07/02/15 00:36:38
>>402
そこで、エスケープ解析によるオブジェクトのスタック割り付けですよ。
405:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/02/15 07:18:52
>>399
昔は希望を書きまくっていた気もするが？
408:デフォルトの名無しさん
07/02/15 08:40:38
>>402
遅いからJNIするんじゃなくて、Win用C++コードをMACに移すためにJNI検討中なんです。
CocoaとかいうやつはObjective-Cだったりして困るし。
409:デフォルトの名無しさん
07/02/15 08:51:30
>>407
希望なら言語仕様作ってる人達に見える形でで出した方が通りやすいよ。
ksl とかあるんだし。
URLﾘﾝｸ(ksl.dev.java.net)
410:デフォルトの名無しさん
07/02/15 08:56:41
>>406
int Integer = 1;
System.out.println( (Integer)+10 );
とかと同じ扱いにすりゃ良いんじゃないかと思ったけど……
参照型へのキャストは 単項+ とか 単項- ついたらいかんのか。
つまり Integer って変数が宣言されてないときに
System.out.println( (Integer)+10 );
がコンパイルエラーになるから参考にならんと。むぅ。
411:デフォルトの名無しさん
07/02/15 17:24:26
>>399
ヲチりながら、愚痴るんじゃないの？
412:402
07/02/15 17:43:18
>>405
リペイントマネージャ乗っ取って全コンポーネントダーティーだと認識させればユーザーの操作に応じて常にスケーラブルでアジャスタブルなウェジェット組めるが流石にまだ重いだろうなｗ
>ベータ時代は・・・
URLﾘﾝｸ(bugs.sun.com)
これの応急処置だと思う。
JDialogに限らずOpenGL使ったコンポーネントが破壊される。
描画領域の破壊は-Dsun.java2d.opengl.fbobject=falseを指定すれば回避できるが・・・
FBO周り以外もバグがあるみたいでどうも-Dsun.java2d.opengl.fbobjectに関係なく-Dsun.java2d.opengl使った処理自体まずいみたい。
nVidiaのリグレッションバグなんだがOpenGL有効にしたらグラボ自体が不安定になって最悪システムクラッシュする。
グラボのドライバって既存アプリの描画に影響を与えるしな。リグレッションバグならそうそう戻す訳にはいかんだろうし。
>>408
結局JNI噛ます共有ライブラリ部分はネイティブなんだからリビルドするだろ？
てかwinのライブラリをmacで使おうって発想もな。
JNIにしたってネイティブ部分はプラットフォーム毎に用意するんだし。
J2MEはそれでカオスってるｗ
413:デフォルトの名無しさん
07/02/15 18:05:37
C++のコードをJavaに移植するほうが早そうだな
414:デフォルトの名無しさん
07/02/15 19:04:29
>>413ロジックのみならね。
Mac→WinだとMacしかないアプリのDLL使ったりして移植ゼロか、
Win→だとGUI周り以外はそうgdgdにならない？
415:デフォルトの名無しさん
07/02/15 19:11:21
あーJ2MEはJSR118-MR2からOpenGL実装したので専用チップ要求して更にカオスｗ
MIDP2.1はハードウェアサポートが強化されてるしウェジェットも地味に強化（新たに取り込まれたオプションパッケージが目立つ）してSEのノウハウもフィードバックされて結構良いんだが・・・
416:デフォルトの名無しさん
07/02/16 17:45:58
>>402
OpenGLといえばJava3Dを思い出した。
あちらも気が付けば大きな進展があるようだ。
JavaからOpenGLのライブラリを使えるようにするというやつ。
プラットフォーム非依存と呼ばれているJavaも3Dとなると
そうもいかないケースがあるものだが、
今後のJava3Dは古臭い時代遅れなビデオカードでは動かなく
なるか、(AWTのようにOS依存する)劣化表示
or
(Java2Dを使用したSwingのように)超低速表示されることになるんだろうか。
417:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/02/16 20:23:44
そろそろ
MFCのようにSwingをラップしたGUIフレームワークが標準でJDKに入らないかな
419:デフォルトの名無しさん
07/02/16 21:14:44
JSR 296: Swing Application Framework
URLﾘﾝｸ(jcp.org)
これどうなるかねぇ。
420:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/02/16 21:21:08
Swing Application Frameworkのプロトタイプ実装らしい。
URLﾘﾝｸ(appframework.dev.java.net)
見てみよっと。
422:デフォルトの名無しさん
07/02/16 21:55:57
SwingのラッパーはGroovyやRhinoから使うの便利そうだな
423:デフォルトの名無しさん
07/02/16 21:58:35
>>420
URLﾘﾝｸ(d.hatena.ne.jp) で話題になってた
URLﾘﾝｸ(bugs.sun.com) か？
J2SE 1.4.0 のときも、コードによっては 1.3.1 より遅くなって処理完了まで
2倍時間かかったり、とかあったしなぁ。個人的にはいつもの事だと思うんだけど。
ってか、JDK6 は既に現行世代だと何度言えば……
424:デフォルトの名無しさん
07/02/16 22:20:15
>>421
SessionStorage.WindowState って最大化状態サポートせんのか？ と思って
users@appframework.dev.java.net に検索かけたら
URLﾘﾝｸ(appframework.dev.java.net)
で、最大化状態は保持してるみたい？
最大化した状態で close(exit)した場合、最大化解除した状態のサイズは持ってないって事かな？
425:デフォルトの名無しさん
07/02/16 22:30:55
>>424
最大化解除したサイズって、どっかのメソッドで取れたっけか？
常に Frame のサイズ保存しておきながら WindowEvent おっかけて、
Frame#getExtendedState が MAXIMIZED になったら、
直前のサイズを最大化解除したサイズとして保存するとか、
Windows と他の OS で最大化する時の WindowEvent の届き方が違うので
面倒くさくて Windows だけしか対応しないとか、そんな記憶が……
426:デフォルトの名無しさん
07/02/16 22:44:31
>>423
いつものことの上、
修正コードが手早く手にはいるようになっただけで
大助かりですよね。
うまく動かなくなるバグなんて、1.4の頃ですが
GC周り突っつけばすぐ出てきましたよ。
バグ報告しても、US SUNまで訴えても直らないバグがあったりしたもんです。
直るにしても、次のリリースまで待たなきゃ駄目だしね。
427:デフォルトの名無しさん
07/02/16 22:55:57
とはいえ今はJDK7で自分で治せて配布できるようになったのは大きいかも
428:デフォルトの名無しさん
07/02/17 00:06:11
>>420
んなの初めて聞いた。バグ修正もてえへんだろうなあ。
TortoiseSVNは結構良いと思うけどなあ。ファイルの移動を
するときもわざわざ右クリックでめんどいことしないといけないけどさ。
429:デフォルトの名無しさん
07/02/17 00:10:08
>>427
直すのかなり難解だと思うが・・・。
Swingが新しくなるということは、SWTやM$のGUIよりも使い勝手がよいAPIを
作れるのだろうか。
430:デフォルトの名無しさん
07/02/17 00:11:12
そもそも新しくなるの?
431:デフォルトの名無しさん
07/02/17 00:18:35
NetBeansのSubversionは修正がされているかどうかがわざわざ再表示押さないと反映されないのがカス
コミットする前に最新状態取得しないとだめってあふぉか
CVSクライアントのほうは問題なし
というかSubversionはCVSのように自前で実装してないからなぁ
CVSモジュールに依存してるし
NetBeans3.6だったかあの時代のCVSサポート並のへっぽこさ
だから標準実装されてないのだろうね
432:デフォルトの名無しさん
07/02/17 01:02:26
>>424
> で、最大化状態は保持してるみたい？
保持してないんじゃね？単に最大化したbounds持ってるだけで。
ってか、WindowStateだしな。getExtendedState使えるのFrameだし……
433:デフォルトの名無しさん
07/02/17 02:32:28
>>431
SVNはCVSにそんなに依存していたっけか。
434:デフォルトの名無しさん
07/02/17 08:40:54
>>433
NetBeansのsubversionモジュールはCVSモジュールに依存している
435:デフォルトの名無しさん
07/02/17 19:04:07
SE 6てOSSにしてからコードの提供あったの？
６で異常な進化遂げてるし、ないならないでただのコミニュティー潰しにしか見えん。
あの超進化マジックは何？
ヒープの割当・インクリメンタルＧＣのアルゴリズム変更だけであそこまで変わるとは思えん。
＃まあ日本じゃ未だに1.4.2主流だしse7も迷走中だけど。
そろそろstaxとrhinoが使われだしても良いと思うんだ・・・
436:デフォルトの名無しさん
07/02/17 19:13:41
>>434
なんだ、そういうことか。
CVS嫌いなSubversion開発者は自分のSVN開発を批判する者に
対してかなり起こっていたからな。
「すでにCVSがあるのに、なんで独自に開発するんだ？」と質問された
ことについてもう反論していた気がする。
437:デフォルトの名無しさん
07/02/17 20:01:54
>>435
インクリメンタルGCの変化あったの?
5.0のときにトレインアルゴリズムつかわなくなってコンカレントGCになったけど
またかわったの？
速度は強度の最適化がクライアントVMでかかってるのがわかる。
演算系でサーバーVMとほぼ同じ速度が出たのはわらえた。
だからサーバーVM同梱してないのだなと。
438:デフォルトの名無しさん
07/02/18 18:07:24
レジスタ割付アルゴリズムが Linear Scan Register Allocation
とかいうものに変更されたとは聞いているが、そんなに効果があったのかー
Linear Scan Register Allocation
URLﾘﾝｸ(www.research.ibm.com)
439:デフォルトの名無しさん
07/02/18 19:25:03
従来のバイナリをいじらずおおむね2、30%速度向上してるんだよね
440:デフォルトの名無しさん
07/02/19 12:35:31
そろそろABAPみたいにSQLをネイティブに書けるようになると思うんだ。
441:デフォルトの名無しさん
07/02/19 12:59:36
>>437
インクリメンタルGCが、コンカレントGCに置き換えられたのは6からじゃなかったっけ？
5の段階では、Xinc使うなって言われてて・・・・
何か自信ないけど、パフォーマンスアップは、GCだけじゃないってのは賛成。
むしろ、Hotspot系だと思うな。
エスケープ分析効いてないかな？
というか、JDK7で盛り込むJVMの改良ってどっかで話題になってる？
JVMの機能強化ってJCPに乗らないと思うし・・・
442:デフォルトの名無しさん
07/02/19 13:03:38
5.0からだよ、コンカレントGCにかわったのは
1.4.1だったかあたりからインクリメンタルGCは採用する価値のないものだったからいい変更だと思ったけどね
トレインアルゴリズムを使いたかったらXXオプションで指定すれば5.0でも使えた
GCの性能アップだけじゃパフォーマンスが落ちるのを防ぐだけであって性能は上がらないからGC以外が主なパワーアップだろう
６でのGCチェックはまだしてないけど、5.0でGCが10、20%性能上がってたのは有名かと
443:デフォルトの名無しさん
07/02/20 19:28:14
Lucidaフォントに日本語を追加する事ってできるの
444:デフォルトの名無しさん
07/02/21 15:02:25
可能だけど莫大な金と人材と時間と日本語を熟知したフォントデザイナが必要だからsunだけじゃ不可能。
フォントならIPAフォントが抱き合わせライセンスじゃなかったら最強だと思うんだけどな。
所でJavaってGCが勝手にメモリガリガリやってるから
メモリの断片化をプログラマで制御出来ないよな？
長期間不眠不休なサーバーとかメモリ空間少ないJ2MEが辛いと思うんだけど、
今後ここら辺の解決策はないの？
緩和でも・・・J2MEのプリベリファイは良い案だったと思うんだ。
＃そういやse6でもプリベリファイ採用してるからそれが実行速度に献上してるかもな。
今思い出したｗ
445:デフォルトの名無しさん
07/02/21 16:32:00
>>444
System.GCしか今のところコントロールする方法はない。
あとはVMの実行時パラメータでヒープやアルゴリズムの調整でカバー。
ただ、System.GCはほとんどの実装でFullGC動くので実質使っちゃダメ。
System.newGCとかがあればかなり変わるんだろうけど。
ゲームとかにしろ常にシビアなタイミングがあるわけじゃなくて、今は100μsも遅れるとまずいけど
このタイミングなら10msは大丈夫とかあるからね。
1フレームに1回殿堂入りさせない新世代GCが指定できればそれでおけ。
どうもsunはここ数年リアルタイムJavaに力を入れてるんだけれども、
常にリアルタイム性が必要な用途ってのは少ないと理解してないっぽい。
446:デフォルトの名無しさん
07/02/21 17:33:20
> 所でJavaってGCが勝手にメモリガリガリやってるから
> メモリの断片化をプログラマで制御出来ないよな？
↑出来る処理系ってあるの？
447:デフォルトの名無しさん
07/02/21 17:47:52
>>446
C/C++だとメモリ管理は自分でするから確保も解放も
自分のタイミングで出来るって程度の意味だ。
勝手なタイミングでガンガンGCされるより断片化起こらないよねって話な。
448:デフォルトの名無しさん
07/02/21 18:01:42
>>447
それはおかしい
断片化と解放とは別の話だろ
それにC++だってアロケートしなおししないと同じだし
JavaのGCはそのタイミングをコントロールできないという点だけが問題
449:デフォルトの名無しさん
07/02/21 20:44:23
>>445
-XX:+ExplicitGCInvokesConcurrent
で、Java6なら完全停止は回避できる、のかな？
URLﾘﾝｸ(java.sun.com)
450:デフォルトの名無しさん
07/02/21 23:45:23
>>448
mallocなりOS依存のシステムコールで、でかいメモリとってきて、その中に
placed newでオブジェクト作れば、制御できると思う。
制御できるだけで、断片化しないメモリ確保戦略はプログラマ任せになるが。
451:デフォルトの名無しさん
07/02/21 23:50:06
>>444
GC でコンパクションが発生するのに断片化って???
452:デフォルトの名無しさん
07/02/21 23:53:01
なんか、全然次世代じゃない話で盛り上がってるな。
453:デフォルトの名無しさん
07/02/21 23:57:03
>>452
いつもの事だ。
454:デフォルトの名無しさん
07/02/22 00:01:05
>>445
> >>444
> System.GCしか今のところコントロールする方法はない。
java.lang.ref.SoftReferenceを使えば間接的にコントロールすることもできる。
455:デフォルトの名無しさん
07/02/22 00:02:05
>>445
> >>444
> どうもsunはここ数年リアルタイムJavaに力を入れてるんだけれども、
> 常にリアルタイム性が必要な用途ってのは少ないと理解してないっぽい。
彼らがJavaを作った目的は家電制御なんだけどな。
彼らはサーバを発電所のように使うものを想定している。
456:デフォルトの名無しさん
07/02/22 00:04:13
>>446
Bufferインタフェースを使って
巨大な配列を確保すれば
擬似的に管理できないこともないぞｗ
C/C++はメモリ全体を巨大な配列として扱えるようになっているのだから。
Javaでも巨大な配列をBufferで作れば似たようなことはできなくもないw
457:デフォルトの名無しさん
07/02/22 00:05:52
java.lang.refでオブジェクトの「到達可能性」をコントロールできる
香具師はいないのね
458:デフォルトの名無しさん
07/02/22 00:14:10
>>457
そりゃ、居ないだろ。
あれは到達可能でなくなった事を知るためのもので、
到達可能でなくす事を可能にしてくれるわけじゃない。
459:デフォルトの名無しさん
07/02/22 01:27:33
>>454
それ定期的に出てくるけどぜんぜんコントロールできねーよ
460:デフォルトの名無しさん
07/02/22 13:56:01
いつの世代でもGCは永遠の謎なのだ。
461:デフォルトの名無しさん
07/02/22 21:22:26
GCなしの方がよかったかもな〜
462:デフォルトの名無しさん
07/02/23 00:09:49
GCなしなんていまさらありえんだろ
463:デフォルトの名無しさん
07/02/23 00:26:43
C++に逆戻りか？
464:デフォルトの名無しさん
07/02/23 00:27:32
C++0xの使用をみたが、期待はずれだった。
あんな仕様では当分Javaには勝てないことがわかった。
D言語やC#のほうが全然魅力的だった。
465:デフォルトの名無しさん
07/02/23 00:31:08
もう使用されているとは
466:デフォルトの名無しさん
07/02/23 01:51:35
なんで、C++はそんなに使用を拡張していくんだろうねぇ…。今でも十分じゃん。
467:デフォルトの名無しさん
07/02/23 01:57:48
そうだよな。
チンコの仕様に優れていても、使用に優れてない奴とかいるし。
468:デフォルトの名無しさん
07/02/23 02:01:08
チョンの仕様かと思ったw
チョンのチンコの仕様は9cmで世界一ミクロ
469:デフォルトの名無しさん
07/02/23 02:06:38
仕様も使用もダメな例だな
470:デフォルトの名無しさん
07/02/23 04:24:39
JDK7 build08
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
サマリが何も出来ていない
変わってないのかっ
と疑問も持ちつつUpdateする俺でした
471:デフォルトの名無しさん
07/02/23 05:02:19
マネージド○○って完全にわすｒｙ
472:デフォルトの名無しさん
07/02/23 06:35:41
CompilerAPIとRhino入れちゃったらこのノリでant入れそうで怖い。
最近標準化連中は仕様作り過ぎｗ
C++のexportみたいにry
コンパイル→テスト→ビルドの流れが全てプログラミング出来ます！
みたいにさ。
マジレスするとunsignedが欲しい。
static final unsigned byte の範囲の定数が欲しいのにって度々思う
#Java書いてるとshortの存在を忘れてint使っちゃう俺
473:デフォルトの名無しさん
07/02/23 07:56:31
>>472
>static final unsigned byte の範囲の定数が欲しいのにって度々思う
short や int じゃだめってこと？
ケータイJavaかなんかかな。
474:デフォルトの名無しさん
07/02/23 08:57:09
マイナス、負の値を使えばいい。
475:デフォルトの名無しさん
07/02/23 10:10:27
>>473
そうJ2MEなんかで何かのパーサ書いてるとステータス操作に丁度0-128を使うことがあったりして。
ビット操作中心なんで負数は使えんし、
そもそもMEで使わんディスクスペースとヒープを確保する余裕はない！
そもそもstatic finalなフィールドすら宣言する余裕なんて無いんだよ。
文字列定数の長さを気にする様な世界だ。
ややこしい・・・
476:デフォルトの名無しさん
07/02/23 11:16:49
>丁度0-128を使う
嫌がらせだなｗ
477:デフォルトの名無しさん
07/02/23 11:19:44
>>475
ビット操作でも負数は使えるはずだが
478:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/02/23 13:38:05
>>472
> CompilerAPIとRhino入れちゃったらこのノリでant入れそうで怖い。
> 最近標準化連中は仕様作り過ぎｗ
> C++のexportみたいにry
> コンパイル→テスト→ビルドの流れが全てプログラミング出来ます！
> みたいにさ。
> マジレスするとunsignedが欲しい。
> static final unsigned byte の範囲の定数が欲しいのにって度々思う
> #Java書いてるとshortの存在を忘れてint使っちゃう俺
ラッパークラス作れ
480:デフォルトの名無しさん
07/02/23 13:54:21
>>475
> >>473
> そうJ2MEなんかで何かのパーサ書いてるとステータス操作に丁度0-128を使うことがあったりして。
今はJ2MEではなくJava ME。
つうか、もうそろそろ、スペック問題解決してもいいのでは。
昔と比べ、容量は10倍以上になったんじゃないのか？
S!アプリももう何年か前から1MBアプリを作れるようになったし
iアプリも903iからDoja5.0になって1MBにもなったし、今やダウンロード、スクラッチパッドの境界が
無くなって外部メモリも使えるようになって1MB以上のアプリも作れるようになったろ。
昔の10kB時代と比べたら全然気にしなくても良いようになってきたんではないのか？
481:デフォルトの名無しさん
07/02/23 13:55:32
>>476
0-127に加えて-1か128を128替わり使えばいいのではと
482:デフォルトの名無しさん
07/02/23 13:56:13
>>478
とりあえず新たにデータ型作るってのはどうよ
483:デフォルトの名無しさん
07/02/23 13:57:12
>>478
jarsで圧縮率を上げればjarサイズが半分になるぜ
484:デフォルトの名無しさん
07/02/23 21:57:02
static final は普通に、コンパイラでインライン展開することが
言語仕様で決まってなかったっけ。
485:デフォルトの名無しさん
07/02/23 22:04:07
今のJava MEではGenericsやアノテーションは
使えるのか？
486:デフォルトの名無しさん
07/02/23 22:05:35
>>484
決まってない。final で修飾されて、確実に定数式で初期化される変数だけ。
それに、ME とかの場合は static final な変数自体も節約したいんでしょ。
487:デフォルトの名無しさん
07/02/24 03:48:32
>>845
使えない。VM仕様がJITがオプション扱いでブートストラップクラスローダしかない1.4か1.3時代程度だったとオモ。
けどジェネリックスなんて使うケースないと思う。
MEじゃあるべき処理を平気でとっぱらうからアルゴリズムの使い回しとか不要。
他にも汎用データクラス作るんじゃなくて一つのクラスに全てのデータと処理をぶち込むからジェネリックスの立場がない・・・。
インターフェイスすら排除する世界だぜｗ
ところでこんなリスト見つけた。VM仕様関連の情報らしい。
URLﾘﾝｸ(www.ingrid.org)
488:デフォルトの名無しさん
07/02/24 12:23:48
>>487
ジェネリクスはコレクションを手軽に扱うためだけとおもっても十分な効果が出るよ
489:デフォルトの名無しさん
07/02/24 12:59:51
Java SE 5になってから大分高速化したのに携帯電話には
まだ搭載できないでいるのか・・・
しかもまたまた1.3レベルとは。assertも使えぬのか。
アノテーションくらいはつかえたほうがいいとは思うのだが。
コンパイル時には無視できるタイプのアノテーションはとくにあったほうが便利だろう？
それに、いくつかクラスやメソッドが増えているし。
制約上全部は使えないとは思うけど、利便性を考えると、1.3レベルってつらそう。
490:デフォルトの名無しさん
07/02/24 13:32:37
>>487
> URLﾘﾝｸ(www.ingrid.org)
古いね。デッドリンク多いし。
491:デフォルトの名無しさん
07/02/24 15:42:08
>>489
高速化したのはSunのJava SE 5の実装で、Javaっていう規格じゃないだろ。
ケータイって、SunのJVMが主流なの？
492:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/02/24 18:28:20
>>492
System.currentTimeMills()の値を引数にして
DateやCalenderを作っても正確にならない？
495:デフォルトの名無しさん
07/02/24 18:31:30
>>492
> >>491
> 主流はアプレックスのJBlend。
> 一応どこもsunのRI参照してるけど遅いとか理由付けてとことん独自実装＋JITが無いんでベンダー独自のインタプリタ高速化技術なるものを実装してRIとは別物。
遅いとかではなく、かれらがハードウェアリソースをケチっているだけだと
いってみたかったりする。
携帯電話をもう少し大型化して、JVMの部分を物理的に大きく専有するようにして、電池も
巨大化させれば携帯電話でも十分早くなるはずだ、と言ってみる。
ハードディスク搭載、とバッテリ寿命さえ延びれば、さらにその理屈もとおるはずだ、と言ってみる。
そして、連中は、独自実装で市場を独占したいだけに過ぎないのだ、
かつてのSonyがやってたような、独自製品で覆い尽くし、ライバル製品との
互換性をわざと奪うために標準Java実装から逃げているだけなのだ、と言ってみせる。
496:デフォルトの名無しさん
07/02/24 19:48:51
>>492
いやVectorとかでいいんだよ
それでも十分使い勝手がいい
中に何を格納するべきなのかをドキュメントに書かないとわからないってのは面倒だったりする
そういやJavaME用HotspotVMを開発したとかどっかのニュースみたな
携帯の用途だとhotspotよりはアーカイブ単位での丸ごとコンパイルのほうがよさそうだが
497:デフォルトの名無しさん
07/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
07/02/24 20:36:05
アサーションだから
>static final boolean DEBUG = false;
>public void assert(boolean flag, ...){
> if(DEBUG){
> if(!flag){
> ...
> }
> }
>}
みたいな感じか。細かいことだけど。
499:デフォルトの名無しさん
07/02/24 20:52:52
なるほどー。
今ならAspectJでもっと効率よくできるかな？
500:デフォルトの名無しさん
07/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
07/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:デフォルトの名無しさん
07/02/24 23:54:51
>>500
もうさ、メガアプリ限定にしてしまえばいいよ。
俺たちが作りたいソフトはこういうものだから、
ハードウェアをもっと強化しろ！
とハード屋に圧力をかけてさ。
マイクロソフトみたいに力がないと
Vistaみたいな激重Windowsを開発してハードウェア屋が
それに追従するってこと難しいかな。
今はハード基準で携帯電話開発を強いられているみたいだけど、
ソフト屋からハード屋になんとかして圧力かけられないかねえ。
「お前らハード屋がだらしないから携帯電話開発がしづらいんだ！
ハードのスペックを高めることを要求する！」
みたいにさ
503:デフォルトの名無しさん
07/02/24 23:58:12
>>500
> >>496
> いやジェネリックスが便利なのは認めてるんだけどMEだとVector使うかテストしまくって確実に足りる最小の固定長配列使うか悩むんだよ。
java.nio.Bufferを実装したクラスを配列代わりに扱えば高速化するのでは？
と思ったら、あれJ2SE1.4からのものだった。
> >>497
> 学習能力が無いね日本の企業は。ブラウザ戦争とpureJava騒動であれだけカオスったのに。
SoftBankもまともじゃないし、KDDIもまともじゃないし、Docomoもどいつもこいつも
独占欲だけは高いからねえ。
ハードウェア重視でソフトウェアをなめてかかっているところが、だらしないよ。
日本の有名な大手家電メーカーがインターネット産業ろくに力を注がず、Web2.0に
乗り遅れたことをも証明しているし。
504:デフォルトの名無しさん
07/02/25 00:04:27
>>502
とは言え、行き過ぎると Vista や PS3 の二の舞になると思うよ。
505:デフォルトの名無しさん
07/02/25 00:42:46
国内だとキャリア（←こいつが一番無関係ｗ）、世界的にはハード屋が頂点か。
どちらにしてもオープン標準のJava仕様がないがしろにされてるな。
まあ、ソフト屋ですら飼いならされてる現状じゃ仕方ないか。
仕様の地位をもっとこうW3C勧告の仕様並みに出来んかねぇ？（IEの糞実装さえなくなれば平和だからなアッチは）
ハードの方は十分にパワフルだと思うけどな・・・
翌々考えたら昔はメモリ以外今の携帯以下のハードと糞ＯＳでJavaが動いてたんだから。
win95よりce5のが安定してるしｗ
国内携帯は無駄な機能に溢れ返ってるからそれにシステムリソースとコストと
開発期間が圧迫されて一ソフトウェアどころじゃないだろうな。
またしても仕様の地位不足か・・・
SUNの苦労体質全部をJavaが担ってる気がするｗ
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5369日前に更新/271 KB
担当:undef