アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
JREなんとかしてほしい・・ (スコア:0)
Javaで作られていることが多く、ベンダ毎に
動作するJREのバージョンが違うために困ってます。
うまい解決方法があるのでしょうか。
Java でそんなことがあるはずがない! (スコア:4, おもしろおかしい)
Re:Java でそんなことがあるはずがない! (スコア:3, おもしろおかしい)
Re:Java でそんなことがあるはずがない! (スコア:0)
JPKIご提供のクラスライブラリ弄る分には。
問題はUI部分とXML署名/検証部分ですかね。1.5系は論外
早く1.5系に電子申請/申告関連が移行してくれればJPKI以外のカードも弄るのが楽になるんですけどね。
Re:Java でそんなことがあるはずがない! (スコア:2, おもしろおかしい)
Write Once, Run Away
Re:Java でそんなことがあるはずがない! (スコア:1, おもしろおかしい)
「Javaにすれば機種依存を無くせるよ。
MacでもWindowsでも、ほかのOSでもJREさえインストールしておけばOK」
「それはいい!その手で行こう。なんてすばらしいものがあるんだ。
Javaってすごいなぁ」
なんて感じだったんだろうな。
お役所はタコな規格を作ってくるSUNを訴えて欲しい。
Re:Java でそんなことがあるはずがない! (スコア:4, 参考になる)
と
一度書けば、ずっと動く
は違うのですよ。
元々ハード屋さんのSUNくんにはソフト屋さんの 気持ちなんてわからんのですよ。
無料だから訴えられないでしょう。
まぁ、タダほど高いものはないということで。
Re:Java でそんなことがあるはずがない! (スコア:0)
これすら十分に実現できてないわけで。
まだCの方が現実的だったよ
Re:Java でそんなことがあるはずがない! (スコア:0)
SUNの代弁者になってる自称Java技術者(=Java厨)のほうが大量にいると思うがね。
Re:Java でそんなことがあるはずがない! (スコア:0)
Re:Java でそんなことがあるはずがない! (スコア:4, 興味深い)
それにも原因の一助がないとは言いきれませんが、それは付加的な要素です。
当初 Java 環境が選択された理由は
方式が検討されていた平成11年ぐらいでは、電子入札をする側は、従業員数人の会社にPCがあっても1台のみとかで、当然専門家なんかいない、って言う背景でした。その人たちにPCの運用や管理を期待しなければならない状況下では、選択肢はあまり多くは無かったように思います。
「どのOSでも」、ってのは電子認証のためのデバイスドライバ/ライブラリが入ってきた時点であり得なくなっていますんで、それは理由ではないです。
ただ、誰かが電子認証用のデバイスドライバ/ライブラリを開発して参入しようとしたときに『できない』ということがないように、って観点はありましたが。
あと、当時では(今でもでしょうが)Active-X は怖くてとてもじゃないですが選ぶ勇気は誰にもありませんでした。
Re:Java でそんなことがあるはずがない! (スコア:0)
>MacでもWindowsでも、ほかのOSでもJREさえインストールしておけばOK」
JVMが全てのAPIをサポートしているか、MS製のJVMではないか、
外部ライブラリが機種依存でないか等等、「どこでも動く」にはそれなりに条件を満たす必要があるのでは?
と、初心者でも思いつきそうなものだけど、銀の弾丸が欲しいという思いからか、
Sunの思惑以上に開発の現場で喧伝されていたと思う。
あるいは、Ajaxやサニタイズ、Web2.0やSOAみたいな流行語として、
WORAなんてどうでもいいけど「とにかくすごい」という事で承認したとか、
そんなところだと思うけどなあ。
Re:Java でそんなことがあるはずがない! (スコア:0)
例えば、SSL通信でクライアント証明書を使おうとした場合、
1.3、1.4、1.5でどれも違った挙動になります。
1.3:SSL通信はブラウザの機能を使用するため、ブラウザのクライアント証明書が使われる。
1.4 : JSSEが組み込まれて、AppletからSSLが使えるようになったものの、ブラウザの証明書ストアを参照することができないため、クライアント証明書へのパスを設定する必要がある。
1.5 : ブラウザの証明書ストアを参照できるようになった(プラグインの設定で変更可)。
で、こんな問題は、プログラムを書き方では解決できないのです。
Re:JREなんとかしてほしい・・ (スコア:0)
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なんとかしてほしい・・ (スコア:0)
そうもいかんのよ。
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 アプレットのランタイム設定]も参考情報。
#とても万能な解決策ではないが、これで幸せになれる人も中にはいるのではないかと。
Re:JREなんとかしてほしい・・ (スコア:0)
Re:JREなんとかしてほしい・・ (スコア:0)
.NETはアセンブリ側にランタイムのバージョン指定を埋め込むなど、このへんかなり綺麗にまとめてるという印象があります。
Re:JREなんとかしてほしい・・ (スコア:0)
Java の言語仕様的にも、実行環境的にも極立って問題視されてきたような個所は、なんらかの対応をしててあたりまえ。
JREそのものは共存できるけど、アプリがどれを使うかは作る側がそれを意識してないとどうなるかわからないだけです。DLLヘルと同じことをやってるわけですな。
WindowsのDLLヘルはDLLによるAPI提供からCOM 前提にうつることで事実上解決しちゃった感がありますが
Re:JREなんとかしてほしい・・ (スコア:1, すばらしい洞察)
んなこたーない。
COMでも解決しなかったからレジストリへの依存を無くすためにSide-by-Side方式を採用し、それが.NETへと受け継がれてるんだから。