スラッシュドット・ジャパン

基本はHTML+CSSのみできっちり作った上で、あってもなくても困らない入力補助機能のみをJavaScriptでというような作りにしておけば利便性をあまり下げることなく、多くの環境で使ってもらえるWebサービスができると思います。
Java必須とかFlash必須とかActiveX必須とかはイントラ向けならありですが、多くの人が自由に使えるサービスには不向きです。特に公のものならなおさら。

WebアプリケーションはWebブラウザから使え、クライアント側のアプリケーション更新も必要なく、「多くの人が利用できる」反面、ネイティブアプリケーションに比べて制約が多く入力補助や画面の変化がスムーズでなく、UI操作をリンクとボタンのクリックのみに縛られるなど「ユーザにとって不便」です。
最初に「ユーザにとって不便」という面の認識をきちんと分かってもらってないと、不便さを克服しようとしてJavaやFlash等を持ち出してネイティブアプリ寄りなことを実現し、その代償としてWebアプリケーションとしての「多くの人が利用できる」利点を失っているのだと思う。

たとえば、最高裁判所オンライン申し立てシステム [courts.go.jp] では、利用上の留意事項 [courts.go.jp] のページで、JREの「1.4.2_04」をインストールしなくてはならないとされているのだけど、最高裁判所のお知らせ [courts.go.jp] のページには、

本申立てプログラムの稼働に必要な中間プログラム（JRE:Java Runtime Environment）の脆弱性について（平成１７年２月２１日）

この問題については，JREを「1.4.2_06」にバージョンアップすることで回避できるとのことですが，裁判所オンライン申立てシステムでは，「JRE1.4.2_06」について，動作確認ができていません。

なんて書いてある。朝日新聞の記事だと、1.3.1と 1.4.1と 1.4.2と 5.0 のバージョンの違いとして書かれているけど、最高裁判所なんかのケースは、1.4.2_04 と 1.4.2_06 という違い。

この程度の違いでどうして動かなくなるのだろう？ と思うわけだけど、最高裁判所のシステムを使うには、必要なプログラム等のダウンロード [courts.go.jp] のページから申立てプログラム [courts.go.jp] というWindowsアプリケーションをダウンロードしてインストールしないといけなくて、ダウンロードした「courtshu_setup.exe」というファイルを起動すると、

裁判所オンライン申立てシステム Setup

JRE 1.4.2_04のレジストリの読み取りに失敗しました。
JRE 1.4.2_04をインストールしていない場合はインストールしてから実行してください。

というエラーダイアログが現れるようになっていて、わざわざインストールできないようにされてるわけ。

官庁はJavaの脆弱性にどう対処すればいいのか [takagi-hiromitsu.jp] in 高木浩光＠自宅の日記 [takagi-hiromitsu.jp]

下手にそろえるより、別々のPC使うことを強要しておくほうが、個人情報流出時とか、PCクラッシュしたときの被害が少なくて済むから、いいんじゃないの。

どこが作ろうが、あんど、アップデート等の絡みで動作不良が問題になる
JREの弊害を、政府に‥という論点ですりかえるのは如何なものか？

#根本的な問題はそこだろう。全く同時期に開発・リリースされるものならいざ知らず。

総務省によると、文部科学省以外の電子申請にはパソコンにあらかじめ、米サン・マイクロシステムズ社のＪＲＥというプログラムを導入する必要がある。パソコンの基本ソフトであるＯＳが違っても申請のための操作を可能にするためだ。

これ、嘘っぱち。
だって、どこの官庁でもWindows限定でしょ？

　各省庁の仕様を見ても、機種(?)依存性やFireWallの特別な設定が必要な上記の技術は、いらないと考えています。
　仕様決定者（お役人）が新技術に興味を持っていた（かつ、本当は、うとい！）か、仕様提供者（業者）が現場を知らないか！なんでしょうねぇ。

ってそんな駄目駄目なの？

とりあえず VMWare や VirtualPC を使うような知恵は・・・期待できないよなぁ。やはり。

漏洩対策にもなると思うのだが。

オフトピックではあるが Java アプリケーションレベルの FireWall ってあるのかな？
あたりまえではあるけれど、通常の FW だと JavaVM としか認識できないのだが。

電子政府って、やる気あるんですか？ [nikkei.co.jp]みたいな根本的な問題を解決しないと、結局ダメダメになりませんかね？

なんで政府専用の処理系とか調達しないんですかね。や、もちろん予算的、政治的に大変なのは分かるんだけど。
DODが公募したadaはプログラミング言語の発展に色々と寄与してる点なんかもあるんで、こういう考えもありなんじゃないのかと素人目には思います。

僕が技術官僚なら政府調達専用処理系の仕様を策定する外部組織をこしらえて、一般公開するんだけど…

PSEだのワケワカラン業界団体法人より理にかなった外部ポスト、悪く言えば天下り先なんじゃないかと思う。

ＮＧワード：シグマ、トロン

本当にJREの互換性が原因なら、どのクラス、どのメソッド、どの書式が問題だったのか確認した方がいいと思うな。

　ほかのコメントを見ると実際使っている人は少なそうですね。
　公共工事の電子入札システムを使っていますが、このJREのバージョン問題に1回嵌りました。そのときはインターネットオプションの詳細設定のJAVAを選択しなおすだけで直りましたが朝日の記事の場合はそれじゃ駄目だったんですかね？
　入札の時動かないと洒落にならないし、パスワードを3回間違うとICカード自体が無効になってしまうこともあり、PC1台を電子入札専用にしてしまいました。
　ほかの人も書いていますが、JAVAはほとんどICカードの認証で使っているだけと思いますよ。

