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

現世代Javaの動向 1 ..

196:デフォルトの名無しさん
06/10/25 21:01:15
>>195
つURLﾘﾝｸ(java.sun.com)

197:デフォルトの名無しさん
06/10/26 00:09:36
Lightweightという単語を初めて見たのはSwingについての説明だったと思うが、
こんなに流行るとは思わなかった

198:デフォルトの名無しさん
06/10/26 00:14:07
Component ベースだと普通にSwing使ったほうが手軽だし高速になるよな

199:デフォルトの名無しさん
06/10/26 01:48:13
>>196 この様子だと、永遠に解決されないみたいですね。

200:デフォルトの名無しさん
06/10/26 02:59:30
>>199
それはOSの問題だと思うが

201:デフォルトの名無しさん
06/10/26 03:05:05
AWTがリソース食うってのは、要するにMFCのCButtonなんかが
ウィンドウだってのと同じことなんだが、わかってる?

202:デフォルトの名無しさん
06/10/26 12:47:03
改善はそれぞれ SWT, Swing, AWT でそれぞれ実験（実装）済みってこと。
Windows9xのときはGDIとかシステムリソース気にしてたけど、
今じゃそんなのどうでもよくて、レスポンスが速いかの方にうつってる。
リソース食いまくるとか過去の話し出し、つまり一番速いAWTつかってOK。

203:デフォルトの名無しさん
06/10/26 13:03:36
でも貧弱すぎてつかうやついねーよ

204:デフォルトの名無しさん
06/10/26 20:04:32
Swing結構速いけど？

205:デフォルトの名無しさん
06/10/26 22:59:45
>>204 Pentium 133 とかだとどうだ？

206:デフォルトの名無しさん
06/10/26 23:02:32
それだとWindowsXPどころか2000やNT4もおもいぞ

207:デフォルトの名無しさん
06/10/26 23:12:38
あれだ、Pentium133は少し言い過ぎだけど、Swingでプログラム作っても
そのプログラムの処理は低速CPUで事足りるんじゃないか？

Javaってのは最新・現状のパソコンだけをターゲットにした言語じゃないだろ。

208:デフォルトの名無しさん
06/10/26 23:22:41
VMは最新に
そしてメモリの速度やキャッシュの速度は速いほうがいい
NetburstアーキよりPenM系列のほうが早い

あとSwingはJava2Dが需要なのでアクセラレーションのレスポンスがいい統合チップセットは意外と早い

Swing使った業務アプリはずっと作ってるけど快適さはやっぱりコードにもよるね
OSがNT4でJRE1.3.1、Pen3/600MHzは快適だった
2000やXPだと5.0にしてPen3/1GHzクラスにならないと快適さはおいつかない感じ

209:デフォルトの名無しさん
06/10/27 00:08:33
>>208
それはSwingやJavaが速いとかではなくて、ハードが進化して速くなった事はじゃないか？
業務アプリならなおさらだけど、端末がNTでPentium 200-600とかざらだからね。
それでSwingはないだろ。そしてJavaつかってもらいたいのに、
AWT無視とかどういうことだ？これだったら、UIはWebブラウザの方に流れて当然。

2D, 3DはJavaでなくてC/C++や専用ライブラリ使うから、
Javaはいくらハードが進化しても入り込めない。
今も昔も、何年たってもいまだにJava向けのヒットゲームないでしょ？

210:デフォルトの名無しさん
06/10/27 00:12:56
>>209
ハードも大事だし、VMの種類も大事とかいてるだろ
1.2と5.0くらべたら恐ろしいほどの性能さだぞ

それに当時のマシンならブラウザよりSwingのほうがはるかに軽いぞ
ブラウザってかなりメモリは食うし重いものなんだよ
それにインターフェースとして参照系ならともかく入力系はおわっとる
AWTも機能不足

ゲームは今MMORPGとかで海外はJava製ふえてきてる

211:デフォルトの名無しさん
06/10/27 00:43:01
性能差は認めるが、その効果が実感できるのは性能（VMの出来）よりも
ハードの進歩が格段に勝っていたってこと。ハード（CPUやGPU）はJavaだけ
じゃなくて他の処理（OSやイベント）をこなして、さらに余った余力でやっても、
VMの性能よりも高速ってどういうこと？

