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


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

【Java】次世代Java・J2SE1.6の動向【Mustang】



1 名前:デフォルトの名無しさん mailto:sage [04/04/12 00:49]
www.itmedia.co.jp/news/articles/0404/07/news018.html


マルチタスク実現へJava言語改良
Sun幹部によると、2005年に一般リリース予定の「J2SE 1.6」には、
Javaバーチャルマシン(JVM)のアプリケーション共有を強化する「分離」機能が備わり、
ローカライズコンピューティング処理実行のための分離が可能になるという。

米Sun Microsystemsは、Javaバーチャルマシン(JVM)内部での
アプリケーションマルチタスク実現に向けてJava言語の改良に取り組んでいる。
カリフォルニア州サンノゼで開催のClusterWorld Conference & Expoで4月6日、同社幹部が明らかにした。

SunのJavaアーキテクト、ムラリ・カウンディンヤ氏によると、
今秋β版が登場し、2005年に一般リリース予定の「J2SE 1.6」には、
JVMのアプリケーション共有を強化する「分離」機能が備わる。
この機能によってローカライズコンピューティング処理実行のための分離が
可能になり、第2のJVMを要求することなくJVM内部でマルチタスクが行えるようになるという。

 またJ2SE 1.6では、Javaプログラム間の高速通信を可能にする
Sockets Direct Protocolのサポートが計画されている。カウンディンヤ氏によると、
J2SEに施された改良は、その後間もなくJ2EEにも組み込まれる予定。

 1月にβ版がリリースされたJ2SE 1.5は、6月のJavaONEカンファレンスで正式リリースの
運びとなる見通し。J2SE 1.5では、Javaプログラミングの簡易化に焦点を当てている。

369 名前:デフォルトの名無しさん mailto:sage [04/11/22 13:12:39]
>>368
JavaWebStartはスタンドアロンアプリを配ることにも使えるぞ。

サーバに依存して動くアプリを配るにしても、
なるべく disconnected operation ができるように
工夫して作るもんじゃないのか?


370 名前:デフォルトの名無しさん mailto:sage [04/11/22 14:36:41]
いやそういう意味じゃなくて
webstartだとサンドボックスで動くんじゃないのか?

通常アプリケーションとの違いはそこだとおもうが

371 名前:デフォルトの名無しさん mailto:sage [04/11/22 15:21:21]
WebStartはアクセス範囲をポリシーファイルで自由に設定可能。
無制限のアクセス権(つまりネイティブアプリと同等)を要求するWebStartアプリも
たくさんあるよ。

372 名前:デフォルトの名無しさん mailto:sage [04/11/22 16:09:39]
それって警告画面でなかったか?

373 名前:デフォルトの名無しさん mailto:sage [04/11/22 21:07:04]
たしか一番最初だけ出るね。「実行しますか?」というのが。
それ以降は普通に起動する。

374 名前:デフォルトの名無しさん mailto:sage [04/11/22 21:50:55]
毎回起動時に出るよ

そんなのユーザーが安心してつかうとはかぎらんだろ
それくらいならJava起動するだけのexe作ったほうがいい
ついでにランタイムも同梱してJavaであることすら意識させないでね

375 名前:デフォルトの名無しさん mailto:sage [04/11/22 22:05:57]
>>374
おおーい。起動時に毎回出る「場合もある」だけでしょー。
1回の同意で以降は聞かれないっていうのもありなんだから。

exeを作る意味は?exeあってもどうせJavaのランタイムがないと動かんでしょ?
ランタイムを入れてるんだったらjnlpで起動しても初回の同意ダイアログさえクリアすれば問題ない。
exeファイルをマシンの中に持ってくるまでの作業よりも(ダウンロード>解凍|インストーラ実行)
よっぽど敷居低いでしょ?

376 名前:デフォルトの名無しさん mailto:sage [04/11/22 23:03:03]
セットアップが嫌という環境もあるわけだ
レジストリをいじられたくないとかね

とくに体験版とかで配布する場合とか圧縮だけのほうが喜ばれるぞい


377 名前:デフォルトの名無しさん mailto:sage [04/11/22 23:07:38]
WebStartアプリって署名なしですべての機能が使えたっけ?

JNLPAPIだけのようなきがしたが



378 名前:デフォルトの名無しさん mailto:sage [04/11/22 23:39:40]
>>376
JREを入れる時点で多少なりとレジストリへ書き込むだろ。
ttp://java.sun.com/j2se/1.4/ja/docs/ja/guide/plugin/developer_guide/version.html
とにかく、「圧縮だけのほうが喜ばれる」というのには賛成できないな。
俺は、得体の知れないサイトからダウソした生のjarとかexeとかでは,
トロイの木馬かもわからんから、起動するのは恐い。