#WindowsXP SP2がでたとき、「ポップアップをブロックしていると動きません」という内容のウィンドウをポップアップしようとしてブロックされていたのには目眩がしましたが。

全部、行政な訳で…

それを十把一絡げに「行政の縦割りの弊害」と言って良いものかどうか…
JREのアッパーコンパチ云々以前の問題だと思う。

＃「縦割り」の効能ってのもあるでしょ？
＃「インターネット経由申請庁」の創設を具申するであります！

お偉いさん（お上）方に対して、意見を出しても通らないので指示通りに作業。
バージョン違う？　そんな事より巷で噂のセキュリティを万全にする事が重要で、
でも進行中の仕事は現状のバージョンで完成させないと駄目。
（そもそも修正してたらリリース間に合わない）
開発陣の部屋の中には、各バージョンの詰まったPCが並んでいる状態。
作業効率UPする為に機材を準備したいが、金銭面が厳しいので却下。
「ちょっと○○のを作業したいんだけど」
「あと1時間程で何とかするから、ちょっと違うのやってて」
今のところ対策の話は無いようですが…

#微妙に関係者かもしれないのでAC

申請手数料が通常より安価なのは確かだが, 一生の内そのシステムを数回しか利用しないであろう私にとって, 認証登録やカードリーダ等の初期投資費用がまったくペーしないというのが, 一番の理由ですね. (個人生活レベルで数百円安くするのに数千円投資するのはどうかと思うぞ)

そもそも、電子政府プロジェクトが走り出した時点でJavaによるバージョン問題は存在していたはずです。
それでも信頼性を買ってJavaの利用を推進したのだと考えていましたが、アプリケーション設計時点では、設計者・製造担当者までコンセンサスが取れてはいなかったのでしょう。
もしくはそれ以前でもコンセンサスが取れていなかったのかも？
受注側にはそのような状況を示唆していた人間はいないとは言い切れませんが、それを解決する方法とコスト考えると現状のシステムはいわば妥当なのかもしれないと思う。
そもそも、アプレットの利用を考えている時点でシステム構成を考え直すべきだったのではないだろうか。
>電子政府も縦割り弊害　各種申請、同一ＰＣで無理
といっているが至極当然なことで、アプリケーションの作成を行ったベンダー間の協議はそう多く行われてはいなかったのであろう。
企業合資の馴れ合いではないのだが、単一フレームワークでの動作を行っているのであれば動作しない状況をフレームワークの修正を行うのみで大部分の緩和が行えたであろうと示唆する。
各アプリケーションの製造元はどうなっているのかは不明だが、お国柄、官庁の風土なのかは知らないが縦割り構造がこの弊害を起こしたものと推測する。
日本人にリーダーシップ・管理統率を求めるのは無茶な話なのだろうか･･･
何処にでも転がっていそうな話ではありますがね、いまさらな感じがします。
ベンダーにサンマイクロシステムズが入っていることは飾りなのでしょう。
流石お国仕事といったところですかね。

電子政府系のシステムでJavaアプレット使わなきゃならない
理由は「ICカードで電子署名を打たせるため」
ICカード使って電子署名が打てればActiveXやJavaアプレットなんて使わない。

本質的な問題は
「Javaアプレット->DLL->ICカードドライバ」
と呼ばないとブラウザ経由でICカードから証明書を吸い出せないこと。

SSLのクライアント認証みたく証明書がファイル形式ならブラウザ登録できるように、
ICカード読み込みもブラウザ側で標準化すれば解決する･･･はず？

一度書けばどこでも動くというのが謳い文句だからそんなバカなことがあるはずがないですよ。

Oracleなんかがよくやってる方法ですね。
ただ、Windows版のOracle製品の場合、自分がインストールした
古いJREをわざわざPATHに書き込んでしまう場合もあるようなので要注意。

自分のアプリケーション専用のJREとしたければ、
Apache Tomcat等に見られるように
バッチファイルでPATHに自分専用のJREを指定してから走るべきでしょう。

でもこれはローカルアプリケーションの場合の話で、
Appletは結局PATHを指定するすべを持たないので、
自分専用のJREを持つことはできないんですが。

今回はクライアント側の問題でしょ
Railsではクライアント側のプログラムなんか書けないですよ？

> ＞地獄とも無縁です。
> JREで痛い目にあってるってのになぜ.Netなら大丈夫と思うのか・・・同じやんけ。

みんなが痛い目に遭ったことをMicrosoftは認識している [google.co.jp]からです。
もちろん「無縁」とまで信頼しきってしまう態度には問題がありますがね。

> DLLによるAPI提供からCOM 前提にうつることで事実上解決

んなこたーない。
COMでも解決しなかったからレジストリへの依存を無くすためにSide-by-Side方式を採用し、それが.NETへと受け継がれてるんだから。

共存はできるけれどもアプリ側が適切にバージョン指定(manifestファイルで)していないと痛い目にあいます。
同じAPIでも後方互換性はない(2.0入れても1.1アプリが正常には動かない)ので基本的に2.0, 1.1を両方入れる必要があり、
しかもアプリ側でちゃんと指定していないと2.0で動かしてしまう。。。

WinでブラウザでSunのJREを動作させたい場合、コントロールパネルの「Java Plug-in」を使って、
一応複数の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 アプレットのランタイム設定]も参考情報。

＃とても万能な解決策ではないが、これで幸せになれる人も中にはいるのではないかと。

そうですね。 「下位互換性のある上位バージョンでの動作を保証すること」とか仕様に書けばいいのにね。
# Java 5 の下位互換性は調べてないが。

大多数の（？）自分では、よく解っているはず（！）という親切な技術者の認識がこの程度だから、官公庁のお役人と出入り業者のレベルは、推して知るべし。