パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

電子政府が使えない理由、縦割りの弊害?JREの弊害?」記事へのコメント

  • by Anonymous Coward on 2006年03月26日 13時45分 (#909062)
    ネットワーク系機器のGUIコンソールが
    Javaで作られていることが多く、ベンダ毎に
    動作するJREのバージョンが違うために困ってます。

    うまい解決方法があるのでしょうか。
    • by Anonymous Coward on 2006年03月26日 14時18分 (#909083)
      一度書けばどこでも動くというのが謳い文句だからそんなバカなことがあるはずがないですよ。
      親コメント
      • by Anonymous Coward on 2006年03月26日 14時47分 (#909105)
        Write once, Debug anywhere. な状況なのですな?
        親コメント
        • 一応1.4.2_06~1.4.2_11までOKでしたよ(´ー`)
          JPKIご提供のクラスライブラリ弄る分には。
          問題はUI部分とXML署名/検証部分ですかね。1.5系は論外
          早く1.5系に電子申請/申告関連が移行してくれればJPKI以外のカードも弄るのが楽になるんですけどね。
      • 同じようにWORAと略しはしますが、このような話で出てくるWORAは少し中身が違うんです。

        Write Once, Run Away
        親コメント
      • by Anonymous Coward on 2006年03月26日 15時23分 (#909126)
        まさにその謳い文句にお役所が釣られた感じだなぁ。

        「Javaにすれば機種依存を無くせるよ。
        MacでもWindowsでも、ほかのOSでもJREさえインストールしておけばOK」
        「それはいい!その手で行こう。なんてすばらしいものがあるんだ。
        Javaってすごいなぁ」
        なんて感じだったんだろうな。

        お役所はタコな規格を作ってくるSUNを訴えて欲しい。
        親コメント
        • by Anonymous Coward on 2006年03月26日 15時42分 (#909143)
          一度書けば、どこでも動く



          一度書けば、ずっと動く

          は違うのですよ。
          元々ハード屋さんのSUNくんにはソフト屋さんの 気持ちなんてわからんのですよ。
          無料だから訴えられないでしょう。
          まぁ、タダほど高いものはないということで。
          親コメント
        • > まさにその謳い文句にお役所が釣られた感じだなぁ。

          それにも原因の一助がないとは言いきれませんが、それは付加的な要素です。

          当初 Java 環境が選択された理由は
          • アプレットをダウンロードする方式であれば配ってしまった専用ソフトウェアのバージョンアップに頭を悩まさなくてもよい(これは最終的にはこれでは収まらなくなってしまいましたが)
          • 実効形式ファイルを配ってしまった場合、PC側でウィルスや悪意のある改変(その当時はフィッシングという言葉はまだなかった)が起こったとしても検出すらできない
          • 利用者の環境がバラバラであり、そのサポートをどうやるのか、コストをどう負担するのか、という問題があるため、専用バイナリを配るのはリスクが大きい
          • 万が一、サーバ側或いは通信路でなんらかのアタック行為があったとしても被害はサンドボックス内で収まることが期待できる
          ってな感じでした。

          方式が検討されていた平成11年ぐらいでは、電子入札をする側は、従業員数人の会社にPCがあっても1台のみとかで、当然専門家なんかいない、って言う背景でした。その人たちにPCの運用や管理を期待しなければならない状況下では、選択肢はあまり多くは無かったように思います。

          「どのOSでも」、ってのは電子認証のためのデバイスドライバ/ライブラリが入ってきた時点であり得なくなっていますんで、それは理由ではないです。

          ただ、誰かが電子認証用のデバイスドライバ/ライブラリを開発して参入しようとしたときに『できない』ということがないように、って観点はありましたが。

          あと、当時では(今でもでしょうが)Active-X は怖くてとてもじゃないですが選ぶ勇気は誰にもありませんでした。
          親コメント
        • >「Javaにすれば機種依存を無くせるよ。
          >MacでもWindowsでも、ほかのOSでもJREさえインストールしておけばOK」
          JVMが全てのAPIをサポートしているか、MS製のJVMではないか、
          外部ライブラリが機種依存でないか等等、「どこでも動く」にはそれなりに条件を満たす必要があるのでは?
          と、初心者でも思いつきそうなものだけど、銀の弾丸が欲しいという思いからか、
          Sunの思惑以上に開発の現場で喧伝されていたと思う。

          あるいは、Ajaxやサニタイズ、Web2.0やSOAみたいな流行語として、
          WORAなんてどうでもいいけど「とにかくすごい」という事で承認したとか、
          そんなところだと思うけどなあ。
      • 言語仕様というよりPlug-inの実装の話ですが、
        例えば、SSL通信でクライアント証明書を使おうとした場合、
        1.3、1.4、1.5でどれも違った挙動になります。
        1.3:SSL通信はブラウザの機能を使用するため、ブラウザのクライアント証明書が使われる。
        1.4 : JSSEが組み込まれて、AppletからSSLが使えるようになったものの、ブラウザの証明書ストアを参照することができないため、クライアント証明書へのパスを設定する必要がある。
        1.5 : ブラウザの証明書ストアを参照できるようになった(プラグインの設定で変更可)。
        で、こんな問題は、プログラムを書き方では解決できないのです。
    • アプリケーション毎に必要なJREを配布すればOKでしょう。 ただ、JREがディスクのあちこちに存在する状態になりますが。
      • by orangeful (21839) on 2006年03月26日 15時57分 (#909152)
        Oracleなんかがよくやってる方法ですね。
        ただ、Windows版のOracle製品の場合、自分がインストールした
        古いJREをわざわざPATHに書き込んでしまう場合もあるようなので要注意。

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

        でもこれはローカルアプリケーションの場合の話で、
        Appletは結局PATHを指定するすべを持たないので、
        自分専用のJREを持つことはできないんですが。
        --
        名物に旨いものなし!
        親コメント
        • by Anonymous Coward on 2006年03月27日 11時33分 (#909607)
          アプレットからJREのバージョンを指定する方法 [sun.com]もちゃんとありますが。
          IEならActiveXの機構を利用して必要なバージョンのJREも自動的にインストールできます。

          # ただし社内システムならともかく、インターネットではセキュリティ脆弱性があるバージョンのJREを喰わせることができるという問題と表裏一体です。
          # DLL hellを解決するという.NETの宣伝文句はGDIPlusの脆弱性で破綻したと思う
          親コメント
      • ブラウザ使うWEBシステムじゃ、
        そうもいかんのよ。
        • by Anonymous Coward on 2006年03月27日 10時52分 (#909577)
          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触ってないので記憶があいまいなんですが、JREって複数バージョンの共存は出来ないんでしたっけ?

      .NETはアセンブリ側にランタイムのバージョン指定を埋め込むなど、このへんかなり綺麗にまとめてるという印象があります。
      • .NET は後発なんで、、、、
        Java の言語仕様的にも、実行環境的にも極立って問題視されてきたような個所は、なんらかの対応をしててあたりまえ。

        JREそのものは共存できるけど、アプリがどれを使うかは作る側がそれを意識してないとどうなるかわからないだけです。DLLヘルと同じことをやってるわけですな。
        WindowsのDLLヘルはDLLによるAPI提供からCOM 前提にうつることで事実上解決しちゃった感がありますが
        • by Anonymous Coward on 2006年03月26日 21時52分 (#909316)
          > DLLによるAPI提供からCOM 前提にうつることで事実上解決

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

人生unstable -- あるハッカー

処理中...