アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
JREの互換性 (スコア:1)
Re:JREの互換性 (スコア:1)
# コンパイルするjavacのバージョンが少しでも変わるとテストを全部やり直す企業とかありますね.
旅に出ます.(バグを)探さないで下さい.
Re:JREの互換性 (スコア:2, 参考になる)
サーバ側ならこれでOKですが、不特定多数のクライアントにそれを強いることには問題がありますね。
side-by-sideな使い方ができないJavaAppletにも問題がありますが、結局のところ、Flashで作ろうが、ActiveXで作ろうが、システム開発側が、「テストしたのと同じ環境」を強いるなら、ブラウザのバージョンやプラグインのバージョンを指定され、同じような問題が発生するでしょう。
問題の根源は、大企業が行うシステム開発における品質保証の考え方が、変化の激しいオープンな環境にはうまく適合できないことだと思います。
Re:JREの互換性 (スコア:1, 参考になる)
できますってば(現状の電子政府のシステムが使っているかどうかはまた別の話)。
互換性とか動作保証の問題で特定バージョンのJREが必要なら(いくつでも必要なだけ)インストールさせればいいだけの話で、正直何が問題なのかさえ理解できないのですが。
古いバージョンのインストールを強制されることによるセキュリティの問題ならまだ理解できるのですが、そちらはほとんど話題にすらなってないようですし。
Re:JREの互換性 (スコア:0)
コンパイラのバージョン上げました。
ソースはいじってないので動作確認しません。
そんな会社ありえんとおもうけど。
Re:JREの互換性 (スコア:1)
間違ってるとか言うつもりは別にないですし,そんなことは書いてないですよ.
ただ,全部テストする苦労に比べればバージョンを指定した方が楽ですね,と.
> ソースはいじってないので動作確認しません。そんな会社ありえんとおもうけど。
ソースをいじらなければテストはしないものだ,とは書いてません.
影響範囲を調べずに全部テストするの無駄とは考えていますけどね.
# 全部のテストやり直すなら自動化が前提になると思います
旅に出ます.(バグを)探さないで下さい.
Re:JREの互換性 (スコア:0)
SUNのコンパイラでコンパイルしてjarにしたライブラリを普通に
併存させてるうえに、時には、SUNでコンパイルしてたのをIBMで
コンパイルしてそのまま組み込んでみたりとか普通にやってるけど?
# Eclipse上でbuildしたか、UNIX上でbuildしたかの違い
# なんですけどね。
Re:JREの互換性 (スコア:0)
コンパイル通した代物をちゃんとテストやって動作確認した上で運用してるのなら。
Re:JREの互換性 (スコア:0)
間違って納品用バイナリに上書しちゃったのでテストを全部やり直してた部署を知ってます。
(バッチ等で自動で流せる代物なので、テスト工程の手間はそれほどかからないらしいけど)
上司曰く「いくら元が一緒でもバイナリが変わればそれは見た目が同じなだけの別物」
流石に過剰とも思ったけど、ソフトウェア品質の維持にはそれ位の覚悟も必要だよなとも思いました。