現世代Javaの動向 1 - 暇つぶし2ch

現世代Javaの動向 1 ..

396:デフォルトの名無しさん
07/11/28 12:55:56
JWSで使う証明書は、３つくらい選択肢がある。

(1). VeriSign や Thawte などの認証局から信頼できる証明書を取得する。
(2) Thawteの無料証明書を取得する。
(3) オレオレ証明書を自分で作成する。

1は正統な方法だが年間6～9万円くらいかかる。
フリーソフトの配布には現実的ではない。

(2)は(3)に毛がはえた程度の証明書だが、一見まともな証明書にみえる。

フリーソフトの配布には(2)と(3)を比べると(2)のほうが一見ふさわしいように思えるが、
ちょっと穴があるような気がするのよ。

JWSで起動する直前ダイアログが出て「この認証局をつねに信頼する」という
チェックボックスがあって、これにチェックを入れると次からこのダイアログは出ない。

アプリ起動のたびにダイアログがでるのはうざいから、ユーザはチェックを入れたくなる。
しかしチェックを入れると、結局(2)の認証局をすべて信頼するわけだから、他のサイトで
それを使っているJWSで動くアプリにも同じ条件が適用されてしまう。
(2)の無料認証局を使うと、他所のアプリも無条件で実行許可しちゃうと思われる。
(もしかしたらサイトごとにちゃんと管理してる？)

ところが(3)のオレオレ証明書の場合、公開しているサイトのみ許可するだけだから、
他のサイトは関係ない。
となったとき(2)より(3)のほうが、ユーザに配慮しているとはいえまいか？

397:デフォルトの名無しさん
07/11/28 13:13:16
社内アプリ等でちょっとしたものでオレオレが必要な場合
先にクライアントにオレオレCAを追加しておく

ということはよくやるかも

398:デフォルトの名無しさん
07/11/28 13:19:48
>>393
GPLのソフトを非GPLであるWindowsで動かしても問題ないのと同じ

399:デフォルトの名無しさん
07/11/28 13:45:03
JWSをインストーラとするアプリをGPL(もしくはその亜種)で公開すると、
実行可能なソースを公開しなきゃいけない規則はどうなるんだろう。

サーバにセットアップしないとインストールはできないけど、
それは知ったことじゃないでいいのかな。

それからGPLとはあまり関係ないけど、
二次三次と他者により複製されて、自分のサイト以外で再配布されはじめたとする。
そのアプリは定期的にオリジナルのサーバにアクセスして、更新データを受け取るような
仕組みをもっていたとする。

他のサイトで再配布されているそのアプリが、すべて自分のとこのオリジナルのサーバに
その更新情報を取得するためアクセスしてきたりする可能性もあるわな。
悩ましい。

まぁ、公開したアプリがそこまで普及するならある意味成功ともいえるけど。

400:デフォルトの名無しさん
07/11/28 13:52:41
>>399
ソースくれといったら渡すだけなのでメールでもFDでもCDでもどっかのページ上においてもいい

401:デフォルトの名無しさん
07/11/28 14:07:27
>>400
最初はWikipediaのGPLの項目を読んでそれでいいと思っていたんだけど、
GNUのサイトを読むと、どうもそれだけでは通用しないような感じもする。

GNUサイトのライセンスの解説は、あいまいな表現が多くて長い文面のわりに
なにいってのか要点が見えにくい。
伏魔殿のようになにしこまれてるかはっきりしないからGPLは用心してしまう。

402:デフォルトの名無しさん
07/11/28 14:08:29
jnlpへのリンクの隣にソースへのリンクを貼っとけばいいよ

自分以外のサイトで再配布された場合、その再配布サイトの人がソースを提供する義務を負うんでない？

403:デフォルトの名無しさん
07/11/28 14:18:05
>>402
それなら問題はないはず。

ただJWS専用のアプリだとソースをそのままコンパイルして実行とはいかないけどね。
サーバごとにセットアップだの場合によってはjarへの署名が必要になるかと。
でもその手続きについて著者は知ったことじゃないでいいと思うけど。

404:デフォルトの名無しさん
07/11/28 15:45:00
>>401
GPLってネットが普及する前からあっただろと

アナログでもとにかくOK
ソースいれたCD郵送とかの実費負担程度も要求してOK

そもそもネットだって金かかってるしな

だが、手間なのでネットで入手できるようにしておくのがいいというだけ

405:デフォルトの名無しさん
07/11/28 17:17:01
>>404
というようにも解釈はできる文言もあるが、次のような文言も用意されている。

URLﾘﾝｸ(www.gnu.org)
#Q
バイナリは私のインターネットサーバに置き、ソースは他のインターネットサイトに
置くということはできるでしょうか?

#A
GPLでは、あなたはソースコードをバイナリと「同じ場所から」コピーするための
アクセスを提供しなければならないと定めています。
すなわち、バイナリのとなりにソースを置けということです。
しかし、他のサイトと協定を結んで、必要なソースコードを入手可能にし続けてもらい、
バイナリの近傍にソースコードへのリンクやクロスリファレンスを張って置くならば、
私たちは「同じ場所から」と言ってよいと判断します。
(以下長いので省略)
----
これを普通に解釈すれば、郵送配布は認められないようにも受け取れるが、
別のとこではネットで配布していても、郵送の手段を用意しておかなきゃいかんともいっている。
ソースをバイナリに同梱しておけば一番問題がないともね。
今では普通あそうにはない話だが、郵送での配布を希望されたら、
拒否できない可能性もあるな。GPLは。

でも、このテーマはすれ違いっぽいから、このへんにしとくわ。

406:デフォルトの名無しさん
07/11/28 17:28:38
同じ場所からってのは配布元がソースとバイナリを一致させる必要があるということ

ネット環境につないでなければ配布しなくてもいいということにはならんだろ？

407:デフォルトの名無しさん
07/11/28 17:46:16
オレオレ解釈するのは自由だが、もめたときそれが通用するかどうかは俺にはなんともいえんよ。

408:デフォルトの名無しさん
07/11/28 18:08:37
>>404
拒否はできると思うんだが、郵送にかかる手間には対価を請求できる。
郵送しか手段がない相手が、どうやってバイナリを手に入れたかのほうが気になる。
郵送しか入手手段がない、というのならその前にその人はバイナリも郵送で手に入れているはずなんだよな。

