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

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

  • by Formula (6605) on 2006年03月26日 13時53分 (#909069)
    ってそんな駄目駄目なの?
    • Re:JREの互換性 (スコア:5, すばらしい洞察)

      by kawaz (15398) on 2006年03月26日 18時08分 (#909211) ホームページ
      JREの互換性ってより、例えば C:\Program Files\Java\1.4.2_04 に Java がインストールされていることを前提にして、フルパスで java.exe を実行させようとしたりというアホ過ぎる仕様のゴミソフトが電子政府に多かったりする。

      JREの互換性問題とかに罪を擦り付けては可哀相です。
      親コメント
    • Re:JREの互換性 (スコア:2, 参考になる)

      by Anonymous Coward on 2006年03月26日 14時54分 (#909109)
      Java Appletを作成した時に同じような問題に悩まされたことがありますが基本的にはコンパイル時の問題ではないでしょうか?

      デフォルトのままjavacでコンパイルすると、コンパイルしたバージョンより低いバージョンのJREでは実行できないコードが作成されます。
      source="1.3" などのオプションを指定することでJRE1.3で実行できるコードが作成できます。
      バージョン間で多少の非互換な機能があっても、基本的には下位互換は保たれているため、"source"で指定したバージョン以降のJREであれば実行できます。

      リンク先にあるように本当に古いJRE1.3.1でしか動かないサービスがあるなら、互換性がない機能をあえて使っているってこと?
      この程度のことを放置しておくというのは役所の対応としては信じられないのだが・・・

      --
      実は余り詳しくないのでAC
      親コメント
      • Re:JREの互換性 (スコア:3, 参考になる)

        by Anonymous Coward on 2006年03月26日 15時08分 (#909117)
        古いバージョンでコンパイルしてあるものが、新しいJREで動かないことはありました。
        だから、古いバージョンを指定してるのかなと思いました。
        互換モードがあれな良いのにな。
        親コメント
        • by Anonymous Coward
          > 古いバージョンでコンパイルしてあるものが、新しいJREで動かないことはありました。

          JDK 1.0.2 や 1.1 で生成したバイトコードが Java VM 仕様に準拠していなかった [sun.com]という太古の問題ですか?
          1.3以降のバージョン間でもそんな問題が起きるとは聞かないのですが、まあ一度植え付けられた先入観はいつまでもいつまでも尾を引くからある意味仕方ありませんか。
          せめて
          > 古いバージョンでコンパイル
          > 新しいJRE
          が具体的にどのバージョンだったのかくらいは書いてくれないと、FUDだと思われても仕方ありませんね。
          • by kubox (23429) on 2006年03月28日 7時31分 (#910130)
            FUDかどうかはともかく、互換性があり、正しく動作していれば、FUDは出てこないと思うのです。
            親コメント
            • by Anonymous Coward
              で、それが1.1以前の話をしているのであれば、まあ一生言ってなさいってなもんですね。
          • by Anonymous Coward
            いいえ。 1.3で作成したバイナリが1.4で動作しないという問題です。 http://java.sun.com/j2se/1.4/ja/compatibility.html#incompatibilities1.4
      • Re:JREの互換性 (スコア:2, 参考になる)

        by Anonymous Coward on 2006年03月27日 16時50分 (#909776)
        > source="1.3" などのオプションを指定することでJRE1.3で実行できるコードが作成できます。

        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]ことで生成されるバイトコードに影響はあるかもしれませんが。

        # なんつーかこのストーリー知ったかぶり大杉
        親コメント
        • by Anonymous Coward
          > Generics等を使いつつ1.3で動くバイトコードを生成することも可能なわけ
          SUN純正のjavacでは不可能です。
          # なんつーかこのストーリー知ったかぶり大杉
    • 動くっちゃあ動くんでしょうけど,すべてのバージョンでちゃんとテストできるわけではないので,テストしたのと同じ環境を用意してね,ということになっているんではないですかね.

      # コンパイルするjavacのバージョンが少しでも変わるとテストを全部やり直す企業とかありますね.
      --
      旅に出ます.(バグを)探さないで下さい.
      親コメント
      • Re:JREの互換性 (スコア:2, 参考になる)

        by t-wata (10969) on 2006年03月27日 13時25分 (#909695) 日記
        > すべてのバージョンでちゃんとテストできるわけではないので,テストしたのと同じ環境を用意してね,ということになっているんではないですかね

        サーバ側ならこれでOKですが、不特定多数のクライアントにそれを強いることには問題がありますね。
        side-by-sideな使い方ができないJavaAppletにも問題がありますが、結局のところ、Flashで作ろうが、ActiveXで作ろうが、システム開発側が、「テストしたのと同じ環境」を強いるなら、ブラウザのバージョンやプラグインのバージョンを指定され、同じような問題が発生するでしょう。
        問題の根源は、大企業が行うシステム開発における品質保証の考え方が、変化の激しいオープンな環境にはうまく適合できないことだと思います。
        親コメント
        • Re:JREの互換性 (スコア:1, 参考になる)

          by Anonymous Coward on 2006年03月27日 15時02分 (#909751)
          > side-by-sideな使い方ができない
          できますってば(現状の電子政府のシステムが使っているかどうかはまた別の話)。
          互換性とか動作保証の問題で特定バージョンのJREが必要なら(いくつでも必要なだけ)インストールさせればいいだけの話で、正直何が問題なのかさえ理解できないのですが。
          古いバージョンのインストールを強制されることによるセキュリティの問題ならまだ理解できるのですが、そちらはほとんど話題にすらなってないようですし。
          親コメント
      • by Anonymous Coward
        それは企業として間違ってないとおもうけど?

        コンパイラのバージョン上げました。
        ソースはいじってないので動作確認しません。

        そんな会社ありえんとおもうけど。

        • > それは企業として間違ってないとおもうけど?
          間違ってるとか言うつもりは別にないですし,そんなことは書いてないですよ.
          ただ,全部テストする苦労に比べればバージョンを指定した方が楽ですね,と.

          > ソースはいじってないので動作確認しません。そんな会社ありえんとおもうけど。
          ソースをいじらなければテストはしないものだ,とは書いてません.
          影響範囲を調べずに全部テストするの無駄とは考えていますけどね.
          # 全部のテストやり直すなら自動化が前提になると思います
          --
          旅に出ます.(バグを)探さないで下さい.
          親コメント
        • by Anonymous Coward
          俺の働いている企業は、IBMのコンパイラでコンパイルしたクラスと、
          SUNのコンパイラでコンパイルしてjarにしたライブラリを普通に
          併存させてるうえに、時には、SUNでコンパイルしてたのをIBMで
          コンパイルしてそのまま組み込んでみたりとか普通にやってるけど?

          # Eclipse上でbuildしたか、UNIX上でbuildしたかの違い
          # なんですけどね。
          • by Anonymous Coward
            別に混ぜて使ってもいいんじゃないの?
            コンパイル通した代物をちゃんとテストやって動作確認した上で運用してるのなら。
      • by Anonymous Coward
        Javaじゃないけど、ソースもライブラリもコンパイラも同じで、再コンパイルしたバイナリを
        間違って納品用バイナリに上書しちゃったのでテストを全部やり直してた部署を知ってます。
        (バッチ等で自動で流せる代物なので、テスト工程の手間はそれほどかからないらしいけど)

        上司曰く「いくら元が一緒でもバイナリが変わればそれは見た目が同じなだけの別物」

        流石に過剰とも思ったけど、ソフトウェア品質の維持にはそれ位の覚悟も必要だよなとも思いました。
    • by suikyo (5361) on 2006年03月27日 22時02分 (#909908) ホームページ
      なんかこのスレ見てると,あんまり生のJava(?)使う人少ないのかな,と思ったり.
      フレームワーク全盛か.はたまた組み込みか.それとも春だから?
      でも,targetとsourceを間違えるとか,deplecatedとかはさすがにあり得ない.

      Javaのライブラリ仕様は,1.1から1.2は救いようも無く変わって(そもそも言語名(?)が違う)いますが,
      1.2から1.3も結構変わっています.
      Java 2 Platform, Standard Edition, v1.3 における非互換性 [sun.com]
      1.3以降は確かにxml周りで大幅変更でしたが,あれも輸入品なんで,一概にSunの
      管理が悪いとも言い切れないものが.

      で,特にJ2SE JRE仕様内でクライアント屋を悩ませたバージョン間互換性トピと言えば,
      やはりSwingだと思うのですが,あんまり具体的に思い出せない.
      googleってもあんまり見つからない.

      http://nekora.cocolog-nifty.com/nekora/2004/05/groupabletableh.html [cocolog-nifty.com]
      http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4689398 [sun.com]
      Bug Paradeでclasses_swingを"compatibility"で引いてみる [sun.com]と,
      大半は「それは正しいAPIを使っていないからだ」と突き返されていますが,
      内部動作が変わっているせいで苦労している例ではあります.

      ところで
      http://ja.wikipedia.org/wiki/Java%E8%A8%80%E8%AA%9E [wikipedia.org]
      の,コーディング規約を守っていれば上位互換性云々(??)というのは何でしょうか?
      どなたか教えてください.
      親コメント
    • by Anonymous Coward
      JREの良し悪しはあるだろうし、JSPとかJSFで統一すべきだろうし、統一できるような時代になってきてる訳だが、基本的に官庁がおバカ過ぎたのは事実かな。 職場でも同様の問題でトラブル対応してて、IEとネスケを使い分けてもらってたりするし。 さらに言えば、こういうことやるためにe-Japanとかに税金が投入されて使われてるようなら、足元の瑣末なJREとか言うメクソハナクソ目くじらな注目点じゃなくて、もっと先を見て見守ってくれませんか?との言い訳は理解できない訳ではないが、なんとも許しがたいものはあるよね。
    • by Anonymous Coward
       Java使いじゃないものの素人考えとしては、バージョン依存しないような書き方をすればすむものじゃないの?
      • by ducky (16839) on 2006年03月26日 20時57分 (#909289)
        例えば、Windowsなんたらだけ動作対象となっている場合、開発会社が調達してきた独自の
        ライブラリを使っている可能性はあります。

        独自のライブラリの中には、特定のバージョンでのJRE環境でのみ動作を保証している
        ものもあります。

        今回の件とは違う例だけど、Excelを直接起動するような作りにするときに、Excel.exeの
        絶対パスを、文字列で埋め込むことを強制されたので、Officeのバージョンが変わると
        動かなかったり。

        互換性は、JREだけがすべての原因ではなく、いろいろなところに関わってくる問題なのが
        現実なので、Javaだけに目をとらわれていると、単にSunを叩くだけの話になっちゃう。
        親コメント
      • by brax3 (15953) on 2006年03月27日 0時51分 (#909433)
        インタフェースが変わってなくて使用方法が変わっていなくても内部動作が変わってきてたりします。

        DOM周りは最悪。
        イベントの発生タイミングがぜんぜん違う。

        1.5の新機能なんかはJavacで吸収しているものがほとんど。
        逆コンパイルしてみると良くわかるのですが、新規に追加された文法は便利だけど動作速度が遅くなっているはず。
        親コメント
        • by Anonymous Coward
          xmlのパーサは切替可能だし、ものによって動作は異なるが。
          標準で付いているxmlパーサの動作が変わったと憤慨しておられるのか?
          • by brax3 (15953) on 2006年03月28日 15時28分 (#910456)
            まさにそのとおりですが。

            標準で付いているのを使用して作られたプログラムのメンテをさせられています。

            おっしゃるとおり、切り替え可能であっても動作が異なってしまうので簡単に切り替えられないのです。
            親コメント
      • by harupunte (10435) on 2006年03月27日 5時02分 (#909490) 日記
        あるシステムはベンダが1.4.2_06までしか動作確認して
        いません。以降は保証対象外ですとあり。

        あるシステムは1.4.2_08で動作確認しています。以外は
        保証対象外ですとある。

        そういうシステムが共存してて、どうすりゃいいのって
        感じだわ
        親コメント
      • Re:JREの互換性 (スコア:0, 参考になる)

        by Anonymous Coward
        >>バージョン依存しないような書き方をすればすむものじゃないの?
        ないからこういう問題になっている。
        というか出来ないといったほうが正解。
        Javaのプラットフォーム間の互換性は同一バージョン下でのお話。それとて結構怪しいもんですが。

        • Re:JREの互換性 (スコア:1, すばらしい洞察)

          by Anonymous Coward on 2006年03月26日 15時33分 (#909135)
          >> バージョン依存しないような書き方をすればすむものじゃないの?
          > ないからこういう問題になっている。

          これ、具体的にお願いします。

          こういう場合って、たいてい筋の悪いプログラムを書いているせいだと思うのだけど、そうでない例があれば教えてください。
          親コメント
          • by Anonymous Coward
            #909107です。
            そうでない例ねぇ。

            バグだったものが修正されて正常な動作になったってのは。
            バグ依存だから筋悪いですか。
            でもそれに対応しないと動作しないわけですが。

            互換性ガイドに非互換性について記述がありますが、予測できないであろう変更が結構ありますよ。
            言語の進化の予測ができない私がヘタレですか。そうですか。
            出来ましたら次々バージョン(1.6はもう話が出ているので)でも
            互換性のあるコード記述についてご教示いただければ幸いです。
            Javaプログラマの底辺があがります。
            # 煽りでも冗談でなく知っていたら教えて欲しい。

            SUNにしてもソース互換性、バイナリ互換
            • by Anonymous Coward
              で、結局互換性が問題になってる具体例は挙げてくれないんですね。
          • by Anonymous Coward
            とりあえずこの辺にぶら下げておこう。

            #909173 [srad.jp]
            >deplicated付きになった物なら大量に知ってますが。
            #909209 [srad.jp]
            >全てDeplicated(非推奨)という形で残してあります。
            #909310 [srad.jp]
            >あと下でメソッドはdeplicated
    • by Anonymous Coward
      JREのバージョンを厳密に指定しすぎているアプリが駄目駄目なのです。

      まあ、「変に動くくらいなら動かせなくする方がマシだろう」という考えもアリっちゃありですが。使う方は迷惑。

犯人はmoriwaka -- Anonymous Coward

処理中...