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)
URLﾘﾝｸ(ja.wikipedia.org)
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が担ってる気がするｗ
506:デフォルトの名無しさん
07/02/25 01:02:42
>>505
パワフルな割には容量が足りないってどういう事なんだろうなあと思うよ。
メモリもっと増やすべき。でないととてもパワフルじゃないな。
現実問題として電力消費が激しいと言う問題があるそうだ。
しかし省エネ型DRAMのようなメモリがもっと普及すれば解決できるんだとか。
つうか、携帯電話会社は、余計な機能にエネルギーを無駄に費やさず
Javaの部分にエネルギーを費やして欲しいな。
あらゆる機能をJavaを中心に動かせるようにすれば水平ポータビリティを
維持できるし、どの携帯電話でも同じように動くアプリを簡単に作れるようになる。
507:デフォルトの名無しさん
07/02/25 01:23:02
KDDIがBREWで水平ポータビリィティやろうとしてソフト屋・消費者から大ブーイング受けた結果
建前上JBlend on BREW（サービス名オープンアプリ/どこがオープン何だと小一時間・・・）のっけましたが？
Javaで水平ポータビリティ実現すればsunの当初の目的が実現するな。
その為にはベンダーに協力してもらわんとダメだが。
その前に日本の携帯ビジネスモデルを破壊しないと受け入れられないだろう。
4G携帯なんて出したらドコモが死守してソフトバンクが
嘘ばら蒔いてイーモバとウィルが歓迎するんだろうな。
KDDIはBREW動いて音楽と動画DL出来れば何でも良さそうだが。
ネイティブ開発は個人には不可能か敷居高いだろうしJava（MIDP）流行らんもんかね
508:デフォルトの名無しさん
07/02/25 01:38:36
つかネイティブ開発はCPの審査がウザイよ。
審査に金かかるわ時間もかかるわ。
509:デフォルトの名無しさん
07/02/25 06:56:24
今のケータイでJavaをやろうとすること自体が間違いなことに気づけ。
510:デフォルトの名無しさん
07/02/25 07:12:43
て事は昔の、今の携帯以下のスペックで動かしてたJava自体間違いだったって事か
511:デフォルトの名無しさん
07/02/25 10:59:44
Javaで何をするかが問題。
今の技術では、携帯に望みすぎ。
512:デフォルトの名無しさん
07/02/25 12:55:29
>>509
燃料電池またはＨＤＤが搭載されるもしくは
PDAなどもっと大型の携帯端末なら、
Javaをやる価値は少しはあるのではないかと言ってみる。
携帯キャリアメーカーもJavaに自分たちの収入源を
奪われるのを恐れて、わざとJavaの機能を制限して
Write Once, Run Anywhereの妨害をしているとおもうけどな。
彼らの、Javaの普及を妨害するやり方はつくづく陰湿だと思う。
513:デフォルトの名無しさん
07/02/25 13:37:18
>>510
CPUのクロックだけで比べても意味がないぞ
514:デフォルトの名無しさん
07/02/25 21:46:09
まあ、VMはハードウェアとＯＳを仮想化してるから下にパワーが無いとVMも非力になるな。
515:デフォルトの名無しさん
07/02/25 22:17:51
>>510
すごく間違いだと思うなあ。Java熱に浮かされてただけじゃないかな。
516:デフォルトの名無しさん
07/02/26 03:24:52
>>510
今に間違いじゃない日が来るって
おまいのPCのメモリに4GBのせなきゃVistaが・・・とか悩む日が来る事を
５年前に予想してたか？
>>512
わざとっていうか、自由はセキュリティリスクを持っているからな。
徐々に拡大してけばいいだろう
何でも出来る穴だらけの何かがデファクトになるのが怖いよ
517:デフォルトの名無しさん
07/02/26 04:23:39
>>516
>今に間違いじゃない日が来るって
それって、今は間違いってことじゃん。
間違いじゃない日がきてから実用化すればいいのに。
なんでJava以外の選択肢を考えないのかね。
Collectionも使えないなんて、そんなんJavaじゃねーよ。
道具は適材適所。そこまでしてJavaにこだわるのが分からん。
518:デフォルトの名無しさん
07/02/26 06:53:19
*7の頃から追っかけてるがあの頃の方が見向きもされなかったぞ。
それどころかボロクソに言われてた
昔はAWTすら使いもんにならなかった気がする。もっとスリムだったし。
519:デフォルトの名無しさん
07/02/26 08:18:20
Avalon・Quartz・Cairoて出そろったのになんでJavaだけJava2Dなんだよ。
新型レンダラまだー？
520:デフォルトの名無しさん
07/02/26 09:07:33
JOGLがあるよ。
521:デフォルトの名無しさん
07/02/26 10:50:29
3DはJOGLが1.0になったので使い物になった
ただ、フルスクリーン時にGLCanvasが描画されないプラットフォームがあるとかが気になる
GLJPanelは遅くてゲームなどでは実用にならないし
あと日本語ドキュメントが皆無なのがきついな
OpenGL部分はどうでもなるがそこ以外が追うのがきつい
JOGLがコアAPIになればJOGL自体の機能も充実してくると思われ
522:デフォルトの名無しさん
07/02/26 16:20:42
JOGLのコア化ってありえるか？
あるとしたら現行Java2Dのハードウェア支援コードとの統合くらいじゃない？
どちらにせよいつの時代もOpenGLはデスクトップ向けVGAのドライバ対応が中途半端だからな。
ワークステーション向けは知らんが。
523:デフォルトの名無しさん
07/02/26 16:59:41
>>516
> >>510
> 今に間違いじゃない日が来るって
> おまいのPCのメモリに4GBのせなきゃVistaが・・・とか悩む日が来る事を
> ５年前に予想してたか？
> >>512
> わざとっていうか、自由はセキュリティリスクを持っているからな。
> 徐々に拡大してけばいいだろう
> 何でも出来る穴だらけの何かがデファクトになるのが怖いよ
多重継承も演算子オーバーロードも何でもできますよとPRする
C++言語仕様じゃあるまいし。それはちょっと違うだろう。
Javaでできることはいっぱいあるのに、あえて彼らがそれをやらないのは
彼らが己の既得権益が破壊されるのを恐れているから。
日本企業はハードウェアに強い企業は多いけどソフトウェアには弱い
企業ばかりだからね。ソフト屋にハード屋をつぶされるのを恐れている。
その構図は、テレビ局などのメディアがインターネットを嫌っている理由に非常に良く似ている。
彼らがインターネットやGoogle、Web2.0を嫌っているのは、
彼らが苦労して長い時間をかけて培ってきたノウハウを破壊されるのを恐れているから。
彼らは小泉純一郎のような「痛みを伴う改革」や「格差社会」に自分たちが巻き込まれる
ことをひどく嫌い、ひどく恐れている。
524:デフォルトの名無しさん
07/02/26 17:06:04
>>517
Javaでもこういうことができるよってことで、
とりあえず宣伝だけしておいただけだと思うがな。
いや「だけ」ってことはないな。
Sunが目指していることを実現するための
前準備としての実験でもあったわけだし
一般人にも、Javaというものがどういうものか、
これで理解してもらえたかもしれないね。
最近じゃauの勢力が拡大してどうなるかわからないけど、
一応、BREWの上でJavaも動かせると言われているし。
それに携帯Javaアプリは使えるものはいくつもある。
SuicaのアプリだってＦｅｌｉＣａチップと入出力するところを除き、
アプリケーションはJavaでできている。
なんだかんだいって、燃料電池のような大容量電池を携帯電話に搭載し、
チップが小型化すれば携帯電話Javaもますます良い方向に進んでゆくと
思うけどね。
そこで、Java以外の選択肢を出すと、結局ベンダ依存になってしまう。
今でさえ、JavaアプリはSoftBankとDocomoとでは異なるAPIを使用しているとはいえ、
基本的なAPIはベンダ依存していない。Java以外の選択肢で、
複数のキャリアに対応したアプリを作ることは、そう簡単なことではなかったはず。
BREW開発なんてCPに検査してもらうコストも時間もかかるし、メモリリークの
心配ばかりしないといけないし、容量は相変わらずS!アプリやiアプリの半分くらいでとっても地獄じゃないか。
そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。
525:デフォルトの名無しさん
07/02/26 17:21:02
>>523-524
マ板行け。
526:デフォルトの名無しさん
07/02/26 17:30:02
マ板ネタも含まれているかもしれないけどJava MEの将来に対する
要望も含まれているから、ここでもいいのではないかと
527:デフォルトの名無しさん
07/02/26 17:35:53
>>526
要望なら要望聞いてくれるところで言わんと意味無かろうが。
動機からして現状を変えたいというものではなく、
単なる現状の愚痴なわけだし、完全にマ板ネタだろ。
>>523-524 は技術的な話ですらないし。
528:デフォルトの名無しさん
07/02/26 22:03:34
表題みるかぎりSE専門かと
529:デフォルトの名無しさん
07/02/26 23:23:01
技術的な話も含まれているがのう。
要望ねえ。JCPか？
530:デフォルトの名無しさん
07/02/26 23:26:20
>>529
含まれてないよ。マ板池。
531:デフォルトの名無しさん
07/02/26 23:29:54
>>530
営業やってる連中とか、プログラマ卒業した連中とかだと
>>523-524 が技術的に見えるのかもしらん。
532:デフォルトの名無しさん
07/02/27 03:14:34
むしろBREW上のJAVAで話を広げて欲しかった。
というか、そろそろ携帯でJavaSE動かすことできそうなんだけど・・・
Mysaifuの取り組みには期待している
533:デフォルトの名無しさん
07/02/27 06:00:49
>>524
>今でさえ、JavaアプリはSoftBankとDocomoとでは異なるAPIを使用しているとはいえ、
>基本的なAPIはベンダ依存していない。Java以外の選択肢で、
>複数のキャリアに対応したアプリを作ることは、そう簡単なことではなかったはず。
ダウト。Write once Run anywhere はケータイでは全然できていない。
APIも仕様も違うのに、簡単とかいうな。お前、じつは作ったことないだろ。
＃何だよ、scratch padって。
#if #else #endif が使えるC++のほうがまだケータイ向き。
でもauの審査がクソ遅いのはなんとかしてほしい。マジで。
> そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。
それこそお前が知らんだけじゃん。Pythonが使える機種があるんだけど、これなかなかいいよ。
つうかPalmOSが載ってくれれば一番よかったんだよ。なんでJavaなんだ？
534:デフォルトの名無しさん
07/02/27 07:00:15
>>532
phoneME Advancedのどこが不満なんだ！ｗ
Mysaifu JVMは俺も入れてるけど・・・。
だって～かんきょうなくてびるど出来なかったんだも～んｗｗ
まあ、冗談は置いといてphoneME AdvancedならRIだし全部入りだしHotoSpotあるし、phoneMEベースのプロジェクトを見かけた事ないのが不思議だ。
てかBREW自体流行ってないし国内じゃあうのせいでBREWの印象悪いし、正直実装さえしてくれたらKJNIの方が良いな。
もうちょっとJBlendがRI通りに実装してくれたら・・・
MIDPにMMAPIのprotocolパッケージ入れてくれたら・・・
WavPlyer実装してくれたら・・・
後はデコードくらい自分でするのに・・・
ところでMEにnioパッケージ実装しても端末の物理メモリが足りませんって落ちになるんだろうか？
535:デフォルトの名無しさん
07/02/27 07:09:12
>>533
M1000ってPalmじゃなかったけ？
MIDPが使えるからkjavaじゃなくてMIDP for Palm OSなんだろうか。
536:デフォルトの名無しさん
07/02/27 12:07:15
>>532-535
キミら、次世代と関係ない話題は他所でやってくれんかね？
次世代っても、勝手な妄想とか勝手な要望とかは愚痴と変わらんのよ。
便所に「税金安くしてくれ」って書いて要望とか言わんでしょ。
537:デフォルトの名無しさん
07/02/27 19:04:27
て言ってもSE7って情報少ないな
538:デフォルトの名無しさん
07/02/27 20:21:12
これがSDKに内包されてjavaguiが広まないかなぁ
URLﾘﾝｸ(journal.mycom.co.jp)
539:デフォルトの名無しさん
07/02/27 21:17:25
それSwing普通に使える人にとってメリットがほとんどないぞ
フレームワークがはやったから作っただけというのが近い
struts以上に薄いラッパだし、SwingWorerとダブるところも多いし
これほどメリットがないフレームワークってのも珍しい
540:デフォルトの名無しさん
07/02/27 21:33:51
ポトペタツールが対応するか次第のよーな。
541:デフォルトの名無しさん
07/02/28 09:38:38
>>533
> >>524
> #if #else #endif が使えるC++のほうがまだケータイ向き。
> でもauの審査がクソ遅いのはなんとかしてほしい。マジで。
プリ糞セッサに依存している時点で設計が全然駄目じゃん。
> > そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。
> それこそお前が知らんだけじゃん。Pythonが使える機種があるんだけど、これなかなかいいよ。
Python載せられることのどこがいいの理解できない。
542:デフォルトの名無しさん
07/02/28 22:01:15
どこかで見たような・・
543:デフォルトの名無しさん
07/02/28 22:22:37
>>533
んー、まえもimodeスレかMIDPスレで書いたけど、#ifdefのような条件
コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん
だよね。C/C++の後追いだからちゃんと考えられてる。仕様書よんでごらん。
そのほかJavaME向けにインライン展開がんがんつかうようなコンパイラ
併用してクラス設計すると携帯向けでもプリプロセッサって必要ない。まあ
マクロはないから文法ひっくりかえすような表記でコードは書けないけど、
それはC/C++でも行儀良くないからな。
544:543
07/02/28 22:31:04
スレ違いの話だけだとあれなんでSEの話もふっとく。
URLﾘﾝｸ(techon.nikkeibp.co.jp)
↑
OSGi(JSR232)はJavaMEの分野では静かに着々と浸透しているのに
SEへの導入(JSR291)は及び腰なんだよな、Sun。自分で旗振って
OSGi始めたのにいまさら梯子外すのはないよなあ。
545:デフォルトの名無しさん
07/03/01 09:21:12
>>543
>#ifdefのような条件
>コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん
だからそれはJ2SEのような環境が統一されている場合の話であって、
機種依存が激しい携帯ではなりたたないって。
VMですら機能やバージョンが違うのに。
>そのほかJavaME向けにインライン展開がんがんつかうようなコンパイラ
>併用してクラス設計すると携帯向けでもプリプロセッサって必要ない。
インライン展開があればプリプロセッサは必要ないという根拠が分からん。説明よろしく。
546:デフォルトの名無しさん
07/03/01 10:02:45
>>543
>#ifdefのような条件
>コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん
MEで一つのソースの中に複数ターゲット向けのコード混ぜたら絶望的なソースになるよ？
最低プロファイル・機種毎にソース分けんと確実に死ねる。
jadも分けんとたまにハマるから油断できん！
547:デフォルトの名無しさん
07/03/01 10:13:36
あー言い忘れたeclipseでリファクタリングしただけでエミュでは動いて実機では動かなくなるのがMEの世界だ。
システムが勝手に走らせる特定のスレッドの実行が一定時間以内に終わらないと強制終了とか。
実行時例外catchしてcatch節でコード実行すると問答無用で落とすとか（catchしても何もしなければ良かったり、ときにはcatchすら許してくれない）
あと実機じゃ機嫌悪いと動くコードもマジで動かん。
MEでプリプロセッサ使ったソースなんて保守以前の問題。
548:デフォルトの名無しさん
07/03/01 10:58:01
>>545
>だからそれはJ2SEのような環境が統一されている場合の話であって、
>機種依存が激しい携帯ではなりたたないって。
>VMですら機能やバージョンが違うのに。
つーか、J2SEでも、Sun/IBM VM間のクセの違いの吸収や、
Sun VMでもSwingの1.4, 5, 6での差を吸収させるのに、#ifdefは欲しい。
549:デフォルトの名無しさん
07/03/01 11:39:58
いやだからそういう次元じゃないとｒｙ
MEやれ
550:デフォルトの名無しさん
07/03/02 00:07:56
>>548
SEで、ifdefは勘弁して欲しい。
それなら、せめて其処のコードは別クラスに分けて設計してくれよ・・・
551:デフォルトの名無しさん
07/03/02 20:50:21
JDK7 build09
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
何だろう？2回続けてサマリがないビルドだ・・・
まあ今回もupdateするけど～
552:デフォルトの名無しさん
07/03/02 21:32:24
>>551
>>470 のリンク先見たら前回のは出てる。
ビルド方法でトラブってて changes が自動生成できてないから、
後から手動で生成してるとか？ それとも単に怠慢で遅れてるだけ？
553:デフォルトの名無しさん
07/03/03 07:27:48
フィールドのgenericTypeを取りたいんだが方法はある？
例：List<Integer> listのInteger
554:デフォルトの名無しさん
07/03/03 08:19:37
>>544
べつに無理にJava標準に含めることを早めなくても問題なかろ。
早めることよりもむしろ、理にかなってこそ導入すべきだが。
Javaを駄目にするおそれがあるとしてJavaに導入することをまだ認めていないだけだと思うぞ。
JCPは少なくとも、Java SE 1.3以降からの上位互換性をもの凄く気にしているようだから
下手にほいほいと導入するわけにはいかんでしょうや。
そう考えると、enum型の導入が遅くなった理由もなんとなくわかる。
OSGiはなぜかEclipse Communityががんばっているようだし。
Eclipseのプラグインフレームワークに導入されているが、
SunとIBMだもんね。そういうところでは決して仲がよいとはいえないしねえ。
SWTを巡る技術的な問題もあるし。Swingは遅いからSWTを作ったと主張してきたIBM
に不信感を抱いているのではないかな？
555:デフォルトの名無しさん
07/03/03 08:22:53
>>548
駄目だお前。
ソフトウェア工学をなめとる。
修行が足りんぞ。
556:デフォルトの名無しさん
07/03/03 08:24:07
>>553
get(i)
557:デフォルトの名無しさん
07/03/03 08:28:45
>>553
URLﾘﾝｸ(download.java.net)
558:デフォルトの名無しさん
07/03/03 08:50:51
>>557
$ cat Test.java
import java.util.List;
import java.util.ArrayList;
import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;
public class Test {
public static void main(String[] args) {
ArrayList<Integer> l = new ArrayList<Integer>();
Type type = l.getClass().getGenericSuperclass();
ParameterizedType pt = (ParameterizedType)type;
for (Type t: pt.getActualTypeArguments()) {
System.out.println(t);
}
}
}
$ java Test
E
ありゃ。
559:デフォルトの名無しさん
07/03/03 09:02:20
class IntegerList extends ArrayList<Integer> {}
public class Test {
public static void main(String[] args) {
Type type = IntegerList.class.getGenericSuperclass();
for (Type t: ((ParameterizedType)type).getActualTypeArguments()) {
System.out.println(t);
}
}
}
とすると
class java.lang.Integer
となるな。
560:デフォルトの名無しさん
07/03/03 11:03:18
>>553
List<Integer> の Integer はコンパイル時に情報消えるよ。
>>559 みたいなのは特殊な例。
561:デフォルトの名無しさん
07/03/03 11:15:54
って、ローカル変数じゃなくてフィールドの宣言についてか。
public class test {
public List<Integer> sample;
public static void main(String[] args) throws Exception {
for (Type t: ((ParameterizedType)test.class.getField("sample").getGenericType()).getActualTypeArguments()) {
System.out.println(t);
}
}
}
>java test
class java.lang.Integer
562:デフォルトの名無しさん
07/03/03 11:21:52
>>558はgetClassしてる時点でどうなるかをかんがえればよろし
563:デフォルトの名無しさん
07/03/03 14:24:41
>>553
初心者質問スレ行けよ。
564:デフォルトの名無しさん
07/03/03 15:28:47
>>556-563
㌧
565:デフォルトの名無しさん
07/03/04 09:29:05
>>551
追記：
見た目で大きく変わるところ発見。
Javaのウィンドウのデフォルトアイコンがデュークのアイコンになってる！！
可愛いです。
デュークのライセンス変更で、こういう事になったのね
わかりにくいカップよりコレはいいな
566:デフォルトの名無しさん
07/03/05 16:02:11
invokedynamic 使えるかどうかプログラム側から判断するのって、どうすれば良いですか？
567:デフォルトの名無しさん
07/03/05 16:44:34
>>566
実行時に動的でも静的でも良いから invokedynamic 使ったクラス読み込んで、
エラー出たら使えないんじゃね？
そーいや、invokedynamic って今どーなってんだろ？
invokedynamic のオペランドとかの詳細あったっけか？
568:デフォルトの名無しさん
07/03/11 15:34:36
某スレの 288 へレス。
> クロージャよりは揉めずに入りそうな気がしてる。
ウソはいかん。javac の人なんかはイラネって言ってるし。
URLﾘﾝｸ(blogs.sun.com)
要は、プロパティに dot でアクセスしようとすると、
既存のフィールドアクセスと区別つかなくなるので、後付の面倒なルールを加える必要があるから嫌だそうで。
例えばフィールド宣言したコンパイル単位ではフィールドアクセスで それ以外ではプロパティアクセスとか、
プロパティと同名のフィールド持てないとか、そんな感じのルール。
どんなルールで対処するにせよ、完全な互換性維持は無理だろうし。
もしくは "->" とかでプロパティにアクセスする とかだけど、これはこれでキモイから嫌なんだそうで。
URLﾘﾝｸ(weblogs.java.net)
ksl でプロパティの試験実装してた人とかも、
Access to property は setter getter で、って意見変えてるし。
569:デフォルトの名無しさん
07/03/11 17:20:57
>>568
そうか、キモイか・・・うん、キモイなぁ
dotを使うのは、駄目と言う点は全く賛成だが
表記方法さえ、決まればOKだと思ってるんだけどなぁ
俺は、個人的な好みは->はキモイけど、 : ならOKです。
570:デフォルトの名無しさん
07/03/11 17:41:54
::
.
.*
->
->*
いろんな言語のaccessor。あと何があったっけ？
571:デフォルトの名無しさん
07/03/11 17:48:11
>>569
オレ自身は "->" でもいいじゃん、とか思ってたりする。
他の人が "->" がキモイって言うのも理解できるんだけど。
URLﾘﾝｸ(jroller.com)
${classInstance.propertyName} みたいに ${} で括った部分では
式言語使えるようにすりゃええやん、ってのも出てるけど……
そこまでして dot に拘らんでも、と思わなくもない。
572:デフォルトの名無しさん
07/03/11 18:14:36
>>569
:: じゃなくて : なの？
class A { property Object b; }
class B { property Object c; }
class Hoge {
A a; B b; Object c;
boolean flag;
Object method(){
return flag ? a : b : c;
}
}
とかされると分かりにくくなるよーな気もする。
構文解析自体は結合順位とかがあるから出来ると思うけど。
573:デフォルトの名無しさん
07/03/11 18:15:17
dot人気ないね。
フィールドアクセスとプロパティのインターフェースを別のものにしたら、
単なるgetter/setterの省略表記になってしまってあまりうまみがないと
思うのは俺だけかな？
574:デフォルトの名無しさん
07/03/11 18:42:44
>>573
皆が納得できる上手いルールが作れれば dot でも良いと思うけど。
人気がないって言うよりも、>>568 のような追加ルールを決める部分を
誰もやりたがらないような気もする。
簡単なルールで互換性壊したりすれば既存のソース使えなくなった人から嫌われるだろうし、
なるべく互換性維持しようとすると、ルールが複雑になって
今度はコンパイラの作者とかから嫌われるだろうし。
>>132 のリンク先が紹介された後、"->" はキモい、dot が良いって言ってた連中の
blog 見た感じだと、>>568 みたいな問題を小さく考えてるか、
もしくは問題自体を理解してないような。
C# みたく最初から言語機能としてプロパティを持ってる言語ならともかく、
Javaの場合は既存のJavaBeansのプロパティがあって後付けしようとしてるんだから
getter/setter の省略表記と割り切った方が現実的じゃないかな？
575:デフォルトの名無しさん
07/03/11 22:38:47
>>572
あ、いや、: ←コロンを使うという意味だった。
Perl、Pnutsなんかで親しんでいる例からいくと、 :: で使うのを想定してた。
一つだと、 hogehoge==null？a : b;
とか、switchが混乱するから。
>>573
いや、むしろそれがいい。
見たら裏で何をしているかがよく分かる。
別に、dotではなくて :: でも可読性は落ちないと思う。
-> は、演算記号と紛らわしくて、嫌。
576:デフォルトの名無しさん
07/03/11 23:03:00
プロパティなんてそもそも本質的には冗長な機能なんだから、
どうせ使えるようにするならマイクロソフト系の言語と同じ記法でいいと思うんだがなあ。
577:デフォルトの名無しさん
07/03/11 23:08:52
> マイクロソフト系の言語と同じ記法でいいと思うんだがなあ。
具体的には？
578:デフォルトの名無しさん
07/03/12 03:22:06
C++で->使ってるから、->でいいや。
579:デフォルトの名無しさん
07/03/12 04:10:14
>>576
VBだとdotじゃなかったっけ？
580:デフォルトの名無しさん
07/03/12 08:32:28
>>577,579
VB,C#ともどっとだね。
仕様策定してる連中がドットを嫌う理由がよくわかんない。
どうせ現存するソースコードにはプロパティ使ってるものなんて無いんだから
新しくプロパティの意味を持たせても別にいいと思うんだが。
581:デフォルトの名無しさん
07/03/12 08:50:48
>>580
C# だと、同名のプロパティとフィールドは同時に宣言できないんだっけか？
まぁ、そーゆー後付けのルール追加すりゃ出来るかもしれんけどさ。
Javaに、そんなルール後付けしたら互換性無くなるし。
なんでこんな簡単な事が理解できないのかわかんない。
582:デフォルトの名無しさん
07/03/12 08:55:00
>>581
プロパティ自体後付けじゃん…て思ったんだけど、
setter/getterペアにアクセスする演算子のことなのか。
プロパティ定義の構文も新しく作るのかと思ったよ。
C#の Property Hoge { ～ } みたいにさ。
だったら「そんなもんｲﾗﾈ」に一票だなあ
583:デフォルトの名無しさん
07/03/12 09:19:05
>>582
> プロパティ自体後付けじゃん…て思ったんだけど、
JavaBeans のプロパティ自体はあって、その構文糖を追加しなければならない。
だから、完全に後付けってわけでもない。
JavaBeansのプロパティや、それを使ってる既存のフレームワーク捨てるなら別だけど。
あとプロパティ定義の構文を新しく作っても、プロパティアクセスに dot 使えば問題は出る。
例えば、
class MyComponent implements java.beans.DesignMode {
private boolean designTime;
public boolean isDesignTime(){ return designTime; }
public void setDesignTime(boolean f){ designTime = f; }
}
みたいな既存のコードがあるとする。
プロパティが追加されて java.beans.DesignMode が
interface DesignMode {
public static final String PROPERTYNAME = "designTime";
public abstract property designTime;
}
みたいに変更された場合に、MyComponent をコンパイルする（＝互換性を持つ）のが難しい。
584:デフォルトの名無しさん
07/03/12 09:57:09
>>580
> 仕様策定してる連中がドットを嫌う理由がよくわかんない。
dot 使ったらフィールドアクセスとプロパティアクセスの区別がつかなくなると何度言えば……
585:デフォルトの名無しさん
07/03/12 10:02:47
>>580
> どうせ現存するソースコードにはプロパティ使ってるものなんて無いんだから
ひょっとして、現存するソースコードに Beans のプロパティ持ってるものが
大量にあるって事がわかってない？
586:デフォルトの名無しさん
07/03/12 11:37:56
だからさ、プロパティってのはgetter/setterペアのことじゃなくて
それとは別に新しい概念を持ち込むのかと思ってたって>>582に書いたでしょう。
何嬉しそうにツッコミいれてんだよ。
587:デフォルトの名無しさん
07/03/12 11:41:08
> 何嬉しそうにツッコミいれてんだよ。
いや、無知だなぁ、と思って。
588:デフォルトの名無しさん
07/03/12 11:51:08
>>587
どの辺が無知だったか教えてちょ。勉強するから。
589:デフォルトの名無しさん
07/03/12 11:56:57
>>588
このスレに出てるのだけでも、プロパティに関するリンク先読んでれば
beans と関係のない新しいプロパティを導入するとか思わんでしょ。普通。
590:デフォルトの名無しさん
07/03/12 13:21:21
>>589
そうだな。すまんかった。
591:デフォルトの名無しさん
07/03/12 20:35:44
>>583
>みたいに変更された場合に、MyComponent をコンパイルする（＝互換性を持つ）のが難しい。
ここがよくわかんないんだけど、誰か解説して。
アクセッサがあればそちらを優先的に使う（あるいは逆にフィールドアクセスを優先する）というルールを決めればすむ話じゃないの？
で、583みたいな状況になったらコンパイラが警告を出してくれればそれでいいと思うんだけど。
592:デフォルトの名無しさん
07/03/12 20:47:38
>>591
> アクセッサがあればそちらを優先的に使う
それやったらコンパイルが通らん。
> フィールドアクセスを優先する
フィールドでプロパティを上書きできるようになるけど、それで良いんか？
593:デフォルトの名無しさん
07/03/12 20:56:24
× フィールドでプロパティを上書き
○ フィールドでプロパティを覆い隠し
594:デフォルトの名無しさん
07/03/12 21:00:25
>>592
> > アクセッサがあればそちらを優先的に使う
> それやったらコンパイルが通らん。
いや、コンパイルは通るかもしれんが……
例えば
> public boolean isDesignTime(){ return designTime; }
は public boolean isDesignTime(){ return isDesignTime(); }
に展開されるから実行時に StackOverflowError 吐いて死ぬ。
595:デフォルトの名無しさん
07/03/12 21:20:38
>>584
区別させないのがプロパティだろうに。
596:デフォルトの名無しさん
07/03/12 21:24:32
>>595
コンパイラが区別できないって意味なんだけど。
人間が区別しないとか、区別を意識させるべきでないってのとは別の話だよ。
597:デフォルトの名無しさん
07/03/12 22:11:17
>>596
まぁ互換性を維持してのプロパティの導入には実装上の困難を
解決できていないというのはいいんだが、だからといって
「できる方法で実装しちゃおう」となるとしたら賛成できないなぁ。
互換性の面から考えた場合、方法は大きく3種類に分類できて、
1.JavaBeansと相互に互換性のある方法
2.JavaBeansとは互換性がないが、バイトコードレベルでの
仕様変更を伴わない方法
3.バイトコードレベルで拡張する方法
このうち、3.を採用すると何でもありだから議論から除外するとして、
個人的には1.には拘らないから2.でうまいことやってくれないかなと
思うんだが。
598:デフォルトの名無しさん
07/03/12 23:05:53
>>597
1 の場合はともかく、2 や 3 の場合は コンパイラ実装するとか言語仕様追加する、
とかってのは一番楽な部分だからね。
JavaBeans を切り捨てるってのは、技術的というより政治的な問題だから、
ハッカー気質が強い人ほど、自分でコード書いたりする時間がなくなって
政治的な問題に時間を取られる、って予感があるので手を引きたがる。
2 の場合は機能を欲しがる人は居るかもしれんけど、
（2 をやれるだけの政治的立場とか確保してる人の中で）
やりたがる人は居ないと俺は思うから、たぶん実現できないと思う。
599:デフォルトの名無しさん
07/03/12 23:18:49
> JavaBeans を切り捨てるってのは
切り捨てるわけじゃないか……
でもまぁ、標準API とかで setter/getterと新プロパティ共存させるとか
標準API とかの setter/getter を新プロパティで置き換えるとかってなれば
厄介な政治的問題だってのは予想できるでしょ。
言語として 2 のプロパティ持ってても、
標準API は 2 のプロパティをサポートしませんとかなったら間抜けだし。
600:デフォルトの名無しさん
07/03/12 23:26:45
> でもまぁ、標準API とかで setter/getterと新プロパティ共存させるとか
こんな決定したら 袋叩きにあうような気もする。
メンテ面倒くさいし。
enum でも、似たような事やってたけどさ。
enum だと、自前の enum を定義するクラスが比較的少ないから
メンテが面倒って不満がそれほど大きくならんかっただけだと思うし。
601:デフォルトの名無しさん
07/03/12 23:30:42
XMLEncoderがenumに対応してないと気づいたときに、Javaは終わったと思った。
602:デフォルトの名無しさん
07/03/12 23:34:54
これ?
URLﾘﾝｸ(bugs.sun.com)
603:デフォルトの名無しさん
07/03/13 08:40:52
>>592
>それやったらコンパイルが通らん。
だから具体的に説明してくれって。頭の悪い俺でも分かるように。
>フィールドでプロパティを上書きできるようになるけど、それで良いんか？
これが問題になるのって、フィールドがnon privateのときだけだよね。
フィールドもアクセッサもpublicというのはちょっと考えにくいから、これでも別にいいと思うけど。
>>594
>例えば
>> public boolean isDesignTime(){ return designTime; }
>は public boolean isDesignTime(){ return isDesignTime(); }
>に展開されるから実行時に StackOverflowError 吐いて死ぬ。
これ、展開させたらだめだよ。インスタンス変数に全くアクセスできなくなる。
展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。
これなら大丈夫じゃない？
604:デフォルトの名無しさん
07/03/13 09:35:33
>>603
> これが問題になるのって、フィールドがnon privateのときだけだよね。
違う。例えば
class A{ public int field = 0; }
class B extends A{ private int field = 1; }
class C { public static void main(String[] args){
System.out.println( new B().field );
} }
とかだと A の field にアクセスできんでしょ？
つまり、private なフィールドでも public なプロパティを覆い隠せる。
ってか、言語仕様読んでも、なんで Ａ の field にアクセスできないのか
俺には良くわからんのだが…… 覆い隠しって単純名だけに作用するんじゃないんかな？
> これ、展開させたらだめだよ。インスタンス変数に全くアクセスできなくなる。
そうだよ。だから無理だって言ってるじゃん。
> 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。
そんな無茶な。現行の言語仕様では foo.bar と this.bar は区別してないし。
605:デフォルトの名無しさん
07/03/13 09:38:13
>>603
> 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。
> これなら大丈夫じゃない？
package-private もしくは protected な フィールドと、
public なプロパティで問題起こるから解決になってない。
606:デフォルトの名無しさん
07/03/13 10:13:00
>>604
> 覆い隠しって単純名だけに作用するんじゃないんかな？
違うか。覆い隠しじゃなくて、隠蔽されたフィールドは継承されないから、
B のインスタンスからは A の field にはアクセスできないのか。
名前の章ばっかし見てたら理解できんかった。
607:デフォルトの名無しさん
07/03/13 10:17:35
どっちにしろ、今更プロパティを言語仕様に導入しようなんて考えるのが間違ってる。
608:デフォルトの名無しさん
07/03/13 12:25:26
間違い、とまでは思わないけどね。
609:デフォルトの名無しさん
07/03/13 13:47:17
>>603
> 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。
これだと、他にも穴があるか。
class A implements Compareble<A>{
private int field; public long getField(){ return field; }
public int compareTo(A another){ return this.field - another.field; }
}
とかがコンパイルエラーになる、と。
610:デフォルトの名無しさん
07/03/13 15:00:26
> 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。
(this).bar とかだと どうすんだろ？
611:デフォルトの名無しさん
07/03/13 16:53:37
ってか、そーゆールールなら
・フィールドが可視ならフィールドアクセス
・そうでなければ、プロパティがあるならプロパティアクセス
とかの方が良いような気もする。
それでも static なプロパティを許したりすると、同名のメンバークラスと衝突するし。
ってか、同名のフィールドが可視なら shorthand syntax for accessing properties
を使えないのって、本当に使いやすいかも結構問題のような？
612:デフォルトの名無しさん
07/03/13 19:42:20
何か激しく壊れてない？
URLﾘﾝｸ(download.java.net)
613:デフォルトの名無しさん
07/03/13 19:42:27
>>604
>違う
というのは勘違いということでいいのかな？
>そうだよ。だから無理だって言ってるじゃん。
だから『 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく』といっているんだけど。
>そんな無茶な。現行の言語仕様では foo.bar と this.bar は区別してないし。
なんで無茶なの？区別してないなら区別すればいいじゃん。thisは予約語なんだから簡単じゃん。
614:デフォルトの名無しさん
07/03/13 19:48:30
>>613
＞なんで無茶なの？区別してないなら区別すればいいじゃん。thisは予約語なんだから簡単じゃん。
汚い設計。
わかりにくいです。
あとマルチスレッド周りで問題がでそうだな。
615:デフォルトの名無しさん
07/03/13 20:05:41
>>613
> というのは勘違いということでいいのかな？
いや、覆い隠しは勘違いだったけど、
private フィールドで public なプロパティを隠蔽できるから問題になるのは変わらない。
> 区別してないなら区別すればいいじゃん。
区別しても、 >>605、>>609、>>610 みたいな穴があるから、やるだけ無駄。
616:デフォルトの名無しさん
07/03/13 20:44:57
>>611
どっちかっつーと dot でプロパティアクセス許す場合、
フィールドと同名のプロパティを作れるってのが混乱の元だとか認識されてんのかも？
617:デフォルトの名無しさん
07/03/13 20:51:03
> あとマルチスレッド周りで問題がでそうだな。
問題でるかな？
618:デフォルトの名無しさん
07/03/13 20:53:23
>>613
> なんで無茶なの？
根本に近い方のルールを書き直すってのは、
既存のコンパイラを改変する時に多くの労力がかかりそうだってのは分かるでしょ？
だから無茶なの。
619:デフォルトの名無しさん
07/03/13 21:20:36
>>571
> ${classInstance.propertyName} みたいに ${} で括った部分では
> 式言語使えるようにすりゃええやん、ってのも出てるけど……
ksl の 課題追跡にあった
URLﾘﾝｸ(ksl.dev.java.net)
に似てるっちゃ似てるかも。
でも、ecmascript みたいに Java と同じく } でブロック終了する言語だと
対応とるの大変そうだなとか思った。その辺は EL だと楽だけど。
620:デフォルトの名無しさん
07/03/13 21:34:43
ヒアドキュメント＋式言語ってのが良さそう
Velocityが標準になるみたいな感じだが。
621:デフォルトの名無しさん
07/03/13 22:29:53
>>616
要は、今の仕様で
private int xxx;
というフィールドと
public int getXxx()
というメソッドが混在できる以上、フィールドの延長上のプロパティと
getter/setterの延長上のプロパティとは相容れないわけだ。
いまのキモいJavaBeansのgetter/setterはプロパティとはなんの
関係もないことにすりゃ、それで解決すると思うんだけどね。
622:デフォルトの名無しさん
07/03/13 22:49:49
>>621
> いまのキモいJavaBeansのgetter/setterはプロパティとはなんの
> 関係もないことにすりゃ、それで解決すると思うんだけどね。
仮に、それをやっても「解決する」のは言語仕様の問題だけで、
ライブラリ＆フレームワーク＆ユーザーコードの方に問題を押し付けてるのような。
それなら、ぶっちゃけ新しい言語作っちゃった方が速いと思う。
623:デフォルトの名無しさん
07/03/13 23:18:12
>>622
上の方でだれか言ってたけど、フレームワークのプロパティとは無関係な「Java言語プロパティ」
を作ってもいいんじゃないか。紛らわしいなら名前は変えてもいいけど。
そもそもなんでプロパティ構文が欲しいんだ。ドットネットが羨ましいんだろうか。
624:デフォルトの名無しさん
07/03/13 23:24:53
>>622
「問題」って、どんな問題かな？
別に既存コードの変更が迫られるわけじゃないっしょ？
625:デフォルトの名無しさん
07/03/14 00:09:08
>>623
むしろstructが羨ましいんじゃないか？
626:デフォルトの名無しさん
07/03/14 02:48:40
>>624
互換性を確保しつつ新プロパティを使おうと思ったら、
既存のプロパティと、新プロパティの両方管理しなきゃいけなくなる。
二重のコストを払う必要が出るんだから、普通は問題になる。
おまけに、フレームワークやライブラリが二重のコストに耐えかねて
既存のプロパティを捨てたら、やっぱり既存のコードを書き換える必要が出る。
直接コードの変更を迫ってないだけで、間接的にコードの変更を迫ってる。
627:デフォルトの名無しさん
07/03/14 07:18:35
>>626
プロパティが導入されたからといって、既存のコードを無理に
対応させることはないでしょ？別物なんだから。
それに例えば、ジェネリクスが導入されたとき、それに対応して
書き換えられたフレームワークはあったし、もちろんそれを利用
しているユーザーコードも書き換えられることがあったけど、
それは別に変更を余儀なくされて行ったわけじゃないよね？
628:デフォルトの名無しさん
07/03/14 07:52:01
>>627
> それに例えば、ジェネリクスが導入されたとき、それに対応して
Generics の場合は「JavaBeans とは無関係なプロパティ」導入と違って、
例えば Collection フレームワークを Generics対応に書き換えたら、
互換性が完全に無くなるってわけではなかったけど、
「JavaBeans とは無関係なプロパティ」の場合は、
「JavaBeansのプロパティ」のサポートをうちきれば互換性が無くなるし。
例えるなら enum の方が近いな。int enum と typesafe enum の両方を提供してるAPIがあって。
それにはコストがかかる。int enum だけ、typesafe enum だけを提供してるAPIもあるけど、
プロパティの場合は影響範囲も、統一的に扱う必要性も enum の時より大きいから
両方の提供がより大規模に起こるのは容易に想像できる。
「JavaBeansのプロパティ」と「JavaBeans とは無関係なプロパティ」は共存可能って話なんだろう？
互換性維持のためには「JavaBeansのプロパティ」が必要で、
新機能対応のためには「JavaBeans とは無関係なプロパティ」が必要で、
それを両方管理しようとすりゃコストはかかる。問題になるだろ、普通は。
629:デフォルトの名無しさん
07/03/14 08:10:26
定義はgetter/setterで行って、呼び出すときだけプロパティみたいにも使えるようにするのじゃダメ？
例えば、p=a.getXxx()をp=a.xxx、a.setXxx(p)を a.xxx=pとか。
630:デフォルトの名無しさん
07/03/14 08:37:50
>>629
それだと dot でやるのが面倒。
既存の getter/setter に使われてる「プロパティの名前」と
同名のフィールドが存在可能だから。
631:デフォルトの名無しさん
07/03/14 08:39:25
>>628
そのコストってのもフレームワークの作者とかはともかく開発者は関係ないね
632:デフォルトの名無しさん
07/03/14 08:44:16
>>631
何より、無駄にバグのリスクが増えるし、
標準APIとかでドキュメントの翻訳に時間がかかるようになるとも考えられるね。
633:デフォルトの名無しさん
07/03/14 08:45:07
>>631
開発者というより、末端ユーザだな
634:デフォルトの名無しさん
07/03/14 09:10:34
>>629
a.xxx と同名のフィールド a.xxx があった場合、扱いが面倒。
互換性を考えるなら >>611 あたりのルールが落としどころかとも思うけど、
public な同名のフィールド使えば、プロパティに触れなくする事ができたりするし、
完璧とはいいがたい。
言語仕様に書く文言も相当慎重に選ばないと、
デフォルトパッケージのクラスが import 出来なくなったみたいに、
言語仕様の文言から副作用がでる可能性も……
もっとも、import の方は意図しない副作用なのか意図的なものか、
ちゃんと知らんのだけど。
635:デフォルトの名無しさん
07/03/14 12:24:27
マルチコア対応は言語に乗っかるのか、VMに乗っかるのか・・・
636:デフォルトの名無しさん
07/03/14 12:37:32
>>627
Genericsは、既存の一般コードに関しては意味の変更なく使えたぞ
>>632
さすがにそのコストを考えるのは臆病すぎｗｗｗ
>>635
マルチコア対応って一体何なのか分からない。
なぁ、何でみんなdotにこだわるの？
別の記号にして、定義も全く別にすればスッキリ導入なんだけど？
バイトコードは拡張しないと駄目だろうけど。
637:デフォルトの名無しさん
07/03/14 12:48:08
>>636
> 別の記号にして、
dot 以外の記号はキモイから嫌らしい。
> 定義も全く別にすれば
既存の資産と協調して使えないので、導入しても嬉しさ半減。
> バイトコードは拡張しないと駄目だろうけど。
バイトコード拡張は必要ないでしょ。
クラスファイル仕様は弄るかもしらんけど。
638:デフォルトの名無しさん
07/03/14 12:50:02
>>635
マルチCPU対応のVMだったら、マルチコアも そのまま使えるんじゃない？
ってか、マルチコア対応を言語にのっけるってどーやるんだ……
639:デフォルトの名無しさん
07/03/14 13:13:07
そういやRhinoのLiveConnectは実装側で拡張されててJavaObjectのゲッタ(getXxx)・セッタ(setXxx)にJavaScriptObjectのプロパティ(xxx)からアクセス出来たな。
JavaBeans使ってたんだろうか？
結局JavaScriptObjectのプロパティからアクセスしようとした時JavaObject側にxxxってフィールドがあると衝突して使い物にならないから
LiveConnectには元々ない後付けされた機能なんて不完全だって言われてたな・・・。
オライリーのサイ本にも指摘されてたような。
640:デフォルトの名無しさん
07/03/14 13:39:56
>>626
阿呆だな。もっと簡単な問題があるよ。
>>624
JavaBenas のプロパティと別のプロパティなわけでしょ？
標準API とかの既存の interface に abstract な property を追加したら
既存のコードの中で、そのinterface を実装してて JavaBeans とは別のプロパティを
実装してないクラスがあれば、互換性に問題が出る。
互換性に配慮したら interface に迂闊にプロパティ追加できない。
それだと、たぶん使い物にならない。