Print-friendly Version

目次

このドキュメントには、以下の項目に関する情報が含まれます。

• バイナリ互換性
  
• ソース互換性
  
• Java 2 Platform, Standard Edition, v1.4.0 と v1.3 における非互換性

Java^TM プラットフォームのバージョン 1.3 と 1.2 の間の非互換性については、Java 2 プラットフォームのバージョン 1.3 の互換性についてのドキュメントを参照してください。

Java プラットフォームのバージョン 1.1 と 1.2 の間の非互換性については、Java 2 プラットフォームのバージョン 1.2 の互換性についてのドキュメントを参照してください。

Java^TM プラットフォームのバージョン 1.0 と 1.1 の間の非互換性については、JDK^TM 1.1 の互換性についてのドキュメントを参照してください。

最初に Java 言語仕様が発表されて以来 Java プログラミング言語の仕様に対して行われた変更の概要は、「Clarifications and Amendments」を参照してください。

バイナリ互換性

一般的な原則は次のとおりです。

• ファミリ (1.2.x) 内の保守リリース (1.2.1、1.2.2 など) の間では、バイナリレベルの上位互換性および下位互換性が保証される

• ファミリ (1.x) 内の機能リリース (1.3、1.4 など) の間では、バイナリレベルの上位互換性は保証されるが、下位互換性は保証されない場合がある

初期の難読化ツールの中には、仮想マシンの仕様で規定されているクラスファイルの形式に違反するクラスファイルを生成するものがありました。そのような不適切な形式のクラスファイルは、旧バージョンの Java 仮想マシンでは動作する場合もありますが、J2SDK の仮想マシンでは動作しません。この問題を回避するには、適切な形式のクラスファイルを生成する新しい難読化ツールで、クラスファイルを生成し直してください。

ソース互換性

ソースレベルの下位互換性はサポートされていません。新しい言語機能または Java 2 プラットフォーム API を使っているソースファイルは、旧バージョンの Java プラットフォームでは使用できません。

一般的な原則は次のとおりです。

• 保守リリースでは、新しい言語機能または API は導入されないので、ソースレベルでの互換性が両方向に対して保証される

• 機能リリースおよびメジャーリリースでは、ソースレベルの上位互換性は保証されるが、下位互換性は保証されない

非推奨 API は、下位互換性のためだけにサポートされているメソッドやクラスです。推奨 API を使った場合、コマンド行オプションで -nowarn を指定しないと、コンパイラが警告メッセージを出力します。現時点では、非推奨メソッドやクラスをシステムから完全に削除する予定はありませんが、非推奨メソッドとクラスを使わないようにプログラムを修正することをお勧めします。

sun.* パッケージに含まれる API の中には、変更されているものがあります。このパッケージの API は、開発者用のものではありません。開発者が sun.* パッケージからインポートする場合は、各自の責任において行なってください。詳細は、開発者が sun.* パッケージを呼び出すプログラムを記述すべきでない理由を参照してください。

Java 2 Platform, Standard Edition, v1.4.0 と v1.3 における非互換性

J2SE 1.4.0 には、Java 2 プラットフォームの旧バージョンとの高い互換性があります。このため、既存のプログラムの多くは J2SE 1.4.0 でもそのまま実行できます。ただし、非常にまれな例ですが、v1.3 との互換性が提供されない場合もあります。ここでは、こうした非互換性について説明します。

1. Java 2 プラットフォームのバージョン 1.4 から、クラス javax.swing.tree.DefaultTreeModel で null ルートノードを使用できるようになりました。以前のバージョンでは、TreeModel の仕様に null ルートが有効であると示されていたにもかかわらず、DefaultTreeModel では null ルートが許可されませんでした。このバージョンから、DefaultTreeModel で、コンストラクタにおける null ルートの場合と同様に、null ルートを設定できます。この変更に伴い、DefaultTreeModel.setRoot() の仕様が改訂されました。 DefaultTreeModel.setRoot() の以前の仕様は、次のようなものでした。

   該当するルートをルートに設定します。これにより、ルートが null の場合は、IllegalArgumentException がスローされます。

   新たな DefaultTreeModel.setRoot() 仕様を、次に示します。

   該当するルートをルートに設定します。null ルートは、ツリーに何も表示されないことを意味し、有効な設定です。

