Sun Java Solaris Communities My SDN Account Join SDN
 
Compatibility with Previous Releases

 

SDK ドキュメント

英語版

目次

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

互換性に関するドキュメントはバージョンごとに用意されていますが、その 1 つ前のバージョンとの非互換性の問題だけを取り上げています。たとえば、J2SE 1.4.2 の互換性に関するドキュメントに記載されているのは、J2SE 1.4.2 と J2SE 1.4.1 の非互換性の問題だけです。それ以前のバージョンとの非互換性の問題については記載されていません。 したがって、J2SE 1.4.2 とその他の全バージョンの非互換性について調べたい場合は、J2SE 1.4.2 以前のすべてのバージョンの互換性に関するドキュメントを参照する必要があります。

次の各ドキュメントには、それぞれ直前のリリースとの非互換性に関する情報が記載されています。

Java Language Specification, Second Edition』(『JavaTM言語仕様』、James Gosling、Bill Joy、Guy Steele、Gilad Bracha 著、ピアソン・エデュケーション発行、2000) が出版されてから Java プログラミング言語の仕様に対して行われた変更の概要は、「Java Language Specification Maintenance Page」を参照してください。

バイナリ互換性

後述の Java 2 Platform (J2SE), Standard Edition, v1.4.1 と v1.4.2 における非互換性 で説明されている項目を除き、Java 2 SDK (J2SDK), v1.4.2 は、J2SDK v1.4.1 に対してバイナリレベルの上位互換性があります。つまり、互換性のないことが示されている機能を除き、バージョン 1.4.1 のコンパイラで作成されたクラスファイルは、J2SDK v1.4.2 で正常に動作します。

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

ソース互換性

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

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

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

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

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

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

Java 2 Platform, Standard Edition, v1.4.2 における非互換性 (1.4.1 以降)

