Java バージョン X を対象とする Java ソース コード/Java クラス ファイルがバージョン Y (Y > X) でコンパイル/実行されないという Java リリース間の非互換性はありますか?
「Java リリース」とは、次のようなバージョンを意味します。
ハウスルール:
まず第一に、Sun はあなたが言及したすべてのリリース (もちろん 1.0 以外) をメジャー リリースではなくマイナーリリースと見なしています。
その間、バイナリ非互換性の例を知りません。ただし、ソースの非互換性の例がいくつかあります。
Java 5 では、「enum」は予約語になりました。以前はありませんでした。そのため、java 5.0 ではコンパイルされず、java 1.4 でコンパイルされる識別子として enum を使用するソース ファイルがありました。ただし、これを回避するために -source 1.4 でコンパイルできます。
インターフェイスにメソッドを追加すると、ソースの互換性も失われる可能性があります。インターフェイスを実装し、新しいメソッドをインターフェイスに追加する JDK を使用してその実装をコンパイルしようとすると、ソース ファイルはインターフェイスのすべてのメンバーを実装していないため、正常にコンパイルされなくなります。これは、java.sql.Statement およびその他の jdbc インターフェースで頻繁に発生します。これらの「無効な」実装のコンパイルされた形式は、存在しないメソッドのいずれかを実際に呼び出さない限り、引き続き機能します。これを行うと、MissingMethodException がスローされます。
これらは私が頭のてっぺんから思い出すことができるいくつかの例であり、他にもあるかもしれません.
インターフェースjava.sql.Connectionが Java 1.5 から Java 1.6 に拡張され、このインターフェースを実装したすべてのクラスのコンパイルが失敗しました。
1.3 から 1.6 まで、Swing のすべてのリリースで何かが壊れました。
JDBC の問題は既に言及されていますが、既存のコードは機能しました。
1.5 から 1.6 では、Socket の動作が変更され、Cisco クライアントが壊れました。
もちろん、新しい予約キーワードが導入されました。
Sun 側で本当に許しがたいと私が思う大きな問題は、System.getenv() でした。これは 1.0 で動作し、その後非推奨となり、Mac にはシステム環境変数がないというやや疑わしい正当化の下で、すべてのプラットフォームでエラーをスローするように変更されました。その後、Mac はシステム環境変数を取得したため、1.5 では非推奨ではなくなり、動作するようになりました。そうする合理的な理由はありません。Mac (そのレベルのクロスプラットフォームの一貫性を気にしたい場合は、Swing にはクロスプラットフォームの問題がはるかに大きくなります) またはすべてのプラットフォームで空のセットを返します。
私は彼らが機能をオフにすることに同意したことはありませんが、エラーをスローするように変更することは、純粋に破壊的な変更であり、そうする場合はメソッドを完全に削除する必要がありました.
しかし、実際には 1.0 から 1.1 までは、後方互換性についてあまり関心がありませんでした。たとえば、修飾子として「private protected」を削除しました。
つまり、すべてのバージョンが厳密な評価を必要とするほど十分に変更されているということです。そのため、ここ SO で多くの 1.4 の質問がまだ見られるのはそのためです。
私が考えることができる主なものは、新しい予約語の導入です。
Java 1.3: strictfp
Java 1.4: assert
Java 5.0: enum
以前にこれらの値を識別子として使用していたコードは、新しいバージョンではコンパイルできません。
私が取り組んでいたプロジェクトで問題を引き起こしたことを覚えているもう 1 つの問題は、JInternalFrames のデフォルトの可視性が 1.2 と 1.3 の間で変更されたことです。それらはデフォルトで表示されていましたが、1.3 にアップグレードするとすべて消えたように見えました。
1.3 と 1.4 の間で、Long.parseLong(String) の解釈は空の文字列を異なる方法で処理しました。1.3 は値を返しますが0、1.4 は をスローしNumberFormatExceptionます。
再コンパイルは必要ありませんが、1.3 の動作に依存している場合、動作中のコードは動作を停止しました。
メモリ モデル のセマンティクスが1.4 から 1.5 に変更されました。他のこと以外にも、再度ロックをダブルチェックできるように変更されました。(揮発性セマンティクスは修正されたと思います。) 壊れていました。
以下は Java 1.4 ではコンパイルできますが、 Java 1.5 以降ではコンパイルできません。
(Java 5 ではキーワードとして「enum」が導入されました。注: 「-source 1.4」オプションが指定されている場合、Java 5 でコンパイルされます。)
public class Example {
public static void main(String[] args) {
String enum = "hello";
}
}
明らかに、リリース名の命名規則は下位互換性がありません。
互換性を壊す java.sql のさらに別の例:
1.5 では、compareTo(Date) メソッドが java.sql.Timestamp に追加されました。指定された Date が java.sql.Timestamp のインスタンスでない場合、このメソッドは ClassCastException をスローします。もちろん、java.sql.Timestamp は Date を拡張し、Date にはすべての Date で動作する compareTo(Date) メソッドが既にあったため、Timestamp を (非 Timestamp) Date と比較するコードは 1.5 で実行時に壊れることを意味していました。 .
興味深いことに、1.6 ではこの問題が修正されたようです。java.sql.Timestamp.compareTo(Date) のドキュメントには「引数がTimestampオブジェクトでない場合、このメソッドはオブジェクトをスローするClassCastException」と記載されていますが、実際の実装ではそうではありません。私の推測では、これはドキュメントのバグです。
JRE クラス ライブラリの API の変更に関するレポートを参照してください: http://abi-laboratory.pro/java/tracker/timeline/jre/
このレポートには、Java クラスの後方バイナリおよびソース互換性分析が含まれています。
レポートはjapi-compliance-checkerツールによって生成されます。
...
JDK 1.0-1.6 のもう 1 つの興味深い分析は、Japitools JDK-Resultsページにあります。
私はそれを試していませんが、理論的にはこれは Java 1.1 で動作し、Java 1.2 で壊れます。(詳細はこちら)
public class Test {
float strictfp = 3.1415f;
}
Sean Reilly が言ったように、新しいメソッドはコードを壊す可能性があります。新しいメソッドを実装しなければならないという単純なケース (これによりコンパイラの警告が生成されます) の他に、最悪のケースがあります。インターフェイスの新しいメソッドが、クラスに既にあるメソッドと同じシグネチャを持っている場合です。コンパイラからの唯一のヒントは、注釈が欠落しているという警告です@Override(クラスの Java 5、注釈は Java 6 のインターフェイスでサポートされていますが、オプションです)。
個人的な経験から、1.5 の SWT_AWT フレームに埋め込まれたいくつかの AWT/Swing テキスト フィールドがあり、1.6 にアップグレードすると編集できなくなりました。