377が書いているように、JNLP APIしか使わないようなソフトなら
署名も不要になるし、セキュリティ的な安心感を与えられる。
ちゃんとした.jnlpのほうが、ユーザに喜ばれると思うぞ。


379 名前:デフォルトの名無しさん mailto:sage [04/11/23 00:37:20]
まずJREが入っていること、という前提が難しいことに気がつけ

ちなみに>>376>>377も俺な
JNLPAPIだけでもローカル資源アクセスは警告文でるぞ
プリントとファイルアクセスしか試してないがどちらもでる


380 名前:デフォルトの名無しさん mailto:sage [04/11/23 00:55:09]
「次回は聞かない」みたいなチェックボックスないんだっけ

381 名前:デフォルトの名無しさん mailto:sage [04/11/23 01:34:43]
>>379
客自身にJREをインストールさせられないような案件なら、
そもそもJavaを使うのを避けたほうがいいんじゃないか?
WinXP SP2以降は、JREをActiveXのセキュリティホールから
自動インストールさせる技も使えなくなったしな。

俺の場合、客先に導入されているPCがIBMで、
JREがプレインストールされていたから、悩まずに済んだけどな。


382 名前:デフォルトの名無しさん mailto:sage [04/11/23 14:11:06]
仕事で使う場合とそれ以外で使う場合とで分かれるな

仕事でならJREをセットアップさせるのは手間ではないが、
これも最近はJRE同根でやってる

JREのバージョン違いでの動作の不具合を防ぐためね

ゲーム等ではJREのセットアップを別にしておいてくださいというのは
手間もあって嫌がる人は多い

クロスプラットフォームでのゲーム作成という目的もあるから
JRE付属させるだけでいいのでJavaはそれなりに存在意義あるよ


383 名前:デフォルトの名無しさん mailto:sage [04/11/23 17:21:59]
>>382
ちょっと待て。言ってることが矛盾してるぞ。
結局ユーザにJREを入れさせるのが前提なんじゃねーか。
該当するJREをあらかじめインストールしてあるユーザからすれば、
わざわざ余計なもの同梱すんじゃねー糞が!ってとこだな。

警告文をユーザに見せるのがそんなに嫌か?
おまえみたいなセキュリティ意識の低いやつは、
セキュリティ意識の低いユーザと馴れ合ってるのがお似合いだな。

ちなみに、JavaWebStartには、アプリケーションの動作に必要な
バージョンのJREをユーザが持っていないときには、
自動でダウンロード・インストールしてくれる機能がある。
アプリにJREを同梱するだなんて時代は、とっくに終わってんだよ…


384 名前:デフォルトの名無しさん [04/11/23 17:59:20]
ようやく話題が次世代Javaっぽくなってきたのでアゲ


385 名前:デフォルトの名無しさん mailto:sage [04/11/23 18:02:37]
JREが入ってるのが前提ってのはおかしいな

毎回警告文がでるゲームとか使いたいというやつの気がしれん

webstartは場合によっては使えるものの
JNLPAPI以外はあいかわらずサンドボックス内じゃねーの?

386 名前:デフォルトの名無しさん mailto:sage [04/11/23 18:02:58]
JREっていつWindows標準搭載になるの?
デフォルトでインストール済みにしてよ。

387 名前:デフォルトの名無しさん mailto:sage [04/11/23 18:07:27]
>>385
コード署名しろ




388 名前:デフォルトの名無しさん mailto:sage [04/11/23 19:04:18]
すべて署名しろっていうのは結局すべてActiveXで作るのとかわらんな

389 名前:デフォルトの名無しさん mailto:sage [04/11/23 19:05:07]
署名しても認証局とかの問題で貧乏人は警告文でるだろ・・・

390 名前:デフォルトの名無しさん mailto:sage [04/11/23 19:13:24]
java.net内のこの辺について話せるスレはここですか
community.java.net/javatools/
community.java.net/javadesktop/

391 名前:デフォルトの名無しさん mailto:sage [04/11/23 21:15:39]
最初の1回はVerisignの証明書でコード署名してたって警告は出るだろ。


392 名前:デフォルトの名無しさん mailto:sage [04/11/23 21:56:47]
PKIはユーザ各自が安全と思われる経路でルート証明書を入手していることが前提。
んでもって、その証明書からの信用の連鎖をユーザが理解してリスクを受け入れる
ことで、サービスに関する責任の線引きをできるようにすることに意味がある。
これの価値がわからないか、面倒だと思う奴は、電子署名とか使わないほうがいいぞ。