で、JavaでGPLライブラリを使う場合だが、JNLPでライブラリだけリンクってのは
大変だから、ライブラリjarにソースを含めてもらうのがいいんじゃないかな？
LGPLじゃなくGPLのライブラリだとしたら、使ってるアプリもGPLのはずだから
ライセンスの同意とかはあまり気にしなくていいのかな？

409:デフォルトの名無しさん
07/11/28 18:14:42
jarにソースが入ってても、jnlpじゃダウンロードした中身を見れないんじゃないかなぁ
個別のjarに別のリンクを張るか、アプリにソース展開コマンドを用意して同梱のソースを取り出せるようにするとかしないと意味ない気がする

410:デフォルトの名無しさん
07/11/28 18:21:42
GPLv3だと、アプリのボタン押したらソースがDLできるようにするのを推奨
とかなかったっけ。

411:デフォルトの名無しさん
07/11/28 18:23:59
>>409
おいおい。親切すぎだろ。
tar.gz 形式で配布してるソースはアウトになっちゃうぞ。
ヘルプにライブラリからの取り出し方書いておけばOKだと思うぞ。

ん？ああ、クラスファイル固めたjarファイルにソースが入ってるって
書いてるように見えるな・・・・。

いや、ソース用のjarを別に用意して、JNLPファイルで1ライブラリとして
指定しておけば楽ちんだろうな、と思ったの。
キャッシュに入る訳だけど、キャッシュ内ではライブラリとソースのバージョンは一致するはずでしょ。

412:デフォルトの名無しさん
07/11/28 18:40:03
キャッシュの中のjarって見れる？
C:\Documents and Settings\....\Application Data\Sun\Java\Deployment\cache\6.0
の中を見ても、目的のファイルの探し方がわからん

413:デフォルトの名無しさん
07/11/28 19:00:19
>>412
！もう少し分かりやすく格納してたと思ったが、・・・記憶違い？
こりゃ・・・駄目だ。

もう、ライブラリ配布サイトのURLが表示される、くらいで勘弁してもらおう・・・・

414:デフォルトの名無しさん
07/12/04 20:08:23
JWSで動作するアプリがあって、そのユーザがサードパーティのプラグインをアプリにインストールして
使用できるというようなのをやりたいんだけど、そういうのって可能なんかな。
JNLPファイルの中で、あらかじめ使用するjarファイルをすべて宣言しておくしかないようだけど。

というのは、たとえJNLPファイルの中で、<permission-all>を指定してあっても、
後からJWSの管理外のコードベースから動的に読みこまれたクラスに対しては、
あいかわらずセキュリティマネージャの監視が効いてて、それを解除する方法がよくわからない。

415:デフォルトの名無しさん
07/12/04 20:22:31
Mavenとかそういうこと?

416:デフォルトの名無しさん
07/12/04 20:34:31
Maven使ったことないのでよくわからん。スマソ。

417:デフォルトの名無しさん
07/12/04 21:04:53
>>414
プラグインが必要としそうな入出力APIを本体アプリの方に持っておいて、プラグインからはそれを使う
AccessController#doPriviliegedをお忘れなく

418:デフォルトの名無しさん
07/12/04 22:08:28
>>415
Mavenは構築用だから関係ないんジャマイカ？

419:デフォルトの名無しさん
07/12/04 23:02:53
>>417
なるほど。
また仕事が増えてしまったけどw

> AccessController#doPriviliegedをお忘れなく

このクラスを使ったことがないので今から勉強しますです。

普通のアプリとして動かしていたときは、ポリシーファイルを使ってプラグインの権限に制限かけてたんだけど、
JWSでは多分その方法は使えそうにないですね。 ( ためしてないから確かなことはいえないけど )。

420:デフォルトの名無しさん
07/12/05 01:43:38
>>419
URLClassLoaderのgetPermissionsをオーバーライドして
PermissionCollectionにAllPermissionを追加したらいいかもしんない。

421:デフォルトの名無しさん
07/12/07 06:27:42
>>420
その方法で一応セキュマネを突破できた。
AllPermissionのまま使うわけにはいかないけど、あとは応用だからなんとでもなりそうです。
資料が少ないのでソース調べまくって悩んだ悩んだw
あんたただ者じゃないよ！
大感謝！

422:デフォルトの名無しさん
07/12/07 06:31:49
>>420
すごく勉強になった。ありがと。

423:デフォルトの名無しさん
07/12/07 14:51:30
JDK6u10 build08
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)

変更点からすると、Netbeansの表示が
直っているかな・・・と思ったんですが直ってないですね。
まだまだ絞っていかないと駄目みたいですね。

424:デフォルトの名無しさん
07/12/07 18:11:17
とりあえずwebsphereで始めたらいいですか？

425:デフォルトの名無しさん
07/12/08 03:34:00
Nimbusの正式リリースも近そうだな。楽しみ。

426:デフォルトの名無しさん
08/01/12 16:12:05
うｐ毎回のようにリグレッションが出るのは何とかならないの？

427:デフォルトの名無しさん
08/01/12 16:13:34
なんともならない

428:デフォルトの名無しさん
08/01/12 21:58:41
バグのないプログラムが存在しないのは数学的に証明されてるからな。

429:デフォルトの名無しさん
08/01/12 22:20:20
バグのないプログラムなんていくらでも存在するがw

430:デフォルトの名無しさん
08/01/12 22:26:49
cabosを使おうと思っているのですが最新型のJavaをDLしているにもかかわらず

「ソフトウェアをロードできませんでした」

という表記がででいるのですが…

これってどうすればいいんでしょうか？