2. 直列化可能な入れ子クラスに、たとえば「Foo.class」という名前のクラスオブジェクトへの明示的な参照が含まれる場合、入れ子クラスとそのクラスが包含するクラスの両方のクラスのデフォルトの直列化バージョン UID の計算値が、J2SE 1.3 と J2SE 1.4 では異なります。この相違は、直列化バージョン UID の計算が J2SE 1.3 および J2SE 1.4 の javac コンパイラ間でなされた変更の影響を受けるためです。

   使用するアプリケーションにこの問題が影響するのを避けるため、直列化可能クラスに明示的な直列化バージョン UID を追加することをお勧めします。serialver ツールを使用して、J2SE 1.3 javac コンパイラでコンパイルされたクラスの直列化バージョン UID を取得できます。

3. J2SE 1.4.0 から、クラス javax.swing.text.DefaultHighlighter 内の public static フィールド DefaultPainter が final になりました。Java 2 Platform, Standard Edition の以前のバージョンでは、このフィールドは final ではありませんでした。

4. Java 2 プラットフォームの実装内で HTML フォームを内部的にモデリングする方法は、J2SE 1.4.0 から変更されました。以前のバージョンでは、フォームの各属性は、すべての子キャラクタ要素の attributeset に格納されました。J2SE 1.4.0 ではフォームを表す要素が作成され、これは HTML ファイル自体の要素にさらに適合しています。この結果、フォームのモデリング機能が向上し、フォームの記述方法が一貫したものになりました。この変更は、バグ 4200439 に対処するために行われました。

   この変更により、厳密でない方法で処理されるフォームを利用してきた開発者が影響を受けます。次の例を考えてみましょう。

     <table>
       <form>
     </table>
     </form>
   

   1.4.0 以前の実装では、上記の無効な HTMLが、次のように処理されていました。

     <form>
       <table>
       </table>
     </form>
   

   J2SE 1.4.0 では、次のように処理されます。

     <table>
       <form>
       </form>
     </table>
   

   この変更は多くの開発者に影響を与えるものではありませんが、コードの更新が必要になる可能性があります。これまで、リーフの要素の属性にフォームの属性が含まれると考えてきたのであれば、今後は、フォーム要素の AttributeSet から属性を取得する必要があります。

5. J2SE 1.4.0 から、java.awt.event.MouseEvent クラスの static final フィールド MOUSE_LAST の値が、507 に変更されました。Java 2 プラットフォームの以前のバージョンでは、MOUSE_LAST の値は 506 でした。

   コンパイラが、コンパイル時に static final 値をハードコードするため、MOUSE_LAST を参照し、1.4.0 より前のバージョンの java.awt.event.MouseEvent を使用してコンパイルされたコードは、以前の値を保持します。この種のコードを J2SE 1.4.0 で動作させるには、バージョン 1.4.0 のコンパイラで再コンパイルする必要があります。

6. CORBA 互換性情報に記載されている OMG ドキュメントの指定に基づき、J2SE 1.4.0 の提供する CORBA テクノロジ用 API を、CORBA 2.3 マッピングに準拠させるという変更が加えられました。J2SE v1.3 と v1.4.0 間の CORBA 機能に関するすべての API 変更情報、および J2SE 1.4.0 が準拠するすべての OMG 仕様の一覧については、このリンクを参照してください。

7. J2SE 1.4.0 から、ObjectOutputStream の 1 つの引数を取る public コンストラクタ は、ObjectOutputStream.putFields または ObjectOutputStream.writeUnshared をオーバーライドするサブクラスに (直接的また間接的に) 呼び出される場合、SerializablePermission の "enableSubclassImplementation" が必要になります。

   また、J2SE 1.4.0 から、ObjectInputStream の 1 つの引数を取る public コンストラクタは、ObjectInputStream.readFields または ObjectInputStream.readUnshared をオーバーライドするサブクラスに (直接的または間接的に) 呼び出される場合、SerializablePermission の "enableSubclassImplementation" が必要になります。

   この変更は、大多数のアプリケーションには影響を及ぼしませんが、putFields または readFields メソッドをオーバーライドし、かつ他の直列化インフラストラクチャをオーバーライドしないすべての ObjectInputStream または ObjectOutputStream が影響を受けます。