JavaWebStartにも、ユーザが手作業でルート証明書をインポートする機能が用意されてある。
ルート証明書を自己署名で作って、安全と思われる経路でユーザに配る方法を、
自前で持っているのなら、Verisignとかに頼らずにこの機能を使うのが普通だと思う。
貧乏かどうかとかは関係無い(企業内で利用する場合とか)。


393 名前:デフォルトの名無しさん mailto:sage [04/11/23 22:04:52]
ちなみにJavaWebStartには、証明書の指紋をGUI上で確認する方法が無い。
手作業での証明書の受け渡し・インポートをさせるときに、
内容が本物であることを確かめにくい。PKIとしては不備だ思う。

1.5からのJavaWebStartのアプリケーションマネージャは、
編集→設定→セキュリティ→証明書→詳細 をすると、
cerの中身のバイナリが表示されるようになったので、
この画面をダンプして印刷してユーザに配布しておけば、
代用できるかもしれないけどな。


394 名前:デフォルトの名無しさん mailto:sage [04/11/23 23:06:04]
>>393
1.5から多少よくなったのか
ノーチェックだった
さんきゅ

395 名前:デフォルトの名無しさん mailto:sage [04/11/23 23:09:00]
>>392
企業内ならWbeStart使わないという手が一番だったけどな

セットアッププログラムでJRE埋め込みとスタートアップ部分作って
ネット経由で肝心の実行プログラムのダウンロード、実行という仕組み作ってる

再発明とかいうな
手間の問題とかJREのバージョン問題とかプログラムの追加と削除で
アンインストールができることとかいろいろあってな

396 名前:デフォルトの名無しさん mailto:sage [04/11/23 23:47:16]
>>394
つーか、1.5になってなお、鍵指紋を表示するフィールドが無い、
っていうことをには、わりとガッカリさせられている。
keytoolで鍵を作る過程でも、MD5,SHA1とかは、
フツーに表示されてるのにな….1.6?に期待、なのかな…。

>>395
セットアッププログラムを配るというのなら、
ネイティブバイナリのインストーラで、
JREインストール+JavaWebStartでのアプリ導入・警告了承済の
構成状態を作ってやるほうが、バージョンアップとか、いろいろ
楽できると思うがな。


397 名前:デフォルトの名無しさん [04/11/24 02:09:16]
横道にそれてしまいますが、、、
これからの時代、クライアント上で動くプログラムが
「セキュリティチェックの為に警告ダイアログが出力される」という
動作自体が、便利といわれるか、不便といわれるかで
ニーズが分かれるような気がする。

例えば話ですが、
ウイルスバスターで個人情報保護設定で自分の名前やメールアドレスを
登録しておいたら、意外と不便でした。主に、登録フォーム系のページ
が大体引っかかる。んで、やり直しが発生。



398 名前:デフォルトの名無しさん mailto:sage [04/11/24 02:54:21]
まあ月並みだが便利さと安全性のトレードオフだろ。
.NETはどちらかというと便利さに重きをおいていて
Javaはどちらかというと安全性に重きをおいているという話。

399 名前:デフォルトの名無しさん mailto:sage [04/11/24 03:08:24]
>>397
そりゃ、Javaのセキュリティサンドボックスの話じゃなくて、
PICSとかP3Pとかの情報の入りと出のポリシの設定とか、
CC/PPとかのcontent negotiation系の技術に関わる話なんじゃないかな。


400 名前:デフォルトの名無しさん [04/11/26 00:00:46]
>>397
これからの時代は
セキュアプログラミングに対する意識が高まったことにより
安全性が重要視される。

セキュアプログラミングをしないで
セキュリティホールを作ってしまうと逮捕されてしまうことがあるらしいぞ。
恐ろしいことに。C/C++プログラマはソフトウェア開発で慎重にならなければならない
立場に追いやられてる。

401 名前:デフォルトの名無しさん mailto:sage [04/11/26 00:06:55]
問題は何度も何度も警告ダイアログでてきて
ほいほいOK押すもんだから
なんの意味もないということだ


402 名前:デフォルトの名無しさん mailto:sage [04/11/26 00:17:07]
もしくはまったく内容を確認せずに寄り付かなくなるかだな