431:デフォルトの名無しさん
08/01/12 23:23:02
>>429
プログラムがバグってなくても仕様がバグったら(ry

432:デフォルトの名無しさん
08/01/12 23:23:42
>>429
プログラムがバグってなくても仕様がバグってたら(ry

433:デフォルトの名無しさん
08/01/12 23:37:17
プログラムじゃなくて、それを作った奴がバグってるだけ。
機械は忠実に実行してるだけだし、javaでもvbでも奴がアホならプログラムもアホになる。

434:デフォルトの名無しさん
08/01/12 23:43:27
>>428がバグってる件について

435:デフォルトの名無しさん
08/01/13 00:07:26
ググってみろ

436:デフォルトの名無しさん
08/01/13 01:45:04
こっちでやれ、ハゲが。

バグのないプログラムは存在しない
ｽﾚﾘﾝｸ(tech板)

437:デフォルトの名無しさん
08/01/13 01:46:41
ハゲがいないプログラマは存在しない

438:デフォルトの名無しさん
08/01/13 01:52:01
波平はハゲじゃないんだ！

439:デフォルトの名無しさん
08/01/13 14:38:13
update 4が出てる

440:デフォルトの名無しさん
08/01/13 18:31:50
英語版だけね

なぜか日本語版が出てないのに日本語のページはすでにupdate4になってるけど

441:デフォルトの名無しさん
08/01/13 21:13:21
そもそもJDKは国際化版はあっても日本語（オンリー）版ないし。

442:デフォルトの名無しさん
08/01/13 23:18:41
>>441揚げ足取りするなよ
マルチリンガル版がないのだよ

443:デフォルトの名無しさん
08/01/14 00:02:46
ん？置いてあるのってマルチリンガル版だけじゃないの？
Windowsに入れた時、ちゃんとインストーラでは日本語表示されてたような気がするが。

444:デフォルトの名無しさん
08/01/14 00:08:40
JREはenglishってかいてないか？

445:デフォルトの名無しさん
08/01/14 00:10:33
JREはローカライズするんじゃなかったっけ？

446:デフォルトの名無しさん
08/01/14 00:14:00
JDKは>>443。JREは知らん。

447:デフォルトの名無しさん
08/01/14 01:30:21
JDKのダウンロードページもEnglishと書いてあるな

今回急にダウンロードページのつくりが変わったからわけがわからん

448:デフォルトの名無しさん
08/01/14 08:09:16
>>447
Englishと書いてあるけど、置いてあるブツはUS版じゃないと思うんだが。

449:デフォルトの名無しさん
08/01/14 23:39:37
JDK6u4インストールしたがI18N化されてたぞ。毎度のごとくインストーラだけ。

450:デフォルトの名無しさん
08/01/15 00:21:01
インストールだけしてその後一切使ってないなら判らないかもしれないけど、
charsets.jarも入ってるし、コントロールパネルもjavacのエラーも日本語表示されるよ。

そーいや、コントロールパネルのカテゴリが「その他」から「プログラム」に移動してた。

451:デフォルトの名無しさん
08/01/15 00:29:53
URLﾘﾝｸ(bugs.sun.com) これかな

452:デフォルトの名無しさん
08/01/15 08:38:24
javaコマンドのメッセージが英語だったんだが。

453:デフォルトの名無しさん
08/01/15 12:03:42
javaコマンドのメッセージが日本語だった事ってあるの？

454:デフォルトの名無しさん
08/01/15 12:28:12
あるよ。
ただ、コマンドライン、システム・エンコーディング指定とか、
右往左往しすぎて今でも何が何だかよくわからん。

455:デフォルトの名無しさん
08/01/15 12:29:33
>>453
ないはず。少なくともSunの奴では。

456:デフォルトの名無しさん
08/01/16 14:10:22
Java Kernel(旧姓：Consumer JRE) の jre が出たらしい(もちろんテスト版)
URLﾘﾝｸ(jdk6.dev.java.net)
変更点は、リリースノートが不在のためまだ不明。
Mercurialに変わってビルドに問題が？

457:デフォルトの名無しさん
08/01/16 14:29:39
Java Kernelいらね。
実際、需要はどうだろうね？

458:デフォルトの名無しさん
08/01/16 15:33:32
>>456
インストーラがVista対応してないとか書いてある

459:デフォルトの名無しさん
08/01/20 22:28:34
そういやIcedTea 1.5が出てたな。
PPCアーキテクチャへの対応が主な成果だが、ゲーム機で動いたら遊びがいがあるのにな。

箱○で.netが使われてるからPS3上のlinuxで動けば面白いのに。

460:デフォルトの名無しさん
08/02/27 20:27:12
jdk6uN build12
URLﾘﾝｸ(jdk6.dev.java.net)
URLﾘﾝｸ(download.java.net)

ほとんどがBugFixのようでリリースは近いかな？？

461:デフォルトの名無しさん
08/02/27 21:02:00
>>460
リンク先のスケジュールに FCS Summer/Fall 08 って書いてあるんだが
リリース前倒しの情報かなんかあったっけ？

462:デフォルトの名無しさん
08/02/28 14:49:34
エスケープ解析ってどうなったの？

463:デフォルトの名無しさん
08/02/28 16:46:00
ServerVMで使えるよ。

464:デフォルトの名無しさん
08/02/29 04:54:52
有用そうだけど、話にも上がらなかったからもう消えた技術なのかと思ってたｗ

465:デフォルトの名無しさん
08/02/29 05:22:00
知らないうちに使われているのが一番だから

466:デフォルトの名無しさん
08/02/29 07:47:23
デファルトの起動オプションではおふじゃなかったか？

467:デフォルトの名無しさん
08/03/01 01:54:07
つ -XX:DoEscapeAnalysis

468:デフォルトの名無しさん
08/03/01 04:43:30
やっぱりオフじゃん。
確かスタックにnewオブジェクト置いても、すぐ解放みたいのだろ？
クライアント側(java.exe)にないと意味なくないか。
サーバー（といっていいのか）側の方が、クライアントより計算が多いなら別だが。
まあ、多分必要とされてないんだろうな（技術的には最適化みたいで大変そうだけど）。

469:デフォルトの名無しさん
08/03/01 13:36:28
サーバってのは、プログラムを24時間365日ずっと起動しっぱなしで、
何度も繰り返し大量のリクエストを捌くものだ
クライアントより計算（の量？）が多いってのは、確かだろう
多少時間をかけても入念に最適化してコンパイルしておく意義がある
クライアント側は、起動に時間かかると文句言うやつが多いからじゃないか

470:デフォルトの名無しさん
08/03/01 13:43:08
>>467
さりげなくうそおしえてるのわろた

471:デフォルトの名無しさん
08/03/01 14:02:33
（JVMの）起動に時間がかかるのは、ライブラリのロードとかが本質的なところじゃなかったか？
String以外なら、やりたいことはクライアント側で行列とかなんだけど、普通サーボー側ではやらんだろ。
もしかしてエスケープ解析が目指しているのは、これとは違う目的なのだろうか？

472:デフォルトの名無しさん
08/03/01 14:15:24
>>471
よくわからんのだけど(今のJVMの)エスケープ解析に最適化以外の目的がありえるの?
それともどんなケースで最適化が効くのかという話?

473:デフォルトの名無しさん
08/03/01 14:20:45
エスケープ解析すると、newしたオブジェクトがエスケープしてるかどうかがわかる
エスケープしないオブジェクトは、ヒープに割り当てる代わりにスタックやレジスタ上で済ますことができる
ヒープの割り当てが減ると、GCの回数が減る
GCがボトルネックになっている場合は、それで高速化できるかも
エスケープしないオブジェクトは、synchronizedを省略できる
synchronizedを多用してる場合は、それで高速化できるかも

474:デフォルトの名無しさん
08/03/01 14:23:47
>>472
意味不のレスを無理して理解しようとするな
スルーしろ

475:デフォルトの名無しさん
08/03/01 16:35:58
久々に話題振ってきてるのに、そりゃないよｗ

476:デフォルトの名無しさん
08/03/01 16:38:34
＞エスケープしないオブジェクトは、synchronizedを省略できる　
＞synchronizedを多用してる場合は、それで高速化できるかも　

並列処理と相性がいいらしいというのは、ここだったんですか。

477:デフォルトの名無しさん
08/03/01 16:46:51
たしかメソッドに渡してしまうとエスケープ解析対象外になるんじゃなかったか？
mat3=MyMatrix.mul　(mat1,mat2);
みたいなの。

でも思うんだけど、クラスが状態変更しないこと（immutable　class）が
保障されているならこのインスタンスもエスケープできるんじゃないか？
実装とか細かい動作はしらね―けど。
例えばclass　Stringとか、class　BigIntegerみたいなの。これと同じく、自作クラスの
class　MyMatrix　みたいなのでも出来て欲しいなと思って。

エスケープ解析とか、多分知ってる人いないし、見向きもしてないと思うけど。
特別に行列とかにこだわってんじゃないけどね。

478:デフォルトの名無しさん
08/03/01 16:53:23
ローカルでnewしてるわけで、メソッドに渡したのにスタックフレームと一緒に解放されたらまずいか。
やっぱimmutableとか関係ないし、無理だな。

エスケープ、やっぱイラネ―よ。こんな無駄な技術に人員割くなよなw

479:デフォルトの名無しさん
08/03/01 17:01:55
やっぱC#じゃないけど、stackallocみたいので一気に解決だな。
で、メソッドに渡すときは、自動でclone()みたいのを呼び出しになる。
たしかどこかの言語でref,　outみたいなのあったけど、Javaだとそういうのカッコ悪いしｗ
stackallocのバイトコードを追加してくれ！

480:デフォルトの名無しさん
08/03/01 17:33:12
リファクタリングしまくるとエスケープ解析と相性悪くなりそうだな。
それでも、短いコードは正義だぜ。

481:デフォルトの名無しさん
08/03/01 19:03:28
そんなことじゃC99コンパイラと同じ運命だろうな

482:デフォルトの名無しさん
08/03/01 19:07:28
バイトコード、並列処理な話題をたのむ

483:デフォルトの名無しさん
08/03/01 19:08:33
エスケープ解析に最適化ってのは、ループ展開の最適化程度のことを大げさに言ってるだけｗ

484:デフォルトの名無しさん
08/03/01 19:57:27
もともとエスケープ解析が役に立つのは世代別GCを意識したコードだろうから
そんなに効果が挙げられないのかも

コンカレントGCのレスポンスが改善されるとそれだけでほとんどいけるんだけどね

485:デフォルトの名無しさん
08/03/01 20:36:31
Nimbusはいったいいつ正式リリースされるのかね

486:デフォルトの名無しさん
08/03/01 20:40:54
Summer/Fall 08じゃないのかね

487:デフォルトの名無しさん
08/03/01 21:33:53
ありがとう。
というかjdk6.dev.java.netにあったのね

488:デフォルトの名無しさん
08/03/02 01:29:35
>>477
実行時に最適化すれば、他のパッケージの関数の解析結果も利用できる。

489:デフォルトの名無しさん
08/03/02 06:12:01
GCの機嫌を取るようなコードを書く必要があるなら、
Javaなんかでやらない、でそもそも他の専用・特化した言語でやるよｗ

native　float　func(float);
とかすると、結局ネイティブ関数呼び出しコストが大きいし、
なんならjava.nioとか使うから別にいいよｗ

490:デフォルトの名無しさん
08/03/02 06:15:58
ただよく考えてみると、あまりに技巧的じゃないか？
例えば100x100の行列計算とか、BigIntegerで100桁の四則演算とsqrt実装とか、
今の計算機なら当たり前すぎる事をやりたいのに、
それをするためにはJavaでは高度な技術(java.nioとかgc)が要求されるから、
Javaは敬遠されるんじゃないかと思う。

本当はJavaがいいんだが、専門学校中退とかおサルなクリエーターはflushとかお気軽な方に流れる。
今のままじゃ、Appletで微分方程式や３Dのデモとかが限界なのかもね。

多分だけど、エスケープ解析とかで技巧を凝らせば２０ナノ秒も速くなるんだろうけどｗ

491:デフォルトの名無しさん
08/03/02 06:35:06
確かに行列計算とかはサーバー側で計算したりさばいたりするものではない罠
せいぜい1ミリ秒速くなる程度だし、forループ内でnewしまくりでいいんじゃね？
さらにUIがGUIなら、ボタンとかのイベント待ちの時にGCすればいいだろ。
これが今のプログラミング・スタイルだと思う。

492:デフォルトの名無しさん
08/03/02 10:34:20
>>490
> Javaは敬遠されるんじゃないかと思う。
> 本当はJavaがいいんだが、専門学校中退とかおサルなクリエーターはflushとかお気軽な方に流れる。

（　ﾟдﾟ）ﾎﾟｶｰﾝ

493:デフォルトの名無しさん
08/03/02 10:40:31
>>492
「技術的に1秒速くできる！」とか、いわゆる技術者のオナニーなんて実際はどうでもいいし、この指摘はある意味的を得てる。

494:デフォルトの名無しさん
08/03/02 11:22:41
>>492
＞（　ﾟдﾟ）ﾎﾟｶｰﾝ　

久々に見てワロタｗ
いつのまにか、こんなスレの主になってたのかｗ

495:デフォルトの名無しさん
08/03/02 11:37:27
誰ともコミュニケーションできないで、研究室で寂しく２CHに書き込んでる雑用見習いあたりだろよ。
やけにAPIとか詳しそうだしｗ

496:デフォルトの名無しさん
08/03/02 12:40:57
>>491
GCのタイミングがコントロールできないのがゲーム等で問題になってる
いつ発生するかわからない1msのGCより発生をコントロールできる10msのGCのほうがましなんだよね
new領域のGCができればいいけど、今のsunのSystem.gcの実装はfullGCなんだよね

497:デフォルトの名無しさん
08/03/02 15:50:20
ゲーム。その話になると思ったんですけど、多分設計上の問題で回避できるでしょう。
別にゲームじゃなくても、アニメーションとかストリーム（とかメディアAPI）でも
単純に作ると一瞬「ピックっ」として止まりますしｗ
GCをコントロールしたいという発想から抜けてみてはどうですか？

498:デフォルトの名無しさん
08/03/02 15:51:07
ストリーミング

499:デフォルトの名無しさん
08/03/02 16:45:17
1ms程度ならいつ発生したって別にどうってことない
60fpsで動かすとしても1フレームあたり16msもあるんだから十分吸収できる
問題は100msにも達することがあるfull　gcの方で・・・

500:デフォルトの名無しさん
08/03/02 16:59:58
60fps、だいぶ大規模なソフトでも作ってるんですね。
まずC++（とかMS)を考えてみて、どうしてもJavaじゃないとダメなんだと考えてから設計してますか？
それともJavaならどこでも動くとかの趣味程度なら、Javaなのにこれを気にすること自体が間違いでしょう。

jdk1.8がどうなるかjdk1.9が何を目指すか、そういうのに合わせるのが吉じゃないでしょうかね。
もし趣味程度なら、メモリとかの先の話は独学や個人で解決できる問題じゃないですよ。

501:デフォルトの名無しさん
08/03/02 17:11:09
60fpsが出せる環境はwin,　mac,　linuxとかに絞られるからグダグダいうなら別にJavaじゃなくていいんと思うぞ。
C++とかで、自分でオブジェクトプール実装とかデストラクタでメモリ管理とかも出来ないのに、GC云々なんて文句垂れてるわけじゃないよなw
ANSICで簡単なGC実装してみろよとまでは言わないからさｗ

502:デフォルトの名無しさん
08/03/02 17:19:23
>>499
FullGCは発生はとめることはできるが、新世代は無理
垂直同期直前でGCが発生すると確実にフレーム落ちするんだよ
これは100マイクロ秒でも同じ

発生をコントロールできる10msは処理が終わった後余裕があるという場合は多いからその間にやればいいというだけ

503:デフォルトの名無しさん
08/03/02 17:30:46
そこまでリアルタイム性が高くてシビアなのを求めるんなら
C で行けって言うのは確かに間違いではないんだが、
俺も出来る事なら Java で書きたいかな。

Java の C++ に比べたときの仕様の簡潔さ・小ささや
エクリプスのコードの書きやすさは今のところ他の言語で同等のものを知らない。

504:デフォルトの名無しさん
08/03/02 17:42:39
JDK6がでてしばらくたってネタがなくなったためいまではおちてしまったが、
ゲームスレではそのGCのコントロールとクラスロードのコントロールと
ジョイパッドがあればCとほぼかわらない物ができるという結論だったはず

505:デフォルトの名無しさん
08/03/02 18:19:45
JavaのGCは想像を絶するほどの人員と金が投資されてるし、
これに比べれば上のエスケープ解析なんかは鼻くそ程度の小手先技でしかない。

GCにグダグダ文句つける奴はさっさと消えてくれよ。

とっても、非常に単純でいいなら個人でGCを実装するのは実はそんなに難しくないんだけどｗ

506:デフォルトの名無しさん
08/03/02 18:25:58
>>504
60fpsとか作ったことないし、イマイチ、どういう原因でGCの起動と処理時間が問題になるわけ？

Graphics.dispose();
Image.flush();
とか手動で解放（を期待する）でいいだろ。

もしかして違うところが話題なの？

507:デフォルトの名無しさん
08/03/02 18:31:49
>>501
そんな大規模なわけでもない・・・期待に添えなくてすまそ。
JOGLが出てきたんで、Javaで作ってみるのもいいかと思ってやってみてるだけの試作品。
もちろん商用でもない単なる趣味。
とりあえず作ってみて、無理そうだったらC++に戻るよてい。
>>501
C++でもいいんだけど、Eclipseが便利なもんで。。。
GCは昔趣味でScheme処理系作ったときに実装したことありますよ。
世代別は面倒くてやめたけど簡単なコピーGCくらいなら。
>>502
FullGCを止めるには、やっぱnewとかallocateDirectを抑えるしかない？
メモリ管理を自前でやるんなら、C++とあんまり変わらない・・・

SoftReference使いまくってGCまかせのリソース管理（テクスチャのキャッシュとか
モデルデータのキャッシュとか）ってのはやっぱりだめですかそうですか。。
ThreadPoolExecutorとかもあるし何気に便利なんだよねJava・・・

508:デフォルトの名無しさん
08/03/02 18:32:45
ゲーム類やメディアっぽいことをJavaでやるなら、ジャンルによるだろ。
ハードよりになるからまだ何年も先だろうし、ライブラリがあっても、今は人柱バージョンだろうな。
スカイプみたいなビデオ・チャットが手軽にできれば
少しはメディア系の開発者が増えるんじゃないか？

509:デフォルトの名無しさん
08/03/02 18:45:17
>>507
きっと君は技術的な興味・趣味でプログラムやってるていう感じじゃないか？
作りたいものよりも技術を試してみる方が優先していると思う。
それだけの技術力があれば一応なんでも作れるから、
自分が作りたいもの・作るものにあわせて使う言語を選び、
言語やライブラリの癖にあわせて使い分けるという発想にそろそろ切り替えたらどうだろうか。

＞GCまかせのリソース管理

多分ですけど、jdk1.9とかになるとjavax.lang.native_resource_and_memoryとかの
パッケージで標準サポートされるから自作しても無駄になる、と期待したい！！

allocateDirect　現状ではやっぱこれになるでしょな。

510:デフォルトの名無しさん
08/03/02 19:27:31
> 多分ですけど～と期待したい！！
自分の期待だけを根拠に予想に昇格させるのは止めたほうが

511:デフォルトの名無しさん
08/03/02 19:48:48
真性機械じゃないし、冗談ぐらいは通じるだろｗ

512:デフォルトの名無しさん
08/03/02 19:56:11
100×100の行列計算とか、100桁のsqrtやりたいのにJavaは敬遠されて、flushとかお手軽な方にながれるのか。
へんなの。

513:デフォルトの名無しさん
08/03/02 19:57:45
flush

514:512
08/03/02 20:07:01
>>490な。

515:デフォルトの名無しさん
08/03/02 20:56:20
>>509
そんな感じです。
面白そうなものを見かけたり思いついたりすると試してみたくなります。
常に最新技術を追ってないと追いてかれるという強迫観念みたいなものもなくもないですが。。
アドバイスありがとうございます。
心に留めておきます。

関係ないけど、flashは開発ツール高すぎ

516:デフォルトの名無しさん
08/03/02 21:28:59
自らが電車でお店に行って、店員にクレジットカードで払って、カバンに入れて、家に持ち帰って、
パッケージを空けたあとに、何十分もインストール画面を眺めながら完了するまで待ち、
さらに自分用にカスタマイズ設定をする。
とかだと、おっしゃるように、これでさらに日本円まで支払うとすれば、高すぎかもしれません。

きっとあなたは、孤独でかつ正直者なんでしょうなｗ
大学とか行かないで独学なのかとおもうのですけど、
freebsdの世界にいる人たちはあなたみたいな静かな人とか技術力が高く趣味の人が多いですよ。

517:デフォルトの名無しさん
08/03/02 22:12:59
>>506
表示されるときは垂直帰線期間中にフリップされる
つまり、垂直同期中直前にGCが発生すると意図せずフレームレートがおちる
一方、処理が6ms以内でおわっていれば10msのGCを指定した場所で発生させても問題はなくスムーズに動く
レスポンスとスループットの違いみたいなもんだ

>>507
SoftReferenceは使い物にならないよ
FullGCなくすならコンカレントGCがもっとも楽な方法だけど、new世代では効果がない

使用するメモリ量を把握することやプリミティブ型を積極的に使ってのオブジェクトプールしかないが
こうなるとJavaの利点が激しくなくなるのでnew世代のGCもSystemクラスにほしいところ

518:デフォルトの名無しさん
08/03/02 23:17:18
もうObject#dispose()でいいよ。

519:デフォルトの名無しさん
08/03/02 23:19:56
そんな糞実装だとJavaの意味ゼロだろう・・・
リソースの開放だけなら別に問題ないけど
コレクションの参照とかどーすんだよ

520:デフォルトの名無しさん
08/03/02 23:44:23
明示的に破棄されなかったオブジェクトはGCで回収されるでいいんでない？
どうせGCを無くすわけにはいかないんだし。

Java開発者側もGCの改善に苦労してるんだったら、プログラマ側に任せられる
ところは任せたほうが双方ハッピーになれる気がする。

521:デフォルトの名無しさん
08/03/03 00:02:39
Object#dispose() で明示的に破棄されたけど、他で強参照してる場合とかはどーすんの？

522:デフォルトの名無しさん
08/03/03 00:17:17
>>521
そんときはException投げる。
って、それちゃんとやろうとしたらNextみたいなシステムレベルの
object poolになっちゃうか。

523:デフォルトの名無しさん
08/03/03 05:17:33
例外を投げられずに、異常動作に陥る時の方が多い。
必ず例外を投げられるようにしようとすると、
普段のメモリ確保、解放のコストも上がる。

524:デフォルトの名無しさん
08/03/03 06:37:31
freebsdは、こいつがやりたい（であろう）uiとか3dとかと無縁の世界だと思うが？
20ナノ秒間の処理をどう扱うかが「本物のハッカーである」ことに変わりはないｗ

525:デフォルトの名無しさん
08/03/03 08:05:56
ここでGCの細かい内部のことを解説してる奴がいるけど、一見凄いことしてそうだけど
実はコンパイラ作成とかGC実装とかしたことないような所詮は専門バカ（研究者）だろな。
そんな俺様研究者の話なんか真に受けんなよ。

研究者ってのは原子・粒子の大きさ（笑）、２００００ピコ秒の限界に挑戦！とかしてるアホだし、
現実からこいつらを見れば、こいつらのようなキモオタ（学者級）のオナニーに付き合わされてるようなもんだろうな。

526:デフォルトの名無しさん
08/03/03 10:15:15
リアルタイム用の仕様は見たのか？

527:デフォルトの名無しさん
08/03/03 10:20:31
>>525
でもそんな変人がいるから世界が進歩するんだよ。

528:デフォルトの名無しさん
08/03/03 10:30:51
研究者も何タイプかに別れるからね。
観察・統計取るの好きな人とか、実験・実証するの好きな人とか。

529:デフォルトの名無しさん
08/03/03 10:59:32
もし一人とか孤独でやってんなら、java.netで世界中のハッカーが集まっておのおのがプロジェクトやってるから、
そっちでみんなでやってると英知が集まってるし役立つだろう。
特にメディアっぽいこととか最先端で試行錯誤中なんかはヒートしてるｗ
英語でもロムってる分には２CHとおなじだしな。

プロジェクトの最終的なゴールは、ライブラリー作ることになるだろうな。
MSの世界で見てるとオープンって何？とかなんだろうけどね。

530:デフォルトの名無しさん
08/03/03 11:02:47
外人も変な要望とか記事かくやついるけど、MSDNとかPerlほどカルトっぽくはない。
URLﾘﾝｸ(community.java.net)

それと、日本のIT記事？はつくづくゴミだって分かるよｗ
そもそも三次四次情報だしｗｗ芸能ゴシップネタと同レベルだろなｗｗ
日本のブログっぽいので、個人のやつは、そもそもゴシップぽいことは書かないし、
word,excel,vba程度の普通の人はそもそも高度な事は書けないし。

531:デフォルトの名無しさん
08/03/03 11:20:37
日本の個人の奴は別にひどくないけど。
IT記事（特にWebのやつ）はほぼゴミ情報でしかない。
Webの記事は、書いてる奴の原稿料も微々たるもんだから、そんなもんだろ。
これを信じるかどうかは別だけどｗ
読むには一見無料かもしれないけど、いつのまにかAJAXのスキル云々講座・・・とか（笑い）

って、文章が尻切れてたｗ

532:デフォルトの名無しさん
08/03/03 12:27:35
>>525
なんかlコンプレックスでもあるの？

533:デフォルトの名無しさん
08/03/03 12:58:38
>>532
定期的にこいつ現れるから無視しとけ

534:デフォルトの名無しさん
08/03/03 14:31:02
>>532
GCの話になるとムキになるようだし、コンプレックスあるのはおまえの方じゃないのか？

535:デフォルトの名無しさん
08/03/03 14:45:17
日本語のIT記事（笑）は半年から既に1年以上前とかで古い。
ニュースなのに半年とかなんだよ。
一番の問題は、その当時の外人の記事を直訳や下手な和訳で日本人記者（なのか？）の
英語や業界などの素質や精通度合いを疑ってしまうのが多いところ。

536:デフォルトの名無しさん
08/03/03 16:00:01
>>521-522
Interface実装することで特別扱いにするとかかな。Iterableみたいなの。
でも既にライブラリ（パッケージ）で、そういう擬似リアルタイム処理可能で
Object.dispose()みたいなことしてくれるようなのがあったし。

537:デフォルトの名無しさん
08/03/03 16:42:39
JavaSE7の登場が近づいてきたこの時期にやっと5.0の記事とかどんだけ・・・というのは確かに多い

538:デフォルトの名無しさん
08/03/03 17:03:57
既に日本の若い情報技術者（笑）は、日本語では情報が少ないので海外にシフトしてますよｗ

539:デフォルトの名無しさん
08/03/05 09:34:58
6u5 が出てるみたい。

540:デフォルトの名無しさん
08/03/08 12:17:47
6u5にしろ、6uN b12にしろ、Windows L&Fのときに、
JFileChooserのコンストラクタで、IndexOutOfBoundsExceptionが出るのは俺だけ？

541:デフォルトの名無しさん
08/03/08 13:32:04
u4では問題なかった?

542:デフォルトの名無しさん
08/03/08 18:43:03
u5でも6uNb12でもでないよ。

543:540
08/03/09 12:54:41
>>541-542
URLﾘﾝｸ(bugs.sun.com)

どうやら、Vista限定バグらしい。StateはClosed, fixedになってるけど、↑のページの
コメントにあるように、fixされてない。

544:デフォルトの名無しさん
08/03/09 13:07:58
JFileChooserの遅いのも結局なおってないからね
ファイル選択でいらいらするのはやめてほしいな

545:デフォルトの名無しさん
08/03/11 04:40:20
JDK6u10 build13
URLﾘﾝｸ(jdk6.dev.java.net)
URLﾘﾝｸ(download.java.net)

In b13, we introduce new Java system properties to support the usage of version download
and Pack200 without any server side requirements.
This addresses the issue that is raised in RFE 6378311.
This increases the flexibility of deploying version download and Pack200 JARs
without using JNLPDownloadServlet on web servers.

Pack200形式のファイルをサーバに置くとき、サーブレットが要らなくなったそうな。
今まで必要だったのがおかしいっちゅう話ですね。
あと、Numbus周りの改修とプラグイン周りにたくさん改修が入ってます。
デモのSwtingSet2が新しくなってるそうです。

546:デフォルトの名無しさん
08/03/17 03:20:20
GC時間を気にしていた人・・・
-XX:MaxGCPauseMillis
は試したかな？

いずれにせよ、New世代のGC時間をコントロールするにはNew世代の
大きさを小さくすることになると思うけどね。
UseParNewGC + UseConcMarkSweep で何処まで行くか・・かな・・・
ただ、いくら時間が短くても
フレームレートいっぱい処理に割り当てると同じ事だからどうしたもんだか。

547:デフォルトの名無しさん
08/03/17 09:21:48
JOGLとかLWGLで実行速度稼いでGC時間は気にしない。

548:デフォルトの名無しさん
08/03/17 14:48:58
本当に困ってんなら、あきらめてフレームレート下げるだけでよい

549:デフォルトの名無しさん
08/03/17 17:31:34
>>546
それやってみればわかるけどうまく動かないよ
あくまでも参考値だし、それに割合のコントロールじゃないから

この期間だけはGCは1msでも発生するな、というだけ
この処理が終わったら（JOGLやJava2Dのフリップ等）10msはGCつかってもいい

>>547
JOGLでもJavaコードが動いている間の問題なので関係ある
ネイティブコードを呼びに逝くときが問題

>>548
原理的に1fpsでも60fpsでも発生するからそれで改善されない
フレーム落ちがはいっていいのならローエンドのCore2Duoでも60fpsとかは余裕

550:デフォルトの名無しさん
08/03/18 02:29:34
で、そこまでの水準を求めて、おまえは一体何をやりたいんだ？

551:デフォルトの名無しさん
08/03/18 02:31:08
てか、そこまで念入りに調べてんなら、おまえがHP作ってみんなで情報共有すればいいんじゃないか？

552:デフォルトの名無しさん
08/03/18 04:10:18
批判は簡単だけど、
自分で形にまとめるのは難しいじゃん

553:デフォルトの名無しさん
08/03/18 05:40:45
↑おまえじゃまとめる事すら出来ないけどなｗｗおまえは黙ってろよｗｗ

554:デフォルトの名無しさん
08/03/18 11:46:14
>>549
そこまでいうなら、ネイティブコードで書いても、OSがフリップのタイミングにタイムスライスを
くれなくてフレーム落ちする可能性がある。RTOS使えって答えになる。
java上だと、OSがタイムスライスをくれないリスクに加えて、GCと重なるリスクがあるから、
ネイティブよりもフレーム落ちする可能性は高いけど、
どっちもゼロじゃないから割り切って選択しろってことになるんじゃないの？

555:デフォルトの名無しさん
08/03/18 23:58:56
>>554
GCが原因になってフレーム落ちするのが頻繁に発生するのが問題
WindowsなどOSが原因となってフレーム落ちするほうはそんなに頻度が高くない
30fpsくらいだとめだたないけど、60fpsじゃないとお話にならないしね

JavaSE7の正式版が出てからソースいじるさ

556:デフォルトの名無しさん
08/03/19 00:23:55
60fps使うアプリって例えば何があるの？

557:デフォルトの名無しさん
08/03/19 01:02:20
まぁ、1フレーム時々落ちるぐらいだったらそんなに神経質になるなよって気もするけど
GC掛かったら悪くすれば10や20フレームぐらいは一気にドロップするんじゃね？

アクションゲームでフルGCなんて掛かった日には悪夢だろうな。

それでも、今ならJavaでゲームって言うのもそんなに悪い選択肢だとは思わない。

558:デフォルトの名無しさん
08/03/19 01:51:22
>>555
お話にならないのはおまえの神経の方じゃね？

559:デフォルトの名無しさん
08/03/19 20:34:09
Full GCはともかくScavenge GCって
フレームがまとめて落ちるほどそんなに激しく発生するん？

560:デフォルトの名無しさん
08/03/22 02:33:30
企業の阿保どもはいつになったらJREをバンドルするという事を学ぶのだろう

561:デフォルトの名無しさん
08/03/22 02:41:06
マイクロソフトの安卸しオプションがなくならないと無理だろ。

562:デフォルトの名無しさん
08/03/22 05:04:53
JREはそんなに普及してないのか？問題にならないほど（jdk1.4相当は）普及していると聞いているが。

563:デフォルトの名無しさん
08/03/22 07:15:38
ニュー速からこっそり誘導して調べた結果は 1.4 以降が起動したのは半数弱だな。
MSJVM すらインストールされていないのが 41% も居た。

564:デフォルトの名無しさん
08/03/22 07:20:44
×インストールされていないのが
○インストールされていないかアプレットオフってる連中が

565:デフォルトの名無しさん
08/03/22 09:49:16
XML出力に特化したBean/XML変換の最近のトレンドって何ですか？
XMLEncoderとかJAXBとかあると思いますが、出力だけでいいので速いものはないかなと。

566:デフォルトの名無しさん
08/03/22 13:33:41
どちらも標準APIになった現在ではシリアライズの結果がどう違うのかだけ考えればいい
出力だけってのがわからんが、入力はせんの？

出力結果を見るとJAXBのほうがはるかに扱いやすいと思う
ただ、アノテーションつけたりクラス構造の制限もあるけどね

速さだけがすべてなら自分で計測してみては?
シリアライズするbeansの種類によって結果は違うかもよ

JAX-WSとかすべて基盤はJAXBにうつったので個人的にはJAXBをお勧めしたい

567:デフォルトの名無しさん
08/03/22 15:55:21
JVMも所詮は一つのアプリだし、半分も動けば十分じゃないか？
PCの台数換算でも、多く見ても数億台って単位だろ。

568:デフォルトの名無しさん
08/03/22 15:56:07
＞ニュー速からこっそり誘導して調べた

ていうかこっちの方が問題じゃないかｗ

569:デフォルトの名無しさん
08/03/22 21:13:00
VMはひとつの環境っていう認識はどれくらいが持ってるんだろうね

570:デフォルトの名無しさん
08/03/23 01:32:19
>>563
MSJVM「すら」というか、今時だとMSJVM入れる方が難易度高いだろ。

571:デフォルトの名無しさん
08/03/23 02:09:25
そういう意味の表現じゃねーっつーの。

572:デフォルトの名無しさん
08/03/23 02:37:34
>>569
おまえ、その環境ってのがどういうのか当然分かってんだろうな。

573:デフォルトの名無しさん
08/03/23 15:52:28
カリカリすんな、サル。

574:デフォルトの名無しさん
08/03/23 21:01:14
さるｗ

575:デフォルトの名無しさん
08/03/23 23:30:03
>>573
こういうこと言うサルは早く退場し欲しい。

576:デフォルトの名無しさん
08/03/24 01:53:29
おまえら >>572 が「その環境」について説明するから静かにしてろ
↓

577:デフォルトの名無しさん
08/03/24 01:53:48
カリカリすんな、ハゲ。

578:デフォルトの名無しさん
08/03/24 02:19:11
ハゲじゃねぇよ、剃ってんだよ

579:デフォルトの名無しさん
08/03/24 04:37:03
>>576
で、おまえは誰だ？

580:デフォルトの名無しさん
08/03/24 14:58:57
URLﾘﾝｸ(japan.cnet.com)
>マイクロソフト、Javaを使ったWindowsアプリ開発でEclipse財団と協力へ
なんか、MS自らVista用SWTをてこ入れするらしい。
この話とJNA組み合わせると、J/DirectでMSが作りたかった環境になるよね。

Javaから締め出されたMSはC#/CLR/WinFormsという世界を別個に作ったわけだけど、
eclipseユーザーに取り入ろうという戦略か。

個人的には、MSにSwingをてこ入れしてもらいたい。
WinFormsとかMFCとか、GTK+のような、Heavy weight widgetなGUIツールキットは
そろそろ時代に合わなくなってるんじゃないかと思う。CPUパワーが上がって、相対的に
ウィンドウシステムのウィンドウ間のメッセージング(Win32でいうとSendMessage)がボトルネックに
なってる。テーブルやリストで大量の項目を扱うときは、いかにSendMessageの回数を減らすかが
チューニングになってて、なんかいびつな感じ。
MSも、大量のコントロールが頻繁にレイアウトされるIEのレンダリングでは、Light weight widgetだし。

581:デフォルトの名無しさん
08/03/24 15:25:20
Swingというクロスプラットフォームを意識したものをMSがいじるとはおもえん
SWTはWindowsの環境を他の環境にも、という意味合いからスタートしてるのでそっちなんだろう

というかSwingは標準APIだからコントロールは難しいんじゃね？
sunががんばってWindowsネイティブにちかいようにはしてるけど

それよりFileChooserの死ぬほどトロイのいいかげん直してくれよと
JavaSE6u2からひどすぎる

582:デフォルトの名無しさん
08/03/24 15:44:23
>>580
それMicrosoft が割り当ててくれる人員ってどんぐらいいるんだろ？
そこまで大規模な話なんか？って気もする。
EclipseはVisualStudioと競合する製品だし。

583:デフォルトの名無しさん
08/03/24 17:22:29
>>580
> eclipseユーザーに取り入ろうという戦略か。
というよりは、開発者にWPF移行を促す戦略の一環なんじゃね？

584:デフォルトの名無しさん
08/03/24 22:45:48
>>583
同意。既にこんなのあるから、これを支援することでWPFを後押ししたいんじゃないかな。
URLﾘﾝｸ(d.hatena.ne.jp)

585:デフォルトの名無しさん
08/03/25 10:59:29
>>580
おまえ、その考え方は治した方がいいよ。キモイ。

586:デフォルトの名無しさん
08/03/25 11:57:48
>>580
> 個人的には、MSにSwingをてこ入れしてもらいたい。

真逆やん
SWTをもっとWindows(WPF)べったりにしようって取り組みなんだから。

> ネイティブのWindows Vistaのようなルックアンドフィールを備えたアプリケーションを
> Java開発者が容易に開発できるように

587:デフォルトの名無しさん
08/03/25 15:51:50
Java SE 6 Update N build 14 is now available
URLﾘﾝｸ(jdk6.dev.java.net)
URLﾘﾝｸ(download.java.net)

b13に比べるとちょっとしか変更はない。
betaが近いな。

588:デフォルトの名無しさん
08/03/25 18:50:13
>>580は確かにキモイな。オナニーのし過ぎだろ？

589:デフォルトの名無しさん
08/04/02 12:59:54
Java 6u10 beta age

次ページ