業務アプリはデータベース問い合わせを想定しているが、
大体は業務アプリはその程度じゃないか？AWTやブラウザで十分だろ。
つまりブラウザが重いとか言ってるなら、(winなら）VBとかでUIつくっても
いいけど、そうするとどこにJava（とSwing）の出番があるんだ？

212:デフォルトの名無しさん
06/10/27 00:48:54
>>211
DB引いてくるだけて、・・・・どんな業務アプリ・・・
集計ロジックくらいは、入るだろ。

ユーザとのインタラクションはいくらでも入ってくる。

213:デフォルトの名無しさん
06/10/27 01:00:09
どうもJavaがデスクトップに入り込めないでいるのは、
「出番なし」だからじゃないか？
C, C++, Perl, Ruby, JavaScript ライバルの方が強すぎて
（PCの）デスクトップには入れないだろ。
ネットワークでも、アプレットでこけたのがいたかったんじゃないか？
今じゃFlashに持ってかれてるし… （デスクトップの話ね）

214:デフォルトの名無しさん
06/10/27 06:54:07
ビジネス系だとAppletのが多いけどな。
まあオーサリングツールが無かったのと
ダウンロードの手間がFlashのが少なかったというのが大きい

215:デフォルトの名無しさん
06/10/27 08:28:55
>>212
集計ロジックはサーバサイドにやらせて
画面は入力と参照だけの作りが多いと思う。
三階層モデルが普通。DB直で触るような
C/Sモデルは5年前くらいに下火になってる。

それよりも210氏が指摘してるが入力系での優位性が大きい。
ブラウザで入力なんてのは業務系だと無理。
(業務系はえてして入力項目数が多い。)
ここ数年はそれでやってきたプロジェクトが多いけど
結局効率下げるだけで現場では不評。
これからはブラウザベースで作った業務アプリを
作り直す需要が多くなる。(既に増え始めてる。)
リッチクライアントの標準を巡って主導権争いが盛んなのもそれを見越してるから。

Swing は能力的に善戦できると思うんだけど
JRE 入れないと行けないところが難点。
(業務系になると致命的な問題にはならないことが多い。)
FLASH の方がウケが良いのは確かだが、
Swing アプリの方が制約の少ない分、後で盛り返せる余地はあると思う。

アプレットは問題外。これ提案するようなベンダーと付き合うべきでない。

216:デフォルトの名無しさん
06/10/27 09:40:09
FLASHで業務アプリって今流行ってんの？

217:デフォルトの名無しさん
06/10/27 11:06:46
>>215
>ここ数年はそれでやってきたプロジェクトが多いけど
>結局効率下げるだけで現場では不評。
>これからはブラウザベースで作った業務アプリを
>作り直す需要が多くなる。(既に増え始めてる。)
>リッチクライアントの標準を巡って主導権争いが盛んなのもそれを見越してるから。
でもこのおかげで社員のほとんどは意味も無いのにPCの前に座らせる必要が無いって事に経営層が気づいたのは事実
更に業務はパッケージ買って、経理/人事の社内総務部門をアウトソースして
株主へ利益を還元していく仕組みが出来上がりつつある

218:デフォルトの名無しさん
06/10/27 12:12:50
サーバーサイドが普及してきたのはこの5年ほどだし
すべてWEBアプリになってるわけじゃない

クライアントサーバーも開発コストの面で優れるために今でも業務系では多いし
WEBアプリからクラサバや３層式への動きもある
って>>215と重なることばっかりだ
業務系パッケージ／受託とかクラサバ多くてびびるかもよ
ようは流行とか関係なくユーザーの求めるもの作ったところが勝ち

ただアプレットはリッチクライアント用途として問題ないと思うぞ
WEBスタートにしてもいいわけだし、もちろんSwingを使うわけだし

>>216
開発ライセンスの問題とか高コストとかライブラリが整備されていないとかあって
わりと敬遠されてる
3倍金はらってくれるなら作ってもいいとはよく言われる

>>217
総務のアウトソースってはやってるようには見えないし、
パッケージのカスタマイズだけでは無理な場合も多いぞ
無理してカスタマイズされたコードのさらに修正とか死ぬぞ
新規に作ったほうが早くて使いやすい場合も多い

日本はユーザーがパッケージに業務をあわせる文化ないからね

219:217
06/10/27 12:37:05
>>218
仕組みが出来つつあるってこと
偽装派遣を合法化した結果はおそらくそこに影響が出る
最終的には金を生み出す仕組みと借金の担保になる会社という資産以外は交換可能な部品にするのが今の経団連のトップ辺りに居る連中の考え方

220:デフォルトの名無しさん
06/10/27 13:19:18
偽装請負がいつ合法化されたの？
この数年どんどん手が入ってるでしょ

キヤノンとか偽装請負すべてやめると明言したばかりでしょ

221:デフォルトの名無しさん
06/10/27 14:46:03
キャノン・トヨタ・派遣。
密告とかなかなか深いね。
これから噴出する問題だね。
御手洗さんですか・・・
ただ、スレ違い。

222:デフォルトの名無しさん
06/10/27 14:51:15
>>215
なかなか良かったんですが…
>Swing アプリの方が制約の少ない分、後で盛り返せる余地はあると思う。
これの根拠はあるんですか？次のJava6でってこと？

>アプレットは問題外。これ提案するようなベンダーと付き合うべきでない。
そうでもないと思うけど、どうしてアプレットは問題外なの？
確か、サーバ・クライアントモデルで、DB集計はサーバーって書いて
るんだから自分の言ってる事と矛盾してるでしょ。

223:デフォルトの名無しさん
06/10/27 15:36:43
>>222
昔のしょぼい連中の作ったJavaAppletをみてリッチクライアントじゃねえとか思ってる口だから気にするな

224:デフォルトの名無しさん
06/10/27 21:56:24
>>222
＞これの根拠は
ローカルリソースにアクセスする為に
署名しろとかいろいろ面倒。
ブラウザから始めるのも一手間無駄になる。
(ブラウザを開くことと仕事とは一切関係がない。)
zip 落として展開して、これを叩いてください、
次からはショートカット叩きゃOKです、の方が最終的に楽。

だと俺は思ってる。そうは思ってない人も居るだろうし、
それは根拠と言えないだろうと言われればそれまで。
個人の意見なのでご自由にどうぞ。

＞どうしてアプレットは問題外なの？
アプリに比べて上段で挙げたことを感じるから。
逆にアプレットの方が優れてるところってどこでしょうか？

225:デフォルトの名無しさん
06/10/27 22:22:01
>>224
>個人の意見
そういうことなら了解です。面倒とかそういうのは分かりますです。

>アプレットの方が優れ
サーバー・クライアントモデル、そのままってところでしょうか。

226:デフォルトの名無しさん
06/10/27 23:07:19
これってアプレット？

CGoban 3 のダウンロード
URLﾘﾝｸ(www.gokgs.com)

227:デフォルトの名無しさん
06/10/27 23:17:24
署名って面倒か？
「最初に自動的にインストールしてくれます。更新も自動です。」
ってだけでしょ。

228:デフォルトの名無しさん
06/10/28 00:20:59
>>224
そもそも一般人はローカルにZIP落として適当なフォルダに展開というのを嫌がる＆出来ない人もいる
というのを認識したほうがいい

わかる人だとZIP版のほうがレジストリいじらないとか変なところやられてないとか安心感はあるけど
普通の人はウィザードインストーラがないとダメみたい

WebStartって最初だけでその後はショートカットがデスクトップに自動的に生成されたり
バージョンチェックとか細かく動かなかったっけ？
アプレットもあるバージョンだった科からはいろいろと細かく動くしね

用途としてローカル資産いじりまくるようなのは確か似合わないけど
WebStartアプレットならJNLPAPI経由でローカル資源はアクセス可能だよ

雇う側からすると今の時代は鯖サイドの技術者のほうが入手せいがいいので
クライアントはあくまでも操作性がいいSwingベース、鯖でロジックという3層式はやりやすい
SpringとかDI使ってさくさく組めるしね

229:デフォルトの名無しさん
06/10/28 00:28:44
>>228
>>226がそれ。
起動時にバージョンアップもしてくれるので楽。

230:デフォルトの名無しさん
06/10/28 00:29:53
数年で便利になりましたね～
まだまだ途中ですけどね～

231:デフォルトの名無しさん
06/10/28 00:48:00
さっきJREを_09にアップデートしたんだけど以前のJREも残るんだな。
しかもJDKじゃないからserver vmはふるいまんまだし。
せめて古いバージョンって自動的に削除とかしてくれないの？

232:デフォルトの名無しさん
06/10/28 00:52:57
本来あってはならないことだけど
パッチレベルの違いで挙動が異なるプログラムがある以上
勝手に削除するわけには行かないところなのが実情。

233:デフォルトの名無しさん
06/10/28 01:32:35
新陳代謝の激しいフリーウェアにはいいかも知れんね。
例えばゲームとかだと頻繁にバグフィクスや難度調整が入るだろうし。

234:デフォルトの名無しさん
06/10/28 03:50:26
>>213
「デスクトップ」という言葉が何を指しているのか人によってまちまちなんで
難しいんだけど。

Perl, Ruby, Java Scriptはサーバーサイドでよく使われる技術であって、
ＰＣのデスクトップでの競争にはならないんだと思うけど。

Ruby&Ruby on Railsも、ウェブアプリケーション開発でPHP, Python, Perlを
飛び越してJavaの得意とする業務系でとタイマンでやり合えるかも？という
期待感で注目されているわけで。

デスクトップについてはおれはSwingで作ったらWin標準と同等になるという
ここ最近の状態を今の今まで作らなかったのが最大の敗因だと思う。

あとOSをまたがって汎用性を持たせようとするあまり、あるプラットフォーム
固有の文化というかやり方に合わせようとしないような文化がJavaには
あるような気がする。

例えば、MacユーザーはMacぽくないUIはうけいれないし。

一方でV2Cという２チャンネルビューアがプラットフォームを超えて受け入れられ
ているのは、もしかしたら今後に期待できるということなのかもなーとか思う。

235:デフォルトの名無しさん
06/10/28 04:28:57
JavaScriptは思いっきりクライアントサイドですがな。

236:デフォルトの名無しさん
06/10/28 05:25:12
JavaScriptはデスクトップでの競争になってるな。

237:デフォルトの名無しさん
06/10/28 09:24:55
Web2.0という名称の下で、デスクトップの領域に侵食しようと頑張っているよね。

238:デフォルトの名無しさん
06/10/28 09:32:19
Adobeがアポロだったかいう名前で
デスクトップ用のFlash&Ajaxな世界を画策してるな。

239:デフォルトの名無しさん
06/10/28 10:59:01
cgiも単なるインターフェースでperlとかもともとクライアント用途メインだったし

240:デフォルトの名無しさん
06/10/28 11:03:36
>>234はMacのSwingみたことないのかなぁ

241:デフォルトの名無しさん
06/10/28 15:22:46
>>240
ないんだろうなぁ・・・・

242:デフォルトの名無しさん
06/10/28 15:38:52
>>234は強烈な電波ってことで・・
言いたい事はわかるが、ずれてる・・

243:デフォルトの名無しさん
06/10/28 18:11:23
VM が 0 秒以下で起動するようにならんと
Java 遅いというレッテルはなくならない。
つまり永遠になくならない。

244:デフォルトの名無しさん
06/10/28 18:26:45
OS起動時にサービスとして立ち上がり、
そのまま実行環境を10個くらいプーリングし
要求に応じて割り当てる。
メモリをデフォで2GB以上消費する。

そんなJVMサービスプロセス。

245:デフォルトの名無しさん
06/10/28 18:45:59
Windowsのプロセス起動の遅さは10年たっても改善されていないけど実用になってるのだが
その辺はどうかね

246:デフォルトの名無しさん
06/10/28 18:50:18
ハードが進化してるから

247:デフォルトの名無しさん
06/10/28 20:38:33
坊やだからさ

248:デフォルトの名無しさん
06/10/29 00:34:40
>>245
どうかねって言われても、この図式だろ。
話をそらしたつもりか？

Java アプリ：プロセス起動時間＋ VM 起動時間
ネイティブアプリ：プロセス起動時間

249:デフォルトの名無しさん
06/10/29 04:22:05
>>243
JVMのプロセス起動しとけばいいじゃない
MVMが実現したら、解決だな、それじゃ

250:デフォルトの名無しさん
06/10/29 15:37:09
>>248
こまかい揚げ足だが、
＞Java アプリ：プロセス起動時間＋ VM 起動時間
Javaの場合、プロセス＝JVMだから、プロセス起動時間＋バイトコード起動時間ね。
昔は.EXEは.COMに比べて起動に時間がかかるとか言われてたけど、いまや誰も気にしてないから、
そのうち、マシンパワーが吸収してくれると思う。WindowsはUNIX系に比べて元々プロセス起動が重いOSだからね。
だからスレッドが発達した訳だし。
でも、regeditとかnotepadのような軽さには到達できんとは思うが。

>>249
やっぱり、.NET Frameworkのような、バイトコード実行インフラが必要になるわけね。
JavaもGlobal Jar Cacheとか作って、共用JarはJITコンパイルされて、キャッシャされるのだろうか。

251:デフォルトの名無しさん
06/10/29 16:34:48
ユーザーの作ったクラスは難しいと思う
アプリごとにクラスパスも違うし、バージョンアップ作業もコピーだけでよかったり
クラスパスルートもさまざまだしね

でも標準APIくらいはやってくれてもよさそうなんだけどね

あと設定でクラスをロードしたらすべてコンパイル完成するまで待つというモードもほしいよ
ゲーム用途とかだととくにね

フォアグラウンドコンパイルにしたところでそのメソッドを指定スレッショルド以上つかわないと
コンパイルされねーからな

252:デフォルトの名無しさん
06/10/29 17:07:46
>251 -Xcomp

253:デフォルトの名無しさん
06/10/29 17:17:15
>>252
だからそれだとだめなんだってば
フォアグラウンドコンパイルになるだけ

254:デフォルトの名無しさん
06/10/29 17:34:14
>253 それは-batchでは。

255:デフォルトの名無しさん
06/10/29 17:47:59
>>254
だから実行時にコンパイルされるのはメソッド単位なのが問題といってるでしょ
-XX:+PrintCompilationで確認すればわかると思うが-Xcompでは解決しない

メソッドよびだしたときにかたまるようではそれは使い物にならない
まだバックグラウンドコンパイルして最初はインタプリタ動作のほうがかたつきはへる分まし

256:デフォルトの名無しさん
06/10/29 22:08:25
Javaじゃなければとっくに解決している問題じゃないのか。
なぜJava使ってる？

257:デフォルトの名無しさん
06/10/29 22:27:30
起動時間が遅いって・・・CGI使うわけじゃあるめーしｗ

258:デフォルトの名無しさん
06/10/30 00:25:42
Swing とか SWT って知ってるか？

259:デフォルトの名無しさん
06/10/30 00:45:54
>>250
ネイティブコンパイルの結果を再利用できればいいんだが
それと>>249の話は別、単にアプリ起動のフットプリントの話だろうから
JVM起動にかかるコストを無くしたいんだったらJVMは常駐にしとけばいいじゃん、ってこと

260:デフォルトの名無しさん
06/10/30 02:24:29
>>259
VM常任しておいて、どうやってプログラム終了するんだよ！

261:デフォルトの名無しさん
06/10/30 02:52:40
>>260
その課題も含めてMVMの実現なんだって・・・

262:デフォルトの名無しさん
06/10/30 02:54:03
現世代で出来ないならスレ違いだろ。
それをここで愚痴るな。

263:デフォルトの名無しさん
06/10/30 10:05:18
次世代のスレは糞みたいなやつが常駐してるので使い物にならん

264:デフォルトの名無しさん
06/10/30 17:03:18
>>263 だからここで愚痴るな。おまえは、やっぱりカスだな。

265:デフォルトの名無しさん
06/10/30 18:19:14
>>228
> そもそも一般人はローカルにZIP落として適当なフォルダに展開というのを嫌がる＆出来ない人もいる
> というのを認識したほうがいい
素朴な質問ですが、今時そんなことやらせてる会社ってあるのでしょうか
私の知っている会社は皆、キッティングなり配布なりでコマンド一発でOKなのですが

266:デフォルトの名無しさん
06/10/30 18:46:21
>>264
だからお前はここに来るなと

267:デフォルトの名無しさん
06/11/07 22:09:44
>>265
たとえ話として、数人でやるシェア・フリーソフトや会社内部・部署の
みで使うってのもありうるわけで…
ご自分の場合だけで考えるのはいけないですよね。

268:デフォルトの名無しさん
06/11/15 10:33:10
些末な例外は何にでもあるからな。

269:デフォルトの名無しさん
06/12/01 20:37:55
現世代って言うのか過去なのか一時JythonとかJRubyとかjava実装の言語がはやってたけど
あれは何が目的だったん？

270:デフォルトの名無しさん
06/12/01 22:13:55
・Yet Anotherな実装が欲しいが、一からつくんの面倒だしという発想
・一時期以降のJVMは結構速いから、使えば結構嬉しいかもという発想
・セキュリティ機構も活かせると面白いかもという研究ネタ
まあ色々ある。

271:デフォルトの名無しさん
06/12/02 00:05:20
現世代と言えば1.5になるのだろうか。

generics の erasure は・・・失敗だったような。

272:デフォルトの名無しさん
06/12/02 07:41:35
>>269
JRubyはRuby on Railsも動かしたりしてるし、PHPも動くし「一時」じゃ内希ガス

273:デフォルトの名無しさん
06/12/06 01:24:48
Javaって、GPLになったじゃない
だから、Troveみたいな標準より速いとかいうコレクション実装に差し替えちゃう
見たいな話とか出てこないのかな？

274:デフォルトの名無しさん
06/12/06 01:59:00
>>273
コレクションってクラスライブラリだよね？
OpenJDKでGPLv2になった部分の範囲外のような気がする。

まだ不勉強なので違ってたらごめん。

275:デフォルトの名無しさん
06/12/06 02:12:34
ライブラリはGPLの範囲外ですな

276:デフォルトの名無しさん
06/12/11 20:15:34
こんにちは、現世代Javaの仲間入りです。JDK6リリース。

URLﾘﾝｸ(java.sun.com)

277:デフォルトの名無しさん
06/12/11 21:22:27
>>276
まだ文残ってる
＞ご注意: 現時点で J2SE 5 Itanium ポートは利用できません。ダウンロードバンドルは後日リリースされる予定です。
結局5最後までItanium版出なかったなー

278:デフォルトの名無しさん
06/12/16 18:58:57
Summary of changes in Java SE 6u1 build b01
URLﾘﾝｸ(www.java.net)
URLﾘﾝｸ(download.java.net)

updateリリースに切り替わった。

279:デフォルトの名無しさん
07/01/16 21:09:27
Summary of changes in Java SE 6u1 build b02
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)