403 名前:デフォルトの名無しさん mailto:sage [04/11/26 21:12:21]
java web start起動時のメッセージはかなり引くよ、
まるで全件委譲の誓約書にサインさせられるみたいなんだから。

404 名前:デフォルトの名無しさん mailto:sage [04/11/26 22:36:29]
1.5ってどうやって起動させるの?
1.4にあったあのアイコンが無いのですが・・・

405 名前:デフォルトの名無しさん mailto:sage [04/11/27 01:08:18]
>>403
そりゃJavaWebStartに限らないよ。
いろいろなソフトウェアをインストールするときに出てくるライセンス文書は、
真面目に読むと、かな〜り引くような内容が多いよ。

JavaWebStartのアレは、シロウトが読んでも、リスクがあるということが
ちゃんと理解できるような書き方をしている分だけ、良心的だと俺は思うよ。

まぁ、署名なし・securityなしとのやつと、
署名あり・all-permission,application-client-permissionsのやつとの間で,
何かもうちょっと、資源アクセス権限の許認可を、GUIで対話的にできるような
しくみがあったりしてもいいかなぁ…、とかは思うけどね。


406 名前:405 mailto:sage [04/11/27 01:11:38]
>>404 まちがえた。
誤 application-client-permissions
正 j2ee-application-client-permissions


407 名前:405 mailto:sage [04/11/27 01:17:26]
ごめん。こんどは数字をまちがえた。さっきのは404じゃなくて405。
ついでに404に回答すると、
JavaWebStartのアプリケーションマネージャなら、
jreのフォルダの中のjavawsフォルダの中にある、
javaws.exeで起動できるはず。




408 名前:デフォルトの名無しさん mailto:sage [04/11/27 01:31:29]
1.5の場合には「Javaアプリケーションキャッシュビューア」と言うらしい。
jre1.5.0\bin\javaws.exe


409 名前:デフォルトの名無しさん mailto:sage [04/11/27 01:39:41]
>>405
あれ?でも実際問題として、JavaWebStartで起動したアプリって、
それほどの権限もってるんだっけ?
つまり普通のexe並みの権限を?

410 名前:デフォルトの名無しさん mailto:sage [04/11/27 01:56:48]
>>403
警告のデザインをもっと工夫して
わかりやすくすればいいと思うけどな

411 名前:405 mailto:sage [04/11/27 02:02:56]
すべてのjarに署名して、.jnlpに
<security>
<all-permissions/>
</security>
と書けば、exe並です。
っていうかふつうのJavaアプリケーションと同じ。


412 名前:デフォルトの名無しさん mailto:sage [04/11/27 11:08:54]
でもそれだと信頼できないActiveXのアプリを野放しにしているのと同じだからな
アプリケーションの変わりに使うというのならいいのだが
webstartはアプレットのように気軽にブラウザから起動できるので危険極まりない

それならばいったんダウンロードさせて各自の責任においてアプリケーションを起動したほうがまし


413 名前:デフォルトの名無しさん mailto:sage [04/11/27 11:26:07]
ダウンロードさせて各自の責任においてアプリケーションを起動

webstartじゃん。

414 名前:デフォルトの名無しさん mailto:sage [04/11/27 11:26:14]
>>412
あれ、まさしくその通りなんじゃないんだっけ?<JavaWebStart

415 名前:414 mailto:sage [04/11/27 11:27:23]
被った・・・。
秒単位で。

416 名前:デフォルトの名無しさん mailto:sage [04/11/27 11:44:12]
AllPermissionで使った場合でも、アプリケーションを配布してインストールさせる
必要がないってところがウリなんだろ。新バージョンをあげとけば、WebStartが
勝手に認識してダウンロードしてくれるし。

417 名前:デフォルトの名無しさん mailto:sage [04/11/27 11:50:01]
自分で保存先を選んでウイルススキャンして実行とかできるのにたいして
webstartはリンククリックしたらいきなり起動だからな
ユーザーはしらないでOKOKと押していくよ

アプレットやwebstartはサンドボックスの中でありながら影響のない部分で
アプリを動かせるのだけが強みかと

JNLPAPIみるかぎりアプレットでは制限厳しすぎたと思ってるようだけどね

まぁ野良署名つきがいいと思うのならActiveXでもいいしアプレットでもいいけどな




418 名前:デフォルトの名無しさん mailto:sage [04/11/27 11:54:57]
WebStartはベターアプレットを目指してるだけだから
JNLPAPIによるサンドボックス内の緩和とキャッシュ制御だけだと思うがな

基本的に署名はベリサインと握手せんといかん

