アカウント名:
パスワード:
ていうかですね、入力するシステムまで官庁が用意するのが おかしいんですよ。
国の事務関係のファイルフォーマットとその送付方法だけ 定めれば、あとは（Intuitとかみたいな）民間が使い勝手の よいアプリケーションを開発・販売するのではないか？
そこを官庁が使い勝手と品質に劣るシステムをわざわざ作って 無料化とかやるから民間のビジネスチャンスは潰すわ、 駄目システムで利用者を減らすわ、縦割り弊害でコストは かかるは電子政府をせっせと潰しているんだから世話ないと しかいいようがありません。
元ACですが、クライアント側で各アプリケーションが 独自に色々なことをするのははっきりいって望ましい。
例えば会計ソフトに申請機能を組み込む、CADソフトに 建築設計の審査申請機能を埋め込む、などなどです。 もちろん拡張部分はそのアプリ固有に閉じますが、その シェアを奪わんとする側は移行ツールを用意するなど 製品をさらに改善してくるでしょう。また逆に、アプリに 閉じない汎用ツールを目指す側はシンプルな申請ツールを 開発するでしょう。
申請操作ではなく、本質的な申請情報の部分に国の役割を 限定することがクライアント側に自由をもたらし、一定 ルールの下での自由競争が多様性と品質の改善を もたらします。最終的にはこのような民間がドライブする 努力こそが優れた電子国家を作るのであって、国は申請を 受け付けるプレーヤでもあるものの、基本的にはそれを 阻害しない範囲での審判に徹しなくてはなりません。
リファレンス実装に関していえば、あくまでリファレンスに とどまる（MIT X 的？）のであれば有益ですが、現状では 実提供にシフトしてしまっていること、また、実装に 傾きすぎて、本質である情報交換フォーマット・プロトコルの 制定からかけ離れていることから、現状反対です。彼らは 単なる「リファレンス」実装の表面動作に囚われすぎており、 規格制定の重要性・意義について理解しているとは 思えません。これは各省庁の責というより、e-japanという 大本の基本方針が「枠組み作り」ではなく「動かすこと」に 実質なってしまっていることが大きいかとは思いますが。
なお、ここから先は枝葉末節な技術論ですが、フォーマット対 パラメータについては、フォーマットであるべきと思います。 これらの情報の応用分野を広げるには、
>入力補助機能のみをJavaScriptでというような w3mではJavaScriptが使えない。 多くの環境で使ってもらえるWebサービスではないです。
「入力『補助』機能」に JavaScript が使われるくらいなら構わないのではないでしょうか？ JavaScript が実装されていない UA なら自力で入力すればすむことです。
# JavaScript が画面遷移とかに使われていて、かつ # 手動で画面遷移できるボタンだの何だのが # 画面上になければ「死ね」ですが。
本申立てプログラムの稼働に必要な中間プログラム（JRE:Java Runtime Environment）の脆弱性について（平成１７年２月２１日） この問題については，JREを「1.4.2_06」にバージョンアップすることで回避できるとのことですが，裁判所オンライン申立てシステムでは，「JRE1.4.2_06」について，動作確認ができていません。
この問題については，JREを「1.4.2_06」にバージョンアップすることで回避できるとのことですが，裁判所オンライン申立てシステムでは，「JRE1.4.2_06」について，動作確認ができていません。
この程度の違いでどうして動かなくなるのだろう？ と思うわけだけど、最高裁判所のシステムを使うには、必要なプログラム等のダウンロード [courts.go.jp] のページから申立てプログラム [courts.go.jp] というWindowsアプリケーションをダウンロードしてインストールしないといけなくて、ダウンロードした「courtshu_setup.exe」というファイルを起動すると、
裁判所オンライン申立てシステム Setup JRE 1.4.2_04のレジストリの読み取りに失敗しました。 JRE 1.4.2_04をインストールしていない場合はインストールしてから実行してください。
JRE 1.4.2_04のレジストリの読み取りに失敗しました。 JRE 1.4.2_04をインストールしていない場合はインストールしてから実行してください。
「技術的にはある程度過去のバージョンのJREでも動く様にできるけど入札仕様書でそれが要求されてないんだから現行のバージョンだけ(もしくは自分たちが使い慣れたバージョンだけ)で動くようにしておいて、さらに文句が出ないようにそれ以外では動かないように制限しておこうっと」
Windows みたいな、温泉旅館状態の「汚い」APIと云うのも、下位互換性確保の点からは重要ではないかと。
総務省によると、文部科学省以外の電子申請にはパソコンにあらかじめ、米サン・マイクロシステムズ社のＪＲＥというプログラムを導入する必要がある。パソコンの基本ソフトであるＯＳが違っても申請のための操作を可能にするためだ。
Applet でなくて Java Web Start を使えばいいのに。別窓になるけど。
それ以前に、どうせ Windows しかサポートしないのなら ActiveX を使えばいいのにw
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
Webは不便だ (スコア:5, すばらしい洞察)
Java必須とかFlash必須とかActiveX必須とかはイントラ向けならありですが、多くの人が自由に使えるサービスには不向きです。特に公のものならなおさら。
WebアプリケーションはWebブラウザから使え、クライアント側のアプリケーション更新も必要なく、「多くの人が利用できる」反面、ネイティブアプリケーションに比べて制約が多く入力補助や画面の変化がスムーズでなく、UI操作をリンクとボタンのクリックのみに縛られるなど「ユーザにとって不便」です。
最初に「ユーザにとって不便」という面の認識をきちんと分かってもらってないと、不便さを克服しようとしてJavaやFlash等を持ち出してネイティブアプリ寄りなことを実現し、その代償としてWebアプリケーションとしての「多くの人が利用できる」利点を失っているのだと思う。
Re:Webは不便だ (スコア:4, すばらしい洞察)
ていうかですね、入力するシステムまで官庁が用意するのが おかしいんですよ。
国の事務関係のファイルフォーマットとその送付方法だけ 定めれば、あとは（Intuitとかみたいな）民間が使い勝手の よいアプリケーションを開発・販売するのではないか？
そこを官庁が使い勝手と品質に劣るシステムをわざわざ作って 無料化とかやるから民間のビジネスチャンスは潰すわ、 駄目システムで利用者を減らすわ、縦割り弊害でコストは かかるは電子政府をせっせと潰しているんだから世話ないと しかいいようがありません。
Re:Webは不便だ (スコア:2, すばらしい洞察)
ドメインのルート(当時internicやjpnic)は原則として定型フォーマットのメールで申請を受け付けていました。
事業者はwebform等の皮をかぶせてユーザに提供します。
そこに使いやすい事業者、使いにくい事業者等の差が出てきます。
あるいは自力で定型フォーマット書けば事業者通さずに安く上げることもできました。
現在はjpドメインの場合は必ず事業者通すようになってるので、事業者-jprs間でどのようなやり取りになっているのかはユーザには不明ですが、おそらく内部的には定型フォーマットで、皮や価格の部分で各社競争しているという構図は変わらないと思います。
Re:Webは不便だ (スコア:2, 参考になる)
> 制定したフォーマットとプロトコルが形骸化する恐れがあるからです。
そんなことはあり得ないでしょ。
元ACの提案は、
ユーザーインターフェース周りは民間にまかせて、
官庁の電子申請用サーバは、
・制定したプロトコルを通して
・制定したフォーマット形式のデータが届いたら
・申請を処理する
・UIの無いシステム
にしたらどうかということですから、プロトコルやフォーマットに独自の機能拡張なんかしようとしても、官庁サーバ側が受け付けてくれません。
問題が起きるとしたら、
「官庁ごとに勝手な独自拡張をして、官庁間の互換性が取れなくなる」
可能性でしょうか。
縦割りでいかにも起きそうです。
国は枠組みを作り、民間が実行を担う (スコア:4, 興味深い)
元ACですが、クライアント側で各アプリケーションが 独自に色々なことをするのははっきりいって望ましい。
例えば会計ソフトに申請機能を組み込む、CADソフトに 建築設計の審査申請機能を埋め込む、などなどです。 もちろん拡張部分はそのアプリ固有に閉じますが、その シェアを奪わんとする側は移行ツールを用意するなど 製品をさらに改善してくるでしょう。また逆に、アプリに 閉じない汎用ツールを目指す側はシンプルな申請ツールを 開発するでしょう。
申請操作ではなく、本質的な申請情報の部分に国の役割を 限定することがクライアント側に自由をもたらし、一定 ルールの下での自由競争が多様性と品質の改善を もたらします。最終的にはこのような民間がドライブする 努力こそが優れた電子国家を作るのであって、国は申請を 受け付けるプレーヤでもあるものの、基本的にはそれを 阻害しない範囲での審判に徹しなくてはなりません。
リファレンス実装に関していえば、あくまでリファレンスに とどまる（MIT X 的？）のであれば有益ですが、現状では 実提供にシフトしてしまっていること、また、実装に 傾きすぎて、本質である情報交換フォーマット・プロトコルの 制定からかけ離れていることから、現状反対です。彼らは 単なる「リファレンス」実装の表面動作に囚われすぎており、 規格制定の重要性・意義について理解しているとは 思えません。これは各省庁の責というより、e-japanという 大本の基本方針が「枠組み作り」ではなく「動かすこと」に 実質なってしまっていることが大きいかとは思いますが。
なお、ここから先は枝葉末節な技術論ですが、フォーマット対 パラメータについては、フォーマットであるべきと思います。 これらの情報の応用分野を広げるには、
- 情報として流通可能で、
- 他の情報と統合でき、
- 他の情報から抽出できる
といった点を満たさなくてはなりません。そして、 このためには、標準の表現形式（＝フォーマット）でなくては なりません。官庁 API のほげほげパラメータとかではまったく不足です。Re:Webは不便だ (スコア:1, すばらしい洞察)
#w3mしか使ってない人って、全Webユーザの何ppmくらい?
Re:Webは不便だ (スコア:1)
どれだけ多くのシステムに、ユーザの閲覧を必要としない
Web クライアントがあると思ってる？
ユーザが直接扱う Web ブラウザなんてのは、
Web クライアントが使われる場面のうちの、ほんの
一部でしかないよ。
# mishimaは本田透先生を熱烈に応援しています
Re:Webは不便だ (スコア:1, すばらしい洞察)
w3mはページャであるという逃げ道があるからいいけど。
Re:Webは不便だ (スコア:1)
Ajaxも、そういう風に使われていればいいんだけどね。
Re:Webは不便だ (スコア:1)
「入力『補助』機能」に JavaScript が使われるくらいなら構わないのではないでしょうか？ JavaScript が実装されていない UA なら自力で入力すればすむことです。
# JavaScript が画面遷移とかに使われていて、かつ
# 手動で画面遷移できるボタンだの何だのが
# 画面上になければ「死ね」ですが。
Re:Webは不便だ (スコア:2, 参考になる)
DocomoとかDocomoとかDocomoとか。
せめてクッキーくらいは使えるようにしないと、セッションキーをURLに含むハメに遭い、セキュリティ面でも相当危ういサイト作りになってるところが多い。
その点、auは標準的な作りのページにしていれば、携帯であることを意識した作りにしていなくてもしっかり使えるのが嬉しい。
vodafoneはよくしらない…
JREの互換性以前の問題（一部の発展途上官庁） (スコア:5, 参考になる)
この程度の違いでどうして動かなくなるのだろう？ と思うわけだけど、最高裁判所のシステムを使うには、必要なプログラム等のダウンロード [courts.go.jp] のページから申立てプログラム [courts.go.jp] というWindowsアプリケーションをダウンロードしてインストールしないといけなくて、ダウンロードした「courtshu_setup.exe」というファイルを起動すると、
というエラーダイアログが現れるようになっていて、わざわざインストールできないようにされてるわけ。仕様書の書き方がわるいのか？ (スコア:2, 興味深い)
っていう感じじゃないのかなぁ。
屍体メモ [windy.cx]
Re:JREの互換性以前の問題（一部の発展途上官庁） (スコア:3, 参考になる)
結局のところ、技術的に互換性があるのかないのかは関係ないんですよね。
設計書に「前提JREは1.4.2」と書いてあれば、他のJREはサポート外。サポート外であればもし不具合が起きても開発会社から「正しいJRE使ってください」と言われるだけ。
本当は開発会社とかSEとかプログラマはたぶん分かっていると思います。このバージョンでもたぶん動くだろうと。
ただしテストしてないのに動くとは絶対言えないから、設計書にはなるべく限定して前提条件を書く。
じゃあテストすればいいんですが、実際問題として、動いているシステムで新しいJREでの稼働検証の予算をつけるのは難しい。つかたぶん無理。
官庁の末端の担当者が必要性を理解していたとしても、新しい機能が付くわけでもないのに上司を説得できないでしょう。
だから対策としては、
(1) 予算取りに上司を説得できる大義名分のため、電子政府統括庁というものが出来てそいつが電子政府全体のJREバージョンを各省庁に強制する。JREがバージョンアップしたら、そのJREでの検証もさせる。
(2) JREが、アプリごとに任意のJREを使い分けられるような仕組みになる。どうやら.NETは出来ている？
-- sun burst.
参考資料 (スコア:3, 参考になる)
縦割りの功 (スコア:3, おもしろおかしい)
縦割りの弊害じゃなくJREの問題かと (スコア:2, すばらしい洞察)
JREの弊害を、政府に‥という論点ですりかえるのは如何なものか？
#根本的な問題はそこだろう。全く同時期に開発・リリースされるものならいざ知らず。
Re:縦割りの弊害じゃなくJREの問題かと (スコア:3, 参考になる)
例えばe-japanの名の下にアーキテクチャの標準化等をすればかなり改善できのにそう言う動きはあまり見えない。
今は日付処理のようなどこでも使う物でも個別に開発している。
この程度の事でも共有していれば互換性の問題に気づけるのに縦割りだからそれが無い。
バラバラなのはJREのバージョン程度ですむ話ではないのだ。
どちらかというとJRE問題は結果でしょう。
Y.HIROSI
Re:縦割りの弊害じゃなくJREの問題かと (スコア:1, すばらしい洞察)
実際にはリリース時のJREでしか検証してなくて、新版での検証費用を各省庁がケチっているだけなんじゃあ。
Re:縦割りの弊害じゃなくJREの問題かと (スコア:1, 参考になる)
Re:縦割りの弊害じゃなくJREの問題かと (スコア:1, 参考になる)
それだけじゃ無理ですね。
WindowsのAPIが汚いというのはよく言われる話ではありますが、旧来のAPIを残すだけではABIの維持(リコンパイル不要)は達成出来ても仕様変更等の問題には対処しづらいでしょう。
良くも悪くも「汚い」のはそこじゃなくって、こっちの方かな。
http://www.radiumsoftware.com/0406.html#040624 [radiumsoftware.com]
Windowsは、大量の互換性モードをもっていて、アプリケーション単位でAPIの動作をオーバーライドできます。
それこそ「Windows開発における典型的なバグ」の回避モードすら存在します。
そして互換モードを必要とする有名アプリケーションの膨大なカタログがあって、それによってやっとこさ何度かのOSのメジャーバージョンアップをくぐり抜けてきたと。
APIが建て増しに次ぐ建て増しというのは一側面に過ぎないと思いますよ。
そこだけ同じことをやってもうまくいくとは限らない。
付随する運用ベースのノウハウも重要でしょうね。
Re:縦割りの弊害じゃなくJREの問題かと (スコア:1, 参考になる)
Re:縦割りの弊害じゃなくJREの問題かと (スコア:2, 参考になる)
PS2用のソフトはPSでは動かないが、PS用のソフトはPS2で動きますから、PS2⊃PS です
(PS2はPSのスーパーセットであり、PSはPS2のサブセット)
これを互換という言葉で説明するなら、「PS2はPSの上位互換」「PSはPS2の下位互換」という関係になります。
「PS2はPSの下位互換です」とか「Java2はJava1の下位互換です」なんて言ったら大嘘。
一方、後方互換は時系列的に見て、過去の資産を生かせるかどうか。
普通、後継はスーパーセットになるので、後方互換=上位互換。
「PS2はPSとの後方互換性を考え、上位互換になっている。」
ですが、たとえば、GBA MICRO は、初代GBのソフトは使えなくなってますから、GBA SPとBGA MICRO を比べると、
「MICRO はGBAに対し後方互換性を考えつつ、不要な機能を削った下位互換のものになっている。」
ということになる。
総務省の嘘 (スコア:2, 興味深い)
だって、どこの官庁でもWindows限定でしょ？
JavaもLDAPも不要だ！ (スコア:2, すばらしい洞察)
仕様決定者（お役人）が新技術に興味を持っていた（かつ、本当は、うとい！）か、仕様提供者（業者）が現場を知らないか！なんでしょうねぇ。
JREの互換性 (スコア:1)
Re:JREの互換性 (スコア:5, すばらしい洞察)
JREの互換性問題とかに罪を擦り付けては可哀相です。
Re:JREの互換性 (スコア:2, 参考になる)
デフォルトのままjavacでコンパイルすると、コンパイルしたバージョンより低いバージョンのJREでは実行できないコードが作成されます。
source="1.3" などのオプションを指定することでJRE1.3で実行できるコードが作成できます。
バージョン間で多少の非互換な機能があっても、基本的には下位互換は保たれているため、"source"で指定したバージョン以降のJREであれば実行できます。
リンク先にあるように本当に古いJRE1.3.1でしか動かないサービスがあるなら、互換性がない機能をあえて使っているってこと？
この程度のことを放置しておくというのは役所の対応としては信じられないのだが･･･
--
実は余り詳しくないのでAC
Re:JREの互換性 (スコア:3, 参考になる)
だから、古いバージョンを指定してるのかなと思いました。
互換モードがあれな良いのにな。
Re:JREの互換性 (スコア:2, 参考になる)
source [sun.com]はソースコードの解釈(1.4で導入されたアサーションとか5.0で導入されたGenericsとかを認識するか)を変えるオプションで、生成されるバイトコードに影響を与えるのはtarget [sun.com]オプションです。
まあsourceに低いバージョンを指定するとtargetもそれに合わせて引き下げられるので結果的にそういう動作に見えるのかもしれませんが、Generics等を使いつつ1.3で動くバイトコードを生成することも可能なわけです。
> コンパイルしたバージョンより低いバージョンのJREでは実行できないコードが作成されます。
これはJDK 5.0になってからの話で、JDK 1.4ではデフォルトで1.2以降のJREで実行できるコードが生成されていました [sun.com]。つまり1.3を指定するとかえって1.2で動かなくなります。
> バージョン間で多少の非互換な機能があっても、基本的には下位互換は保たれているため、"source"で指定したバージョン以降のJREであれば実行できます。
今のところヘッダのバージョン番号が書き換わるだけで、バイトコード自体の仕様はまったく変わっていません。
# その結果配列のインデックスが64bitに対応していないとか、古くなってきた点もあるけど
コンパイラのバグが修正される [srad.jp]ことで生成されるバイトコードに影響はあるかもしれませんが。
# なんつーかこのストーリー知ったかぶり大杉
Re:JREの互換性 (スコア:4, 興味深い)
ライブラリを使っている可能性はあります。
独自のライブラリの中には、特定のバージョンでのJRE環境でのみ動作を保証している
ものもあります。
今回の件とは違う例だけど、Excelを直接起動するような作りにするときに、Excel.exeの
絶対パスを、文字列で埋め込むことを強制されたので、Officeのバージョンが変わると
動かなかったり。
互換性は、JREだけがすべての原因ではなく、いろいろなところに関わってくる問題なのが
現実なので、Javaだけに目をとらわれていると、単にSunを叩くだけの話になっちゃう。
Re:JREの互換性 (スコア:2, 興味深い)
DOM周りは最悪。
イベントの発生タイミングがぜんぜん違う。
1.5の新機能なんかはJavacで吸収しているものがほとんど。
逆コンパイルしてみると良くわかるのですが、新規に追加された文法は便利だけど動作速度が遅くなっているはず。
Re:JREの互換性 (スコア:1, すばらしい洞察)
> ないからこういう問題になっている。
これ、具体的にお願いします。
こういう場合って、たいてい筋の悪いプログラムを書いているせいだと思うのだけど、そうでない例があれば教えてください。
Re:JREの互換性 (スコア:2, 参考になる)
deplicated付きになった物なら大量に知ってますが。
norimu
Re:JREの互換性 (スコア:2, 参考になる)
変わったんじゃなくてAPIが増えただけだと思いますが。
ちなみに1.5でガラリと変わった様に見える Generics とかの言語仕様は、javac が頑張ってるだけでバイトコード的には今まで通りキャストしたりする処理に置き換えられてるだけなんですけどね。
Re:JREの互換性 (スコア:2, 参考になる)
サーバ側ならこれでOKですが、不特定多数のクライアントにそれを強いることには問題がありますね。
side-by-sideな使い方ができないJavaAppletにも問題がありますが、結局のところ、Flashで作ろうが、ActiveXで作ろうが、システム開発側が、「テストしたのと同じ環境」を強いるなら、ブラウザのバージョンやプラグインのバージョンを指定され、同じような問題が発生するでしょう。
問題の根源は、大企業が行うシステム開発における品質保証の考え方が、変化の激しいオープンな環境にはうまく適合できないことだと思います。
仮想化ソフトを使えばよいのだが (スコア:1)
漏洩対策にもなると思うのだが。
オフトピックではあるが Java アプリケーションレベルの FireWall ってあるのかな？
あたりまえではあるけれど、通常の FW だと JavaVM としか認識できないのだが。
JREのバージョンを明示的に指定したければ (スコア:1, 参考になる)
Applet でなくて Java Web Start を使えばいいのに。別窓になるけど。
それ以前に、どうせ Windows しかサポートしないのなら ActiveX を使えばいいのにw
Re:JREのバージョンを明示的に指定したければ (スコア:2, すばらしい洞察)
うーん、それは困るな
JAVAを使っているオンラインバンキングとか、
知ってる所では、どこもWindowsしかサポートしてないけど
linuxユーザーの僕も問題なく使え、恩恵受けてますからね
分からない事やトラブルあってもサポートに頼れませんけど
あるOSをサポートしないのと
あるOSではまったく動作しないのと
では天地の差がありますよ
ActiveXなんかで組まれたら、その銀行は解約しますけど。
#サポートされていないLinuxを使っていた事が原因で
#システムにトラブルが発生して、こちらに損害が発生した場合
#銀行さんにはあなたがサポートしてないLinuxを使っていたのが
#悪いと言われて責任はこちらになるのかなー
#そんな判例があれば知りたい。
#多分約款には、多分そんな事が書いてあるんだろーなー(読んでない)
Re:JREのバージョンを明示的に指定したければ (スコア:2, 興味深い)
バージョンがいろいろなので困るんだよな。
最近は、Java Web Startを利用しているのが増えてきていて、それはそれでありがたいんだが、
他にもいろいろ問題があって起動しないこともしばしば。
先日送られてきた某省のシステムはJava Web Startを使っていたが、制限ユーザで起動しなかった。
電話をかけて「制限ユーザでテストしたのか？」と聞いてもお茶を濁すだけで明確な回答が得られず，
「ああしてみて、こうしてみて」とこっちでテストをしろと言うばかり。
最終的に「これ以上、オタクらに付き合って無駄な時間を使うわけにはいけません。」と切れて電話を叩き付けた。
JREのバージョン揃えてもさ... (スコア:1)
---- 末は社長か懲戒免職 なかむらまさよし
Java でそんなことがあるはずがない！ (スコア:4, おもしろおかしい)
Re:Java でそんなことがあるはずがない！ (スコア:3, おもしろおかしい)
Re:Java でそんなことがあるはずがない！ (スコア:2, おもしろおかしい)
Write Once, Run Away
Re:Java でそんなことがあるはずがない！ (スコア:1, おもしろおかしい)
「Javaにすれば機種依存を無くせるよ。
MacでもWindowsでも、ほかのOSでもJREさえインストールしておけばOK」
「それはいい！その手で行こう。なんてすばらしいものがあるんだ。
Javaってすごいなぁ」
なんて感じだったんだろうな。
お役所はタコな規格を作ってくるSUNを訴えて欲しい。
Re:Java でそんなことがあるはずがない！ (スコア:4, 参考になる)
と
一度書けば、ずっと動く
は違うのですよ。
元々ハード屋さんのSUNくんにはソフト屋さんの 気持ちなんてわからんのですよ。
無料だから訴えられないでしょう。
まぁ、タダほど高いものはないということで。
Re:Java でそんなことがあるはずがない！ (スコア:4, 興味深い)
それにも原因の一助がないとは言いきれませんが、それは付加的な要素です。
当初 Java 環境が選択された理由は
- アプレットをダウンロードする方式であれば配ってしまった専用ソフトウェアのバージョンアップに頭を悩まさなくてもよい（これは最終的にはこれでは収まらなくなってしまいましたが）
- 実効形式ファイルを配ってしまった場合、PC側でウィルスや悪意のある改変（その当時はフィッシングという言葉はまだなかった）が起こったとしても検出すらできない
- 利用者の環境がバラバラであり、そのサポートをどうやるのか、コストをどう負担するのか、という問題があるため、専用バイナリを配るのはリスクが大きい
- 万が一、サーバ側或いは通信路でなんらかのアタック行為があったとしても被害はサンドボックス内で収まることが期待できる
ってな感じでした。方式が検討されていた平成11年ぐらいでは、電子入札をする側は、従業員数人の会社にPCがあっても１台のみとかで、当然専門家なんかいない、って言う背景でした。その人たちにPCの運用や管理を期待しなければならない状況下では、選択肢はあまり多くは無かったように思います。
「どのOSでも」、ってのは電子認証のためのデバイスドライバ／ライブラリが入ってきた時点であり得なくなっていますんで、それは理由ではないです。
ただ、誰かが電子認証用のデバイスドライバ／ライブラリを開発して参入しようとしたときに『できない』ということがないように、って観点はありましたが。
あと、当時では（今でもでしょうが）Active-X は怖くてとてもじゃないですが選ぶ勇気は誰にもありませんでした。
Re:JREなんとかしてほしい・・ (スコア:3, 参考になる)
ただ、Windows版のOracle製品の場合、自分がインストールした
古いJREをわざわざPATHに書き込んでしまう場合もあるようなので要注意。
自分のアプリケーション専用のJREとしたければ、
Apache Tomcat等に見られるように
バッチファイルでPATHに自分専用のJREを指定してから走るべきでしょう。
でもこれはローカルアプリケーションの場合の話で、
Appletは結局PATHを指定するすべを持たないので、
自分専用のJREを持つことはできないんですが。
名物に旨いものなし！
Re:JREなんとかしてほしい・・ (スコア:2, 興味深い)
IEならActiveXの機構を利用して必要なバージョンのJREも自動的にインストールできます。
# ただし社内システムならともかく、インターネットではセキュリティ脆弱性があるバージョンのJREを喰わせることができるという問題と表裏一体です。
# DLL hellを解決するという.NETの宣伝文句はGDIPlusの脆弱性で破綻したと思う
Re:JREなんとかしてほしい・・ (スコア:2, 参考になる)
一応複数のJREを手動で切り替えられる。
ただし、サポートしている範囲は限られているので万能ではない。
1.4.2の「Java Plug-in」では1.2.2は選べない。
1.3.1の「Java Plug-in 1.3.1」は、1.2.2を選べるけれど、上記1.4.2の「Java Plug-in」の設定
と共存しない（レジストリの設定が一部バッティングしているものと思われる）。
とはいえ、レジストリの上書きの順番を理解して、JRE自体のインストールやコントロールパネル
での設定、ブラウザの設定を行えば、例えばIEではJRE1.2.2を使って、Firefoxでは1.4.2を使う
といったことは可能（ただし、何かの操作の結果レジストリを含む関連設定が変更されてしまった
場合の復旧は簡単とは限らない）。
例えば、
Firefox/Opera等のブラウザをあらかじめ入れておく。
jdk-1_5_0_06-windows-i586-p.exe
をインストールする:Public JREは入れない。
j2sdk-1_4_2_10-windows-i586-p.exe
をインストールする。
C:\Program Files\Java\j2re1.4.2_10\bin\jpicpl32.exe
を実行し、IEのJava Plug-inを1.4にする（他のブラウザは変えない）
：まず、ここでJava Applet起動時に1.4が起動することをJavaコンソールで確認。
C:\Program Files\Java\j2re1.4.2_10\bin\jpicpl32.exe
を実行し、IEからはJavaAppletを実行しないように変更する。
j2sdk-1_3_1_17-windows-i586.exe
をインストールする。
jdk-1_2_2_017-windows-i586.exe
をインストールする。
コントロールパネルのJava Plug-in 1.3.1_17を起動する。
JavaPluginに1.2.2を指定し、IEからここで設定したJavaAppletを起動するようにする。
と、Firefox/OperaではJRE1.4を使いながら、IEでJRE1.2を使いながら、JDKは1.5が使えるかもしれない。
＃トラブってもサポートはしないので。
他に、
http://java.sun.com/j2se/1.5.0/ja/docs/ja/guide/deployment/deployment-guide/jcp.html
の[Java アプレットのランタイム設定]も参考情報。
＃とても万能な解決策ではないが、これで幸せになれる人も中にはいるのではないかと。