J2SE 1.4.2 には、Java 2 プラットフォームの旧バージョンとの高い互換性があります。このため、既存のプログラムの多くは J2SE 1.4.2 でもそのまま実行できます。ただし、非常にまれなケースですが、1.4.1 との互換性が得られなくなる場合もあります。ここでは補足として、このような特例について説明します。

  1. J2SE 1.4.2 には既知の JCK のバグがあります。 -enablesystemassertions フラグを付けて実行すると、まれに浮動小数点が文字列に変換され、アサーションエラーをスローします。

    J2SE 1.4.2_01 ではこの非互換性は取り除かれ、関連バグは修正されました。 この非互換性に関連したバグレポートは 4905011 です。

  2. J2SE 1.4.2 以降の java.net.URI クラスでは、単一のドメインラベルからなる階層 URI のホストコンポーネント内にホスト名を含めることにより、URI を数字で開始することができます。以前は、s://123/p のような URI は、権限コンポーネントをサーバベースの権限ではなく、レジストリベースの権限と見なしていました。この変更により、URI.getHost() の仕様が改訂されました。以前の仕様の「ドメイン名に含まれる最後のラベルだけは英字で始まる」という記述は、新しい仕様では「複数のラベルからなるドメイン名の一番右のラベルは英字で始まる」と書き換えられました。
  3. J2SE 1.4.2 より前は、Microsoft Windows プラットフォームを使用するユーザが「コントロールパネル」で ANSI コードページに対応していないユーザロケール (ヒンディー語など) を選択すると、file.encoding システムプロパティが utf-16le に設定されます。このプロパティが Java のデフォルトエンコーディングとして使用されるため、すべての読み取りおよび書き込みがこのエンコーディングで行われることになります。 このため、システム上のファイルは、utf-16le コンバータを使用して読み取りおよび書き込みが行われます。この状況では、例外が頻繁に発生します。

    J2SE 1.4.2 では、file.encoding システムプロパティは、システムのデフォルトロケールから派生します。 Microsoft Windows プラットフォームでは明示的なデフォルトのファイルエンコーディングが存在しないため、システムのデフォルトロケールにより、Java のデフォルトファイルエンコーディングが推測されます。

    アプリケーションが utf-16le エンコーディングを非 ANSI コードページベースのデフォルトロケールと想定すると、アプリケーションで障害が発生します。

    この変更に関連したバグレポートは、4459099 です。

  4. J2SE 1.4.0 より前は、セキュリティポリシーファイルの文字エンコーディングスキーマは指定されておらず、ファイルの読み取りにはデフォルトの文字エンコーディングが使用されていました。1.4.0 からは、ポリシーファイルを UTF-8 でエンコードすることが必要になりました。

    これにより、ポリシーファイルを異なるロケール間で使用できるようになりましたが、デフォルトエンコーディングの文字を含む既存のポリシーファイルは破壊されてしまいます。

    J2SE 1.4.2 では、新たなシステムプロパティ     sun.security.policy.utf8 が導入されました。

    このシステムプロパティを true に設定すると、 ポリシーファイルの読み取りが UTF8 を使用して行われます (1.4.0 および 1.4.1 で動作)。 システムプロパティを false に設定すると、ポリシーファイルの読み取りがデフォルトエンコーディングを使用して行われます (1.4.0 以前で動作)。 システムプロパティが設定されていない (NULL の) 場合、デフォルト値は true になります。

  5. 指定されたカラーマップから IndexColorModel オブジェクトの Transparency 値を決定するコードが、より整合性が高く、予測可能なものになりました。関連するドキュメントも、この変更に応じて更新されています。

    IndexColorModel を使用するすべてのコードで、getTransparency() および getTransparentPixel() の戻り値がより正確で整合性の高いものになっています。

    この変更に関連するバグレポートは、4688381 です。

  6. J2SE 1.4.0 から、Kerberos V5 を利用した Java Generic Security Services (JGSS) がサポートされるようになりました。 セキュリティコンテキストの確立処理の一部として、クライアントは Kerberos サーバからサービスチケットを受け取ります。このサービスチケットは、GSS Context の確立処理の一部として、クライアントからサーバに提示されます。

    J2SE 1.4.2 より前は、useSubjectCredsOnly プロパティが true に設定されている場合、Ticket Granting Ticket (TGT) が Subject から取得されて、GSS Security コンテキストの確立に使用されていました。 GSS Context の確立処理中に取得されたサービスチケットは、Subject に格納されませんでした。

    J2SE 1.4.2 から、useSubjectCredsOnly プロパティが true の場合、取得されたサービスチケットは Subject に格納されます。 これにより、アプリケーション開発者は JGSS 外部のサービスチケットにアクセスできます。たとえば、ネイティブアプリケーションや独自のプロトコルで、この種のチケットを使用できます。また、クライアントが同じサービスに対して再度セキュリティコンテキストの確立を試みる場合に、この種のチケットを再利用できます。

    関連する API の変更はありません。ただし、クライアントアプリケーションが Subject の非公開資格を検索する場合、J2SE 1.4.2 より前のリリースでは TGT のみが検出されましたが、J2SE 1.4.2 では取得された追加サービスチケットもすべて検出されます。

  7. J2SE 1.4.0 では、キーボードのフォーカス管理が再設計され、「opposite」フィールドが java.awt.event.FocusEvent および java.awt.event.WindowEvent に追加されました。

    たとえば、WindowEvent では、opposite は状態の変化に関係するもう一方の Window です。 イベントのソースがアクティブに設定された場合、opposite は非アクティブに設定された Window になります。この逆も同様です。FocusEvent では、opposite はフォーカスの移動に関係するもう一方のコンポーネントです。イベントのソースがフォーカスを取得した場合、opposite はフォーカスを失ったコンポーネントになります。この逆も同様です。

    他のイベントの継承元となる java.util.EventObject 内の「source」フィールドは、一時的なフィールドです。 FocusEvent.opposite および WindowEvent.opposite は一時フィールドではないため、これらを直列化および直列化復元しても意味がありません。 このため、J2SE 1.4.2 では、直列化復元後に WindowEvent.opposite および FocusEvent.opposite が null に設定されます。

    この変更に関連するバグレポートは、4759974 です。