419 名前:デフォルトの名無しさん mailto:sage [04/11/27 11:55:41]
ダウンロード&実行と比べれば、どうでもいい話だな。

420 名前:デフォルトの名無しさん mailto:sage [04/11/27 12:07:37]
ワンクッションおくというのがいいという場合もある
あとはリソース読み込みがなぜかうまくいかないライブラリもそれなりにある
JavaSoundとか変な動きするのがちらほらと

421 名前:デフォルトの名無しさん mailto:sage [04/11/27 12:37:41]
ああインターネット配布を想定してたのか。なるほどね。
おれは企業内で社内アプリとか配布するのを想定してたから、
「ウイルス汚染されたもんを配布サーバに置いたらクビもんだろ」
とか思ってしまったよ。

422 名前:デフォルトの名無しさん mailto:sage [04/11/27 16:04:53]
JavaWebStartではendorsed mechanismが使えないから、
JRE同梱のXalan2のバグとかを回避できなくて、泣いた。


423 名前:デフォルトの名無しさん [04/11/28 15:24:47]
>>418
別に自前署名でも問題ないぞ。DLL使いたいがためにVerisign使うバカはいない。
ってか、Mustangのネタはどうなった。個人的にはJVMの共有が気になる。
JVM起動のフットプリントがさらに下がるわけだし。
Acrobatの常駐プロセスのっけてるのに気がつかんようなやつなら
「Java速くなった」って単純に喜べるようになるでしょ?

424 名前:デフォルトの名無しさん mailto:sage [04/11/28 15:47:00]
自前じゃ警告がなぁ
社内システムとかならそれでいいかもしれんが

425 名前:デフォルトの名無しさん mailto:sage [04/11/28 20:40:55]
いつでも安全にローカルディスク上から取り除く為の仕掛けを各プログラムによ
らないセントラルなシステムとしてJava自身(JavaVM?)が持つ。

そして、警告は実行時に逐次ポップアップしてユーザーに許可を問う。
例えば、ローカルディスクから読み出しを行う場合、「警告:〜がローカルディス
ク上のファイル××に対する読み出し権限を要求しています。許可しますか?」
といった具合。
ここでの許可不許可は全てセントラルなシステムに記録され、いつでもユーザー
によって変更する事ができるものとする。

こうなってれば俺としては安心して使えるんだが、どうだろう?

426 名前:デフォルトの名無しさん mailto:sage [04/11/28 20:49:01]
署名なしのJNLPAPIがほぼそれだけど?


427 名前:デフォルトの名無しさん mailto:sage [04/11/28 21:26:25]
>>426
あれ?そうなの?
どこかのスレにサンプルとして貼られてたURLをクリックしたら
最初に全ての権限を要求されたけど?
これだと、完全拒絶か完全黙認かの二択しかない。

あと、これってどこからアンインストールできるのか分からん。
真面目に調べれば直ぐにみつかる事なのかもしれないけど
大して邪魔にもならんから放ってる。
ただ第三者に自分が提供する場合を考えると、もうちょっとど
うにかならんか?と思う。



428 名前:デフォルトの名無しさん mailto:sage [04/11/28 21:38:13]
そりゃサンプルが全権限を要求したからだろうなあ。全権限要求するアプリには、
最初に警告がでる。

言ってるのは、ファイルとかにアクセスするたびに「許可しますか?」と聞いてきて、
許可したら、許可したってことを覚えておくってこと?
そうだとしたら、ちょっとうっとうしくないかな?

それよりはJNLPみたいに、ファイルAには読み書き、ファイルBには読み込みのみ、
開けるソケットは何番から何番、と一括で制御できるほうが。

429 名前:デフォルトの名無しさん mailto:sage [04/11/28 21:43:24]
全権要求は一般的なWebstartとはいえん
自分で適当にサンプル作ってやってみればわかる

プリンタ使うときやファイルの保存やロードのダイアログを出す直前に
確認のダイアログが出る

次からもこのダイアログを出すかどうかのチェックボックスもでる
ただし、アプリ終了したら次回もまた確認の画面はでるが

JNLPAPIの実装でやってるんだろうね
VMがずっと見張っているというのは厳しいからね

430 名前:デフォルトの名無しさん mailto:sage [04/11/28 22:03:26]
>>428
>言ってるのは、ファイルとかにアクセスするたびに「許可しますか?」と聞いてきて、
>許可したら、許可したってことを覚えておくってこと?
そう、とりあえず実行してみて、信用するか否かは動作を見ながら決める。
そして、許可した権限は何時でも好きな時に一覧として閲覧したり変更したりでき
ると、そんな感じ。

