アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
JREの互換性 (スコア:1)
Re:JREの互換性 (スコア:5, すばらしい洞察)
JREの互換性問題とかに罪を擦り付けては可哀相です。
Re:JREの互換性 (スコア:2, 参考になる)
デフォルトのままjavacでコンパイルすると、コンパイルしたバージョンより低いバージョンのJREでは実行できないコードが作成されます。
source="1.3" などのオプションを指定することでJRE1.3で実行できるコードが作成できます。
バージョン間で多少の非互換な機能があっても、基本的には下位互換は保たれているため、"source"で指定したバージョン以降のJREであれば実行できます。
リンク先にあるように本当に古いJRE1.3.1でしか動かないサービスがあるなら、互換性がない機能をあえて使っているってこと?
この程度のことを放置しておくというのは役所の対応としては信じられないのだが・・・
--
実は余り詳しくないのでAC
Re:JREの互換性 (スコア:3, 参考になる)
だから、古いバージョンを指定してるのかなと思いました。
互換モードがあれな良いのにな。
Re:JREの互換性 (スコア:0)
JDK 1.0.2 や 1.1 で生成したバイトコードが Java VM 仕様に準拠していなかった [sun.com]という太古の問題ですか?
1.3以降のバージョン間でもそんな問題が起きるとは聞かないのですが、まあ一度植え付けられた先入観はいつまでもいつまでも尾を引くからある意味仕方ありませんか。
せめて
> 古いバージョンでコンパイル
> 新しいJRE
が具体的にどのバージョンだったのかくらいは書いてくれないと、FUDだと思われても仕方ありませんね。
Re:JREの互換性 (スコア:1)
Re:JREの互換性 (スコア:0)
Re:JREの互換性 (スコア:0)
Re:JREの互換性 (スコア:0)
Re:JREの互換性 (スコア:2, 参考になる)
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]ことで生成されるバイトコードに影響はあるかもしれませんが。
# なんつーかこのストーリー知ったかぶり大杉
Re:JREの互換性 (スコア:0)
SUN純正のjavacでは不可能です。
# なんつーかこのストーリー知ったかぶり大杉
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)
間違って納品用バイナリに上書しちゃったのでテストを全部やり直してた部署を知ってます。
(バッチ等で自動で流せる代物なので、テスト工程の手間はそれほどかからないらしいけど)
上司曰く「いくら元が一緒でもバイナリが変わればそれは見た目が同じなだけの別物」
流石に過剰とも思ったけど、ソフトウェア品質の維持にはそれ位の覚悟も必要だよなとも思いました。
Re:JREの互換性 (スコア:1)
フレームワーク全盛か.はたまた組み込みか.それとも春だから?
でも,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]
の,コーディング規約を守っていれば上位互換性云々(??)というのは何でしょうか?
どなたか教えてください.
Re:JREの互換性 (スコア:0)
Re:JREの互換性 (スコア:0)
Re:JREの互換性 (スコア:0)
まぁ・・・ブラウザがサポートしてるから使えるんだけど。
Re:JREの互換性 (スコア:0)
何故ここでサーバーサイドの話?
Re:JREの互換性 (スコア:0)
全部サーバサイドでやればいい? (スコア:0)
その場合、電子署名法的にどうなんだろうか。
Re:JREの互換性 (スコア:0)
Re:JREの互換性 (スコア:0)
Re:JREの互換性 (スコア:4, 興味深い)
ライブラリを使っている可能性はあります。
独自のライブラリの中には、特定のバージョンでのJRE環境でのみ動作を保証している
ものもあります。
今回の件とは違う例だけど、Excelを直接起動するような作りにするときに、Excel.exeの
絶対パスを、文字列で埋め込むことを強制されたので、Officeのバージョンが変わると
動かなかったり。
互換性は、JREだけがすべての原因ではなく、いろいろなところに関わってくる問題なのが
現実なので、Javaだけに目をとらわれていると、単にSunを叩くだけの話になっちゃう。
Re:JREの互換性 (スコア:1)
ExcelならCOM呼べば勝手に起動するから絶対パスはいらないんじゃ?
Re:JREの互換性 (スコア:1)
>ExcelならCOM呼べば勝手に起動するから絶対パスはいらないんじゃ?
「COMを呼ぶ」というのは、OS非依存に実装できるのでしょうか?
Re:JREの互換性 (スコア:1)
Re:JREの互換性 (スコア:1)
Re:JREの互換性 (スコア:1)
少なくともWindowsでは元コメントのようなOfficeバージョン依存にはならんように作れると思うが
Re:JREの互換性 (スコア:2, 興味深い)
DOM周りは最悪。
イベントの発生タイミングがぜんぜん違う。
1.5の新機能なんかはJavacで吸収しているものがほとんど。
逆コンパイルしてみると良くわかるのですが、新規に追加された文法は便利だけど動作速度が遅くなっているはず。
Re:JREの互換性 (スコア:0)
標準で付いているxmlパーサの動作が変わったと憤慨しておられるのか?
Re:JREの互換性 (スコア:1)
標準で付いているのを使用して作られたプログラムのメンテをさせられています。
おっしゃるとおり、切り替え可能であっても動作が異なってしまうので簡単に切り替えられないのです。
Re:JREの互換性 (スコア:1)
いません。以降は保証対象外ですとあり。
あるシステムは1.4.2_08で動作確認しています。以外は
保証対象外ですとある。
そういうシステムが共存してて、どうすりゃいいのって
感じだわ
Re:JREの互換性 (スコア:0, 参考になる)
ないからこういう問題になっている。
というか出来ないといったほうが正解。
Javaのプラットフォーム間の互換性は同一バージョン下でのお話。それとて結構怪しいもんですが。
Re:JREの互換性 (スコア:1, すばらしい洞察)
> ないからこういう問題になっている。
これ、具体的にお願いします。
こういう場合って、たいてい筋の悪いプログラムを書いているせいだと思うのだけど、そうでない例があれば教えてください。
Re:JREの互換性 (スコア:0)
そうでない例ねぇ。
バグだったものが修正されて正常な動作になったってのは。
バグ依存だから筋悪いですか。
でもそれに対応しないと動作しないわけですが。
互換性ガイドに非互換性について記述がありますが、予測できないであろう変更が結構ありますよ。
言語の進化の予測ができない私がヘタレですか。そうですか。
出来ましたら次々バージョン(1.6はもう話が出ているので)でも
互換性のあるコード記述についてご教示いただければ幸いです。
Javaプログラマの底辺があがります。
# 煽りでも冗談でなく知っていたら教えて欲しい。
SUNにしてもソース互換性、バイナリ互換
Re:JREの互換性 (スコア:0)
Re:JREの互換性 (スコア:0)
#909173 [srad.jp]
>deplicated付きになった物なら大量に知ってますが。
#909209 [srad.jp]
>全てDeplicated(非推奨)という形で残してあります。
#909310 [srad.jp]
>あと下でメソッドはdeplicated
Re:JREの互換性 (スコア:2, 参考になる)
deplicated付きになった物なら大量に知ってますが。
norimu
Re:JREの互換性 (スコア:1)
仕様的にある程度安定したクラスライブラリ(あるんかな?ちと心配)だけを使用して、
それ以外は全部自前
えらく時間かかりそうだけど
バージョン依存の問題がクラスライブラリで
バージョン依存なくしてほしいとお願いされちゃうと
そうするしかないよね...たぶん
その代わり、納期もその分引き延ばししてもらうようにお願いしなきゃならんだろうけど
Re:JREの互換性 (スコア:0)
どのライブラリは今後互換性が保証される、みたいな話は無いから、
アプリケーション開発者は、自分が使っているライブラリに魔の手が伸びないように、
祈るしかありませんね。
Re:JREの互換性 (スコア:0, 余計なもの)
全てDeplicated(非推奨)という形で残してあります。
親スレッドは完全な間違いです。
モデを下げてくださいますようよろしくお願いいたします。
Re:JREの互換性 (スコア:2, 参考になる)
変わったんじゃなくてAPIが増えただけだと思いますが。
ちなみに1.5でガラリと変わった様に見える Generics とかの言語仕様は、javac が頑張ってるだけでバイトコード的には今まで通りキャストしたりする処理に置き換えられてるだけなんですけどね。
Re:JREの互換性 (スコア:0)
まあ、「変に動くくらいなら動かせなくする方がマシだろう」という考えもアリっちゃありですが。使う方は迷惑。