このマニュアルでは、次のトピックについて説明します。
互換性についてのドキュメントは、前後するバージョン間だけの非互換性を示すように分割されています。たとえば、この 1.5.0 互換性ページは、1.4.2 と 1.5.0 の間の非互換性についてのみ説明しており、以前のバージョンとの非互換性については説明していません。このため、1.5.0 がすべてのバージョンとどのような非互換性があるかを確認するには、すべての互換性ページに目を通す必要があります。
前後するリリース間の非互換性については、以下のドキュメントで説明されています。
http://java.sun.com/j2se/1.4.2/ja/compatibility.html にある「バージョン 1.4.2 における非互換性 (1.4.1 以降)」
http://java.sun.com/j2se/1.4.1/ja/compatibility.html にある「バージョン 1.4.1 における非互換性 (1.4.0 以降)」
http://java.sun.com/j2se/1.4/ja/compatibility.html にある「バージョン 1.4.0 における非互換性 (1.3 以降)」
http://java.sun.com/j2se/1.3/ja/compatibility.html にある「バージョン 1.3 における非互換性 (1.2 以降)」
Java Language Specification, Second Edition (http://java.sun.com/docs/books/jls/index.html) の公開以降に Java プログラミング言語の仕様に加えられた変更の概要については、『Java Language Specification Maintenance Page』 (http://java.sun.com/docs/books/jls/jls-maintenance.html) を参照してください。
Java 2 Platform Standard Edition 5 のバージョン 1.5.0 は、以下に示す非互換性を除き、バージョン 1.4.2 とバイナリレベルの上位互換性があります。これは、下記の非互換性を除き、バージョン 1.4.2 コンパイラで構築されたクラスファイルはバージョン 1.5.0 上で正しく稼動することを意味します。
初期のバイトコード難読化ツールの中には、仮想マシンの仕様とは異なる形式のクラスファイルを生成するものがありました。このような不適切な形式のクラスファイルは Java 2 JDK の仮想マシン上では動作しませんが、初期バージョンの仮想マシン上では動作するものもあります。この問題を修復するには、適切な形式のクラスファイルを生成する新しい難読化ツールでクラスファイルを生成し直します。
ソースの下位互換性はサポートされません。新しい言語機能や Java 2 Platform API を使用するソースファイルは、初期バージョンの Java 2 Platform では使用できません。
後の方に挙げられた非互換性を除き、一般にポリシーは次のとおりです。
保守リリース (1.4.1、1.4.2 など) は新しい言語機能や API を取り入れていないため、互いにソースレベルの互換性があります。
機能リリースとメジャーリリース (1.3.0、1.4.0、1.5.0 など) は上位互換性はありますが、ソースレベルの下位互換性はありません。
推奨されない API は、下位互換性だけを考慮してサポートされているインタフェースです。これらのどれかを使用すると、-nowarn コマンド行オプションを指定していないかぎり、javac コンパイラは警告メッセージを生成します。推奨されない API を使用しないようにプログラムを変更することを推奨しますが、JVMDI と JVMPI がシステムから完全に削除される以外、現在のところこのような API を削除する計画はありません (バグ 4639363 を参照)。
sun.* パッケージ内のいくつかの API は変更されました。これらの API は開発者向けではありません。sun.* パッケージからインポートする場合、開発者は自分の責任で行うようにしてください。詳細については、http://java.sun.com/products/jdk/faq/faq-sun-packages.html にある 「Why Developers Should Not Write Programs That Call sun.* Packages」を参照してください。
J2SE 5 は以前のバージョンの Java 2 Platform との強力な互換性を持っています。既存のプログラムは変更しなくても、ほとんどすべて、J2SE 5 上で動作するはずです。しかし、JRE と JDK にはまれな状況や「コーナーケース」で発生するソースレベルまたはバイナリレベルのマイナーな潜在的非互換性も存在するため、その状況に対処できるように補足情報をここで説明します。
総称化 - 総称化は既存のクラスとメソッドに総称 (generic) 型のパラメータと引数を追加するプロセスであり、それらのクラスの仕様に一致した方法で行われます。JSR 14 では、多くの core ライブラリについて総称化の仕様が定められました (代表的なものはコレクションクラスと Class クラス)。1.5 Beta 2 リリースでは、core の総称化の効果が、可能なかぎりプラットフォームの残りの部分全体に伝播されました。
総称化されたクラス、コンストラクタ、メソッド、フィールドを使用するほとんどのソースコードは 1.5 でもコンパイルを継続しますが、一部はコンパイルを継続しません。総称化の変更が原因となってコードがコンパイルに失敗する場合は、最も簡単な方法として javac コマンド行で -source 1.4 と指定できます。
汎用型および core の総称化については、JSR 14 と、http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf にある「Generics in the Java Programming Language」を参照してください。
仮想マシン - 以前には、Solaris (SPARC 版) のデフォルト仮想マシン (VM) はクライアント VM でした。しかし、パフォーマンスを考えた場合、サーバー VM の方が適しているため、多くの Solaris (SPARC 版) はサーバーとして使用されます。このため、1.5 ではサーバークラスの Solaris (SPARC 版) マシンはデフォルトでサーバー VM を実行します。一般に、サーバー VM のスループットはクライアント VM よりもはるかに優れていますが、起動時間は少し劣ります。サーバークラスマシン は、現在、2 個以上のプロセッサと 2GB 以上のメモリーを持つマシンと定義されています。
詳細については、「サーバークラスマシンの検出」(http://java.sun.com/j2se/1.5.0/ja/docs/ja/guide/vm/server-class.html) と「ガーベージコレクタのエルゴノミクス」(http://java.sun.com/j2se/1.5.0/ja/docs/ja/guide/vm/gc-ergonomics.html) を参照してください。
仮想マシン - 1.5 で導入されたクラス共有機能を反映するため、このリリースでは java.vm.info プロパティ (java -version によって表示されるテキストに示される) は共有モードを指定するようになりました。java.vm.info プロパティ値の最後まで解析を行うコード、または java -version の出力を解析するコードは必要に応じて変更してください。
詳細については、バグ 4964160 と、http://java.sun.com/j2se/1.5.0/ja/docs/ja/guide/vm/class-data-sharing.html にある「クラスデータの共有」を参照してください。
クラスローダ - 以前には、String クラス名引数を受け付ける ClassLoader メソッドにバイナリでないクラス名を指定できました。この意図的でない動作は、長年にわたるクラス名の仕様に準拠していませんでした。1.5 では、これらの ClassLoader メソッドをチェックするパラメータは仕様に準拠するように変更され、バイナリ名でないクラス名は認識されないその他のクラス名と同様に扱われます。クラス名を明示的に要求するか、あるいはクラス名を明示的に返す API (Class.forName、Class.getName など) は、参照型にバイナリ名を使用します。このため、Class を返すクラス名を通常のユーザーが生成することはありません。
詳細については、『Java Language Specification, Second Edition』(http://java.sun.com/docs/books/jls/) 内の 「binary name」の定義 (http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html#59876) を参照してください。また、バグ 4986512 の評価も参照してください。
直列化 - コンパイラによって生成された全体的な合成結果に変更を加えると、デフォルトのシリアルバージョン UID に影響を与えます。したがって、その UID が明示的に上書きされない場合には直列化の互換性が保たれなくなる可能性があります。
詳細については、バグ 4786115 を参照してください。
ロギング - 以前には、java.util.logging.Level(String name, int value, String resourceBundleName) コンストラクタは null の name 引数を許可しましたが、parse メソッドは許可しませんでした。1.5 では、コンストラクタは名前が null の場合、NullPointerException をスローするようになりました。このコンストラクタを使用するには Level をサブクラス化する必要があり、後続の呼び出し (toString のようなシンプルな呼び出しを除く) で null の Level 名を使用する場合には NullPointerException を受け取るため、互換性上のリスクは軽減されます。
詳細については、バグ 4625722 を参照してください。
Apache - org.apache クラス (J2SE API ではサポートされなかったが javax.xml パッケージでは使用されている) は、開発者によってダウンロードされる最近のクラスバージョンと重複しないように、1.5 で com.sun.org.apache.package.internal に移されました。J2SE リリースに含まれる org.apache クラスに依存するアプリケーションを 1.5 で稼動させるには、以下の作業のいずれかを実施する必要があります。
「JAXP」に含まれるサポート対象のインタフェースだけを使用するようにアプリケーションを作成する
Apache から org.apache.xalan クラスをダウンロードする
詳細については、バグ 4740355 を参照してください。
JAXP - J2SE 1.4 プラットフォームには JAXP 1.1 (Crimson) が含まれていました。J2SE 1.5 プラットフォームには JAXP 1.3 (Xerces) が含まれます。Crimson と Xerces は、同一のコードベースを持つ個別のバージョンではありません。これらは、まったく異なる JAXP 標準実装です。このため、どちらも JAXP 標準に準拠していますが、微妙な違いがあります。
Crimson はサイズが小さく高速でしたが、結局のところ機能的には Xerces (Apache でホスティングされるオープンソース実装) に及びませんでした。この上、JAXP 標準が 1.1 から 1.3 へ進みました。これらの 2 つの要因が相まって互換性問題が出現しました。
詳細については、http://java.sun.com/j2se/1.5.0/ja/docs/ja/guide/xml/jaxp/JAXP-Compatibility_150.html にある「JAXP 互換性ガイド J2SE5 Platform 用」を参照してください。
JAXP - J2SE 1.4 プラットフォームは、DOM Level 2 API をサポートしました。J2SE 1.5 プラットフォームは、DOM Level 3 ファミリの API をサポートします。DOM Level 3 インタフェースに新しいメソッドがいくつか追加されました。このため、DOM Level 2 を使用する既存のアプリケーションの中には新しいインタフェースではコンパイルできないものがあります。
クラスパス内で DOM Level 2 の代わりに DOM Level 3 が使用されていると、ほとんどの DOM Level 2 アプリケーションは稼動します。しかし、中には NoSuchMethodException が発生するものもあります。したがって、一部のアプリケーションはバイナリレベルの互換性を維持できません。
詳細については、http://java.sun.com/j2se/1.5.0/ja/docs/ja/guide/xml/jaxp/JAXP-Compatibility_150.html にある「JAXP 互換性ガイド J2SE5 Platform 用」を参照してください。
JAXP - J2SE 1.4 プラットフォームは、SAX 2.0 API をサポートしました。J2SE 1.5 プラットフォームは、SAX 2.0.2 をサポートします。SAX 2.0.2 はバグ修正リリースであり、API の変更はありません。しかし、SAX 2.0.2 リリースの一部として行われたいくつかの修正作業が互換性問題を引き起こしている可能性があります。
ErrorHandler、EntityResolver、ContentHandler、および DTDHandler は、現在ではアプリケーションによって null に設定される可能性があります。この場合、SAX 2.0 は java.lang.NullPointerException をスローするために XML プロセッサを必要とします。ほとんどの構文解析部はデフォルト設定に戻すことにより null に対応するため、この変更が XML プロセッサに関係します。
DefaultHandler は、各種のハンドラ (EntityResolver など) のデフォルトの実装クラスです。DefaultHandler における resolveEntity メソッド実装は、現在では throws IOException, SAXException として宣言されます。以前には、この実装は SAXException しかスローできませんでした。
resolveEntity メソッドによってスローされる例外リストへの java.io.IOException の追加は、ソースレベルでは互換性のない変更です。具体的には、resolveEntity を呼び出すコードは SAX 2.0 で正常にコンパイルできる可能性がありますが、SAX 2.0.2 ではコンパイルに失敗する可能性があります。これは、SAXException と共に IOException を処理する必要があるためです。
詳細については、http://java.sun.com/j2se/1.5.0/ja/docs/ja/guide/xml/jaxp/JAXP-Compatibility_150.html にある「JAXP 互換性ガイド J2SE5 Platform 用」を参照してください。
JAXP - 以前には、デフォルトのトランスフォーマは Xalan でした。Apache コミュニティは XSLT 2.0 の開発用として XSLTC をデフォルトのプロセッサとすることに同意したため、1.5 では XSLTC がデフォルトのトランスフォーマです。これには以下の互換性のリスクがあります。
Xalan には XSLTC にはないバグがあり、XSLTC には Xalan にないバグがあります。Xalan のバグを考慮したアプリケーションコードは失敗する可能性があります。
Xalan がサポートしている拡張子の中には XSLTC でサポートされないものがあります。これらの拡張子については、JAXP 仕様および XSLT 仕様の範囲外です。このことに影響を受けるユーザーは、現在でも Apache から Xalan クラスをダウンロードできます。また、将来的には XSLTC でより多くの拡張子がサポートされると予測されます。
詳細については、http://java.sun.com/j2se/1.5.0/ja/docs/ja/guide/xml/jaxp/JAXP-Compatibility_150.html にある「JAXP 互換性ガイド J2SE5 Platform 用」を参照してください。
2D - 以前には、null の Image パラメータを Graphics.drawImage メソッドに渡すと NullPointerException が発生しました。1.5 ではこの例外は発生しません。このように動作が変わったため、Microsoft VM で稼動したアプリケーションは標準の VM でも稼動できます。NullPointerException に依存しているアプリケーションは、1.5 で稼動するように変更する必要があります。
AWT - 以前には、フォーカストラバーサルポリシーを提供できたのはフォーカスサイクルルートであるコンテナだけでした。1.5 では、どのコンテナもフォーカストラバーサルポリシーを提供できます。Container の新しい FocusTraversalPolicyProvider プロパティは、ポリシーを提供するかどうかを示します。
Java プラットフォームで提供されるフォーカストラバーサルポリシーは、フォーカストラバーサルポリシープロバイダに対応するように変更されました。具体的には、フォワード (バックワード) トラバーサル中にポリシーがフォーカストラバーサルポリシープロバイダに遭遇すると、ポリシーは提供されたフォーカスサイクルルートに属するものとしてそのコンポーネントを扱わず、フォーカストラバーサルポリシプロバイダのフォーカストラバーサルポリシーを使用して次の (前の) コンポーネントを取得する必要があります。返されたコンポーネントがフォーカストラバーサルポリシプロバイダのフォーカストラバーサルポリシーによって返された最初の (最後の) コンポーネントと同じである場合、フォーカストラバーサルポリシープロバイダの後 (前) のサイクル内における次の (前の) コンポーネントをポリシーの呼び出しによって取得する必要があります。フォーカスサイクルルート内の最初と最後のコンポーネントの計算には、必要に応じて (最初または最後のコンポーネント自体が Container でかつフォーカストラバーサルポリシープロバイダである場合) フォーカストラバーサルポリシープロバイダのフォーカストラバーサルポリシーを使用する必要があります。
この変更はフォーカストラバーサルポリシー内に新しいメソッドを使用することを要求しないため、サン以外のフォーカストラバーサルポリシーは引き続き稼動します (ただしプロバイダという概念はサポートしない)。
フォーカストラバーサルポリシーを作成してあり、プロバイダをサポートしたいという場合は、1.5 でプラットフォームによって提供されているポリシーに加えられている変更に類似した変更を加える必要があります。
詳細については、フォーカス仕様の http://java.sun.com/j2se/1.5.0/ja/docs/ja/api/java/awt/doc-files/FocusSpec.html#FocusTraversalPolicyProviders にある「Focus Traversal Policy Providers」セクションと、http://java.sun.com/j2se/1.5.0/ja/docs/ja/api/java/awt/doc-files/FocusSpec.html にある「AWT Focus Subsystem」を参照してください。
ドラッグ&ドロップ - 以前には、X11 でサポートされたドラッグ&ドロップ (DnD) プロトコルは Motif DnD プロトコルだけでした。1.5 では XDND プロトコルもサポートされ、Motif DnD プロトコルは Motif ライブラリに依存しないように実装し直されました。新しい Motif DnD プロトコル実装と Motif ライブラリで提供されるプロトコル実装の違いのためにリグレッションが起きる可能性があります。ただし、Motif ライブラリの実装はバグが発生するため、新しい実装は少なくとも質において高く、サポートも比較的良いと考えられています。
詳細については、バグ 4638443 を参照してください。
Swing - カスタマイズされた背景色を持つボタンは、1.5 Java の見た目と使い心地がテーマである Ocean で意図されたように描画するためにはコード変更が必要となる場合があります。これは、デフォルトの設定では Ocean がボタンに明暗を付けるためです。明暗を付けたくない場合は、contentAreaFilled プロパティを true に設定するか、あるいは背景を UIResource でない Color に設定してください。ほとんどの場合、これは以下のように簡単です。button.setBackground(Color.RED);何らかの理由で UIResource を選択している場合には、次のように指定して UIResource 以外の新しい Color を作成できます。button.setBackground(new Color(oldColor));
詳細については、バグ 4908404 を参照してください。
Swing - JTree と JList では、ユーザーは常にキーボードを使用してリードインデックスを操作する必要がありました。たとえば、リードが JList 内で 4 行目 に存在する場合、上向きの矢印キーを押して 3 行目 にリードを移動させ、この行で項目を選択します。以上の操作で、これらのコンポーネントはリードをフォーカスされたインデックスと見なします。これらのコンポーネントは、その描画機能 (renderer) に情報を渡して特定のインデックスのフォーカスインジケータを描画するかどうかを示します。これは、そのインデックスがリードであるかどうかに基づいて行われます。
1.5 よりも前のリリースでは、JTable は逆の処理を行っていました。そして、JTree と JList がリードを使用するのと同じ方法でアンカーインデックスを使用していました。これを正す要求が RFE 番号 4759422 としてなされ、最終的に 4303294 の一環として修正されました。現在 JTable は、JList と JTree に対応したものとなっています。以前の動作を想定していた開発者は、この影響を受ける可能性があります。たとえば、フォーカスされたセルとして JTable で何が表示されているかという情報を必要とするアプリケーションの場合、アンカーが想定されます。1.5 以前ではこれは正しかったかもしれませんが、現在では、実際には他のインデックスがフォーカスを示す四角形を表示している時点で 1 つのインデックスがフォーカスされていると判断される可能性があります。
JVMDI - 1.5 では、Java Virtual Machine Debug Interface (JVMDI) は推奨されていません。JVMDI は、次のメジャーリリースよりサポートされなくなります。新しい開発では JVMTI を使用してください。既存のツールは JVMTI への移行を始めることをお勧めします。
詳細については、http://java.sun.com/j2se/1.5.0/ja/docs/ja/guide/jvmti/index.html にあるJVMTI の文書を参照してください。
JVMPI - 1.5 では、Java Virtual Machine Profiling Interface (JVMPI) は推奨されていません。JVMPI は次のメジャーリリースよりサポートされなくなります。新しい開発では JVMTI を使用してください。既存のツールは JVMTI への移行を始めることをお勧めします。
詳細については、http://java.sun.com/j2se/1.5.0/ja/docs/ja/guide/jvmti/index.html にあるJVMTI の文書を参照してください。