自分とこの看板に自信がある人なら、最初に全権を要求するとか、読み込みに関
するフリーパスを要求しても大丈夫だろうけど、そうでない(例えば、2ch発の名無
しさんアプリだったり?した)場合に、最初から敬遠されてしまっては意味がないか
ら、段階的に少しずつ要求したい(&してほしい)。

勿論、最初にある程度纏まった要求を出す事*も*できていいと思う。
個別に毎回というのは、あくまで+αとしてって事で

431 名前:デフォルトの名無しさん mailto:sage [04/11/28 22:10:12]
>>429
げっ、すれ違ったorz

個別に要求を出す事はできるのか・・・・・・
それじゃあ後は覚えててくれて、一覧で確認できて、それを変更する事も
できて、嫌になったら何時でも放り出せる様になってれば十分。

ダイアログが出せるなら、一覧から過去に要求を問うた事があるか否か
を調べて、ないならダイアログを出し、あるならその時に設定されたフラ
グを元に動作を決定すればいいだけだから、やろうと思えばやれると思
う。

432 名前:デフォルトの名無しさん mailto:sage [04/11/29 09:50:59]
まとめるとこんな感じであってますか?
■署名なし
 JNLP APIでのみ、ローカルリソースにアクセス可能。
 アクセス開始時に確認ダイアログがでて、以後は許可とすることができるが、
 起動しなおすとまた確認ダイアログがでるのでうざい。
■自己署名
 all-permissionにして、通常のJavaアプリとして操作可能。
 1回目の起動時のみ、確認ダイアログが表示される。
 「この証明書の信頼性を検証できません」というキツイメッセージ。
■Verisignで署名
 all-permissionにして、通常のJavaアプリとして操作可能。
 1回目の起動時のみ、確認ダイアログが表示される。
 自己署名よりもやさしいメッセージ。
■自己署名の証明書をルート証明書としてインストール
 Verisignで署名したのと同じような表示。
 証明書の安全な配布・インストール方法が必要なので面倒。
 1.5より前は、証明書の指紋をGUI上で確認する方法が無いので、
 インストールした証明書が本物かどうか確認できない。

433 名前:デフォルトの名無しさん mailto:sage [04/11/29 11:19:53]
>>432
乙!

だいたい、いいんじゃない。
all-permission じゃなくて all-permissions だけどな。

ちなみに俺は all-permissions と j2ee-application-client-permissions の
違いがよくわからん。教えてエロイ人。


434 名前:デフォルトの名無しさん mailto:sage [04/11/29 11:32:56]
webstartスレかと思うくらいの流れだが
6.0の話題はまったくないな

5.0も変更が大きすぎて今まで以上に以降が進んでいないように見える


435 名前:デフォルトの名無しさん mailto:sage [04/11/29 14:05:04]
6.0によるJVM共有の意義は、サーバ側Javaよりもむしろ、
クライアント側Javaのほうにある、ってことだろ。

そういう意味で、JavaWebStartを話題にするのは、
それなりに主旨に合ってると思うぞ。


436 名前:デフォルトの名無しさん mailto:sage [04/11/29 14:37:15]
MustangかDolphineかで、入るとか入らないとか言われている、
JDICについて貼っときます。

https://jdic.dev.java.net/

The JDesktop Integration Components (JDIC) project aims to make Java
technology-based applications ("Java applications") first-class citizens of
current desktop platforms without sacrificing platform independence.

JDIC provides Java applications with access to facilities provided by the native
desktop such as the mailer, the browser, and registered document viewing
applications. Additionally it provides the mechanisms by which Java applications
can integrate into the native desktop such as registering Java applications as
document viewers on the desktop, creating tray icons on the desktop, and
creating installer packages.

JDIC consists of a collection of Java packages (JDIC API), all with the package
name prefix org.jdesktop.jdic, and a JNLP application packaging tool (JDIC
Packager).

つーわけで、これもJNLPでdeployされるわけだ。


437 名前:デフォルトの名無しさん mailto:sage [04/11/29 14:57:44]
>>428,429
ttp://java.sun.com/products/javawebstart/docs/javadoc/
の、FileOpenServiceとかFileSaveServiceを見てくれ。

JNLPでは、どのファイルを開く・どのファイルに保存するかは
ユーザが選ぶするから安全、という考え方をするようだ。

よって、「他のプロセスが作ったディレクトリ/ファイルを共有して、
ディレクトリ単位での処理をする」というようなプログラムが書けない
ことになる(署名が必要になる。ちょっと不便。JNLP APIが改訂されないかな…)。