年明けなので、Copyright変えましたってのが
変更のほとんどである点がほほえましい

280:デフォルトの名無しさん
07/01/18 23:54:26
Java 6ってOpenGLをSwingで使えるんじゃなかったっけ？

281:デフォルトの名無しさん
07/01/19 00:26:48
Swingが（というかJava2Dが）OpenGLアクセラレーションできるようになってるが正解
まだバグも多いのでデフォにはできんけどな

5.0のときから一応出来るようにはなってるけどね
5.0でのOpenGLはほんとバグだらけでひどかった

282:デフォルトの名無しさん
07/01/21 05:01:11
CompilerAPIがわかんね
ファイル読み込んでクラス生成は出来ても、
文字列からのクラス生成ができね

283:デフォルトの名無しさん
07/01/21 05:51:51
仮想ファイルが使えるようになったんだっけ？

284:デフォルトの名無しさん
07/01/21 14:27:25
Compiler Tree API を隠しAPI扱いにするのはやめてほしかったなぁ。

バージョン名をパッケージ名前に含めることで下位互換性を保つことは可能だし、
なぜ隠しAPI扱いになったのか理解に苦しむ。

285:デフォルトの名無しさん
07/01/21 15:54:17
> Compiler Tree API を隠しAPI扱いにするのはやめてほしかったなぁ。
> なぜ隠しAPI扱いになったのか理解に苦しむ。
どっちなんだ……