8. J2SE 1.4.0 の Javac バイトコードコンパイラは、Java 言語仕様への準拠を強制する点で、以前のバージョンよりも厳密になっています。この新たなコンパイラでは、Java 言語仕様に厳密に準拠していない既存コードは (たとえ以前のバージョンのコンパイラでコンパイルできたとしても) コンパイルできません。

   J2SE 1.4.0 コンパイラの厳密性が増したことを示す例を、次にいくつか示します。

   • コンパイラは、言語仕様で要求されているとおり、到達不可能な空白文を検出するようになりました。コンパイラが検出および拒否を行うごく一般的な 2 つの例を、次に示します。

     return 0;/* exit success */;
     

     および

     { return f(); } catch (Whatever e) { throw new Whatever2(); };

     
     

     どちらの例でも、余分のセミコロンがあるために、コンパイラは到達不可能な空白文と正しく見なします。また、自動的に生成されたソースコードに、到達不可能な空白文が含まれる場合があります。

   • コンパイラは、名前のないネームスペースから型をインポートする import 文を拒否するようになりました。以前のバージョンのコンパイラは、こうした import 宣言を、理論的には言語で許可されていなくても (import 句に現れる型名がスコープ内に存在しないため)、 受け入れていました。仕様の中では、import 文の中に単純名を含めることはできないこと、また名前のないネームスペースからインポートを行うことはできないことが明示されています。

     要約すると、次の構文は有効ではなくなりました。

     import SimpleName;
     

     また、名前のないネームスペースからネストしたクラスをインポートする次の文も、有効ではなくなりました。

     import ClassInUnnamedNamespace.Nested;
     

     コード内でこうした問題を修正するには、すべてのクラスを、名前のないネームスペースから名前付きのネームスペースへ移動する必要があります。

9. J2SE 1.4.0 では、javac バイトコードコンパイラは、これまでの「-target 1.1」動作ではなく「-target 1.2」をデフォルトで使用します。これらの動作の詳細は、javac コンパイラのリファレンスページを参照してください。1.2 での変更には、クラスがインタフェースから未実装のメソッドを継承する場合、コンパイラがクラスファイル内でメソッド宣言を生成および挿入しない、という点が含まれます。挿入されたこれらのメソッドは、private でない他のメソッドと同様、デフォルトの serialVersionUID 計算に含まれます。この結果、インタフェースを直接実装していても、そのメソッドを実装していない抽象直列化可能クラスを定義する場合、そのデフォルトの serialVersionUID 値は、J2SE 1.4 バージョンの javac 、または以前の javac のどちらを使用してコンパイルするかにより異なります。

   以前のバージョンの javac で挿入されたこれらのメソッドに関する背景情報は、バグ 4043008 を参照してください。

10. ソースの非互換性 - JDBC 3.0 API は、J2SE 1.4 プラットフォームの一部として含まれています。新しい 2 つのインタフェースを備えており、既存のインタフェースにいくつかの新しいメソッドを追加します。 以前のバージョンの JDBC API を使用するドライバおよびアプリケーションは、J2SE 1.4 プラットフォームとバイナリレベルでの互換性があり、問題なく動作します。 ただし、JDBC 3.0 API に追加された変更には、ソースレベルでの互換性がありません。 JDBC インタフェースを実装するドライバおよびアプリケーションは、正常に構築するためには、アップデートして変更を反映する必要があります。 JDBC 3.0 の仕様 の第 6 章に、JDBC 3.0 API に適応し、J2SE 1.4 とソースレベルでの互換性を持つために行わなければならないことの完全なリストが掲載されています。

11. J2SE 1.4 以前では、ファイルの種類がわかっていて、応答コードが 400 またはそれ以上である場合、FileNotFoundException がスローされます。これ以外の場合は、例外はスローされません。

    J2SE 1.4 に実装された正しい動作は、すべての http エラーに対し、ファイルの種類に関わらず URLConnection.getInputStream が IOException をスローします。 FileNotFoundException は IOException のサブクラスで、http 応答がリソースが見つからないことを示す場合だけスローされます。 つまり、FileNotFoundException は、応答コードが 404 または 410 の場合にだけスローされます。

    この変更の一部として、HttpURLConnection.getErrorStream は、サーバから戻されたエラーページを読み取るのに使用できるようになりました。 J2SE 1.4 以前では、getErrorStream は常に null を返しました。 また、J2SE 1.4 では、メソッド HttpURLConnection.getResponseCode が正しく動作するようになりました。