署名無しでクライアントローカルに永続データを作って、
アプリケーション間で共有して読み書きしたければ、
PersistenceServiceを使え、ということらしい。




438 名前:デフォルトの名無しさん mailto:sage [04/11/29 19:13:54]
javaws が CUIで使えるようになったらいいのになぁ・・・ってこういうの1.6ではどうでしょう。

439 名前:デフォルトの名無しさん mailto:sage [04/11/29 21:27:17]
>>437
429だけどなんで参照されたのかわからんが、当たり前のことかかれても

ユーザーで選択するから安全ってのはWebstartが標準添付される前から
やってきた俺にとっては当たり前というか、まずはそこを解決したかったのが
WebStartという感じだが


440 名前:デフォルトの名無しさん mailto:sage [04/11/29 23:11:45]
>>439 なんか誤解させてしまってスマソ。

ようは、JNLP APIの、FileOpenServiceとかFileSaveServiceは、
JFileChooser#setFileSelectionModeメソッドでFILES_ONLYにした場合の
JFileChooserに相当する機能しか使えないけど、
DIRECTORIES_ONLYやFILES_AND_DIRECTORIESの機能も使いたい、ってこと。

java.io.Fileというクラスには、
javax.naming.Binding的な機能と、
javax.naming.Context的な機能などが,
いろいろに混ざっている。

で、これに対して、
javax.jnlp.FileContentsというクラスは、
javax.naming.Binding的な機能に相当するクラスとして作られている。
javax.naming.Context的な機能は取り除かれている。

java.io.Fileを生で使わせるのは危ないっていうのはわかる。
でも本当に危ないのは、
・java.io.Fileのコンストラクタが呼び出せる
・java.io.File#getParentが使える
の2点に限られるんじゃないのかなぁ?

javax.jnlp.FileOpenServiceやjavax.jnlp.FileSaveServiceから
ユーザの自己責任で生成されたオブジェクトに対して使うんだから、
javax.naming.Context的な機能も使わせてくれよ、って俺は思うんだよ。

つーわけで、javax.jnlp.FileContentsのサブクラスとして
javax.jnlp.FileContextなんていうのが作られることを1.6ではキボンヌ。


441 名前:439 mailto:sage [04/11/29 23:14:31]
ああ、了解了解

ところで次のやつは6.0だよな?
内部バージョンも次からは6.0と聞いたが

442 名前:440 mailto:sage [04/11/29 23:14:57]
ごめん、FileContents はインターフェイスだった。


443 名前:デフォルトの名無しさん mailto:sage [04/12/01 01:03:40]
内部バージョンって System.getProperty("java.version") とかで取れる奴の事?

444 名前:デフォルトの名無しさん mailto:sage [04/12/05 16:46:03]
public class Binder2nd<_Arg1, _Arg2, _Result, _Operation extends BinaryFunction<_Arg1, _Arg2 , _Result>>
implements UnaryFunction<_Arg1, _Result> {

protected _Operation op;
protected _Arg2 y;
public Binder2nd(_Operation __op, _Arg2 __y) {
op = __op;
y = __y;
}
public _Result execute(_Arg1 __x) {
return op.execute(__x, y);
}

public static <_A1, _A2, _R>
Binder2nd<_A1, _A2, _R, BinaryFunction<_A1, _A2, _R>> make(BinaryFunction<_A1, _A2, _R> __fn, _A2 __y) {
return new Binder2nd<_A1, _A2, _R, BinaryFunction<_A1, _A2, _R>>(__fn, __y);
}
}

これはもうJAVAじゃないな

445 名前:デフォルトの名無しさん [05/02/27 09:12:59 ]
期待あげ
6.0仕様公開らしいよ
ttp://jcp.org/en/jsr/detail?id=270


446 名前:デフォルトの名無しさん mailto:sage [05/02/27 14:42:50 ]
jsr203 NIO2入れて欲しかったなぁ。。。

447 名前:デフォルトの名無しさん mailto:sage [05/02/27 15:48:03 ]
6.0のソースコードgets.

このソースコード、ほんとにJVM入ってるの?




448 名前:デフォルトの名無しさん mailto:sage [05/02/27 16:10:20 ]
>>446
なんができるの?

449 名前:デフォルトの名無しさん mailto:sage [05/02/27 18:34:01 ]
NIOはネットワークソケット周りにOSのnon-blockingアクセスを使えるようにして高速化した。
メモリバッファをJVM内ではなくOSのネイティブなメモリ空間を使用したりするなど、なかなか
いい感じだった。