286:デフォルトの名無しさん
07/01/21 15:59:04
キミはなにを言いたいの？
理解に苦しむ。

287:デフォルトの名無しさん
07/01/21 16:21:00
つーかCompiler API使えばクロージャ出来るじゃん・・・
わざわざ言語使用に入れんでも。

288:デフォルトの名無しさん
07/01/21 16:26:00
>>284
tree API は doclet API並に公開されてるし、compiler API は java の標準APIでしょ。

javax.lang.model の方で将来のバージョンに対する考慮はしてるみたいだし。

289:デフォルトの名無しさん
07/01/21 16:28:27
>>287
今までだってJavaCC 使うとか、自力で字句解析と構文解析すりゃできたよ。

290:デフォルトの名無しさん
07/01/21 16:32:30
>>287
サンプル書いてみろよｗ
口だけやろうがｗｗ

291:デフォルトの名無しさん
07/01/21 16:38:26
全部機械語で出来るじゃん・・・
わざわざ言語作らんでも。

こんな感じかな。

292:デフォルトの名無しさん
07/01/21 17:26:09
>>290
ほらよ
import java.io.File;
import java.io.Writer;
import javax.tools.JavaCompilerTool;
import javax.tools.JavaFileManager;
import javax.tools.JavaFileObject;
import javax.tools.ToolProvider;
public class Main {
public static void main(String[] args) {
JavaCompilerTool javaCompilerTool = ToolProvider.defaultJavaCompiler();
JavaFileManager javaFileManager = javaCompilerTool
.getStandardFileManager();
try {
JavaFileObject javaFileObject = javaFileManager
.getFileForInput("bin/Tutorials.java");
Writer writer = javaFileObject.openWriter();
writer.write("public class Tutorials{"
+ "public static void main(String[] args){"
+ "System.out.println(\"We love JavaLobby :)\");"+ "}" + "}");
writer.close();
javaCompilerTool.setOutputDirectory(new File("bin"));
System.out.println(javaCompilerTool.run(null,new JavaFileObject[]{javaFileObject}).getDiagnostics());
Class.forName("Tutorials").getDeclaredMethod("main",
new Class[] { String[].class }).invoke(null,
new Object[] { null });
} catch (Exception e) {e.printStackTrace();
}}
}

