アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
JREの互換性 (スコア:1)
Re:JREの互換性 (スコア:2, 参考になる)
デフォルトのままjavacでコンパイルすると、コンパイルしたバージョンより低いバージョンのJREでは実行できないコードが作成されます。
source="1.3" などのオプションを指定することでJRE1.3で実行できるコードが作成できます。
バージョン間で多少の非互換な機能があっても、基本的には下位互換は保たれているため、"source"で指定したバージョン以降のJREであれば実行できます。
リンク先にあるように本当に古いJRE1.3.1でしか動かないサービスがあるなら、互換性がない機能をあえて使っているってこと?
この程度のことを放置しておくというのは役所の対応としては信じられないのだが・・・
--
実は余り詳しくないのでAC
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では不可能です。
# なんつーかこのストーリー知ったかぶり大杉