だけどNon-blocking I/Oはソケットにしかつかえないという制限もあった。メモリマップ・ファイル
とか意欲的な取り組みもあったけど、やはりキモはSocketのNon-blocking I/Oだった。

NIO2はファイル周りにも手を付けて、OSの非同期ファイルアクセス機能を取り入れたり、
ファイル属性を扱えるようにしたり、NIOで未実装となったものも実装しちゃうぞ、となかな
か面白い試みで、実はJSRとしてあげられた段階では 1.5 Tigerに入れる、とか書いてた。

実際VoteもMacromedia以外はOK出してるんだけど、6.0にも乗らないのかよ...

450 名前:デフォルトの名無しさん mailto:sage [05/02/27 19:27:13 ]
そうなのか。
いまさらNIOの質問だけど、NIOのメモリバッファって、JVMの設定とは別にメモリが使えることになるのかな。

451 名前:デフォルトの名無しさん mailto:sage [05/02/27 19:31:55 ]
allocateDirect()で確保されたバッファは、JVMのヒープじゃなくて、
プラットフォームのネイティブなメモリ空間として確保されるから、関係なかったはず。

ごめんソースが出せない...

452 名前:デフォルトの名無しさん mailto:sage [05/02/27 19:47:32 ]
サンクス。
なんとなく巨大なメモリが必要なときにつかえそうだってことがわかった。

453 名前:デフォルトの名無しさん mailto:sage [05/02/27 22:12:08 ]
>>450
ほとんどのケースで NIO 使わんほうが
効率いいけどな。

454 名前:デフォルトの名無しさん mailto:sage [05/02/27 23:02:05 ]
NIOというと
New I/Oと勘違いしそうだ

455 名前:デフォルトの名無しさん mailto:sage [05/02/27 23:06:25 ]
NIOっていったらNew I/Oじゃん。

456 名前:デフォルトの名無しさん mailto:sage [05/02/27 23:16:59 ]
Nice I/Oに決まってる。

457 名前:デフォルトの名無しさん mailto:sage [05/02/28 00:01:07 ]
>>454
天然?



458 名前:デフォルトの名無しさん mailto:sage [05/02/28 00:08:51 ]
Neo I/O

459 名前:デフォルトの名無しさん [05/02/28 04:48:47 ]
トリニティ助けてー

460 名前:デフォルトの名無しさん [05/02/28 23:14:14 ]
6.0のソースコード解読はムズい。
コメントが少なすぎてわけわからんよ

461 名前:デフォルトの名無しさん [05/03/01 09:33:44 ]
Non-blocking I/O

New I/O

New I/Oのパッケージ名が
java.nio
なら
Non-blocking I/O

java.nbio
になる?

462 名前:デフォルトの名無しさん mailto:sage [05/03/01 21:00:49 ]
Non-blocking I/OはNew I/Oの一機能にすぎんぞ。
だからjava.nio.channel.SocketChannelでサポートされてる。

463 名前:デフォルトの名無しさん mailto:sage [05/03/04 17:47:39 ]
bugs.sun.com/bugdatabase/view_bug.do?bug_id=4057701
上記のは Evaluation に書いてあるんだけど、
ディスクの空きスペースを取得するAPIはMustangに追加されるみたい。

464 名前:デフォルトの名無しさん mailto:sage [05/03/05 12:01:05 ]
DirectByteBufferってJNI側で確保したメモリ領域をJavaから使えるようにするために用意したとしか思えん

465 名前:デフォルトの名無しさん mailto:sage [05/03/09 01:45:35 ]
ファイラー書いてるんで、お願いだから属性の取得、設定を追加して欲しい・・・

466 名前:デフォルトの名無しさん mailto:sage [05/03/09 01:46:37 ]
ごめん、ファイルの属性ね。

467 名前:デフォルトの名無しさん mailto:sage [05/03/09 13:03:31 ]
>>465
jconfig使えってのが定番の答えだねぇ。

JDICとかに要望出してみれば?



468 名前:465 mailto:sage [05/03/11 00:59:24 ]
JConfigはフリーじゃないのが痛いけど、品質が確かなら
採用する価値ありそうだね。
JDICにも要望出してみるよ。
ありがとう。

469 名前:デフォルトの名無しさん mailto:sage [05/03/14 04:40:57 ]
そういやJDICってMustangに入るって噂あったけど入らないことに決まったの?

P.S. そろそろ Dolphine のスレたたないのかな?






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

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<228KB

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