JDKリリース・ノート一覧(US) JDK 8リリース・ノート
互換性は複雑な問題です。このドキュメントでは、このJavaプラットフォームのリリースに関連する次の3種類の潜在的な非互換性について説明します。
ソース:ソース互換性とは、コードのコンパイルが成功するかしないかなどを含む、Javaソース・コードのクラス・ファイルへの変換に関係します。
バイナリ:バイナリ互換性は、Java言語仕様で次のように定義されています。'型への変更が行われた場合に、以前にエラーなしでリンクされた既存のバイナリが引き続きエラーなしでリンクされれば、既存バイナリとのバイナリ互換性があります(つまり、既存バイナリとのバイナリ互換性は損なわれません)。'
動作:動作互換性は、実行時に実行されるコードのセマンティックなどの互換性です。
詳しくは、OpenJDK Developer's GuideのKinds of Compatibilityの項を参照してください。
以下の互換性に関するドキュメントには、隣接するJavaバージョン間の非互換性について記載されています。たとえば、この互換性のページには、Java SE 8のJava SE 7との非互換性のみが記載され、それより前のバージョンとの非互換性は記載されません。過去のJavaバージョンとのJava SE 8の非互換性を調査するには、以下のファイルをこの順で遡って非互換性を確認する必要があります。
Java SE 8には、このページの下部に示す非互換性を除き、Java SE 7とのバイナリ互換性があります。記載された非互換性を除けば、Java SE 7コンパイラによりビルドされたクラス・ファイルはJava SE 8で正常に実行されます。Java SE 8コンパイラでビルドされたクラス・ファイルは、以前のJava SEリリースでは実行できません。
Java SE 8には新しい言語機能やプラットフォームAPIが導入されています。これらの機能をソース・ファイル内で使用する場合、そのソース・ファイルを以前のバージョンのJavaプラットフォーム上でコンパイルすることはできません。
一般的には、ソース・コードの非互換性の発生を防ぐことを目的としたソース互換性の方針が採用されています。ただし、一部のJava SE 8機能の実装では変更が必要であり、それによってJava SE 7でコンパイルされたコードがJava SE 8でコンパイルできなくなる場合がありました。詳しくは、Java SE 8とJava SE 7の非互換性およびJDK 8とJDK 7の非互換性を参照してください。
廃止されたAPIとは、以前のリリースとの互換性を確保する目的でのみサポートされるインタフェースです。廃止されたAPIが使用されている場合は、javac
コンパイラにより警告メッセージが表示されます(-nowarn
コマンドライン・オプションを使用している場合を除く)。廃止されたAPIの使用箇所を削除するようにプログラムを修正することをお勧めします。
sun.*
パッケージの一部のAPIが変更されました。これらのAPIは、開発者によって使用されることが想定されていません。sun.*
パッケージからのインポートは、開発者の自己責任で行ってください。詳しくは、Why Developers Should Not Write Programs That Call 'sun' Packagesを参照してください。
廃止されたAPIの一覧については、廃止されたAPIを参照してください。
もっとも単純な形式の動作互換性は、ライブラリやプラットフォームのバージョンが異なっていても、プログラムに同じ入力を与えれば、同じ(または同等の)操作が実行されることを表します。プラットフォームの動作に関しては意図的に仕様が定められていない面もあり、プラットフォームの新しいリリースで基盤の実装が変更される場合があります。こうした理由から、仕様が定められていない動作に依存するようなコードを記述しないことが推奨されます。そのような動作に依存するコードを記述していなければ、プラットフォームでの非互換性は問題になりません。問題はコード内のバグということになります。
Java SE 8リリースでは、Javaクラス・ファイルの形式が更新されました。
JVM仕様にあるとおり、Java SE 8のクラス・ファイルのバージョンは52.0です。Java SE 8コンパイラによって生成されたバージョン52.0のクラス・ファイルを以前のJava SEリリースで使用することはできません。
以下のドキュメントに、Java言語仕様(JLS)およびJava VM仕様(JVMS)の変更点に関する情報が記載されています。
Java SE 8には、以前のバージョンのJavaプラットフォームとの強い互換性があります。ほぼすべての既存プログラムが、変更を加えずにJava SE 8で動作する見込みです。ただし、JREおよびJDKには、ごく稀な状況や一般的でない状況で細かい非互換性が発生する可能性があり、それらについて完全を期するためにこのページに記載しています。
この項では、Java言語、JVM、Java SE APIにおけるJava SE 8の非互換性について説明します。
このリリースでは一部のAPIが廃止され、一部の機能が完全に削除されています。これらのAPIや機能も非互換性と言えますが、これまで個別のリスト内で注意喚起されてきました。詳しくは、廃止されたAPIとJDK 8から削除された機能を参照してください。
invokespecial
命令がインスタンス初期化メソッド("<init>
")を参照する場合に、この命令の検証が厳密化されました。
動作
Java SE 8以降では、Java仮想マシンにより、すべてのクラス・ファイル内にACC_SUPER
フラグが(クラス・ファイル内のこのフラグの実際の値や、クラス・ファイルのバージョンが何であるかにかかわらず)設定されているものと見なされます。ACC_SUPER
フラグはinvokespecial
命令の動作に影響します。
動作
classes_text
DateFormat
およびSimpleDateFormat
を使用して日時の値の書式設定を行う場合に、月の名前の書式設定形式と独立形式を持つ言語については、状況に応じた月の名前がサポートされます。たとえば、チェコ語での1月に対する優先される月の名前は、書式設定形式ではledna、独立形式ではledenです。DateFormatSymbols
のgetMonthNames
メソッドとgetShortMonthNames
メソッドは、そのような言語の書式設定形式での月の名前を返します。DateFormatSymbols
により返される月の名前は、Java SE 7までは独立形式のものでした。Calendar.getDisplayName
メソッドおよびCalendar.getDisplayNames
メソッドを使用して、書式設定形式や独立形式を指定できます。詳しくは、APIドキュメントを参照してください。
動作
javax.lang.model
Java SE 8では、複数の境界を持つTypeVariable
のjavax.lang.model.type.TypeVariable.getUpperBound
の戻り値が、以前のリリースの戻り値とは異なります。新しく導入されたIntersectionType
のインスタンスが返されるようになります(元は、DeclaredType
のインスタンスが返されました)。この結果、javax.lang.model.util.TypeVisitor
の既存の実装の動作に変化が生じる可能性があります。以前は、複数の境界を持つ型変数のTypeVariable.getUpperBound
の戻り値に対してvisitDeclared
メソッドが呼び出されましたが、このリリースではvisitIntersection
が呼び出されるようになりました。この違いは、戻り値のgetKind()
のコール時にも観察できます。
動作
java.lang.reflect
public以外のインタフェースを実装するjava.lang.reflect.Proxy
クラスは、non-publicで、finalであり、abstractではありません。Java SE 8よりも前のリリースでは、このプロキシ・クラスはpublicで、finalであり、abstractではありませんでした。
ソース
既存のコードでProxy.getProxyClass
メソッドとConstructor.newInstance
メソッドを使用してプロキシ・インスタンスを作成している場合、public以外のプロキシ・インタフェースと同じランタイム・パッケージ内にコール元が存在しない場合に、IllegalAccessException
が発生してコンパイルに失敗します。そのようなコードでは、次のいずれかの方法でソースを変更する必要があります。(1) Constructor.setAccessible
をコールしてaccessibleフラグをtrueに設定します。(2) Proxy.newProxyInstance
という簡易版メソッドを利用します。
既存のコードで、異なるランタイム・パッケージにあるpublic以外のインタフェースを実装したプロキシを作成している場合は、新しく導入されるpermission ReflectPermission("newProxyInPackage.{package name}")
という権限を付与する必要があります。
java.lang.reflect
java.lang.reflect.Proxy(InvocationHandler h)
コンストラクタのInvocationHandler
パラメータがnullの場合に、NullPointerException
がスローされるようになりました。
動作
既存のコードでnullの引数を指定して動的プロキシ・インスタンスを作成している場合、NullPointerException
が発生するようになりました。nullのプロキシ・インスタンスは利用価値がなく、結局はそのインスタンスのメソッド呼出し時にNullPointerException
が発生するため、このような利用方法はほとんどないと見込まれます。
java.math
Java SE 8より前のバージョンでは、計算上0(ゼロ)に等しい値に対してBigDecimal.stripTrailingZeros
がコールされた場合に、その値自体が返されました。Java SE 8では、定数のBigDecimal.ZERO
が返されるようになります。
動作
java.net
以前のリリースでは、Digest認証実装のHttpURLConnection
で、WWW-Authenticateレスポンス・ヘッダー内の一部の値が誤って引用符で囲まれていました。Java SE 8リリースでは、これらの値が引用符で囲まれなくなります。これは、RFC 2617(HTTP Authentication: Basic and Digest Access Authentication)に厳密に従うことによる措置です。
一部のサーバー実装の特定のバージョンは、引用符で囲まれた値を想定することが知られています。そのようなサーバーへのHTTPリクエストの認証が成功しなくなる可能性があります。また、値が引用符で囲まれていたために以前は認証に失敗していたサーバー実装で、認証に成功するようになる可能性があります。
動作
java.net
このリリースでは、信頼できないコードを含むすべてのコードに割り当てられるデフォルトのソケット権限が変更されました。以前は、すべてのコードで1024以上の任意のポート番号に任意のソケット・タイプをバインドできました。Java SE 8リリースでも、各システムのエフェメラル・ポート範囲にソケットをバインドすることは可能です。正確なエフェメラル・ポート範囲はオペレーティング・システムによって異なりますが、通常は大きな値の範囲(49152~65535など)になります。新しい制約として、エフェメラル範囲外のポート番号にソケットをバインドするには、システム・セキュリティ・ポリシー内で明示的に権限を指定する必要があります。クライアントTCPソケットおよびセキュリティ・マネージャを使用するほとんどのアプリケーションでは、通常エフェメラル・ポートにバインドするため、問題は発生しません。一方、データグラム・ソケットまたはサーバーTCPソケット(およびセキュリティ・マネージャ)を使用するアプリケーションでは、以前には発生しなかったセキュリティ例外が発生する可能性があります。そのような例外が発生した場合は、リクエストされたポート番号が想定内の番号であるかどうかを確認し、この問題に当てはまる状況の場合は、ローカル・セキュリティ・ポリシーにソケット権限付与を追加することで問題を解決できます。
動作
java.net
Java SE 8よりも前のリリースでは、java.net.SocketAddress
引数を受け取るjava.net.DatagramPacket
コンストラクタに、java.net.SocketException
のスローに関する宣言が含まれていました。しかし、これらのコンストラクタが実際にこの例外をスローすることはありませんでした。Java SE 8リリースでは、これらのコンストラクタから、java.net.SocketException
のスローに関する宣言が削除されました。既存のコードでSocketException
またはそのスーパークラスのjava.io.IOException
を明示的に捕捉している場合は、この例外のcatchブロックを削除してからJava SE 8でコンパイルしてください。
ソース
java.util.i18n
LocaleServiceProvider
を選択するためのメカニズムが変更されました。LocaleServiceProvider
実装では、LocaleServiceProvider.isSupportedLocale
メソッドをオーバーライドすることで、特定のLocale
がサポートされるかどうかを判断できるようになりました。ただし、このメソッドをオーバーライドして厳密なロケール拡張チェックを実行する場合、ロケール・サービス・プロバイダをJDK 7から移行すると、既存のアプリケーションとの互換性の問題が発生する可能性があります。詳しくは、LocaleServiceProvider
クラスおよびisSupportedLocale
メソッドの説明を参照してください。
動作
java.awt
Java SE 8よりも前のリリースでは、キーストロークがAWTKeyStroke
型であることを確認するための手動のチェックが必要でした。Java SE 8では、このチェックが、Component.setFocusTraversalKeys()
メソッドおよびKeyboardFocusManager.setDefaultFocusTraversalKeys()
メソッド内の汎用チェックに置き換わりました。Object
がAWTKeyStroke
型でない場合は、ClassCastException
がスローされるようになりました。
動作
javax.net.ssl
オラクルのJSSEプロバイダでは、クライアントが初期化した再ネゴシエーションをサーバー・サイドで拒否するための新しいシステム・プロパティであるjdk.tls.rejectClientInitializedRenego
が定義されます。このシステム・プロパティがtrue
に設定されている場合、クライアントが初期化した再ネゴシエーションがサーバー・サイドで許可されず、受信側のクライアントが再ネゴシエーション・リクエストを初期化した場合に、サーバー・サイドで致命的なhandshake_failure
アラートが発生して失敗します。
動作
コマンドライン・フラグのPermSize
とMaxPermSize
が削除され、実行時には無視されます。コマンドラインで使用した場合に表示された以下の各フラグの警告が生成されます。
Java HotSpot(TM) Server VM warning: ignoring option PermSize=32m; support was removed in 8.0
Java HotSpot(TM) Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0
ソース
この項では、HotSpot内、またはJava SE API内のjavac
に関するJDK 8の非互換性について説明します。
このリリースでは一部のAPIが廃止され、一部の機能が完全に削除されています。これらのAPIや機能も非互換性と言えますが、これまで個別のリスト内で注意喚起されてきました。詳しくは、廃止されたAPIとJDK 8から削除された機能を参照してください。
java.lang
Windowsでユーザーのホーム・ディレクトリを判別するための手順が、Microsoftが推奨するアプローチに従うように変更されました。過去のWindowsエディションを使用する場合や、レジストリ設定または環境変数に別のディレクトリが設定されている場合に、この変更が観察される可能性があります。
動作
java.text
NumberFormat
クラスおよびDecimalFormat
クラスを使用する場合に、以前のバージョンのJDKでは、一般的でない一部のケースで丸め動作が誤っていました。この誤った動作は、丸めの基準となる中間の値に非常に近い値を指定してformat()
メソッドをコールした場合に、NumberFormat
型またはDecimalFormat
型のインスタンスのパターンによって指定された丸め位置が、その中間の値の位置とまったく等しいときに発生しました。その場合、誤って2回丸められたり、誤ってまったく丸められなかったりしました。
例として、推奨されるデフォルトのNumberFormatFormat
API形式を使用し、NumberFormat nf = java.text.NumberFormat.getInstance()
、nf.format(0.8055d)
の順でコードを記述した場合、この0.8055d
という値はコンピュータでは0.80549999999999999378275106209912337362766265869140625
として記録されます。この値をバイナリ形式で正確に表現することはできないためです。ここで、デフォルトの丸めルールは"half-even"であり、JDK 7でformat()
をコールした結果、"0.806
"という誤った結果が出力されます。コンピュータによってメモリに記録されている値が、中間の値よりも"小さい"ため、正しい結果は"0.805
"となります。
この新しい動作は、プログラマが選択した任意のパターン(デフォルト以外のパターン)で定義されたすべての丸め位置に対しても実装されます。
動作
java.util.collections
以前のリリースでは、Collection.removeAll(Collection)
およびretainAll(Collection)
の一部の実装で、コレクション自体が空の場合に特に通知することなくnullパラメータが無視されました。このリリースより、パラメータとしてnullが指定された場合は一貫してNullPointerException
がスローされます。
動作
java.management
仕様に定められている、管理インタフェースをpublicにしなければならないという要件が、強制的に適用されるようになります。
public以外のインタフェースが管理機能を公開することは許可されません。MBean
インタフェースおよびMXBean
インタフェースはすべてpublicにする必要があります。
以前の動作に戻してpublic以外の管理インタフェースを許可するには、システム・プロパティのjdk.jmx.mbeans.allowNonPublic
を使用してください。このプロパティは暫定的なものであり、今後のリリースで削除される予定です。
動作
java.awt
キーストローク内のObject
がAWTKeyStroke
でない場合に、java.awt.Component.setFocusTraversalKeys()
メソッドが(IllegalArgumentException
の代わりに)ClassCastException
をスローします。
動作
java.security
JDK 8の制限付きパッケージの一覧にcom.sun.media.sound
が追加されました。SecurityManagerの基で実行されるアプリケーションは、明示的な権限を付与しない限り、このパッケージ階層内のクラスにアクセスできなくなります。com.sun.media.sound
パッケージは、サポート対象外の内部的なパッケージであり、外部アプリケーションから使用されることは想定されていません。
ソース
JDK内部パッケージのcom.sun.corba.se
およびそのサブパッケージが制限付きパッケージの一覧に追加され、セキュリティ・マネージャとともに実行する場合に直接使用できなくなりました。
動作
javac
Java言語仕様(JLS)15.21の項に示されるバイナリ比較の型ルールがjavac
コマンドによって正しく適用されるようになりました。JDK 5リリース以降、javac
は、JLS 15.21に従えば不正な型付けであるObjectプリミティブの比較を行う一部のプログラムを許容していました。これらの比較が型エラーとして正しく識別されるようになりました。
動作
javac
このリリースより、パラメータとメソッドのアノテーションが合成ブリッジ・メソッドにコピーされるようになります。この修正は、以下のようなプログラムに影響があります。
@Target(value = {ElementType.PARAMETER}) @Retention(RetentionPolicy.RUNTIME) @interface ParamAnnotation {} @Target(value = {ElementType.METHOD}) @Retention(RetentionPolicy.RUNTIME) @interface MethodAnnotation {} abstract class T<A,B> { B m(A a){return null;} } class CovariantReturnType extends T<Integer, Integer> { @MethodAnnotation Integer m(@ParamAnnotation Integer i) { return i; } public class VisibilityChange extends CovariantReturnType {} }
生成される各ブリッジ・メソッドに対して、リダイレクト先のメソッドのアノテーションがすべて付きます。パラメータのアノテーションもコピーされます。この動作上の変更は、一部のアノテーション・プロセッサや、一般的にはアノテーションを利用するすべてのアプリケーションに影響を及ぼす可能性があります。
動作
javac
パラメータのアノテーションが、インナー・クラス用に自動生成されるコンストラクタに対してコピーされます。この修正は、以下のようなプログラムに影響があります。
@Target(value = {ElementType.PARAMETER}) @interface ParamAnnotation {} public class initParams { public initParams(@ParamAnnotation int i) {} public void m() { new initParams(2) {}; } }
この場合、m()
メソッド内で作成されるインナー・クラス用に生成されるコンストラクタには、アノテーション@ParamAnnotation
が付いたパラメータint i
があります。この動作上の変更は、一部のアノテーション・プロセッサや、アノテーションを利用するアプリケーションに影響を及ぼす可能性があります。
動作
javac
ドキュメントに記載されていないターゲット値の"1.4.1
"、"1.4.2
"、"jsr14
"がjavac
で認識されなくなりました。"1.4.1
"および"1.4.2
"のターゲットでは、"1.4
"よりも新しいコード生成イディオムが使用されていました。"-source 1.4 -target 1.5
"というオプションの組合せによって、これらの新しいイディオムが使用されますが、より新しいクラス・ファイル形式も出力されます。"jsr14
"オプションは、このプラットフォームに最初に総称型(ジェネリクス)が追加されたときの暫定のプライベート・オプションでした。現在は、総称型は1.5以降のターゲットを使用してコンパイルされます。
動作
javac
JDK 7で警告付きでコンパイルされた以下のコードは、JDK 8ではコンパイルに失敗します。
import java.util.List; class SampleClass { static class Baz<T> { public static List<Baz<Object>> sampleMethod(Baz<Object> param) { return null; } } private static void bar(Baz arg) { Baz element = Baz.sampleMethod(arg).get(0); } }
このコードをJDK 8でコンパイルすると、以下のエラーが発生します。
SampleClass.java:12: error:incompatible types:Object cannot be converted to Baz Baz element = Baz.sampleMethod(arg).get(0); Note:SampleClass.java uses unchecked or unsafe operations. Note:Recompile with -Xlint:unchecked for details. 1 error
この例では、サブタイピングによって適用可能になるsampleMethod(Baz<Object>)
メソッドにraw型が渡されます(JLS, Java SE 7 Editionの15.12.2.2の項を参照)。このメソッドが適用可能になるには、未チェックの変換が必要になるため、戻り型が消去されます(JLS, Java SE 7 Editionの15.12.2.6の項を参照)。この例の場合、sampleMethod(Baz<Object>)
の戻り型はjava.util.List<Baz<Object>>
ではなくjava.util.List
になるため、get(int)
の戻り型はObject
となりますが、ObjectはBaz
互換の代入ではありません。
詳しくは、java.netでの関連する電子メールのやり取りを参照してください。
ソース
JAXPのXalan拡張関数が変更され、SecurityManager
が存在する場合にそのデフォルト実装が常に使用されるようになりました。この変更は、DOM文書によって作成されるNodeSet
に影響します。変更前は、DOM実装はDOMファクトリのルックアップ・プロセスを通じてロケーティングされました。この変更により、SecurityManager
によって実行した場合に、このルックアップ・プロセスがスキップされ、デフォルトのDOM実装が使用されます。
この変更は、サード・パーティのDOM実装を使用するアプリケーションにのみ影響します。一般的には、NodeSet
構造は、JDKのデフォルト実装の構造と互換性を持つものと想定されます。
動作
JDK 8にはJAXP 1.6が付属するため、サービス・プロバイダの検索にjava.util.ServiceLoader
を使用することを命じた仕様上の更新が含まれます。JAXP関連のサービス・プロバイダは、常にjava.util.ServiceLoader
に定義されるプロセスの次に位置するようになります。この変更の結果、プロバイダ構成ファイルの配置方法が異なる(ServiceLoader
ではなくClassLoader
のgetXXX
メソッドを使用しているなど)JDK 7実装とは少し違いが生じる可能性があります。
したがって、独自のClassloader
を実装しているアプリケーションでは、互換性を維持するために、ClassLoader
のgetXXX
メソッドが一貫して実装されていることを確認してください。
StAX API(JSR 173)では、factoryId
をパラメータとして持つnewInstance
メソッドおよびnewFactory
メソッドが定義されていました。StAX仕様ではこのパラメータの値に関する制約がなかったため、任意の文字列を設定できました。JDK 8のJAXPのコンテキストにおける仕様変更に伴い、factoryId
がサービス構成ファイル名を示す場合(つまりシステム・プロパティ名ではない場合)、その値はベース・サービス・クラス名である必要があります。
動作
ClassLoader
パラメータがjavax.xml.stream factories
で無視されなくなりました。
javax.xml.stream
パッケージにはファクトリ・クラス(XMLEventFactory
、XMLOutputFactory
、XMLInputFactory
)が含まれ、これらのファクトリ・クラスには、factoryId
およびClassLoader
という2つのパラメータを受け取るnewFactory
メソッドが定義されています。JDK 7では、サービスの検索およびインスタンス化の際に、この第2パラメータ(ClassLoader
)が無視されました。JDK 8ではこのように無視されることがなくなります。詳しくは、これらのメソッドのJava APIドキュメントを参照してください。
動作
java.lang
Thread.stop(Throwable)
が無効化されました。
Thread.stop
メソッドは、リリース1.2以降廃止されています。Java SE 8では、このメソッドがUnsupportedOperationException
をスローするようになりました。
java.net
必要なプロトコル・ハンドラのリストからftpが削除されました。
ftp
はレガシーなプロトコルであり、かなり以前から、ファイル転送用のセキュアなプロトコル(例:sftp
)に置き換えられてきました。このリリースでは、存在が保証されるプロトコル・ハンドラのリストから、ftp
プロトコルが削除されました。実際にこのプロトコル・ハンドラが削除されるわけではなく、このプロトコルを使用するアプリケーションは引き続き動作しますが、そのプロトコルの存在が必須ではなくなりました。
java.security
鍵の長さは、公開鍵ベースの暗号化アルゴリズムの強度を規定する重要なセキュリティ・パラメータです。1024ビット未満のRSA鍵は脆弱だと見なされます。
この更新では、長さが1024ビット未満のRSA鍵を含む証明書がブロックされます。この制約は、Javaのセキュリティ・プロパティであるjdk.certpath.disabledAlgorithms
によって適用されます。この制約は、たとえばSunプロバイダやSunJSSEプロバイダなどの、このセキュリティ・プロパティを利用するプロバイダに影響します。jdk.certpath.disabledAlgorithms
というセキュリティ・プロパティは、TLSで使用される静的な鍵(X.509証明書の鍵)の利用も対象とします。
この鍵のサイズの制約によって、1024ビット未満のRSA鍵に基づいたX.509証明書を利用している場合に、証明書パスの構築と検証において互換性の問題が発生します。また、この鍵のサイズの制約は、X.509証明書を検証するJDKコンポーネント(署名付きJAR検証、SSL/TLS転送、HTTPS接続など)にも影響を及ぼします。
互換性の問題を防ぐためには、1024ビット未満のRSA鍵を含むX.509証明書を利用している場合に、より強力な鍵によって証明書を更新することが推奨されます。また、ユーザーの自己責任による回避策として、小さなサイズの鍵を許容するように鍵のサイズを制約するセキュリティ・プロパティ(jdk.certpath.disabledAlgorithms
)を調整することもできます。
動作
自動更新をオフにしたビルドが提供されなくなりました。
JREの自動更新を無効化するには、自動更新機能を無効化した上で、デプロイメント構成プロパティ・ファイルのdeployment.expiration.check.enabled
プロパティをfalse
に設定します。自動更新機能を無効化するには、Javaコントロール・パネルのUpdateタブでCheck for Updates Automaticallyのチェックをオフにします。deployment.expiration.check.enabled property
について詳しくは、Deployment Configuration File and Propertiesを参照してください。
クラス・データ共有ファイルが作成されなくなりました。
以前は、Solaris SVIDパッケージ・インストーラによってクラス・データ共有ファイルが作成されました。JDK 8では、32ビットのSolarisがサポートされなくなったため、クラス・データ共有ファイルがデフォルトで作成されません。クラス・データ共有を手動で作成するには、以下のコマンドを実行します。
$JAVA_HOME/bin/java -Xshare:dump
このコマンドの実行が完了すると、クラス・データ共有ファイルが$JAVA_HOME/jre/lib/server/{amd64,sparcv9}/classes.jsa
に作成されます。
従来のJavaプラグインが削除されました。
過去のJavaプラグイン(Java SE 6 Update 10より前に提供されたバージョン)がこのリリースから削除されました。
Java Quick Starterが削除されました。
Java Quick Starter(JQS)サービスがこのリリースから削除されました。
ActiveXブリッジが削除されました。
ActiveXブリッジがこのリリースから削除されました。
sun.jdbc.odbc
JDBC-ODBCブリッジが削除されました。
JDK 8以降、JDBC-ODBCブリッジがJDKに付属しなくなりました。JDBC-ODBCブリッジはこれまで常にサポート対象外の暫定的な製品と見なされてきており、一部のJDKバンドルでのみ提供され、JREには含まれていませんでした。JDBC-ODBCブリッジの代わりに、データベース・ベンダーが提供するJDBCドライバか、商用JDBCドライバを使用してください。
apt
apt
ツールが削除されました。
apt
ツール、およびcom.sun.mirror
パッケージに含まれる関連APIがこのリリースで削除されました。javac
ツールで利用できるオプションや、javax.annotation.processing
パッケージおよびjavax.lang.model
パッケージに含まれるAPIを使用して、アノテーションを処理してください。
java
32ビットSolarisが削除されました。
Solarisオペレーティング・システム版Javaの32ビット実装がこのリリースから削除されました。$JAVA_HOME/bin
と$JAVA_HOME/jre/bin
のディレクトリには64ビット・バイナリが含まれるようになります。暫定措置として、ISA(Instruction Specific Architecture)ディレクトリの$JAVA_HOME/bin/{sparcv9,amd64}
と$JAVA_HOME/jre/{sparcv9,amd64}
に、対応するバイナリを指し示すシンボリック・リンクが含まれます。これらのISAディレクトリはJDK9で削除される予定です。
インストール・パッケージのSUNWj8rt、SUNWj8dev、SUNWj8dmoには、以前は32ビット・バイナリが含まれていましたが、このリリースで64ビット・バイナリが含まれるようになりました。インストール・パッケージのSUNWj8rtx、SUNWj8dvx、SUNWj8dmxは削除されました。
64ビット・バイナリには、Java Web StartやJavaプラグインなどのデプロイメント・ツールは含まれていないため、デスクトップ統合が不要になります。
java.lang
SecurityManager.checkMemberAccess
メソッドが廃止されました。これは、深さが4のスタック・フレーム上のコール元に依存するエラーの発生しやすいメソッドでした。このJDK実装では、メンバーのアクセス権チェックを実行するためにSecurityManager.checkMemberAccess
メソッドがコールされなくなり、代わりに、SecurityManager.checkPermission
メソッドがコールされます。
オーバーライドされたバージョンはコールされないため、checkMemberAccess
メソッドをオーバーライドするカスタムのSecurityManager
実装が影響を受ける可能性があります。
java.lang
SecurityManager
checkTopLevelWindow
、checkSystemClipboardAccess
、checkAwtEventQueueAccess
checkPermission
java.rmi
RMI/JRMPからのHTTPプロキシ機能が廃止され、HTTPプロキシがデフォルトで無効化されます。
java.rmi
RMI(JRMP)から静的に生成されるスタブのサポートが廃止されました。
java.util.jar
Pack200.Packer
addPropertyChangeListener
、removePropertyChangeListener
これらのメソッドは、今後のJava SEリリースで削除される予定です。
パッカーの進行状況を監視するには、PROGRESS
プロパティの値をポーリングします。
java.util.jar
Pack200.Unpacker
addPropertyChangeListener
、removePropertyChangeListener
これらのメソッドは、今後のJava SEリリースで削除される予定です。
アンパッカーの進行状況を監視するには、PROGRESS
プロパティの値をポーリングします。
java.util.logging
LogManager
addPropertyChangeListener
、removePropertyChangeListener
これらのメソッドは、今後のJava SEリリースで削除される予定です。
com.sun.security.auth.callback
DialogCallbackHandler
javax.management
JSR-160仕様が更新され、IIOPトランスポートをサポートするためのRMIコネクタが不要になりました。オラクルのJDK 8では引き続きIIOPトランスポートがサポートされますが、このIIOPトランスポートのサポートは今後のJMX Remote APIの更新で削除される予定です。
javax.accessibility
javax.swing.JComponent.accessibleFocusHandler
java.awt.Component.AccessibleAWTComponent.accessibleAWTFocusHandler
Builder<T>
Builder<T>
インタフェースを実装するすべてのクラス。
オブジェクトを作成するための適切なコンストラクタやsetterを使用してください。
java.security
java.security.SecurityPermission
insertProvider.{provider name}
ターゲット名の今後の使用は推奨されません。java.security.Provider.getName
メソッドをオーバーライドして、名前の制約を回避することが可能であるためです。また、コードに対して、特定の名前のプロバイダ、または選択した任意の名前のプロバイダを挿入する権限を付与することにも、同等のリスクが伴います。
新しいinsertProvider
ターゲット名を使用してください。Security.addProvider
メソッドとinsertProviderAt
メソッドでは古い権限と新しい権限の両方がチェックされるため、既存のポリシー・ファイルとの互換性が維持されます。
以下のガベージ・コレクタの組合せが廃止されます。
DefNew + CMS
ParNew + SerialOld
Incremental CMS
対応するコマンドライン・オプションを利用すると警告メッセージが表示されます。これらのコマンドライン・オプションは利用しないことが推奨されます。これらのコマンドライン・オプションは、次以降のメジャー・リリースのいずれかで削除される予定です。
-Xincgc
オプションは廃止されました。
-XX:CMSIncrementalMode
オプションは廃止されました。このオプションはすべてのCMSIncremental
オプションにも影響を及ぼします。
-XX:+UseParNewGC
オプションは、-XX:+UseConcMarkSweepGC
も指定する場合を除いて無効化されました。
-XX:-UseParNewGC
オプションは、-XX:+UseConcMarkSweepGC
と組み合わせて使用する場合のみ無効化されました。
詳しくは、http://openjdk.java.net/jeps/173
を参照してください。
CMSのフォアグラウンド・コレクタは廃止されました。今後のリリースで削除される予定です。代わりに、G1または通常のCMSを使用してください。