12. assert キーワード が、J2SE 1.4 の Java Programming Language に追加されました。 新しいキーワードにより、識別子として "assert" を使用する既存のプログラムは、J2SE 1.4 に適用しません。 しかし、このキーワードの追加により、以前起こったバイナリ (.class ファイル) 使用による問題が発生しなくなりました。 assert が正当な識別子である pre-J2SE 1.4 リリース (J2SE 1.4 では正当な識別子ではありません) から簡単に移行するために、Javac バイトコードコンパイラは、J2SE 1.4 で 2 つのモードのオペレーションをサポートします。
    • 通常オペレーションモード。コンパイラは以前のリリース (J2SE 1.3) の仕様に適用するプログラムを受け入れます。表明は認められず、assert キーワードが識別子として使用されると、コンパイラは警告を生成します。

    • 代替オペレーションモード。コンパイラは J2SE 1.4 の仕様に適用するプログラムを受け入れます。表明が認められ、assert キーワードが識別子として使用されると、コンパイラはエラーメッセージを生成します。

    表明を有効にするには、次のコマンド行スイッチを使用します。

    -source 1.4
    

    このフラグが使用されない場合、デフォルトの動作で最大 "1.3" までソースレベルの互換性が認められます。1.3 とのソースレベルの互換性サポートは、時間をかけて段階的に廃止される予定です。

13. インタフェース AppletContext の API 仕様が修正されて、アプレット開発者がデータおよびオブジェクトを、ブラウザセッション中に持続的に使用するためにストリームに出力できるようになりました。 これにより開発者は、static クラスを使用してデータおよびオブジェクトをキャッシュする必要がなくなりました。ただし、バイナリの互換性がなくなる可能性もあります。 AppletContext インタフェースを実装するクラスを含む既存のアプリケーションは、新規の AppletContext 仕様と互換性がありません。そのようなクラスは、修正後の AppletContext API を実装するように修正する必要があります。 事実上、一般に AppletContext を実装するアプリケーションは、Java Plug-in および appletviewer のようなアプレットコンテナとして動作するアプリケーションだけです。この非互換性による影響は、あるとしても最小限だと思われます。