293:デフォルトの名無しさん
07/01/21 17:32:04
どこからつっこめばいいのやらｗ
まずコンパイラぐらい通せよｗｗ

294:デフォルトの名無しさん
07/02/03 18:43:05
>>287
んなもん、Java6じゃなくてもできるわ。アホかｗｗｗ
クロージャの意味を、

「よ　く　理　解　し　て　か　ら　書　い　て　ね　。」

295:デフォルトの名無しさん
07/02/03 18:44:44
Compiler APIって、APTサポートの目的が強いんだろな。

296:デフォルトの名無しさん
07/02/13 14:12:37
JDK6 の日本語ドキュメント完成だってさ。
URLﾘﾝｸ(blogs.sun.com)

297:デフォルトの名無しさん
07/02/13 16:50:44
今回すごい遅かったな
やっぱり翻訳されたAPIドキュメントがあるのとないのとでは違うからねぇ

298:デフォルトの名無しさん
07/02/19 14:49:38
URLﾘﾝｸ(java.sun.com)
並列若い世代コレクタ
(　ﾟдﾟ)・・・・・・

何処に突っ込むべきなんだろう

299:デフォルトの名無しさん
07/02/19 15:15:38
昔から直訳ってのはよくある
カタカナのままのほうがわかりやすいとかもあるしね

有名どこではシリアライズとかパーシステンスとかだが、まぁこれはまだいいほう
マイナーなAPIだとすごいままだぞ

300:デフォルトの名無しさん
07/02/20 00:23:59
永続性っていう日本語は、なんとなくイメージしやすい気がする
直列化はいまだにピンとこない。

301:デフォルトの名無しさん
07/02/20 00:26:44
劣等GPLとかすばらしいよな

302:デフォルトの名無しさん
07/02/20 08:44:18
劣等パンダ

303:デフォルトの名無しさん
07/02/26 15:24:02
Rhino は javax.script.ScriptContext#setWriter で普通の Writer 渡すと
print 時にエラー吐いて死ぬ……

こんぐらいは、フレームワーク側で吸収して欲しいよーな。

304:デフォルトの名無しさん
07/03/08 17:11:51
>>302
レッサーパンダは火狐の夢を見るか？

305:デフォルトの名無しさん
07/03/09 13:49:06
>>303
そういう差異をラッパー書いてなくしてる俺は

>>304
赤トカゲはゴジラの夢をみるか？

ゴジラには勝ったけど寿命で消えたな。役目は果たした

306:デフォルトの名無しさん
07/03/09 22:55:21
お前ら現実を見ろよ

307:デフォルトの名無しさん
07/03/20 02:16:11
javaのレンダラ探してたら3DCGレンダラ見つかった。

URLﾘﾝｸ(sunflow.sourceforge.net)
javaでここまで実用的なソフトがあったとは

308:デフォルトの名無しさん
07/03/22 23:11:28
URLﾘﾝｸ(www.java.net)
壊れっぷりが素晴らしいな。6u1 Build b04が出るのは何時になるんだ？

309:デフォルトの名無しさん
07/03/22 23:57:41
それよりJavaSE6update1の一般向けリリースをささとだしてもらわんと
ライブラリのバグ以前にVMのバグがはいってるのはかなわん

310:デフォルトの名無しさん
07/03/23 00:07:16
>>308
壊れてるっても、単に CSS のリンク先を間違ってるとかそーゆー問題じゃね？

311:デフォルトの名無しさん
07/03/24 22:07:35
>>310
いや、イメージファイルのGETがforbiddenになってる。
わけわからん。

312:デフォルトの名無しさん
07/03/25 21:44:40
Jdk6で、nioのSocketChannel#connectで頻繁にJVMごと死ぬ(jvm.dll+0xd283d)。
ググるとlimewireでも同じ問題起きてるみたいなんで、さっさとjdk1.6.0-01出してくれ。

313:デフォルトの名無しさん
07/03/25 23:05:57
俺も今日は3回落ちた
性能はいいんだけどねえ…

314:デフォルトの名無しさん
07/03/25 23:51:40
まずはライブラリ以前にVMバグ修正をさっさと

315:デフォルトの名無しさん
07/03/26 02:34:41
1.5で打ち止めでいいよ。
これ以上いじるとグダグダになる。
.Netなんか最悪だぞ

