目次
このドキュメントでは、Java™ SE 6 と J2SE 5.0 の互換性について解説します。説明する内容は次のとおりです。
互換性に関する以下のドキュメントでは、隣接する Java バージョン間の互換性について説明しています。たとえばこれらのドキュメントに記載されているのは、Java SE 6 と J2SE 5.0 の非互換性だけです。それ以前のバージョンとの非互換性については記載されていません。J2SE 5.0 よりも前の Java バージョンと Java SE 6 の非互換性について調べるには、以下のファイルで順を追って確認していく必要があります。
Java Language Specification, Second Edition』(『JavaTM言語仕様』、James Gosling、Bill Joy、Guy Steele、Gilad Bracha 著、ピアソン・エデュケーション発行、2000) が出版されてから Java プログラミング言語の仕様に対して行われた変更の概要は、「Java Language Specification Maintenance Page」を参照してください。
後述の「Java SE Platform Standard Edition 6 における非互換性」で説明されている項目を除き、Java SE 6 は、J2SE 5.0 に対してバイナリレベルの上位互換性があります。互換性のないことが示されている機能を除き、バージョン 5.0 のコンパイラでビルドされたクラスファイルは、JDK 6 で正常に動作します。
初期の難読化ツールの中には、仮想マシンの仕様で規定されているクラスファイルの形式に違反するクラスファイルを生成するものがありました。そのような不適切な形式のクラスファイルは、旧バージョンの Java 仮想マシンでは動作する場合もありますが、JDK の仮想マシンでは動作しません。この問題を回避するには、適切な形式のクラスファイルを生成する新しい難読化ツールで、クラスファイルを生成し直してください。
Java SE 6 はソースの下位互換性をサポートしません。新しい言語機能または Java SE プラットフォーム API を使っているソースファイルは、旧バージョンの Java プラットフォームでは使用できません。
後述の「Java SE Platform Standard Edition 6 における非互換性」で説明されている項目を除き、一般的な原則は次のとおりです。
非推奨 API は、下位互換性のためだけにサポートされているメソッドやクラスです。非推奨 API を使った場合、コマンド行オプションで -nowarn を指定しないと、javac コンパイラが警告メッセージを出力します。現時点では、JVMDI および JVMPI の例外を除いて、非推奨 API をシステムから完全に削除する予定はありませんが、非推奨 API を使わないようにプログラムを修正することをお勧めします。
sun.* パッケージに含まれる API の中には、変更されているものがあります。このパッケージの API は、開発者用のものではありません。開発者が sun.* パッケージからインポートする場合は、各自の責任において行なってください。詳細は、開発者が sun.* パッケージを呼び出すプログラムを記述すべきでない理由を参照してください。
Java Platform、Standard Edition 6 と J2SE 5.0 の間の非互換性
Java SE 6 には、Java プラットフォームの旧バージョンとの高い互換性があります。このため、既存のプログラムの多くは Java SE 6 でもそのまま実行できます。ただし、非常にまれなケースですが、JRE と JDK のソースとバイナリの互換性が得られなくなる場合もあります。 ここでは補足として、このような特例について説明します。
- Java SE 6 で JVMDI が削除され JVMPI が無効になった
JVM™ TI は JSR-163 で定義されます。実装は J2SE 5.0 でリリースされました。JVM™ TI は JVMDI および JVMPI の機能性を置き換えます。JVMDI は J2SE 5.0 で非推奨になりました。JVMDI は Java SE 6 から削除されています。
JVMPI は J2SE 5.0 で非推奨になりました。JVMPI は Java SE 6 では無効にされており、次のリリースで削除される予定です。Java SE 6 で JVMPI を一時的に有効にする方法については、次の連絡先までお問い合わせください:jvmpi_eol@Sun.com
- Java SE 6 における新しい検証方式とその方式をサポートする新しいクラスファイル形式の導入
Java コンパイラ javac はデフォルトで、新しい検証方式に対応したクラスファイルを生成します (クラスファイルのバージョンは 50.0)。この新しいクラスファイルのバージョンは下位互換性を保つように設計されていますが、バイトコード操作ツールのベンダーは、新しいクラスファイル形式をサポートするように各自のツールを更新することが推奨されます。詳細については、次を参照してください:https://jdk.dev.java.net/verifier.html
-
java.nio.channels.FileLock クラスが、ほかの FileChannel インスタンスによってすでにロックされているファイルをチェックする
別の FileChannel インスタンスを通じてロックされた領域と重複する領域をアプリケーションがロックしようとした場合、Java SE 6 は OverlappingFileLockException をスローします。前のバージョンでは、ほかの FileChannel インスタンスによって取得されたファイルロックはチェックされませんでした。
java.nio.channels.FileChannel.lock メソッドはデフォルトで、要求されたロックが、この Java 仮想マシンによって保持される領域と重複するかどうかをチェックします。
Java SE 6 では、java.nio.channels.FileChannel.lock のファイルチェック動作を制御するためのシステムプロパティー sun.nio.ch.disableSystemWideOverlappingFileLockCheck が追加されました。
- このシステムプロパティーが設定される (または、
false 以外の値に設定される) 場合、java.nio.channels.FileChannel.lock は、この FileChannel インスタンスのみを使用して取得された、重複するファイルロックをチェックします。同じファイルに対してほかの FileChannel インスタンスによって獲得されたロックはチェックされません。
- このシステムプロパティーが設定されない (または、値
false に設定される) 場合、java.nio.channels.FileChannel.lock は仕様に従って、すべての FileChannel インスタンスからの重複するファイルロックをチェックします。
sun.nio.ch.disableSystemWideOverlappingFileLockCheck システムプロパティーは、J2SE 1.4 および 5.0 との互換性を確保するために用意されています。これらのリリースでは、JVM 全体を対象とした重複ファイルロックのチェックは実装されていません。
- Solaris およびその他の UNIX ベースのプラットフォームで、Java SE 6 はデフォルトで
sun.awt.x11.XToolkit を使用する
awt.toolkit プロパティーを sun.awt.motif.MToolkit に設定することにより、MToolkit を使用できます。
- Java SE 6 が適切に不正なキャストを拒絶する
キャストの実装がより忠実に Java 言語仕様に準拠するようになりました。これは一般に、javac がより多くのプログラムを許容することを意味します。ただしまれに、以前は許容されていた実際には不正なプログラムが、現在の javac によって拒絶される可能性があります。
- Java SE 6 の
rt.jar から非クラスファイルを削除
-Xbootclasspath:<rt.jar へのパス> を指定してリソースファイルを要求する Java アプリケーションがある場合、これらのリソースは現在では resources.jar という別の JAR ファイルに存在するため、そのような要求は失敗します。
java.beans.EventHandler が有効な引数を強制する
java.beans.EventHandler のドキュメントで、以下の記述がより完全になっています。
- 現在
EventHandler は有効な引数を強制しません。target、action、および listenerInterface の各引数は、正しく機能するためには NULL でない値である必要があります。Java SE 6 では、constructor および create メソッドがこれらの引数をチェックし、NULL の引数がある場合はただちに IllegalArgumentException をスローするようになりました。
- Java SE 6 では、
eventPropertyName に対して "" を指定すると、イベントがターゲットアクションに渡されます。
- Java SE 6 では、
eventPropertyName に関する仕様の記述がより完全になり、target/action/listenerInterface が NULL でない必要があるという注記が追加されました。
- Java SE 6 の仕様に、
create および constructor メソッドが NullPointerException をスローする可能性があるという注記が追加されました。
これらの変更により、NULL の target/action に関して、constructor および create があとからではなく即時に nullPointerException をスローすることが強制されます。例外のスローのタイミングは変更されましたが、例外自体は同じであり、コードロジックが例外をキャッチして適切に処理できるポイントでスローされます。
SpringLayout に対する制約の指定が順序に依存していた
SpringLayout は、コンポーネントのサイズと位置を決定する 3 つの Spring を各軸に沿って指定します。各軸に沿った 2 つの Spring だけが必要であり、3 番目は派生します。3 つの Spring が指定された場合、レイアウトの制約が多すぎるとみなされ、Spring のうち 1 つは削除されます。現時点では、削除する Spring を決定する動作は直観的ではなく、順序付けの問題を招きます。
Java SE 6 では、SpringLayout は Spring が設定された順序を維持します。結果として、Spring の指定は順序依存ではなくなりました。中央揃えおよび基準線に合わせた整列のサポートも追加されました。
この変更によって影響を受けるプログラムには、J2SE 5.0 で冗長であったステートメントが含まれる可能性があります。
次に例を示します。
constraints.setX(xSpring);
constraints.setConstraint("East", eastSpring);
J2SE 5.0 では、setX を呼び出しても何も起こりませんでした。Java SE 6 では、setX の呼び出しには意味があり、結果的に異なる動作が発生します。
- ダブルバッファリングの強化
現時点では、ウィンドウが unobscured されてから再描画されるまでの間にかなりの遅れが発生する可能性があります。
Java SE 6 では、Swing は完全なダブルバッファリングを提供します。Java SE 6 では各ウィンドウに対して、オンスクリーンウィンドウバッファーと同期を保つオフスクリーンバッファーが維持されます。ウィンドウがいつ unobsruced されても、Swing によって直接、バッファーから画面への逆コピーが行われます。Swing は JWindow、JDialog、JApplet、JFrame、および、Swing パッケージ内のその他の重量コンポーネントの再描画も管理します。この処理を管理するために、RepaintManager に新しいメソッドが追加されています。
expose イベント時の描画を実行するために Swing に依存できるアプリケーションが、この変更の影響を受ける可能性があります。Java SE 6 では、代わりに backbuffer から画面を更新できる場合、Swing クラスが expose イベントを描画しない場合があります。
- Java SE 6 のドラッグ動作は Microsoft Windows のドラッグ動作と一貫性がある
現在の Swing のドラッグ＆ドロップ実装では、ユーザーはまずオブジェクトをクリックして選択したあと、同じオブジェクトをもう一度クリックしないとドラッグ操作を開始できません。この動作は、オブジェクトの選択とドラッグ操作の開始を 1 回のクリックで済ませることに慣れたユーザーにとっては不便です。
Java SE 6 では、いくつかの Swing クラスが変更され、シングルクリックのドラッグモデルが実装されました。影響を受けるコンポーネントに関してはドキュメントが更新され、ドラッグジェスチャーがどのように認識されるかが説明されています。
この問題を解決するために、ドラッグ＆ドロップのサポート実装において、互換性を損なう可能性がある変更を若干行う必要がありました。ドラッグ操作のサポートが無効なコンポーネントについては、これらの非互換性は一切影響しません。ドラッグ操作のサポートはデフォルト設定では無効です。またこれらの非互換性は、ドラッグ操作のサポートを有効にしたほとんどのユーザーにも影響しません。
- MouseListener の統合
以前は、ドラッグに対応したコンポーネントの UI は 2 つのマウスリスナーをインストールしていました。一方のリスナーが選択変更の詳細を処理し、もう一方がドラッグジェスチャー認識の詳細を処理しました。ドラッグ＆ドロップ動作を変更するために、互いに独立したロジック間で必要な通信量が増加しました。ドラッグジェスチャーが選択変更を管理できるようにするには、これら 2 つのリスナーを 1 つのリスナーに統合することがベストでした。
この統合によって影響を受けるアプリケーションには、以下で説明する 2 つのケースが含まれます。
- 2 つのマウスリスナーが存在することを明示的に想定するアプリケーション。
- UI がインストールしたマウスリスナーを置き換える、カスタムの Look & Feel を実装するアプリケーション。カスタムの Look & Feel が UI の MouseListener を置き換える場合、ドラッグはサポートされなくなります。
JTable および JTree の編集セマンティクス
ドラッグに対応した JTable および JTree では、マウス解放イベントを受け取ってからでないと編集を受け付けません。以前は、特定の押下イベント (ドラッグジェスチャーの一部でないものなど) が編集をトリガーすることができました。一貫性のため、選択変更を可能にするため、そしてドラッグ＆ドロップが押下イベント時に正しく発生するようにするために、マウスが解放された時点ではじめて編集を開始できるようにしました。ドラッグを無効にすると、選択の動作は以前と同じようになります。
JTable および JTree エディタと shouldSelectCell()
JTable および JTree 用のエディタには、shouldSelectCell() という名前のブール型メソッドが含まれます。このメソッドは、現在のセルが選択されるべきかどうかを返します。このメソッドは編集開始時に呼び出されます。また、エディタを設定するために、編集が開始されたタイミングを特定するためにも使用できます。コンポーネントでドラッグが有効なとき、セルはそれを選択してからでないとドラッグできません。この理由から、Java SE 6 では shouldSelectCell を無視し、ドラッグが有効なときは常にセルを選択します。ただし、Java SE 6 では引き続き、メソッドの副次的効果を必要とするユーザーのために、編集開始後に shouldSelectCell を呼び出します。ドラッグが無効の場合、変更はありません。
-
JDK1_1InitArgs と JDK1_1AttachArgs について
JDK1_1InitArgs と JDK1_1AttachArgs のデータ構造はもう使用されていませんが、jni.h ファイルと、対応するドキュメントには存在しました。JDK1_1AttachArgs は jni.h から削除され、JDK1_1InitArgs は jni.h から jvm.h に移動されて内部的に使用されています。
- Java SE セキュリティツールでのパスワードの表示について
JDK ツールの keytool、jarsigner、kinit では、パスワードを画面に表示しません。ユーザーは、新しいパスワードを入力する場合や既存のパスワードを変更する場合にパスワードを二度入力する必要があります。keytool が新しいキーストアを作成するスクリプトや、キーストアパスワードから一意のパスワードを使用してキーストアに新しいキーを作成するスクリプトは変更する必要があります。
-
jar が抽出中にファイルの変更日時を保存
jar アーカイブから抽出されるファイルとディレクトリには、jar アーカイブの対応するファイル/ディレクトリのタイムスタンプと一致するタイムスタンプが設定されます。
Java SE 6 より前は、jar アーカイブから抽出されるファイルとディレクトリには抽出時の日時が設定されました。sun.tools.jar.useExtractionTime=true システムプロパティで、Java SE 5.0 以前の動作を実行できます。このプロパティのデフォルト値は Java SE で false になっています。
- Duration/
XMLGregorianCalendar equals() メソッドが null パラメータに false を返す
javax.xml.datatype.Duration.equals() と javax.xml.datatype.XMLGregorianCalendar.equals() メソッドは null パラメータに対して NullPointerException をスローするのではなく false を返します。
- ダブルスラッシュ文字 (「//」) が JMX ObjectNames で予約される
JSR 255 は「//」をカスケーディングの区切り文字として javax.management.ObjectName のドメイン部分で使用する予定です。JSR 255 は Java SE 6 に含まれませんが、将来的な問題を避けるため、ObjectName のドメイン部分に「//」を含めないことを推奨します。
| 
印刷用ページ