14. J2SE^TM 1.4 では、Socket API に大幅な変更が加えられています。そのうちのひとつに、SocketImpl 抽象クラスへの新しい抽象メソッドの追加があります。この新しいメソッドの追加により、J2SE 1.4 より前に作成された SocketImpl のサブクラスについては、新しいメソッドに対応する実装が存在しないため、1.4 の javac コンパイラでは正常に処理できません。

    ただし、「バイナリ互換」は維持されているので、このようなサブクラスの既存のクラスファイルは従来通りに動作します。

    SocketImpl のサブクラスを使用するアプリケーションはほとんど存在しないため、この潜在的な非互換性の影響は最小限にとどまるものと思われます。SocketImpl のサブクラスを作成する開発者は次のいずれかの方法でこの変更に対処できます。

    • J2SE 1.3.x (またはそれより前のバージョン) でコンパイルされたクラスファイルを使用する。
    • 追加された新しいメソッドの実装を用意する。単純な TCP/IP の実装を想定し、タイムアウト値を無視する簡単な例を、以下に示します。ただし、実際にはタイムアウト値を考慮した適正な実装を行うべきです。

      /** * Creates a socket and connects it to the specified address on * the specified port. * @param address the address * @param timeout the timeout value in milliseconds, or zero for no timeout. * @throws IOException if connection fails * @throws IllegalArgumentException if address is null or is a * SocketAddress subclass not supported by this socket * @since 1.4 */ protected void connect(SocketAddress address, int timeout) throws IOException { if (address == null || !(address instanceof InetSocketAddress)) throw new IllegalArgumentException("unsupported address type"); InetSocketAddress addr = (InetSocketAddress) address; if (addr.isUnresolved()) throw new UnknownHostException(addr.getHostName()); this.port = addr.getPort(); this.address = addr.getAddress(); try { connect(this.address, this.port); return; } catch (IOException e) { // everything failed close(); throw e; } }

      
      

15. J2SE 1.4 プラットフォームには、Java Secure Socket Extension (JSSE) API が含まれます。J2SE 1.4 では、JSSE 実装はシステムプロパティ com.sun.net.ssl.dhKeyExchangeFix を識別し、この変数は J2SE 1.4 ではデフォルト値として true を持ちます。以前にリリースされた JSSE 1.0.2 のオプションパッケージでは、デフォルト値は false でした。DH 鍵交換を使用する暗号群は、このプロパティ値の変更により影響を受けます。そのような暗号群はほとんど使用されないため、この非互換性による大きな影響はないと思われます。

背景 : 当初リリースされた JSSE API のオプションパッケージのバージョンでは、DSA 署名がサーバ鍵交換メッセージの一部として使用された場合に、DSA 署名の不正な符号化を引き起こすというバグが含まれていました。つまり、JSSE は鍵交換仕様に準拠しておらず、そのことが JSSE とほかのベンダーが提供する SSL 実装との非互換性の原因となっていました。この状態を修正するために、オプションパッケージ JSSE 1.0.2 ではシステムプロパティ com.sun.net.ssl.dhKeyExchangeFix が実装されました。このプロパティを true に設定することで、JSSE 1.0.2 はバグを回避した状態で操作することになり、ほかの SSL 実装との互換性をとることができるようになります。プロパティ値が false の場合は、JSSE 1.0.2 は以前の JSSE リリースとの互換性を持つためにバグを回避せずに操作します。 JSSE 1.0.2 ではプロパティのデフォルト値は false でしたが、J2SE 1.4 ではデフォルト値は true であり、J2SE 1.4 とほかの SSL/TLS 実装との互換性を保証しています。　　　

16. J2SE プラットフォームのバージョン 1.4 以降では、デフォルトのポリシー実装が使用するポリシーファイルは UTF-8 文字エンコーディングにエンコードする必要があります。ほかのプラットフォームの文字エンコーディングにエンコードされた可能性のある ASCII 以外の文字を含む既存のポリシーファイルは、UTF-8 に変換する必要があります。変換には、J2SDK の native2ascii ツールを使用することができます。

17. バグ 4395290 に対処するために、J2SE 1.4.0 において動作の変更が行われました。この変更は、J2SE 1.4.1 にも適用されています。この変更によって、ドラッグ操作中に DropTarget のドロップ位置の動作可能部分からマウスポインタが離れた場合のみ、DropTarget と DropTarget に登録されている DropTargetListener において dragExit() が呼び出されるようになりました。J2SE 1.4.0 よりも前のバージョンでは、このメソッドが、DropTarget または DropTargetListener において drop() が呼び出される直前にも呼び出されていました。

    この古い動作については、J2SE 1.3 のドラッグ＆ドロップの仕様で説明されていますが、Java 2 プラットフォームの API の仕様と矛盾しています。また、この古い動作は不便であり、Swing のドラッグ＆ドロップの操作性に大きな影響を与えます。

    J2SE 1.4.0 から、この動作は Java 2 プラットフォームの API の仕様に適合しており、この変更を反映して、ドラッグ＆ドロップの仕様が変更されています。

18. バグ 4426794 と 4435403 に対処するために、J2SE 1.4.0 において動作の変更が行われました。この変更は、J2SE 1.4.1 にも適用されています。J2SE 1.4.0 よりも前のバージョンでは、ドラッグ通知は常にマウスカーソルの下にある最上位のコンポーネントに送られていました。このコンポーネントが関連するドロップターゲットを持っていない場合、ドラッグ通知は破棄されます。この設計には、以下の 2 つの重要な欠点があります。

    • Swing のガラス区画はすべてのドラッグ通知を受け取ってしまうので、ドラッグ通知の送信中には Swing のガラス区画を無視しなければなりません。したがって、開発者は Swing のガラス区画をドロップターゲットとして使用することができません。

    • JColorChooser などの複合コンポーネントにおけるドロップのサポートを実現する場合、複合コンポーネントの内部のどの部分へのドロップも受け入れるようにするには、その複合コンポーネントのすべての下位クラスにおいてドロップターゲットをインストールする必要があります。これでは扱いにくく、効率がよくありません。

    動作の変更後、ドラッグ通知は、有効なドロップターゲットを備えたマウスカーソルの下にある最上位のコンポーネントに送られるようになりました。

19. 1.4.0 で新しいフォーカスアーキテクチャが導入されたことに伴い、フォーカス移動キー (大抵の場合は Tab キー) が消費されます。プログラムがこれらのキーイベントの通知を受けるキーリスナーに依存している場合、フォーカス移動キーが原因で問題が発生する場合があります。フォーカス移動キーが消費されるのを避けるには、次のコードを使用してください。

        component.setFocusTraversalKeysEnabled(false);
    

    ここで、component はキー イベントを発行する Component を指します。詳細は、バグ 4650902 を参照してください。

20. リリース 1.4.0 では、最後のウィンドウが処理され、イベントキューにイベントが存在しなくなると、イベントディスパッチスレッドが終了してプログラムが終了する場合があります。回避方法を含む詳細については、バグ #4030718 を参照してください。