316:デフォルトの名無しさん
07/03/26 05:28:33
>>312
そんなふうに次、次を求めるから不安定になる
必要なら
URLﾘﾝｸ(download.java.net)
こっから取ってくればいい

317:デフォルトの名無しさん
07/03/26 12:50:21
>>315
5.0は言語拡張はあるけど、ライブラリやVMにほとんど手が入ってなかったからね
その割には初期はバグバグだったり日本語バグ1年半くらい放置だったな

6は5.0以上にエンタープライズ分野のバージョンアップの恩恵は大きいから
必要とされてるだろうね

7はいまのところメリットが見えてない

1.4.1以上の混乱はまぁでないだろうね

318:デフォルトの名無しさん
07/03/26 13:04:27
>>316
すまん。言葉が足りんかった。
そこのでもやっぱ>>312のように落ちるんだわ。
だから、さっさと修正して,-01を出してくれってこと。
正確には、nioのSocketChannel関係のsun.*のJNI実装DLL内で、
アクセスバイオレーションで落ちるから、jvmそのものじゃないけど、
標準配布のパッケージ使ってて、ネイティブ内で落ちられるのは耐え難い。

じゃ、1.5.0に戻せば良いのかもしれんが、JTableのTableRowSorterつかってるから、
戻すのめんどくさい。

319:デフォルトの名無しさん
07/03/26 14:57:45
>>312
ここでやるより、BugDatabase 行った方が早いと思うよ。
BugDatabase で SocketChannel connect AccessViolation で探したけど無さそうだった。

>>312 では再現条件がハッキリしないし。

320:デフォルトの名無しさん
07/03/26 16:08:31
>>318
SwingXのJXTable使ったら？
URLﾘﾝｸ(swingx.dev.java.net)

321:デフォルトの名無しさん
07/03/26 17:04:06
>>318
そうか、開発版を許容できるなら話は早い
URLﾘﾝｸ(forums.java.net)
Forumだと結構Sunのエンジニアが相手にしてくれたりするよ。
BugParadeへの登録も内部からだと早いみたいだし。

322:デフォルトの名無しさん
07/03/29 11:08:09
1.6.0_01 age

323:デフォルトの名無しさん
07/03/29 16:09:28
やっときたか
URLﾘﾝｸ(java.sun.com)
これでそれなりに安定するだろうか

324:デフォルトの名無しさん
07/03/29 21:01:16
早速入れてみた
なんかちょっと速くなった気がするよ

325:デフォルトの名無しさん
07/03/29 23:05:03
たぶん気のせい

326:デフォルトの名無しさん
07/04/02 11:37:04
JInternalFrameのバグなおってねーな
触って1分でわかるバグなのになぜ放置かと
比較的よく使われるコンポーネントだと思うんだが

327:デフォルトの名無しさん
07/04/02 14:15:11
誰も指摘しなかったら直らない

328:デフォルトの名無しさん
07/04/02 21:43:35
>>326
BugIdいくつのやつ?

329:デフォルトの名無しさん
07/04/11 13:50:50
JRE6入れてみた
かっこ良くなって、すごく軽くなった

こりゃいいな

330:デフォルトの名無しさん
07/04/12 00:32:00
見積り中の案件、.Netに負けてしまった (´・ω・`)
せっかく1.6触れると思ったのに。

331:デフォルトの名無しさん
07/04/12 11:32:01
ランタイムの互換性のなさと起動の遅さはどうでも良いのか、
それとも客がただのMS信者か・・・。

どっちにしてもデスクトップアプリケーションじゃなけりゃ6はあまり関係ないよ。

332:デフォルトの名無しさん
07/04/12 12:10:16
６はWebStartの進化がすさまじいからな
アプリケーションの追加と削除とかデスクトップやプログラムにショートカットが作られたりな

でも、肝心のスタンドアロンアプリで対応してないのがあふぉかと

333:デフォルトの名無しさん
07/04/12 12:45:58
jarアーキテクチャを拡張すればOSにインストール可能っちゃ可能だな。

MEのjadのようにインストールプロトコル作ってそれを実装したツールが有ればいいか。

jnpl実装からフィードバックが利きそうだ。

linuxやjavaに慣れてる連中には激しくウザイな。
そういう連中にはバージョン管理機能くらい付けてくれんと利点がないな。

334:デフォルトの名無しさん
07/04/12 14:48:18
別に新しいバージョン取得して置き換えるだけだからかまわんと思うけど
Javaアプリ自体いままでバージョン管理してなかったんだし、問題はないだろ

335:デフォルトの名無しさん
07/04/12 21:47:59
>>332
アプリケーションの追加と削除とか、デスクトップへのショートカットは少なくとも5.0のときからあったよ。

336:デフォルトの名無しさん
07/04/14 15:36:26
SEのバージョンって1.4.2のが5.0より安定してるの？
会社が頑なにバージョン変えないようにしてるのが煩わしい。
ぶっちゃけ今SE6を使っても、以前のバージョンのバグは
改修されてると思うんだけど、これはアホい考え？

337:デフォルトの名無しさん
07/04/14 15:46:09
1.4.2だって5.0だってエンバグしたりしてるからどれが安定かというのはない
ただ新しいほうがセキュリティホールがうまってる確率が高いのと
サポート期間で有利

メインストリームになればバグ報告も増えて安定しやすいという利点は多いね
個人的には5.0は1.4.2より安定した感じはする
最初の1年半くらいはひどかったけど

6は今年後半くらいで目立ったバグは取れるんじゃないかなと予想

なにより来年7が出ると1.4のサポートがなくなるんでそういうのも考えながら選択すべし

338:デフォルトの名無しさん
07/04/14 16:32:41
>>336
ん。アホい。
改修されているバグと増えているバグと増えている機能と変わっている機能がある。

会社が頑なに変えないのは、バカが居るだけだろ。
ちゃんと評価して、6.0の利用をすればいいだけ。1.4.2が枯れているなんてのは幻想。
1.4.2で分かっているバグでも対応しないと決められたものもあるからな。

問題は、機能的に変わっているので新しく作るのではなく
今1.4で動いているのを5,6で動かそうとすると問題がでる。こういう用途であればやめたほうがいい。

339:デフォルトの名無しさん
07/04/14 16:45:32
> 1.4.2で分かっているバグでも対応しないと決められたものもあるからな。
「枯れてる」ってのは「不具合の多くが既知である」状態でしょ。
既知の不具合がどれだけ放置されていようが
不具合の多くが既知であれば「枯れてる」と言える。
極端に致命的でなければ。

まぁ、Sun はマイナーバージョンアップでも
不具合修正だけじゃなくて、わざわざ新機能盛り込んでエンバグしたりとか
阿呆な事やらかした実績があるから油断はできないが。

340:デフォルトの名無しさん
07/04/15 10:37:15
バグが直ることによって修正が必要になるアプリもあるからね。
1.4になったときswingのフォーカスバグが直って、1.3で作ったアプリを苦労して直したよ。
直すのに苦労したんじゃなくて検証が大変だったんだけどｗ

341:デフォルトの名無しさん
07/04/16 23:08:55
新機能が安定しないのはある程度仕方ないとしても、
しばしばデグレ起こすのは問題だよな。

342:デフォルトの名無しさん
07/04/16 23:15:03
すべてのリビジョンが取得できるからsunは良心的なほうだと思う。
バグが直った結果動かなくなるとかあるわけで。

343:デフォルトの名無しさん
07/04/17 03:26:11
URLﾘﾝｸ(bugs.sun.com)
> 183 Results Returned,

URLﾘﾝｸ(bugs.sun.com)
> 183 Results Returned,

これって Windows JVM だけリーク満載ってこと？

344:デフォルトの名無しさん
07/04/17 12:46:27
そもそもそこで検索されているバグはJVM本体ではなく
関連APIや関連アプリの話がほとんどのように見える

345:デフォルトの名無しさん
07/04/19 23:15:30
1.6のdocs-jaでかすぎﾜﾛﾀｗ
JDK(SE)本体よりでかいでやんの

346:デフォルトの名無しさん
07/04/19 23:37:14
5.0とあんまりかわらんけど？
別にjaでなくても大きいし

347:デフォルトの名無しさん
07/04/22 02:26:30
zipで12MBも違うが

348:デフォルトの名無しさん
07/06/30 14:51:48
　　　　　　　　　　　 _|_
　　　　　　　　　　／＿＼
　　　　　　　　　　￣|Ｕ￣　　
　　　∧＿∧　　　 /ミヽ、　
　　　(　･ω･)　　ノﾐｼ三　`~ﾟ
　　　(っ　≡つ＝つﾟ　　ﾟ　
　　　./　　　) ﾊﾞﾊﾞﾊﾞﾊﾞ
　　　( /￣∪
　　　　　　　　　　　 _|_
　　　　　　　　　　／＿＼
　　ﾋｭﾝ　　　　　￣|Ｕ￣　　
　∧＿∧　＿∧　 /ミヽ、　
(（(　･ω･)三ω･) ノヽ　 `~ﾟ　））
　　(_っっ=　_っっﾟ　　　ﾟ　
　　　ヽ　　　ノﾋｭﾝ
　　　( /￣∪

349:デフォルトの名無しさん
07/07/04 04:57:53
1.6.0_02 age

350:デフォルトの名無しさん
07/09/27 02:36:54
JavaFXの話題はここでいいんかな

スレ立てたほうがいいかな

351:デフォルトの名無しさん
07/09/27 03:09:06
いんじゃないココで？

352:デフォルトの名無しさん
07/09/28 01:04:53
スレ立てないわ、話題はふらないわで>>351涙目ｗｗｗｗ

353:デフォルトの名無しさん
07/10/01 00:01:44
きょうび何の検討もなく1.42であるべきだといいはる自称Java通がいて悲しくなった。

354:デフォルトの名無しさん
07/10/01 00:06:56
1.4系のサポート切れるのが近づいてるのは無視するんかねぇ
もう2世代前のメジャーバージョンじゃきっついな

2世代前というと・・・今から作るアプリはWindowsMEをターゲットにするべきといってるのと同じことだな

5.0の言語仕様についていけないやつじゃね？
大幅に安定したコードがかけるというのに・・・

355:デフォルトの名無しさん
07/10/01 01:19:51
>>353
理由を明確に説明させてやれ。
長い期間使うものであればあるほど危険であるというのは明白。
３年前ならともかく、今、5.0以降を使わないのはサポート的に危険。

JavaSE7のリリースと同時に1.4シリーズはSunがサポートを放棄します(EOL)
その自称Java痛がサポートしてくれるんでしょうか？と言ってください。

356:デフォルトの名無しさん
07/10/01 01:35:28
でかいところで、自社サポートやってる場合は、むしろ1.4.2の方がよかったりするんだろうか。
そういうレベルのところで、5.0は安定してきているんだろうか？

357:デフォルトの名無しさん
07/10/01 01:46:39
まあ、ケチを付けてる理由がむかーし個人的にぶつかった不具合一つで
それも既に解消していたりするんじゃないかと思うんだが・・・・
何の検討もなくって、所がもう・・・・

ただ、XML扱ってるとこは注意が必要かも、とは思う。
それでも、今から作るなら5.0以降だね。

358:デフォルトの名無しさん
07/10/01 03:34:50
バグフィックスにしてもポートは危険伴うし、1.4.2だから安定というものでもないよ
わりと1.4.2もエンバグくりかえしてるし

359:デフォルトの名無しさん
07/10/01 08:38:25
富士通とかでかいところは、自分ところでバグフィックスしてて、Sunのリリースでは修正されていないバグとかも修正されているという話を聞くけど。
そのレベルでは、Sunのリリースは使い物にならないとか。

360:デフォルトの名無しさん
07/10/01 10:45:09
富士通は自前のハードウェアでSolaris動かしているから、
Sunのハードウェアに適用できないパッチもある。
もちろん共通のバグを富士通がfixすることもあるのだが。

361:デフォルトの名無しさん
07/10/01 12:30:55
自分でソース治したいのならJDK6以上オススメ

昔は各社自前でJREもっていたんだが、結局一番使われるWindows版が安定していたというオチもある

362:デフォルトの名無しさん
07/10/01 15:26:27
次世代のようにこっちもビルド情報あった方がいいのかな、と
JDK6u5 build04
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(www.java.net)

Nimbusが入ってきているという噂があるのでこれから試してみるつもりです。

363:デフォルトの名無しさん
07/10/02 12:55:23
>>362
u3とu4はどこいったんだろ。欠番？

364:デフォルトの名無しさん
07/10/03 01:14:09
"Java SE 6 Update N"最新成果物登場 - 次期Java SE 6はフル改善
URLﾘﾝｸ(journal.mycom.co.jp)

現世代でこんなに変化があるとは思いませんでした。

365:デフォルトの名無しさん
07/10/03 06:03:46
6u3 release age

366:デフォルトの名無しさん
07/10/03 14:12:50
>>363
ビルド番号は、update release毎に刻まれているようです。
なので、u4はもうQAフェーズなのでは？

367:デフォルトの名無しさん
07/10/17 21:40:32
6u3の変更点は何処を見れば分かる？

368:デフォルトの名無しさん
07/10/17 22:47:18
リリースノートみればわかる
基本的にセキュリティアップデートだけだよ
バグが直るのはu4以降

369:デフォルトの名無しさん
07/10/18 01:19:10
>>368
ありがと

370:デフォルトの名無しさん
07/10/20 02:47:01
Update N っていつリリースされるんだろな？
期待してるんだけど。

371:デフォルトの名無しさん
07/10/20 10:09:05
Q.When will the Update N be available?
A. This update is expected to be released to the public around mid 2008.

URLﾘﾝｸ(jdk6.dev.java.net)
URLﾘﾝｸ(jdk6.dev.java.net)

372:デフォルトの名無しさん
07/10/21 02:16:47
Flashのインストール率は「ほぼ100％」
URLﾘﾝｸ(www.atmarkit.co.jp)

JREの普及率はどのくらいだろう？
なんの根拠も無いけど80%ぐらいかな

バージョンの比率も知りたい。
一般人の環境見てるとJRE1.1とか結構いるんだよねｗ

373:デフォルトの名無しさん
07/10/21 06:25:02
1.1ってのはMSのVMじゃないか？

374:デフォルトの名無しさん
07/10/21 10:16:01
>>372
JRE入ってないWindowsプレインストール機ってかなり多いからね。

375:デフォルトの名無しさん
07/10/21 17:42:49
一般的なメーカー製だと5.0とか結構はいってるけどな
IEが搭載しなくなったし、1.1よりは今はシェアあるだろ

376:デフォルトの名無しさん
07/10/21 17:44:00
flashはほぼはいってるが、バージョンで大きな差がありすぎるのが癌
ブラウザで広告が表示できてないのはよく見る

377:デフォルトの名無しさん
07/10/21 20:59:39
会社では、DELLかLenovoのを買うけど、ほぼ確実にJRE入っているなあ
個人ではショップブランドばかりで、OSすぐに入れ直すから、入っていないけど

378:デフォルトの名無しさん
07/10/22 09:16:48
富士通FMV-BIBLO/Vistaは入ってなかった。
MSはややこしい契約で縛る可能性があるからなあ。

379:デフォルトの名無しさん
07/10/25 01:21:41
>>372
URLﾘﾝｸ(www.adobe.com)
URLﾘﾝｸ(www.adobe.com)

380:デフォルトの名無しさん
07/10/25 10:12:42
Java、結構頑張ってんな

381:デフォルトの名無しさん
07/10/26 02:05:40
これ、ConsumerJREが入ったら一気に化けるだろ。

382:デフォルトの名無しさん
07/10/27 23:09:57
明るい未来を信じてます。

383:デフォルトの名無しさん
07/11/15 13:52:54
6uNの新しいビルドでたね

Nimbus周りのバグとJFileChooserの件が
治ったみたい

384:デフォルトの名無しさん
07/11/15 14:52:41
今スナップショットだっけ？
位置づけとしてはマイルストーン？

385:デフォルトの名無しさん
07/11/19 04:51:19
Java Web Startは、巨大な辞書ファイルをランダムアクセス
するようなアプリ配布には使えないのかな。
セキュリティマネージャを使ったのとか。
説明書読むと、すべてjarファイルになってることという条件がついてる。

386:デフォルトの名無しさん
07/11/19 04:56:23
jarにすりゃいいじゃん

387:デフォルトの名無しさん
07/11/19 07:54:45
うーむ、それはそうなんだけど・・・
修正しなきゃいかん部分がたくさんある。テストもやりなおしだなぁ。
でもま、やってみるわ。なんとかなるような気もしてきた。

388:デフォルトの名無しさん
07/11/19 12:01:34
>>386
その文章を理解するとは頭いいな

389:デフォルトの名無しさん
07/11/25 15:59:56
>>385
巨大な辞書ファイルはサーバーで持つべきでは？
何のためのWebだよ。

390:デフォルトの名無しさん
07/11/25 17:51:12
>>389
それしたらオフラインで使えないでしょ。
モバイルのユーザが不便じゃん。

391:デフォルトの名無しさん
07/11/25 17:59:34
でもさ、すべてをjarにする必要はないよ。
JWSはアプレットの延長じゃなくて、Javaアプリのインストーラーだから。
パーミッションでフルアクセスを許可してしまえばすべて解決。

392:デフォルトの名無しさん
07/11/26 14:27:43
>>391
の延長として。

JWSは、それだけでは使いづらいので
アプリケーションのインストーラもしくはランチャーとして使うのが便利だと思う。
ランチャーの仕組みとかは作らないと駄目だけど
リソース周りの自由度がちょっと上がる。
（どうキャッシュさせるかとか、実行中のアップデート確認とか）

393:デフォルトの名無しさん
07/11/27 20:05:50
JWSは機種依存しないインストーラーだからすげーありがたい。

ところでJWSが広く使われるようになると、ソフトの配布の方法が変わってくるよね。
みんなソフトの会社・作者のサイトから直接DLして、第二者、第三者からコピーを
もらう必要はなくなるし、ソフト制作サイドもコピーして配布される形態
を最初から作る必要がなくなって状況次第では楽できる選択肢だったりする。

でもGPLを適用したソフトだとライセンスにひっかかることはないのかな。
漏れはGPLにはどっちかというと否定的なんだけどさ。

394:デフォルトの名無しさん
07/11/28 01:14:24
JWSはjavaアプリケーションデプロイ仕様の一つの実装であってインストーラではない。

395:デフォルトの名無しさん
07/11/28 04:18:09
はいはい

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)のほうが、ユーザに配慮しているとはいえまいか？

次ページ