Java.com

ダウンロード ヘルプ

印刷可能バージョン

Java 8リリースのハイライト


このトピックは、次に当てはまります。:
  • Javaバージョン: 8.0

このページでは、各Javaリリースでエンド・ユーザーに影響を与える変更をハイライトします。変更の詳細は、各リリースのリリース・ノートを参照してください。
» Javaリリース日


Java 8 Update 144 (8u144)

Release Highlights
  • IANA Data 2017b
    JDK 8u144 contains IANA time zone data version 2017b. For more information, refer to Timezone Data Versions in the JRE Software.
  • Bug Fix: java.util.zip.ZipFile.getEntry() now always returns the ZipEntry instance with a / ended entry name for directory entry
    java.util.zip.ZipEntry API doc specifies 'A directory entry is defined to be one whose name ends with a /'. However, in previous JDK releases, java.util.zip.ZipFile.getEntry(String entryName) may return a ZipEntry instance with an entry name that does not end with / for an existing zip directory entry when the passed in argument entryName does not end with a / and there is a matching zip directory entry with name entryName + / in the zip file. With this release, the name of the ZipEntry instance returned from java.util.zip.ZipFile.getEntry() always ends with / for any zip directory entry.
    To revert to the previous behavior, set the system property jdk.util.zip.ensureTrailingSlash to 'false'.

    This change was made in order to fix a regression introduced in JDK 8u141 when verifying signed JARs and has caused some WebStart applications to fail to load.
    See JDK-8184993
Java Expiration Date

The expiration date for 8u144 is October 17, 2017. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u144) on November 17, 2017. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version.

Bug Fixes

This release contains fixes for security vulnerabilities described in the Oracle Java SE Critical Patch Update Advisory. For a more complete list of the bug fixes included in this release, see the JDK 8u144 Bug Fixes page.

» 8u144 Release notes


Java 8 Update 141 (8u141)

リリースのハイライト
  • IANA Data 2017b
    JDK 8u141にはIANAタイム・ゾーン・データのバージョン2017bが含まれています。詳細は、JREソフトウェアのタイムゾーン・データ・バージョンを参照してください。
  • 証明書の変更: ルートCAに追加された新しいLet's Encrypt証明書
    新しいルート証明書が1つ追加されました:
    ISRG Root X1
    alias: letsencryptisrgx1
    DN: CN=ISRG Root X1, O=Internet Security Research Group, C=US

    JDK-8177539 (非公開)
  • JMX診断の改善
    com.sun.management.HotSpotDiagnostic::dumpHeap APIが変更され、指定したファイル名が'.hprof'接尾辞で終わらない場合にIllegalArgumentExceptionをスローするようになりました。'.hprof'拡張子で終わるファイル名を指定しない既存のアプリケーションは、IllegalArgumentExceptionで失敗します。その場合、アプリケーションで例外を処理するか、システム・プロパティ'jdk.management.heapdump.allowAnyFileSuffix'をtrueに設定して以前の動作に戻すかを選択できます。
    JDK-8176055 (非公開)
  • カスタムHostnameVerifierでSNI拡張が可能に
    旧リリースのJDK 8 Updateでは、カスタム・ホスト名検証を使用した場合に、TLS ClientHelloフェーズでServer Name Indication (SNI)拡張が送信されない場合がありました。この検証は、HttpsURLConnectionsetHostnameVerifier(HostnameVerifier v)メソッドで設定します。この修正により、サーバー名がClientHello本文で確実に送信されるようになりました。
    JDK-8144566を参照してください
  • WSDLファイルを処理する際のwsimportツールによるセキュア・チェックの厳密化
    Webサービス記述でのDTDの使用を禁止するようにwsimportツールが変更されました。具体的には次のとおりです:
    • ドキュメントでDOCTYPE宣言を使用することはできません
    • デフォルトでは外部一般エンティティは含まれません
    • デフォルトでは外部パラメータ・エンティティは含まれません
    • 外部DTDは完全に無視されます
    以前の動作に戻すには、次の手順に従います:
    • システム・プロパティcom.sun.xml.internal.ws.disableXmlSecurityをtrueに設定します
    • wsimportツールのコマンドライン・オプション–disableXmlSecurityを使用します
      注意: JDK 7およびJDK 6におけるwsimportのこのオプションのサポートは、7月のCPU後のパッチ・リリースによって提供されます

    JDK-8182054 (非公開)
  • アルゴリズム制約チェックの改善
    弱いアルゴリズムが最も脆弱になる状況で、その使用を制限する必要性を受けて、java.securityファイルでjdk.certpath.disabledAlgorithmsおよびjdk.jar.disabledAlgorithmsセキュリティ・プロパティを構成する際の機能が追加されました。

    jdk.certpath.disabledAlgorithms: certpathプロパティが最も大きく変更されています。これまでは2つの制約タイプに限られており、名前によってアルゴリズムを完全に無効にするか、証明書、証明書チェーンおよび証明書の署名をチェックする際の鍵サイズによってアルゴリズムを完全に無効にするしかありませんでした。そのため、構成は絶対的なものとなり、使用方法の柔軟性に欠けていました。新たに3つの制約が追加され、証明書の許可と拒否がより柔軟に行えるようになりました。

    'jdkCA'は、cacertsファイルに関して、証明書チェーンの終了をチェックします。'SHA1 jdkCA'の場合、次のようになります。証明書チェーン全体を通じてSHA1の使用がチェックされますが、チェーンが拒否されるためには、cacertsキーストア内のマーク済トラスト・アンカーで終了する必要があります。これは、トラスト・アンカーでSHA1の使用を信頼する独自のプライベートCAがあるが、パブリックCAによってアンカーされた証明書チェーンでSHA1が使用されるのを防ぐ必要がある場合に便利です。

    'denyAfter'は、指定した日付が現在の日付またはPKIXParameterの日付より前かどうかをチェックします。'SHA1 denyAfter 2018-01-01'の場合、2018年になるまでSHA1による証明書を使用できますが、その日付を過ぎると証明書は拒否されます。これは、最終期限をもってアルゴリズムを廃止しようとしている組織のポリシーとして使用できます。署名付きのJARファイルの場合、日付はTSAタイムスタンプと比較されます。日付はGMTで指定します。

    'usage'は、指定したアルゴリズムを指定した使用方法に対してチェックします。これは、特定のアルゴリズムをすべての使用方法に対して無効にするのは現実的でない場合に使用できます。指定できる使用方法は次の3つです:

    • 'TLSServer'は、サーバー認証がクライアントとして実行された場合に、TLSサーバーの証明書チェーン内のアルゴリズムを制限します。
    • 'TLSClient'は、クライアント認証がサーバーとして実行された場合に、TLSクライアントの証明書チェーン内のアルゴリズムを制限します。
    • 'SignedJAR'は、署名付きJARファイルの証明書内のアルゴリズムを制限します。使用方法のタイプに続けてキーワードを指定します。使用方法のタイプは空白で区切って複数指定できます。
      たとえば、'SHA1 usage TLSServer TLSClient'と指定すると、TLSServerおよびTLSClient操作に対してSHA1証明書が禁止されますが、SignedJarsは許可されます

    これらの制約はいずれも、組み合せて'&'で区切ると、特定のアルゴリズムを制約することができます。たとえば、マーク済のトラスト・アンカーで終了するSHA1証明書チェーンをTLSServer操作に対してのみ無効にする場合、制約は'SHA1 jdkCA & usage TLSServer'となります。

    jdk.jar.disabledAlgorithms: この.jarプロパティに、JARマニフェスト・アルゴリズムを制限する制約が1つ追加されました。

    'denyAfter'は、署名付きJARファイル内のマニフェスト・ダイジェスト・アルゴリズムに対するアルゴリズム制約をチェックします。制約に指定した日付が署名付きJARファイルのTSAタイムスタンプと比較されます。タイムスタンプがないか、タイムスタンプが指定した日付以降の場合、署名付きJARファイルは署名なしとして扱われます。タイムスタンプが指定した日付より前の場合、.jarは署名付きJARファイルとして機能します。2018年1月1日より後に署名されたJARファイルでSHA1を制限する構文は次のとおりです: 'SHA1 denyAfter 2018-01-01'。構文はcertpathプロパティの構文と同じですが、このプロパティでは証明書のチェックは実行されません。
    JDK-8176536を参照してください

Javaの有効期限

8u141の有効期限は、2017年10月17日です。セキュリティ上の脆弱性の修正を含む新しいリリースが入手可能になると、Javaの有効期限が切れます。Oracle Serverに到達できないシステムの場合、セカンダリ・メカニズムにより、このJRE(バージョン8u141)は2017年11月17日に有効期限が切れます。いずれかの条件(新規リリースが入手可能になるか、有効期限に到達する)が一致した場合、JREは新しいバージョンにアップデートするよう、追加の警告とリマインダを表示します。

Bug修正

このリリースには、Oracle Java SEクリティカル・パッチ・アップデート・アドバイザリに記載されたセキュリティの脆弱性に関する修正が含まれています。このリリースで行われたbug修正の一覧については、JDK 8u141のBug修正のページを参照してください。

» 8u141リリース・ノート

Java 8 Update 131 (8u131)

リリースのハイライト
  • IANAデータ2016j
    JDK 8u131には、IANAタイム・ゾーン・データのバージョン2016jが含まれています。詳細は、JREソフトウェアのタイムゾーン・データ・バージョンを参照してください。
  • Bug修正: 新規ウィンドウ順序付けモデルの導入
    OS Xプラットフォームでは、AWTフレームワークは固有サービスを使用して、ウィンドウの親子関係を実装していました。このため、特にマルチモニター環境で視覚的な悪影響がありました。このような手法のデメリットを排除するために、JDKレイヤーで完全に実装される新規のウィンドウ順序付けモデルが導入されました。主な原則を次に示します。
    • ウィンドウは、最も近くにある親ウィンドウの上に配置する必要があります。
    • ウィンドウにいくつかの子ウィンドウがある場合、すべての子ウィンドウは同じレイヤーに配置する必要があり、アクティブ・ウィンドウ・チェーンのウィンドウはその兄弟の上に順序付けする必要があります。
    • 順序付けは、アイコン化された状態のウィンドウに対して、またはアイコン化された状態への遷移が進行中の場合、実行しないでください。
    これらのルールは、現在フォーカスされているウィンドウを含むウィンドウ階層のすべてのフレームまたはダイアログに適用されます。JDK-8169589を参照してください
  • Bug修正: TLSハンドシェイクからのIllegalArgumentExceptionの修正
    最近のJDK-8173783の修正による問題が原因で、一部のTLSサーバーに問題が発生する可能性があります。問題は、TLSハンドシェイク・コードでスローされるIllegalArgumentExceptionによって発生します:

    java.lang.IllegalArgumentException: System property
    jdk.tls.namedGroups(null) contains no supported elliptic curves


    この問題は、サーバーに楕円曲線名の拡張機能フィールド(存在する場合)を処理するための楕円曲線暗号方式のサポートがない場合に発生する可能性があります。ユーザーはこのリリースにアップグレードするようアドバイスされます。JDK 7 Update以降のJDKファミリには、デフォルトで、楕円曲線暗号方式のサポートを提供するSunECセキュリティ・プロバイダが付属しています。セキュリティ・プロバイダを変更しないかぎり、これらのリリースは影響を受けません。JDK-8173783を参照してください
  • jdk.jar.disabledAlgorithmsセキュリティ・プロパティに追加されたMD5
    このJDKリリースでは、MD5で署名されたJARファイルの検証方法に対する新たな制限が導入されました。署名付きJARファイルがMD5を使用している場合、署名検証操作ではその署名は無視され、JARは署名されていないものとして扱われます。これは、署名付きJARファイルを使用する次のタイプのアプリケーションで発生する可能性があります:
    • アプレットまたはWeb Startアプリケーション
    • スタンドアロンまたはサーバー・アプリケーションで、SecurityManagerが有効な状態で実行され、JARのコード署名者に基づいて権限を付与するポリシー・ファイルを使用して構成されているもの。

    無効化されたアルゴリズムのリストは、java.securityファイルのセキュリティ・プロパティjdk.jar.disabledAlgorithmsで制御されます。このプロパティには、暗号を使用して署名されたJARファイルの無効化されたアルゴリズムと鍵サイズのリストが含まれています。

    JARファイルの署名に弱いアルゴリズムまたは鍵が使用されているかどうかを確認するには、このJDKに付属しているjarsignerバイナリを使用できます。弱いアルゴリズムまたは鍵で署名されたJARファイルに対して"jarsigner -verify"を実行すると、無効化されたアルゴリズムまたは鍵の詳細が出力されます。

    たとえば、test.jarという名前のJARファイルをチェックするには、次のコマンドを使用します:

    jarsigner -verify test.jar

    この例のファイルがMD5withRSAのような弱い署名アルゴリズムで署名されていた場合、出力は次のようになります:

    The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled. Re-run jarsigner with the -verbose option for more details.

    詳細オプションを使用すると、詳細を表示できます:

    jarsigner -verify -verbose test.jar

    出力は次のようになります:

    - Signed by "CN=weak_signer"
        Digest algorithm: MD5 (weak)
        Signature algorithm: MD5withRSA (weak), 512-bit key (weak)
      Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016
        Timestamp digest algorithm: SHA-256
        Timestamp signature algorithm: SHA256withRSA, 2048-bit key
    
    問題に対応するには、JARファイルをより強力なアルゴリズムまたは鍵サイズで署名しなおす必要があります。または、jdk.jar.disabledAlgorithmsセキュリティ・プロパティから該当する弱いアルゴリズムまたは鍵サイズを削除して制限を戻すことができます。ただし、この方法はお薦めしません。影響を受けるJARに署名しなおす前に、JARファイルから既存の署名を削除する必要があります。これは、次のようにzipユーティリティを使用して実行できます:

    zip -d test.jar 'META-INF/.SF' 'META-INF/.RSA' 'META-INF/*.DSA'

    署名付きJARおよび他のセキュリティ・コンポーネントに対して予定されている制限については、http://java.com/cryptoroadmapの「Oracle JRE and JDK Cryptographic Roadmap」を定期的に確認してください。JDK-8171121 (非公開)
  • HTTP SPNEGO接続のキャッシュを制御する新規システム・プロパティ。
    HTTP SPNEGO (ネゴシエーション/Kerberos)接続のキャッシュを制御するJDK実装固有のシステム・プロパティが新たに導入されました。HTTP SPNEGO接続のキャッシュは、デフォルトで有効な状態となるため、このプロパティを明示的に指定しない場合、動作の変更はありません。SPNEGOを使用して認証をネゴシエーションするHTTPサーバーへの接続で、そのサーバーとの接続および認証が成功した場合、認証情報がキャッシュされ、同じサーバーへのその後の接続で再利用されます。さらに、SPNEGOを使用するHTTPサーバーへの接続では、通常、基礎となる接続はキープ・アライブの状態になり、その後の同じサーバーへのリクエストで再利用されます。一部のアプリケーションでは、サーバーへの新規リクエストごとに新規の認証を強制するために、HTTP SPNEGO (ネゴシエーション/Kerberos)プロトコルのキャッシュをすべて無効化することが望ましい場合もあります。

    この変更に伴い、HTTP SPNEGO接続のキャッシュ・ポリシーの制御を可能にする新規システム・プロパティを提供しています。jdk.spnego.cacheが定義されていて、falseに評価される場合、HTTP SPNEGO接続のすべてのキャッシュが無効化されます。ただし、このシステム・プロパティをfalseに設定すると、望ましくない副次的影響がある可能性があります。
    • 新規リクエストごとに接続の再認証が必要となり、サーバーとの複数回の通信が発生するため、HTTP SPNEGO接続のパフォーマンスに重大な影響が及ぶ可能性があります。
    • 新規リクエストごとに、資格証明の取得が再度必要になる場合があり、透過認証が使用可能かどうか、およびグローバル・オーセンティケータの実装に応じて、新規リクエストごとに資格証明をユーザーに求めるポップアップが表示されることがあります。
    JDK-8170814 (非公開)
  • HTTP NTLM接続のキャッシュを制御する新規システム・プロパティ
    HTTP NTLM接続のキャッシュを制御するJDK実装固有のシステム・プロパティが新たに導入されました。HTTP NTLM接続のキャッシュは、デフォルトで有効な状態となるため、このプロパティを明示的に指定しない場合、動作の変更はありません。一部のプラットフォームでは、JDKのHTTP NTLM実装は、システム・ユーザーの資格証明がシステム・レベルで使用される透過認証をサポートできます。透過認証が使用不可の場合、または失敗した場合、JDKではグローバル・オーセンティケータからの資格証明の取得のみがサポートされます。そのサーバーへの接続が成功した場合、認証情報がキャッシュされ、同じサーバーへのその後の接続で再利用されます。さらに、HTTP NTLMサーバーへの接続では、通常、基礎となる接続はキープ・アライブの状態になり、その後の同じサーバーへのリクエストで再利用されます。一部のアプリケーションでは、サーバーへの新規リクエストごとに新規の認証を強制するために、HTTP NTLMプロトコルのキャッシュをすべて無効化することが望ましい場合もあります。

    この変更に伴い、HTTP NTLM接続のキャッシュ・ポリシーの制御を可能にする新規システム・プロパティを提供しています。jdk.ntlm.cacheが定義されていて、falseに評価される場合、HTTP NTLM接続のすべてのキャッシュが無効化されます。ただし、このシステム・プロパティをfalseに設定すると、望ましくない副次的影響がある可能性があります。
    • 新規リクエストごとに接続の再認証が必要となり、サーバーとの複数回の通信が発生するため、HTTP NTLM接続のパフォーマンスに重大な影響が及ぶ可能性があります。
    • 新規リクエストごとに、資格証明の取得が再度必要になる場合があり、透過認証が使用可能かどうか、およびグローバル・オーセンティケータの実装に応じて、新規リクエストごとに資格証明をユーザーに求めるポップアップが表示されることがあります。
    JDK-8163520 (非公開)
  • VisualVMの新規バージョン
    VisualVM 1.3.9は2016年10月4日にリリースされ(http://visualvm.github.io/relnotes.html)、8u131に統合されました。JDK-8167485を参照してください
Javaの有効期限

8u131の有効期限は、2017年7月18日です。セキュリティ上の脆弱性の修正を含む新しいリリースが入手可能になると、Javaの有効期限が切れます。Oracle Serverに到達できないシステムの場合、セカンダリ・メカニズムにより、このJRE(バージョン8u131)は2017年8月18日に有効期限が切れます。いずれかの条件(新規リリースが入手可能になるか、有効期限に到達する)が一致した場合、Javaは新しいバージョンにアップデートするよう、追加の警告とリマインダを表示します。

Bug修正

このリリースには、セキュリティの脆弱性に関する修正が含まれています。詳細は、Oracle Java SEクリティカル・パッチ・アップデート・アドバイザリを参照してください。このリリースで行われたbug修正の一覧については、JDK JDK 8u131のBug修正のページを参照してください。

» 8u131リリース・ノート


Java 8 Update 121 (8u121)

リリースのハイライト
  • IANA Data 2016i
    JDK 8u121にはIANAタイム・ゾーン・データのバージョン2016iが含まれています。詳細は、JREソフトウェアのタイムゾーン・データ・バージョンを参照してください。
  • Bug修正: OS X 10.12 SierraでテキストのTrackpadのスクロールが非常に速くなっています
    MouseWheelEvent.getWheelRotation()メソッドは、Mac OS Xで丸められたネイティブNSEvent deltaX/Yイベントを戻しました。最新のmacOS Sierra 10.12では非常に小さいNSEvent deltaX/Yの値が生成されるため、これらの値を丸めて合計すると、MouseWheelEvent.getWheelRotation()から戻される値は非常に大きくなります。JDK-8166591修正はNSEvent deltaX/Yを累積し、累積値がしきい値およびゼロ値を超える場合のみ、MouseWheelEvent.getWheelRotation()メソッドはゼロ以外の値を戻します。これはMouseWheelEvent.getWheelRotation()仕様に準拠しています: マウス・ホイールが回転した「クリック」の数を整数で戻します。マウスが高解像度のホイールをサポートしている場合、部分的な回転が発生することがあります。この場合、完全な「クリック」が累積されるまで、メソッドはゼロを戻します。厳密なホイール回転の値については、かわりにMouseWheelEvent.getPreciseWheelRotation()メソッドを使用します。JDK-8166591を参照してください
  • JDKにおけるECのデフォルト強度の向上
    EC暗号のデフォルト強度を高めるため、JDKの証明書パス処理(jdk.certpath.disabledAlgorithmsセキュリティ・プロパティによる)とSSL/TLS接続(jdk.tls.disabledAlgorithmsセキュリティ・プロパティによる)では224ビット未満のEC鍵が無効になっています。どうしても必要な場合は、セキュリティ・プロパティのこの制限をアプリケーションで更新して、小さい鍵サイズを許可することができます(例: "EC keySize < 192")。256ビット未満のEC曲線はJDKのSSL/TLS実装から削除されます。新しいシステム・プロパティjdk.tls.namedGroupsは、EC暗号スイート用の有効な名前付き曲線のリストを優先度の高い順に定義するものです。デフォルトの有効なEC曲線または曲線のプリファレンスをアプリケーションでカスタマイズする必要がある場合は、このシステム・プロパティを適宜更新してください。例:
        jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1"
    

    デフォルトの有効なEC曲線またはカスタマイズしたEC曲線はアルゴリズムの制約に従います。たとえば、カスタマイズしたEC曲線では、Javaセキュリティ・プロパティで定義された無効なEC鍵を再度有効にすることはできません。JDK-8148516を参照してください
  • javadocの新しい--allow-script-in-commentsオプション
    javadocツールでは、コマンドライン・オプション--allow-script-in-commentsが指定されている場合を除き、javadocドキュメントのコメントおよびコマンドライン・オプションに出現するJavaScriptコードがすべて拒否されるようになります。--allow-script-in-commentsオプションを指定すると、javadocツールではドキュメントのコメントおよびコマンドライン・オプション内のJavaScriptコードが保持されます。JavaScriptコードが見つかり、コマンドライン・オプションが設定されていない場合、javadocツールでエラーが発生します。
    JDK-8138725 (非公開)
  • XML署名の鍵の最小長を1024に増やします
    デフォルトで1024ビット未満のRSA鍵とDSA鍵は、デジタル署名でセキュアではなくなるため、これらを制限するようにXML署名実装のセキュアな検証モードが強化されます。また、jdk.xml.dsig.SecureValidationPolicyという名前の新しいセキュリティ・プロパティがjava.securityファイルに追加され、セキュアな検証モードが有効な場合に強化される様々な制限を制御するために使用できます。セキュアな検証モードを有効にするには、javax.xml.crypto.XMLCryptoContext.setPropertyメソッドでxml署名プロパティorg.jcp.xml.dsig.secureValidationをtrueに設定するか、SecurityManagerを使用したコードを実行します。XML署名が弱いRSA鍵またはDSA鍵を使用して生成または検証される場合、セキュアな検証が有効な場合、1024ビット未満のRSA鍵は禁止されていますまたはセキュアな検証が有効な場合、1024ビット未満のDSA鍵は禁止されていますというメッセージとともに、XMLSignatureExceptionがスローされます。
    JDK-8140353 (非公開)
  • DSA鍵が1024ビット未満の証明書を制限します
    1024ビット未満のDSA鍵は十分に強くないため、証明書パスの構築および検証で制限する必要があります。そのため、"DSA keySize < 1024"を"jdk.certpath.disabledAlgorithms"セキュリティ・プロパティに追加することによって、1024ビット未満のDSA鍵はデフォルトで非アクティブ化されます。アプリケーションでは、この制限をセキュリティ・プロパティ("jdk.certpath.disabledAlgorithms")で更新でき、実際に必要な場合は、より小さい鍵サイズ(たとえば"DSA keySize < 768")を許可します。JDK-8139565 (非公開)
  • DERエンコーディング解析コードにチェックが追加されます
    様々なエンコーディング・エラーを捕捉するために、DERエンコーディング解析コードにチェックが追加されます。また、構成済の不確定な長さのエンコーディングを含む署名により、解析中にIOExceptionが発生します。JDKデフォルト・プロバイダを使用して生成された署名はこの変更の影響を受けないことに注意してください。JDK-8168714 (非公開)
  • URLClassLoader.newInstanceの追加のアクセス制限
    java.net.URLClassLoader.newInstanceメソッドにより作成されたクラス・ローダーは、指定されたURLのリストからクラスをロードするために使用できます。呼出し元のコードに1つ以上のURLへのアクセス権がなく、アクセス可能なURLアーティファクトに必要なクラスが含まれていない場合、ClassNotFoundExceptionまたは類似のものがスローされます。以前は、SecurityExceptionはURLへのアクセスが拒否されたときにスローされていました。以前の動作に戻す必要がある場合、jdk.net.URLClassPath.disableRestrictedPermissionsシステム・プロパティを設定して、この変更を無効にすることができます。JDK-8151934 (非公開)
  • logging.propertiesの新しい構成可能プロパティjava.util.logging.FileHandler.maxLocks
    新しい"java.util.logging.FileHandler.maxLocks"構成可能プロパティがjava.util.logging.FileHandlerに追加されます。この新しいロギング・プロパティをロギング構成ファイルに定義して、FileHandlerが処理できる最大同時ログ・ファイル・ロック数を構成できるようになります。デフォルト値は100です。複数(101より多い)スタンドアロン・クライアント・アプリケーションがFileHandlerでJDKロギングAPIを同時に使用している高並列環境では、デフォルトの制限である100に達して、FileHandlerファイル・ロックの取得に失敗し、IO例外がスローされる原因となる可能性があります。このような場合、新しいロギング・プロパティを使用して、アプリケーションのデプロイ前に最大ロック数を増やすことができます。オーバーライドされない場合、maxLocksのデフォルト値(100)は変更されないままです。詳細は、java.util.logging.LogManagerおよびjava.util.logging.FileHandlerのAPIドキュメントを参照してください。JDK-8153955を参照してください
注意
JNDIリモート・クラスのロードに対する保護が改善されました

ネーミング・サービスおよびディレクトリ・サービスに格納されたJNDIオブジェクト・ファクトリを介したリモート・クラスのロードは、デフォルトで無効になっています。RMIレジストリまたはCOSネーミング・サービス・プロバイダによるリモート・クラスのロードを有効にするには、必要に応じて、次のシステム・プロパティを文字列"true"に設定します。

    com.sun.jndi.rmi.object.trustURLCodebase
    com.sun.jndi.cosnaming.object.trustURLCodebase

JDK-8158997 (非公開)

jarsigner -verbose -verifyは、jarの署名に使用されたアルゴリズムを出力します

jarsignerツールは、署名付きJARファイルの生成に使用されたアルゴリズムと鍵の詳細を表示するように強化され、アルゴリズムと鍵のいずれかが弱いとみなされるかどうかも示します。

具体的には、jarsigner -verify -verbose filename.jar"が呼び出されると、署名およびタイムスタンプ(存在する場合)の情報を示す別々のセクションが、署名付きJARファイル(様々な理由で署名されていないものとして扱われている場合でも)内に出力されます。使用されたアルゴリズムまたは鍵のいずれかが弱いとみなされる場合、セキュリティ・プロパティjdk.jar.disabledAlgorithmsで指定されているように、「(弱)」とラベル付けされます。

例:

- Signed by "CN=weak_signer"
   Digest algorithm: MD2 (weak) 
   Signature algorithm: MD2withRSA (weak), 512-bit key (weak)
 Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016
   Timestamp digest algorithm: SHA-256 
   Timestamp signature algorithm: SHA256withRSA, 2048-bit key 

JDK-8163304を参照してください

既知の問題
TLSハンドシェイクからのIllegalArgumentException

最近のJDK-8173783の修正による問題が原因で、一部のTLSサーバーに問題が発生する可能性があります。問題は、TLSハンドシェイク・コードでスローされるIllegalArgumentExceptionによって発生します。

java.lang.IllegalArgumentException: System property
jdk.tls.namedGroups(null) contains no supported elliptic curves

この問題は、サーバーに楕円曲線名の拡張機能フィールド(存在する場合)を処理するための楕円曲線暗号方式のサポートがない場合に発生する可能性があります。ユーザーはこのリリースにアップグレードするようアドバイスされます。JDK 7 Update以降のJDKファミリには、デフォルトで、楕円曲線暗号方式のサポートを提供するSunECセキュリティ・プロバイダが付属しています。セキュリティ・プロバイダを変更しないかぎり、これらのリリースは影響を受けません。JDK-8173783を参照してください

javapackagerおよびfx:deployは、JREではなくJDK全体をバンドルします

Mac用のJavaパッケージャには、JDK全体がアプリケーション・バンドルにバンドルされ、バンドルが大きくなりすぎるという既知のバグがあります。回避策として、バンドラ・オプション-Bruntimeを使用します。例: 目的のJREがバンドルするJavaAppletPlugin.pluginが現在のディレクトリにある-Bruntime=JavaAppletPlugin.pluginJDK-8166835を参照してください

UACをオフにした管理者以外のユーザーの場合、Javaインストールは失敗します

ユーザー・アクセス制御(UAC)を無効にした管理者以外のユーザーの場合、WindowsでのJavaインストールは、警告またはプロンプトを表示せずに失敗します。インストーラによって、%TEMP%ディレクトリ内のディレクトリjds<number>.tmpは残されます。
JDK-8161460 (非公開)

新機能
XML署名のセキュアな検証モードを構成するためのセキュリティ・プロパティの追加

jdk.xml.dsig.secureValidationPolicyという名前の新しいセキュリティ・プロパティが追加され、XML署名のセキュアな検証モードが有効な場合に強制される様々な制限を構成できます。java.security構成ファイルのこのプロパティのデフォルト値は次のとおりです。

jdk.xml.dsig.secureValidationPolicy=\
    disallowAlg http://www.w3.org/TR/1999/REC-xslt-19991116,\
    disallowAlg http://www.w3.org/2001/04/xmldsig-more#rsa-md5,\
    disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,\
    disallowAlg http://www.w3.org/2001/04/xmldsig-more#md5,\
    maxTransforms 5,\
    maxReferences 30,\
    disallowReferenceUriSchemes file http https,\
    noDuplicateIds,\
    noRetrievalMethodLoops

詳細は、java.securityファイルのプロパティの定義を参照してください。JDK-8151893を参照してください

シリアライズ・フィルタの構成

シリアライズ・フィルタリングは、セキュリティと堅牢性の両方を向上させるためにオブジェクト・シリアライズ・データの受信ストリームをフィルタできる新しいメカニズムを導入します。すべてのObjectInputStreamは、デシリアライズ中にストリーム・コンテンツにフィルタ(構成されている場合)を適用します。フィルタは、システム・プロパティまたは構成済のセキュリティ・プロパティを使用して設定されます。"jdk.serialFilter"の値のパターンは、JEP 290シリアライズ・フィルタリングおよび<JRE>/lib/security/java.securityで説明します。有効な場合、フィルタ・アクションは'java.io.serialization'ロガーに記録されます。JDK-8155760を参照してください

RMIの制約チェック改善

RMIレジストリおよび分散ガベージ・コレクションは、サービスの堅牢性を向上させるためにJEP 290シリアライズ・フィルタリングのメカニズムを使用します。RMIレジストリおよびDGCは、各サービスとともに使用される一般的なクラスに組込みホワイトリスト・フィルタを実装します。追加のフィルタ・パターンは、システム・プロパティまたはセキュリティ・プロパティを使用して構成できます。"sun.rmi.registry.registryFilter"と"sun.rmi.transport.dgcFilter"のプロパティ・パターン構文は、JEP 290および<JRE>/lib/security/java.securityで説明します。JDK-8156802 (非公開)

メカニズムを追加すると、デフォルト以外のルートCAでアルゴリズムの制限の対象にならないようにすることができます

java.securityファイルでは、"jdkCA"という名前の追加の制約がjdk.certpath.disabledAlgorithmsプロパティに追加されます。この制約では、lib/security/cacertsキーストア内のマーク済トラスト・アンカーで終了する証明書チェーンでアルゴリズムを使用する場合にのみ、指定したアルゴリズムを禁止します。jdkCA制約が設定されていない場合、指定したアルゴリズムを使用するすべてのチェーンが制約を受けます。jdkCAを使用できるのは、DisabledAlgorithm式で1回のみです。例: この制約をSHA-1証明書に適用するには、SHA1 jdkCAを含めます。
JDK-8140422を参照してください

Javaの有効期限

8u121の有効期限は、2017年4月18日です。セキュリティ上の脆弱性の修正を含む新しいリリースが入手可能になると、Javaの有効期限が切れます。Oracle Serverに到達できないシステムの場合、セカンダリ・メカニズムにより、このJRE(バージョン8u121)は2017年5月18日に有効期限が切れます。いずれかの条件(新規リリースが入手可能になるか、有効期限に到達する)が一致した場合、Javaは新しいバージョンにアップデートするよう、追加の警告とリマインダを表示します。

Bug修正

このリリースには、セキュリティの脆弱性に関する修正が含まれています。詳細は、Oracle Java SEクリティカル・パッチ・アップデート・アドバイザリを参照してください。このリリースで行われたbug修正の一覧については、JDK 8u121のBug修正のページを参照してください。

» 8u121リリース・ノート


Java 8 Update 111 (8u111)

リリースのハイライト
  • IANA Data 2016f
    JDK 8u111にはIANAタイム・ゾーン・データのバージョン2016fが含まれています。詳細は、JREソフトウェアのタイムゾーン・データ・バージョンを参照してください。JDK-8159684を参照してください。
  • 証明書の変更: 新しいJCEコード署名ルートCA
    より長いキー長とより強力な署名アルゴリズムをサポートするために、新しいJCEプロバイダ・コード署名ルート認証局が作成され、その証明書がOracle JDKに追加されました。このCAから発行された新しいJCEプロバイダ・コード署名証明書が、これ以降JCEプロバイダの署名に使用されます。デフォルトでは、JCEプロバイダ・コード署名証明書の新しいリクエストはこのCAから発行されます。

    現在のJCEプロバイダ・コード署名ルートからの既存の証明書は引き続き有効です。ただし、このルートCAは将来のある時点で無効化される可能性があります。新しい証明書をリクエストして既存のプロバイダJARを署名しなおすことをお薦めします。JCEプロバイダ署名プロセスの詳細は、Java暗号化アーキテクチャでのプロバイダの実装方法のドキュメントを参照してください。JDK-8141340 (非公開)
  • サービス・メニュー・サービス
    特定のプラットフォームにおいてAWTメニュー・コンポーネントのライフサイクル管理に問題があることが判明しています。この修正により、メニューとそのコンテナの間の状態の同期が改善されました。JDK-8158993 (非公開)
  • HTTPSトンネリングのBasic認証の無効化
    一部の環境で、HTTPSプロキシ時に特定の認証スキームが不適切である場合があります。そのため、Basic認証スキームは、デフォルトではOracle Java Runtimeでjdk.http.auth.tunneling.disabledSchemesネットワーク・プロパティにBasicを追加することで非アクティブ化されています。HTTPSのトンネルの設定時にBasic認証を必要とするプロキシは、デフォルトでは成功しないようになりました。必要な場合、jdk.http.auth.tunneling.disabledSchemesネットワーク・プロパティからBasicを削除するか、コマンド行で同じ名前のシステム・プロパティを"" (空)に設定することで、この認証スキームを再度アクティブ化できます。また、jdk.http.auth.tunneling.disabledSchemesおよびjdk.http.auth.proxying.disabledSchemesネットワーク・プロパティと同じ名前のシステム・プロパティは、それぞれHTTPSのトンネルの設定時またはプレーンなHTTPのプロキシ時に、アクティブ化されている可能性があるその他の認証スキームを無効化するために使用できます。JDK-8160838 (非公開)
  • 弱いアルゴリズムと鍵で署名された制限JAR
    このJDKリリースでは署名付きJARファイルが検証される方法について新しい制限が導入されました。署名付きJARファイルが無効化されたアルゴリズムまたは最小長より小さい鍵サイズを使用している場合、署名検証操作ではその署名は無視され、JARファイルは署名されていないものとして扱われます。これは、署名付きJARファイルを使用する次のタイプのアプリケーションで発生する可能性があります:
    1.アプレットまたはWeb Startアプリケーション
    2.スタンドアロンまたはサーバー・アプリケーションで、SecurityManagerが有効な状態で実行され、JARのコード署名者に基づいて権限を付与するポリシー・ファイルを使用して構成されているもの。

    無効化されたアルゴリズムのリストは、java.securityファイルの新しいセキュリティ・プロパティjdk.jar.disabledAlgorithmsで制御されます。このプロパティには、暗号で署名されたJARファイルの無効化されたアルゴリズムおよび鍵サイズのリストが含まれています。

    このリリースでは、次のアルゴリズムと鍵サイズが制限されています:
    1. MD2 (ダイジェスト・アルゴリズムまたは署名アルゴリズム)
    2. 1024ビットより小さいRSA鍵
    注意: 署名付きJARのMD5ベースの署名は、2017年4月のCPUで制限される予定です。

    JARファイルの署名に弱いアルゴリズムまたは鍵が使用されているかどうかを確認するには、このJDKに付属しているjarsignerバイナリを使用できます。弱いアルゴリズムまたは鍵で署名されたJARファイルに対してjarsigner -verify -J-Djava.security.debug=jarを実行すると、無効化されたアルゴリズムまたは鍵の詳細が出力されます。

    たとえば、test.jarという名前のJARファイルをチェックするには、次のコマンドを使用します:
    jarsigner -verify -J-Djava.security.debug=jar test.jar

    この例のファイルがMD2withRSAのような弱い署名アルゴリズムで署名されていた場合、出力は次のように表示されます:
    jar: beginEntry META-INF/my_sig.RSA
    jar: processEntry: processing block
    jar: processEntry caught: java.security.SignatureException: Signature check failed. Disabled algorithm used: MD2withRSA
    jar: done with meta!

    更新されたjarsignerコマンドは、次の警告を標準出力に出力して終了します:
    "署名は解析または検証できません。jarは署名されていないものとして扱われます。jarは現在無効化されている弱いアルゴリズムで署名されている可能性があります。詳細は、デバッグを有効にして(-J-Djava.security.debug=jar)、jarsignerを再度実行してください"

    問題に対応するには、JARファイルをより強力なアルゴリズムまたは鍵サイズで署名しなおす必要があります。または、jdk.jar.disabledAlgorithmsセキュリティ・プロパティから該当する弱いアルゴリズムまたは鍵サイズを削除して制限を戻すことができます。ただし、この方法はお薦めしません。影響を受けるJARファイルに署名しなおす前に、JARから既存の署名を削除する必要があります。これは、次のようにzipユーティリティを使用して実行できます:

    zip -d test.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*.DSA'

    署名付きJARファイルおよび他のセキュリティ・コンポーネントに対して予定されている制限については、http://java.com/cryptoroadmap「Oracle JRE and JDK Cryptographic Roadmap」を定期的に確認してください。特に、現在の予定として、署名付きJARファイルのMD5ベースの署名は、2017年4月のCPUで制限されることに注意してください。

    JARがMD5で署名されているかどうかをテストするには、jdk.jar.disabledAlgorithmsセキュリティ・プロパティにMD5を追加してから(例:

    jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024)

    前の説明に従ってJARファイルにjarsigner -verify -J-Djava.security.debug=jarを実行します。
    JDK-8155973 (非公開)
  • デプロイメント・オーセンティケータ・ダイアログに追加された警告メッセージ
    プロキシの使用時またはSSL/TLSプロトコルの未使用時にHTTP Basic認証(資格証明が暗号化されずに送信される)を使用している場合の警告がプラグイン認証ダイアログに追加されました:
    "警告: Basic認証スキームでは、資格証明が事実上クリア・テキストで転送されます。実行しますか。"
    JDK-8161647 (非公開)
既知の問題
一部のイベントはWindowsのJFR記録で使用できません
次のイベントは、リリース8u111では、WindowsのJFR記録で使用できません:
  1. hotspot/jvm/os/processor/cpu_load
  2. os/processor/context_switch_rate

これは、JDK-8162419の変更が含まれる8u111で導入されたJDK-8063089のリグレッションに起因します。JDK-8063089の修正は、8u111リリースに含めることができませんでした。これは、次回の8u111 BPRビルドおよび次回の公開リリースで使用可能になる予定です。
JDK-8063089 (非公開)

macOS Sierra 10.12で、JVMによりNullPointerExceptionsがスローされる

macOS Sierra 10.12で、アプレットをブラウザで実行中にユーザーが修飾子キー(コマンド、Shift、Altなど)を押すと、「内部エラー」というエラー・ボックスが表示される場合があります。macOS Dockに「実行」アイコンも表示されます。ユーザーはアプレットを終了するか、修飾子キーを押さずにアプレットの再実行を試行することができます。JDK-8165867を参照してください。

Javaの有効期限

8u111の有効期限は、2017年1月17日です。セキュリティ上の脆弱性の修正を含む新しいリリースが入手可能になると、Javaの有効期限が切れます。Oracle Serverに到達できないシステムの場合、セカンダリ・メカニズムにより、このJRE(バージョン8u111)は2017年2月17日に有効期限が切れます。いずれかの条件(新規リリースが入手可能になるか、有効期限に到達する)が一致した場合、Javaは新しいバージョンにアップデートするよう、追加の警告とリマインダを表示します。

Bug修正

このリリースには、セキュリティの脆弱性に関する修正が含まれています。詳細は、Oracle Java SEクリティカル・パッチ・アップデート・アドバイザリを参照してください。このリリースで行われたbug修正の一覧については、JDK 8u111のBug修正のページを参照してください。

» 8u111リリース・ノート


Java 8 Update 101 (8u101)

リリースのハイライト
  • IANA Data 2016d
    JDK 8u101にはIANAタイム・ゾーン・データのバージョン2016dが含まれています。詳細は、JREソフトウェアのタイムゾーン・データ・バージョンを参照してください。JDK-8151876を参照してください。
  • 証明書の変更
    新しいDTrust証明書がルートCAに追加されました
    新しい2つのルート証明書が追加されました。
    • D-TRUST Root Class 3 CA 2 2009
      alias: dtrustclass3ca2
      DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE
    • D-TRUST Root Class 3 CA 2 EV 2009
      alias: dtrustclass3ca2ev
      DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE
    JDK-8153080を参照してください

    新しいIden証明書がルートCAに追加されました
    新しい3つのルート証明書が追加されました。
    • IdenTrust Public Sector Root CA 1
      alias: identrustpublicca
      DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US
    • IdenTrust Commercial Root CA 1
      alias: identrustcommercial
      DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US
    • IdenTrust DST Root CA X3
      alias: identrustdstx3
      DN: CN=DST Root CA X3, O=Digital Signature Trust Co.
    JDK-8154757を参照してください

    ComodoルートCAが削除されました
    Comodo "UTN - DATACorp SGC"ルートCA証明書がcacertsファイルから削除されました。JDK-8141540を参照してください

    Sonera Class1 CAが削除されました
    "Sonera Class1 CA"ルートCA証明書がcacertsファイルから削除されました。JDK-8141276を参照してください。
  • javax.rmi.CORBA.ValueHandlerへのアクセス制御が向上する
    javax.rmi.CORBA.Utilクラスは、stubおよびtieによって共通操作の実行に使用できるメソッドを提供します。これはValueHandlerのファクトリとしても機能します。javax.rmi.CORBA.ValueHandlerインタフェースは、GIOPストリームに対する値タイプの読取りおよび書込みをサポートするサービスを提供します。これらのユーティリティのセキュリティ認識が、java.io.SerializablePermission("enableCustomValueHanlder")での権限の導入によって強化されました。これは、javax.rmi.CORBA.Utilおよびjavax.rmi.CORBA.ValueHandlerの各APIのユーザー間の信頼関係の確立に使用されます。

    必要な権限は、"enableCustomValueHanlder" SerializablePermissionです。SecurityManagerがインストールされているが新しい権限のないサード・パーティのコードは、Util.createValueHandler()の呼出し時にAccessControlExceptionで失敗します。

    JDK8uおよびそれ以前のリリースでは、システム・プロパティ"jdk.rmi.CORBA.allowCustomValueHandler"を定義すると、権限チェックの動作をオーバーライドできます。

    したがって、javax.rmi.CORBA.Util.createValueHandlerを明示的に呼び出す外部アプリケーションは、SecurityManagerがインストールされており、次の2つの要件のいずれも満たしていない場合に、機能するための構成変更を要求します。
    1. java.io.SerializablePermission("enableCustomValueHanlder")はSecurityManagerによって付与されません。
    2. JDK8uおよびそれ以前のリリースで実行中のアプリケーションの場合、システム・プロパティの"jdk.rmi.CORBA.allowCustomValueHandler"は定義されていないか、"false" (大/小文字を区別しない)と同等に定義されているかのいずれかです。

    "enableCustomValueHanlder"のスペルミスは2016年10月のリリースで修正されることに注意してください。それ以降のJDKリリースでは、"enableCustomValueHandler"が正しいSerializationPermissionになりますので、これを使用します。
    JDK-8079718 (非公開)
  • タイムスタンプ・ハッシュ・アルゴリズムを指定するためのサポートがjarsignerに追加される
    TSAサーバーに送信されるメッセージ・インプリントの生成に使用されるメッセージ・ダイジェスト・アルゴリズムを指定するため、新規の-tsadigestalgオプションがjarsignerに追加されています。JDKの旧リリースで、使用されていたメッセージ・ダイジェスト・アルゴリズムはSHA-1でした。この新規オプションが指定されない場合、SHA-256がJDK 7 Updateおよびそれ以降のJDKファミリ・バージョンで使用されます。JDK 6 Updateでは、SHA-1がデフォルトのままですが、標準出力ストリームに警告が出力されます。JDK-8038837を参照してください
  • MSCAPIキーストアは同じ名前の証明書を処理できます
    Java SEキーストアでは、同じ別名を持つ証明書は許可されません。ただし、Windowsでは、1つのキーストアに格納されている複数の証明書に、一意ではないわかりやすい名前を付けることができます。JDK-6483657の修正では、Java APIを介して、表示される別名を人為的に一意にすることで、このような一意ではない名前が付いた証明書での運用が可能になります。この修正は、Java APIにより同じ名前の証明書の作成を可能にするものではないことに注意してください。サード・パーティ・ツールによってキーストアに追加された同じ名前の証明書の処理を可能にするだけです。これまでどおり、設計においては同じ名前の証明書を複数使用しないことをお薦めします。特に、次の文はJavaドキュメントから削除されません。
    "問題を回避するには、大/小文字のみが異なる別名をキーストアで使用しないことをお薦めします。"
    JDK-6483657を参照してください。
  • デプロイメント・ツールキットAPIメソッドによってJREが今後インストールされない
    デプロイメント・ツールキットAPIの、deployJava.jsからのinstallLatestJRE()メソッドおよびinstallJRE(requestedVersion)メソッドと、dtjava.jsからのinstall()メソッドでは、今後、JREがインストールされなくなります。ユーザーのJavaバージョンがセキュリティ・ベースラインを下回る場合、更新されたJREを取得するようにユーザーはjava.comにリダイレクトされます。JDK-8148310 (非公開)
  • DomainCombinerはProtectionDomainオブジェクトの統合時に静的ProtectionDomainオブジェクト用のランタイム・ポリシーを今後想定しない
    不十分な権限セットで静的ProtectionDomainオブジェクト(2引数コンストラクタを使用して作成される)を使用しているアプリケーションは、この修正によって今後、AccessControlExceptionを生じる可能性があります。現行ポリシーによってその権限セットが拡大される動的オブジェクト(4引数コンストラクタを使用)で静的ProtectionDomainオブジェクトを置き換えるか、すべての必要な権限を使用して静的ProtectionDomainオブジェクトを構築する必要があります。JDK-8147771 (非公開)
既知の問題
静的クラスIDを使用している場合、JRE 8u101がInternet Explorer (IE)によって認識されません

JRE 8u101の使用中に静的クラスIDを使用してアプレットまたはWeb Startアプリケーションを起動すると、最新のJRE (JRE 8u101)をインストールし使用していても、最新のJREを使用するか起動を取り消すかを尋ねる不要なダイアログ・ボックスがユーザーに表示されます。この特定のケースは、WindowsおよびIEでのみ発生します。

http://www.oracle.com/technetwork/java/javase/family-clsid-140615.htmlにより、JREバージョンの選択に対する静的クラスIDの使用を推奨していません(JDK 5u6、2005年12月以降)。

この問題を回避するために、ユーザーは次の2つの方法のいずれかを実行できます。
  • 最新バージョン(8u101)での起動を押し、警告を無視します。
  • JRE 8u101ではなくJRE 8u102をインストールして、この問題が発生しないようにします。
この問題に対処するために、開発者は次の2つの方法のいずれかを実行できます。
  • 静的クラスIDではなく動的クラスIDを使用します。
  • HTMLアプレットを使用している場合はjava_versionを、JNLPを使用している場合はJNLPディスクリプタを使用します。
JDK-8147457 (非公開)

Javaの有効期限

8u101の有効期限は、2016年10月19日です。セキュリティ上の脆弱性の修正を含む新しいリリースが入手可能になると、Javaの有効期限が切れます。Oracle Serverに到達できないシステムの場合、セカンダリ・メカニズムにより、このJRE(バージョン8u101)は2016年11月19日に有効期限が切れます。いずれかの条件(新規リリースが入手可能になるか、有効期限に到達する)が一致した場合、Javaは新しいバージョンにアップデートするよう、追加の警告とリマインダを表示します。

Bug修正

このリリースには、セキュリティの脆弱性に関する修正が含まれています。詳細は、Oracle Java SEクリティカル・パッチ・アップデート・アドバイザリを参照してください。このリリースで行われたbug修正の一覧については、JDK 8u101のBug修正のページを参照してください。

» 8u101リリース・ノート


Java 8 Update 91 (8u91)

リリースのハイライト
  • IANA Data 2016a
    JDK 8u91にはIANAタイム・ゾーン・データのバージョン2016aが含まれています。詳細は、JREソフトウェアのタイムゾーン・データ・バージョンを参照してください。
  • Bug修正: アプレット起動時間のリグレッションが修正されました
    JDK-8080977でアプレット起動時に遅延が発生するようになりました。遅延が発生するのはIEのみで、時間は約20秒です。この遅延はJDK-8136759で解消されました。JDK-8136759を参照してください
  • Bug修正: DSA署名の生成が鍵の強度チェックの対象になりました
    署名の生成では、ダイジェスト・アルゴリズムのセキュリティ強度が署名に使用された鍵のセキュリティ強度より弱い場合(SHA1withDSA署名による(2048、256)ビットのDSA鍵の使用など)は、操作が失敗し、次のエラー・メッセージが表示されます: 「SHA1ダイジェスト・アルゴリズムのセキュリティ強度が、この鍵サイズに対して十分ではありません。」JDK-8138593 (非公開)
  • Bug修正: Firefox 42のライブ接続の問題
    ブラウザがハングする可能性があるため、Javaプラグインをplugin-container.exeから起動し(Firefox 42のデフォルトの動作)、アプレット・ステータスがReady(2)ではない場合、JavaScriptからJavaへの呼出しを処理しません。アプレットがReadyではない(ステータスが2ではない)場合、実際のJavaメソッドを実行せず、nullを返します。

    プラグインをplugin-container.exeから起動する場合、完了までに11秒(dom.ipc.plugins.hangUITimeoutSecsのデフォルト値)を超える時間を必要とするか、JavaScriptからJavaへの呼出し中にモーダル・ダイアログを表示する可能性があるJavaScriptからJavaへの呼出しを使用しないでください。この場合、メインのブラウザ・スレッドはブロックされる必要があるため、ブラウザがハングし、プラグインが終了する可能性があります。

    Firefox 42用の回避策: ユーザーはdom.ipc.plugins.enabled=falseを設定できます。この回避策に伴う悪影響は、すべてのプラグインに対して設定が変更されることです。JDK-8144079 (非公開)
  • Bug修正: JMX RMI JRMPサーバーの新規属性でサーバー資格証明のデシリアライズ時に使用するクラス名のリストを指定します
    JMX RMI JRMPサーバーがクラス名のリストを指定できるように、新しいJava属性が環境に定義されています。これらの名前は、資格証明のデシリアライズ時にサーバーが必要とするクラス名のクロージャに対応しています。たとえば、必要な資格証明が
    List<string>
    であった場合、クロージャはシリアル形式のStringsのリストに必要とされるすべてのconcreteクラスを構成します。

    デフォルトでは、この属性は次を使用するデフォルトのエージェントによってのみ使用されます。
     {   
       "[Ljava.lang.String;",   
       "java.lang.String" 
     } 
    
    資格証明のデシリアライズ時に、Stringsの配列およびStringsのみ受け入れられます。属性名は次のとおりです。
    "jmx.remote.rmi.server.credential.types"
    
    次に示すのは、指定した資格証明のクラス名でサーバーを起動するユーザーの例です。
    Map<String, Object> env = new HashMap<>(1);
     env.put ( 
     "jmx.remote.rmi.server.credential.types",
       new String[]{
       String[].class.getName(),
       String.class.getName()
       }
       );
       JMXConnectorServer server
       = JMXConnectorServerFactory.newJMXConnectorServer(url, env, mbeanServer);
    
    新機能は直接指定して使用する必要があります。
    "jmx.remote.rmi.server.credential.types"

    JDK-8144430 (非公開)
  • Bug修正: JSSEプロバイダのMD5withRSA署名アルゴリズムを無効化します
    MD5withRSA署名アルゴリズムは危険とみなされるようになったため、今後使用しないでください。状況に応じて、"MD5withRSA"を"jdk.tls.disabledAlgorithms"セキュリティ・プロパティに追加して、Oracle JSSE実装でMD5withRSAをデフォルトで非アクティブにします。現在、TLSハンドシェイク・メッセージおよびMD5withRSAアルゴリズムで署名されたX.509証明書はデフォルトで受け入れられません。この変更により、TLSバージョン1.2のハンドシェイク・メッセージも含まれるように、以前のMD5ベースの証明書の制限("jdk.certpath.disabledAlgorithms")が拡張されます。必要な場合、"jdk.tls.disabledAlgorithms"セキュリティ・プロパティから"MD5withRSA"を削除すれば、このアルゴリズムを再度アクティブにできます。JDK-8144773 (非公開)
  • Bug修正: 新しい証明書がルートCAに追加されました
    新しい8つのルート証明書が追加されました。
    • QuoVadis Root CA 1 G3
      alias: quovadisrootca1g3
      DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM
    • QuoVadis Root CA 2 G3
      alias: quovadisrootca2g3
      DN: CN=QuoVadis Root CA 2 G3
    • QuoVadis Root CA 3 G3
      alias: quovadisrootca3g3
      DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM
    • DigiCert Assured ID Root G2
      alias: digicertassuredidg2
      DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
    • DigiCert Assured ID Root G3
      alias: digicertassuredidg3
      DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US
    • DigiCert Global Root G2
      alias: digicertglobalrootg2
      DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
    • DigiCert Global Root G3
      alias: digicertglobalrootg3
      DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US
    • DigiCert Trusted Root G4
      alias: digicerttrustedrootg4
      DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US
    JDK-8145954およびJDK-8145955を参照してください。
注意

静的JREの削除
バージョン8u91より前にリリースされたWindows用Javaインストーラでは、静的にインストールされたJREがデフォルトで削除されませんでした。静的にインストールされたJREを削除するため、ユーザーはJavaインストーラのユーザー・インタフェースでそれらのJREを手動で選択することが必要でした。現在、Javaリリース8u91以上では、静的にインストールされたJREは、セキュリティ・ベースラインを下回る場合に自動的に削除されます。静的なインストールの詳細は、Java Runtime Environmentの構成を参照してください。

Javaの有効期限

8u91の有効期限は、2016年7月19日です。セキュリティ上の脆弱性の修正を含む新しいリリースが入手可能になると、Javaの有効期限が切れます。Oracle Serverに到達できないシステムの場合、セカンダリ・メカニズムにより、このJRE(バージョン8u91)は2016年8月19日に有効期限が切れます。いずれかの条件(新規リリースが入手可能になるか、有効期限に到達する)が一致した場合、Javaは新しいバージョンにアップデートするよう、追加の警告とリマインダを表示します。

Bug修正

このリリースには、セキュリティの脆弱性に関する修正が含まれています。詳細は、Oracle Java SEクリティカル・パッチ・アップデート・アドバイザリを参照してください。このリリースで行われたbug修正の一覧については、JDK 8u91のBug修正のページを参照してください。

» 8u91リリース・ノート


Java 8 Update 77 (8u77)

Javaの有効期限

8u77の有効期限は、2016年4月19日です。セキュリティ上の脆弱性の修正を含む新しいリリースが入手可能になると、Javaの有効期限が切れます。Oracle Serverに到達できないシステムの場合、セカンダリ・メカニズムにより、このJRE(バージョン8u77)は2016年5月19日に有効期限が切れます。いずれかの条件(新規リリースが入手可能になるか、有効期限に到達する)が一致した場合、Javaは新しいバージョンにアップデートするよう、追加の警告とリマインダを表示します。

注意

このセキュリティ・アラート(8u77)は、以前の8u74 PSUリリースに基づいています。以前のJDK 8リリースのすべてのユーザーはこのリリースに更新する必要があります。クリティカル・パッチ・アップデートとパッチ・セット更新の相違点の詳細は、Java CPUとPSUのリリースの説明を参照してください。

8u77のデモ、サンプルおよびドキュメント・バンドルはCVE-2016-0636のセキュリティ・アラートによる影響を受けないので、バージョン8u73のデモ、サンプルおよびドキュメント・バンドルは4月のクリティカル・パッチ・アップデートのリリースまで最新のままです。

Bug修正

このリリースには、セキュリティの脆弱性に関する修正が含まれています。詳細は、Oracle Java SEクリティカル・パッチ・アップデート・アドバイザリを参照してください。

» 8u77リリース・ノート


Java 8 Update 73 (8u73)

リリースのハイライト
Javaの有効期限

8u73の有効期限は、2016年4月19日です。セキュリティ上の脆弱性の修正を含む新しいリリースが入手可能になると、Javaの有効期限が切れます。Oracle Serverに到達できないシステムの場合、セカンダリ・メカニズムにより、このJRE(バージョン8u73)は2016年5月19日に有効期限が切れます。いずれかの条件(新規リリースが入手可能になるか、有効期限に到達する)が一致した場合、Javaは新しいバージョンにアップデートするよう、追加の警告とリマインダを表示します。

注意

影響を受けたバージョンをダウンロードし、これらのダウンロード済バージョンとともに将来インストールを予定しているJavaユーザーは、これらの古いダウンロードを破棄することを強くお薦めします。2016年1月のクリティカル・パッチ・アップデート・バージョンのSE 6、7または8をインストールしたJavaユーザーは、処置を行う必要はありません。2016年1月のクリティカル・パッチ・アップデート・バージョンのSE 6、7または8をインストールしていないJavaユーザーは、CVE-2016-0603のセキュリティ・アラートからJava SE 6、7または8リリースにアップグレードする必要があります。

8u73のデモ、サンプルおよびドキュメント・バンドルはCVE-2016-0603のセキュリティ・アラートによる影響を受けないので、バージョン8u71のデモ、サンプルおよびドキュメント・バンドルは4月のクリティカル・パッチ・アップデートのリリースまで最新のままです。

Bug修正

このリリースには、セキュリティの脆弱性に関する修正が含まれています。詳細は、Oracle Java SEクリティカル・パッチ・アップデート・アドバイザリを参照してください。8u73には8u72に存在していたPSUビルドが含まれていないことに注意してください。8u72に含まれている追加のbug修正が必要なユーザーは、8u73ではなく8u74にアップデートする必要があります。

» 8u73リリース・ノート


Java 8 Update 71 (8u71)

リリースのハイライト
  • IANA Data 2015g
    JDK 8u71にはIANAタイム・ゾーン・データのバージョン2015gが含まれています。詳細は、JREソフトウェアのタイムゾーン・データ・バージョンを参照してください。
  • Bug修正: rootとしてjpsを実行すると、すべての情報が表示されません
    JDK-8050807の修正後(8u31、7u75および6u91で修正済)、rootとしてjpsを実行すると、一部のシステムで他のユーザーによって起動されたJavaプロセスのすべての情報が表示されませんでした。これは修正されました。JDK-8075773を参照してください。
  • Bug修正: ESC構成でインストーラが停止する可能性があります
    Windows Server 2008 R2でInternet Explorerセキュリティ強化の構成を実行しているユーザーは、対話モードでのJavaのインストールで問題が発生することがあります。この問題は8u71リリースで解決されました。対話モードで実行されるインストーラが、ESC構成で停止しなくなりました。JDK-8140197を参照してください。
  • Bug修正: AES暗号化を使用するPBEアルゴリズムに関する問題が修正されました
    導出された鍵が異なり、同じパスワードから以前に導出された鍵と等しくない可能性があるという、256ビットのAES暗号化を使用するPBEに関するエラーが修正されました。JDK-8138589 (非公開)。
  • Bug修正: XML最大エントリ・サイズのデフォルト制限が追加されました
    最大エントリ・サイズにデフォルト制限が追加されました。XML処理制限の詳細は、Javaチュートリアル、処理制限を参照してください。JDK-8133962 (非公開)
  • Bug修正: MSI Enterpriseのスイッチのドキュメントで'REMOVEOLDERJRES'に関する問題が修正されました
    MSI Enterpriseのドキュメントには構成オプションがリストされています。古いJREのアンインストールに使用されるREMOVEOLDERJRESオプションがありませんでした。このオプションが説明とともに追加されました。
    1に設定すると、システムにインストールされている、より古いリリースのJREが削除されます。
    デフォルトは0で、古いJREは削除されません
    JDK-8081237 (非公開)
Javaの有効期限

8u71の有効期限は、2016年4月19日です。セキュリティ上の脆弱性の修正を含む新しいリリースが入手可能になると、Javaの有効期限が切れます。Oracle Serverに到達できないシステムの場合、セカンダリ・メカニズムにより、このJRE(バージョン8u71)は2016年5月19日に有効期限が切れます。いずれかの条件(新規リリースが入手可能になるか、有効期限に到達する)が一致した場合、Javaは新しいバージョンにアップデートするよう、追加の警告とリマインダを表示します。

Bug修正

このリリースには、セキュリティの脆弱性に関する修正が含まれています。詳細は、Oracle Java SEクリティカル・パッチ・アップデート・アドバイザリを参照してください。

このリリースで行われたbug修正の一覧については、JDK 8u71のBug修正のページを参照してください。

» 8u71リリース・ノート


Java 8 Update 66 (8u66)

リリースのハイライト

8u66ビルド18ではFirefoxの問題に対処しています。

  • Bug修正: _releaseObjectが間違ったスレッドからコールされます
    Firefoxにおける最近の変更により、_releaseObjectコールがメイン・スレッド以外のスレッドから行われていました。これにより競合状態が発生し、ブラウザが意図せずクラッシュする可能性があります。この問題には8u66のビルド18で対処しています。詳細は、Bugs@Mozilla 1221448を参照してください。JDK-8133523を参照してください。
Javaのインストール後、FirefoxでJavaプラグインが動作しない

Javaプラグインを実行しようとするとFirefox 42がクラッシュすることがあります。回避策のオプションはFAQに示されています。JDK-8142908 (非公開)を参照してください。

Javaの有効期限

8u66の有効期限は、2016年1月19日です。セキュリティ上の脆弱性の修正を含む新しいリリースが入手可能になると、Javaの有効期限が切れます。Oracle Serverに到達できないシステムの場合、セカンダリ・メカニズムにより、このJRE(バージョン8u66)は2016年2月19日に有効期限が切れます。いずれかの条件(新規リリースが入手可能になるか、有効期限に到達する)が一致した場合、Javaは新しいバージョンにアップデートするよう、追加の警告とリマインダを表示します。

Bug修正

このリリースには、セキュリティの脆弱性に関する修正が含まれています。詳細は、Oracle Java SEクリティカル・パッチ・アップデート・アドバイザリを参照してください。

このリリースで行われたbug修正の一覧については、JDK 8u66のBug修正のページを参照してください。

» 8u66リリース・ノート


Java 8 Update 65 (8u65)

リリースのハイライト
  • IANA Data 2015f
    JDK 8u65にはIANAタイム・ゾーン・データのバージョン2015fが含まれています。詳細は、JREソフトウェアのタイムゾーン・データ・バージョンを参照してください。
  • ISO 4217 '現在のファンド・コード'表(A.2)のサポート
    この機能拡張により、ISO 4217 表A.2のファンド・コードのサポートが追加されました。JDKでは、以前は表A.1にリストされている通貨のみサポートされていました。JDK-8074350を参照してください。
  • Bug修正: [mac osx] Mac 10.11でインストールされているJRE AUクライアントのNEXTVERへの更新に失敗します
    OS Xユーザーを最新バージョンに更新するために、新しいインストーラが8u65リリースで導入されました。インストーラは、スケジュール済更新と手動更新、およびjava.comとOTNで入手可能なバンドルに適用されます。新しいインストーラと互換性の問題があるユーザーは、My Oracle Supportで入手可能な'.pkg'インストーラを手動でダウンロードしてインストールすることができます。
  • Bug修正: SPARCでキャッシュライン・サイズを取得するには、HotspotでPICLインタフェースを使用する必要があります
    キャッシュ・ラインのサイズを特定するために、Solaris/SPARCではlibpiclライブラリが必要となりました。ライブラリが存在しないか、PICLサービスが使用できない場合、JVMは警告を表示し、BIS (Block Initializing Store)命令を使用するコンパイラの最適化がオフになります。JDK-8056124を参照してください。
  • Bug修正: dns_lookup_realmはデフォルトでfalseにする必要があります
    Kerberos krb5.confファイルのdns_lookup_realm設定はデフォルトでfalseです。JDK-8080637を参照してください。
  • Bug修正: libjsig.dylibをプリロードすると、signal()がコールされるときにデッドロックが発生します
    信号チェーンを有効にするには、アプリケーションはlibjsigライブラリをプリロードする必要があります。OS Xで、以前はlibjsig.dylibがプリロードされた後、ネイティブ・コードからsignal()へのコールによってデッドロックが発生していました。これは修正されました。JDK-8072147を参照してください。
  • Bug修正: グループの動的改善
    OpenJDK SSL/TLS/DTLS実装(SunJSSEプロバイダ)では、安全な素数のDiffie-Hellmanグループがデフォルトで使用されます。ユーザーはセキュリティ・プロパティjdk.tls.server.defaultDHEParametersを使用してDiffie-Hellmanグループをカスタマイズできます。
  • Bug修正: クラスをInstrumentation.redefineClassesで再定義すると、VMがクラッシュします
    クラスがInstrumentation.redefineClasses()で再定義されると、JVMがクラッシュすることがあります。クラッシュにより、SystemDictionary::resolve_or_nullでのセグメンテーションの失敗またはメッセージ「タグと解決エラー表の不一致」とともに内部エラーが発生する可能性があります。これは修正されました。JDK-8076110を参照してください。
注意

OSX 10.11 El Capitanで実行している際に、SIPを有効にすると、アプリケーションのデバッグを目的とする特定の環境変数(DYLD_LIBRARY_PATHなど)が、コマンド・ラインからのJavaの実行時またはJARファイルのダブルクリック時に環境から削除されることがあります。アプリケーションは本番環境でこれらの変数に依存しないでください。開発中のデバッグのみを目的としています。

MD5は、衝突困難性を必要とするデジタル署名に使用しないでください。X.509証明書操作中にデジタル署名アルゴリズムとしてMD5を使用できないようにするために、MD5をjdk.certpath.disabledAlgorithmsセキュリティ・プロパティに追加します。MD5署名済証明書をまだ使用しているアプリケーションについては、弱い証明書をできるだけ早くアップグレードしてください。

既知の問題

[macosx] スポンサのオファー画面におけるアクセシビリティ(a11y)の問題
キーボードを操作してJavaインストーラでユーザー・インタフェースにアクセスするユーザーは、ソフトウェア・アドオン・オファー画面でハイパーリンクおよびチェック・ボックスにアクセスできません。ユーザー・インタフェースでのアドオン・ソフトウェアに関連するプリファレンスの設定に対する回避策として、ユーザーはJavaコントロール・パネルで無効にするか、コマンド・ラインでSPONSORS=0を渡すことで、そのようなオファーを無効にすることができます。詳細は、スポンサのオファーなしでのJavaのインストールFAQを参照してください。

Javaの有効期限

8u65の有効期限は、2016年1月19日です。セキュリティ上の脆弱性の修正を含む新しいリリースが入手可能になると、Javaの有効期限が切れます。Oracle Serverに到達できないシステムの場合、セカンダリ・メカニズムにより、このJRE(バージョン8u65)は2016年2月19日に有効期限が切れます。いずれかの条件(新規リリースが入手可能になるか、有効期限に到達する)が一致した場合、Javaは新しいバージョンにアップデートするよう、追加の警告とリマインダを表示します。

Bug修正

このリリースには、セキュリティの脆弱性に関する修正が含まれています。詳細は、Oracle Java SEクリティカル・パッチ・アップデート・アドバイザリを参照してください。

このリリースで行われたbug修正の一覧については、JDK 8u65のBug修正のページを参照してください。

» 8u65リリース・ノート


Java 8 Update 60 (8u60)

リリースのハイライト
  • IANA Data 2015e
    JDK 8u60にはIANAタイム・ゾーン・データのバージョン2015eが含まれています。詳細は、JREソフトウェアのタイムゾーン・データ・バージョンを参照してください。
  • Bug修正: dns_lookup_realmはデフォルトでfalseにする必要があります
    Kerberos krb5.confファイルのdns_lookup_realm設定はデフォルトでfalseです。8080637を参照してください。
  • Bug修正: RC4暗号スイートを無効化します
    RC4ベースのTLS暗号スイート(TLS_RSA_WITH_RC4_128_SHAなど)は危険とみなされるようになったため、今後使用しないでください(RFC 7465を参照)。状況に応じて、"RC4"を"jdk.tls.disabledAlgorithms"セキュリティ・プロパティに追加し、それらをデフォルトで有効化される暗号スイート・リストから削除して、Oracle JSSE実装でRC4ベースのTLS暗号スイートをデフォルトで非アクティブにします。java.securityファイルの"jdk.tls.disabledAlgorithms"から"RC4"を削除するか、Security.setProperty()を動的に呼び出し、SSLSocket/SSLEngine.setEnabledCipherSuites()メソッドを使用して、それらを有効化される暗号スイート・リストに再度追加すれば、これらの暗号スイートを再度アクティブにできます。-Djava.security.propertiesコマンド行オプションを使用して、jdk.tls.disabledAlgorithmsセキュリティ・プロパティをオーバーライドすることもできます。例:
    java -Djava.security.properties=my.java.security ...
    ここで、my.java.securityはRC4を指定しないプロパティを含むファイルです。
    jdk.tls.disabledAlgorithms=SSLv3
    コマンド行からこのオプションを設定しても、SSLSocket/SSLEngine.setEnabledCipherSuites()メソッドを使用して、RC4ベースの暗号スイートを有効化される暗号スイート・リストに再度追加する必要があります。8076221を参照してください。
  • Bug修正: JKSおよびPKCS12キーストアのキーストア・タイプの検出をサポートします
    キーストア互換性モード: 相互運用性を支援するために、Javaキーストア・タイプJKSがデフォルトでキーストア互換性モードをサポートするようになりました。このモードでは、JKSキーストアはJKSおよびPKCS12ファイル形式にアクセスできます。キーストア互換性モードを無効にするには、セキュリティ・プロパティkeystore.type.compatを文字列値falseに設定します。8062552を参照してください。
  • Bug修正: JDK 8uリリースのUnsafeモニター・メソッドは非推奨になります
    sun.misc.UnsafeのメソッドmonitorEntermonitorExitおよびtryMonitorEnterは、JDK 8u60では非推奨としてマークされ、今後のリリースで削除されます。これらのメソッドはJDK自体の内部では使用されませんが、JDKの外部でごくまれに使用されます。8069302を参照してください。
  • Bug修正: SAを使用してコア・ファイルからJFR記録を抽出します
    DumpJFRは運用性エージェント・ベースのツールで、コア・ファイルおよび実行中のHotspotプロセスからJava Flight Recorder(JFR)データを抽出するために使用できます。DumpJFRは次のいずれかのメソッドで使用できます。
    • 実行中のプロセスへのDumpJFRのアタッチ:

      java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.tools.DumpJFR <pid>

    • コア・ファイルへのDumpJFRのアタッチ:

      java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.tools.DumpJFR <java> <core>
    DumpJFRツールは、現在動作しているフォルダのrecording.jfrを呼び出したファイルにJFRデータをダンプします。8065301(非公開)を参照してください。
  • Bug修正: 'enum'という名前のローカル変数により、疑似コンパイラ・クラッシュが発生します
    javacパーサーは'enum'という名前のローカル変数を誤って解析します。これにより、そのようなローカル変数を含むプログラムを、列挙コンストラクトが使用できないリリースに相当する'source'フラグ('-source 1.4'など)を指定してコンパイルすると、疑似失敗が発生します。8069181を参照してください。
Java Development Kit for ARMリリース8u60

このリリースには、Java Development Kit for ARMリリース8u60 (JDK 8u60 for ARM)が含まれています。ARMデバイス・サポート情報は、JDK for ARMダウンロード・ページを参照してください。システム要件、インストール手順およびトラブルシューティングについては、インストール手順ページを参照してください。

制限: ネイティブ・メモリー・トラッキングのサポートはJDK for ARMで制限されています。Javaコマンド行オプションXX:NativeMemoryTracking=detailは、ARMターゲットではサポートされません(エラー・メッセージがユーザーに表示されます)。かわりに、次のオプションを使用します。
XX:NativeMemoryTracking=summary

Nashorn機能強化によるドキュメントの更新
JDK 8u60には、新しいNashornへの機能強化が含まれています。そのため、次のドキュメントの変更は現在のNashornドキュメントとあわせて読む必要があります。
  • 追加: 以前の項では、Java APIへの公開時に、各JavaScriptオブジェクトはjava.util.Mapインタフェースを実装するように記述されていました。これはJavaScript配列にも当てはまります。ただし、JavaコードがJSON解析オブジェクトを必要とする場合、この動作は通常望ましくないか、必要ありません。かわりに、JSON解析オブジェクトを操作するJavaライブラリは、通常配列がjava.util.Listインタフェースを公開することを必要とします。配列がマップではなくリストとして公開されるようにJavaScriptオブジェクトを公開する必要がある場合、Java.asJSONCompatible(obj)関数を使用できます。ここで、objはJSONオブジェクト・ツリーのルートです。
  • 修正: データ型のマッピングに関する項の最後に記述されている警告は、適用不可になりました。Nashornは、外部への公開時に内部のJavaScript文字列がjava.lang.Stringに変換されることを保証します。
  • 修正: データ型のマッピングに関する項で、「たとえば、配列を明示的に変換する必要があります...」と記述されている文は正しくありません。配列はJava配列タイプ(java.util.Listjava.util.Collectionjava.util.Queuejava.util.Dequeなど)に自動的に変換されます。
デプロイメント・ルール・セットv1.2の変更
JDK 8u60には、次の変更を含むデプロイメント・ルール・セット(DRS) 1.2が実装されています。
  • "id"のサブ要素として"checksum"要素が追加され、圧縮されていない形式のjarのSHA-256チェックサムで署名のないjarを識別することができます。
    • "checksum"要素は署名のないjarのみと照合され、指定したハッシュは圧縮されていない形式のjarに対してのみ比較されます。
    • "checksum"要素("certificate"要素と似ている)には、"hash""algorithm"の2つの引数があります。ただし、"certificate"要素とは異なり、"algorithm"に対してサポートされている値は"SHA-256"のみです。他の値を指定しても無視されます。
  • "message"要素をすべてのルール・タイプに適用できます。以前はブロック・ルールに対してのみ適用されていました。
    • 実行ルールでは、メッセージ・サブ要素により、実行ルールがない場合にメッセージ・ダイアログが表示され、デフォルトの動作では証明書または署名のないダイアログが表示されます。メッセージはメッセージ・ダイアログに表示されます。
    • デフォルト・ルールでは、デフォルト・アクションがブロックされている場合のみ、メッセージが表示されます。このような場合、メッセージはブロック・ダイアログに含まれます。
  • Javaコンソール、トレース・ファイルおよびJava使用状況トラッカ・レコードに"customer"ブロックをエコーします。
    • DRS 1.2より前では、"customer"要素はruleset.xmlファイルに(任意のサブ要素と一緒に)含めることができました。この要素とそのすべてのサブ要素は無視されます。DRS 1.2では、要素は機能的にまだ無視されます。ただし、
      • ruleset.xmlファイルの解析時に、すべての"customer"ブロックは、Javaコンソールおよびデプロイメント・トレース・ファイルにエコーされます(コンソールおよびトレースが有効である場合)。
      • ルールの使用時に、そのルール内に含まれるすべての"customer"レコードは、Java使用状況トラッカ(JUT)レコードに追加されます(JUTが有効である場合)。
前述の変更を受けて、DRS 1.2のDTDは次のようになります。
<!ELEMENT ruleset (rule*)>
<!ATTRIBUTE ruleset href CDATA #IMPLIED>
<!ATTRIBUTE ruleset version CDATA #REQUIRED>

<!ELEMENT rule (id, action)>

<!ELEMENT id (certificate?) (checksum?) >
<!ATTRIBUTE id title CDATA #IMPLIED>
<!ATTRIBUTE id location CDATA #IMPLIED>

<!ELEMENT certificate EMPTY>
<!ATTLIST certificate algorithm CDATA #IMPLIED>
<!ATTLIST certificate hash CDATA #REQUIRED>

<!ELEMENT checksum EMPTY>
<!ATTLIST checksum algorithm CDATA #IMPLIED>
<!ATTLIST checksum hash CDATA #REQUIRED>
 
<!ELEMENT action (message?)>
<!ATTRIBUTE permission (run | block | default) #REQUIRED>
<!ATTRIBUTE version CDATA #IMPLIED>
<!ATTRIBUTE force (true|false) "false">

<!ELEMENT message (#PCDATA)>
<!ATTLIST message locale CDATA #IMPLIED>

Javaの有効期限

8u60の有効期限は、2015年10月20日です。セキュリティ上の脆弱性の修正を含む新しいリリースが入手可能になると、Javaの有効期限が切れます。Oracle Serverに到達できないシステムの場合、セカンダリ・メカニズムにより、このJRE(バージョン8u60)は2015年11月20日に有効期限が切れます。いずれかの条件(新規リリースが入手可能になるか、有効期限に到達する)が一致した場合、Javaは新しいバージョンにアップデートするよう、追加の警告とリマインダを表示します。

Bug修正

このリリースで行われたbug修正の一覧については、JDK 8u60のBug修正のページを参照してください。

» 8u60リリース・ノート


Java 8 Update 51 (8u51)

リリースのハイライト
  • IANA Data 2015d
    JDK 8u51にはIANAタイム・ゾーン・データのバージョン2015dが含まれています。詳細は、JREソフトウェアのタイムゾーン・データ・バージョンを参照してください。
  • Bug修正: 新しいComodoルートをルートCAに追加します
    新しい4つのルート証明書がCommodo用に追加されています。
    1. COMODO ECC Certification Authority
      alias: comodoeccca
      DN: CN=COMODO ECC Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
    2. COMODO RSA Certification Authority
      alias: comodorsaca
      DN: CN=COMODO RSA Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
    3. USERTrust ECC Certification Authority
      alias: usertrusteccca
      DN: CN=USERTrust ECC Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
    4. USERTrust RSA Certification Authority
      alias: usertrustrsaca
      DN: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
    JDK-8077997(非公開)を参照してください。
  • Bug修正:新しいGlobalSignルートをルートCAに追加します
    2つのルート証明書がGlobalSign用に追加されています。
    1. GlobalSign ECC Root CA - R4
      alias: globalsigneccrootcar4
      DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4
    2. GlobalSign ECC Root CA - R5
      alias: globalsigneccrootcar5
      DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R5
    JDK-8077995(非公開)を参照してください。
  • Bug修正: ActalisをルートCAに追加します
    新しい1つのルート証明書を追加しました。
    Actalis Authentication Root CA
    alias: actalisauthenticationrootca
    DN: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT

    JDK-8077903(非公開)を参照してください。
  • Bug修正: 新しいEntrust ECCルートを追加します
    新しい1つのルート証明書を追加しました。
    Entrust Root Certification Authority - EC1
    alias: entrustrootcaec1
    DN: CN=Entrust Root Certification Authority - EC1, OU="(c) 2012 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US

    JDK-8073286(非公開)を参照してください。
  • Bug修正: 古いValicert Class 1および2ポリシー・ルートを削除します
    1024ビットのキーを持つ2つのルート証明書を削除しました。
    1. ValiCert Class 1 Policy Validation Authority
      alias: secomvalicertclass1ca
      DN: EMAILADDRESS=info@valicert.com, CN=http://www.valicert.com/, OU=ValiCert Class 1 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
    2. ValiCert Class 2 Policy Validation Authority
      alias: valicertclass2ca
      DN: EMAILADDRESS=info@valicert.com, CN=http://www.valicert.com/, OU=ValiCert Class 2 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
    JDK-8077886(非公開)を参照してください。
  • Bug修正: 古いThawteルートを削除します
    1024ビットのキーを持つ2つのルート証明書を削除しました。
    1. Thawte Server CA
      alias: thawteserverca
      DN: EMAILADDRESS=server-certs@thawte.com, CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
    2. Thawte Personal Freemail CA
      alias: thawtepersonalfreemailca
      DN: EMAILADDRESS=personal-freemail@thawte.com, CN=Thawte Personal Freemail CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA
    JDK-8074423(非公開)を参照してください。
  • Bug修正: 古いVerisign、EquifaxおよびThawteルートを削除します
    1024ビットのキーを持つ5つのルート証明書を削除しました。
    1. Verisign Class 3 Public Primary Certification Authority - G2
      alias: verisignclass3g2ca DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
    2. Thawte Premium Server CA
      alias: thawtepremiumserverca
      DN: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
    3. Equifax Secure Certificate Authority
      alias: equifaxsecureca
      DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
    4. Equifax Secure eBusiness CA-1
      alias: equifaxsecureebusinessca1
      DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US
    5. Equifax Secure Global eBusiness CA-1,
      alias: equifaxsecureglobalebusinessca1
      DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
    JDK-8076202(非公開)を参照してください。
  • Bug修正: TrustCenter CAルートをcacertsから削除します
    3つのルート証明書を削除しました。
    1. TC TrustCenter Universal CA I
      alias: trustcenteruniversalcai
      DN: CN=TC TrustCenter Universal CA I, OU=TC TrustCenter Universal CA, O=TC TrustCenter GmbH, C=DE
    2. TC TrustCenter Class 2 CA II
      alias: trustcenterclass2caii
      DN: CN=TC TrustCenter Class 2 CA II, OU=TC TrustCenter Class 2 CA, O=TC TrustCenter GmbH, C=DE
    3. TC TrustCenter Class 4 CA II
      alias: trustcenterclass4caii
      DN: CN=TC TrustCenter Class 4 CA II, OU=TC TrustCenter Class 4 CA, O=TC TrustCenter GmbH, C=DE
    JDK-8072958(非公開)を参照してください。
  • Bug修正: SunJSSEプロバイダのRC4を非推奨にします
    RC4は脆弱な暗号とみなされるようになりました。サーバーは、暗号スイートをリクエストしたクライアント内により強力な他の候補がない場合を除き、RC4を選択する必要はありません。新しいセキュリティ・プロパティjdk.tls.legacyAlgorithmsが、Oracle JSSE実装で従来のアルゴリズムを定義するために追加されています。RC4関連アルゴリズムはレガシーのアルゴリズム・リストに追加されます。JDK-8074006(非公開)を参照してください。
  • Bug修正: RC4暗号スイートを禁止します
    RC4は危険な暗号とみなされるようになりました。RC4暗号スイートは、Oracle JSSE実装でクライアントとサーバー両方のデフォルトで有効化される暗号スイート・リストから削除されました。これらの暗号スイートは、SSLEngine.setEnabledCipherSuites()およびSSLSocket.setEnabledCipherSuites()メソッドでは引き続き有効化できます。JDK-8077109(非公開)を参照してください。
  • Bug修正: 証明書チェックを改善しました
    この修正により、JSSEエンドポイント識別ではJDKでIPアドレスの逆名前検索がデフォルトで実行されません。アプリケーションがSSL/TLS接続でRAW IPアドレスの逆名前検索を実行する必要があり、エンドポイント識別の互換性に問題が発生した場合は、システム・プロパティ"jdk.tls.trustNameService"を使用して逆名前検索を切り替えることができます。名前サービスが信頼できない場合は、逆名前検索を有効にするとMITM攻撃を受けやすくなります。JDK-8067695(非公開)を参照してください。
Javaの有効期限

8u51の有効期限は、2015年10月20日です。セキュリティ上の脆弱性の修正を含む新しいリリースが入手可能になると、Javaの有効期限が切れます。Oracle Serverに到達できないシステムの場合、セカンダリ・メカニズムにより、このJRE(バージョン8u51)は2015年11月20日に有効期限が切れます。いずれかの条件(新規リリースが入手可能になるか、有効期限に到達する)が一致した場合、Javaは新しいバージョンにアップデートするよう、追加の警告とリマインダを表示します。

Bug修正

このリリースには、セキュリティの脆弱性に関する修正が含まれています。詳細は、Oracle Java SEクリティカル・パッチ・アップデート・アドバイザリを参照してください。

このリリースで行われたbug修正の一覧については、JDK 8u51のBug修正のページを参照してください。

» 8u51リリース・ノート


Java 8 Update 45 (8u45)

リリースのハイライト
  • IANA Data 2015a
    JDK 8u45にはIANAタイム・ゾーン・データのバージョン2015aが含まれています。詳細は、JREソフトウェアのタイムゾーン・データ・バージョンを参照してください。
  • Bug修正: jarファイルの処理を向上しました。JDK 8u45リリースから、jarツールでは、新規作成時またはzipやjarファイルからの抽出時に、zipエントリ・ファイル名の先頭に"/" (スラッシュ)や".." (ピリオド2つ)のパス・コンポーネントを使用できなくなりました。ピリオド2つや絶対パス・コンポーネントを保持するには、必要に応じて、新しいコマンド行オプション"-P"を明示的に使用する必要があります。8064601 (非公開)を参照してください。
  • Bug修正: jre8u40では、resourceセクションがネストしているjnlpアプリケーションは、ロード時にNPEで失敗します。<java>またはタグ内にタグがネストしているjnlpアプリケーションでは、NPEがスローされます。この問題は修正されました。タグは、実際に<java>が使用されている場合にのみ使用してください。8072631 (非公開)を参照してください。
Javaの有効期限

8u45の有効期限は、2015年7月14日です。セキュリティ上の脆弱性の修正を含む新しいリリースが入手可能になると、Javaの有効期限が切れます。Oracle Serverに到達できないシステムの場合、セカンダリ・メカニズムにより、このJRE(バージョン8u45)は2015年8月14日に有効期限が切れます。いずれかの条件(新規リリースが入手可能になるか、有効期限に到達する)が一致した場合、Javaは新しいバージョンにアップデートするよう、追加の警告とリマインダを表示します。

Bug修正

このリリースには、セキュリティの脆弱性に関する修正が含まれています。詳細は、Oracle Java SEクリティカル・パッチ・アップデート・アドバイザリを参照してください。

このリリースで行われたbug修正の一覧については、JDK 8u45のBug修正のページを参照してください。

» 8u45リリース・ノート


Java 8 Update 40 (8u40)

リリースのハイライト
  • IANAデータ2014j
    JDK 8u40にはIANAタイム・ゾーン・データのバージョン2014jが含まれています。詳細は、JREソフトウェアのタイムゾーン・データ・バージョンを参照してください。
  • Bug修正: JDI、JDWPおよびJDBのデフォルトおよび静的インタフェース・メソッド。JDK 8以降、インタフェースの直接実行可能な静的およびデフォルト・メソッドを使用できます。これらのメソッドはJDWPまたはJDIを介して実行できないため、正しくデバッグできません。詳細は、JDK 8互換性ガイドを参照してください。8042123を参照してください。
  • Bug修正: 32ビットJREのコントロール・パネルからJava Access Bridgeを有効化できます。以前は、32ビットJREがまだシステムに存在している場合でも、64ビットJREをアンインストールすると、Javaコントロール・パネルから「Java Access Bridgeを有効にする」チェック・ボックスが削除されていました。JDK 8u40リリース以降、32ビットJREが存在する場合、「コントロール パネル」->「コンピューターの簡単操作」->「コンピューターの簡単操作センター」->「コンピューターを画面なしで使用します」を選択しても、「Java Access Bridgeを有効にする」チェック・ボックスが保持されます。ユーザーはコントロール・パネルでJava Access Bridgeを有効化できるようになりました(8030124を参照)。
  • Bug修正: Mac OS XでのJavaFXメディア・スタックの導入。AVFoundationベースのプレーヤ・プラットフォームがJavaFXメディアに追加されました。Mac App Storeの互換性のため、以前のQTKitベースのプラットフォームは削除可能になりました。8043697(非公開)を参照してください
  • Bug修正: DOM APIの欠落。JDK 8u40リリースでは、旧プラグインのDOM APIが誤って削除されています。アプレットとブラウザとの通信にcom.sun.java.browser.dom.DOMServiceを使用する必要がある場合は、netscape.javascript.JSObjectを使用するようアプレットを更新するか、引き続きJDK 8 Update 31をご使用ください。この問題はビルド26で解決され、新しい8u40のインストーラが公開されています。この問題が発生した場合は、更新済のJDK 8u40のインストーラをダウンロードして実行してください。8074564を参照してください。
  • Bug修正: Mac 10.10: スプラッシュ画面が表示されるアプリケーションで、フォーカスの問題があります。webstartを介して起動されたアプリケーションやスタンドアロン・アプリケーションで、スプラッシュ画面を使用するものは、キーボード・フォーカスを取得できません。回避策: -Xnosplashオプションを使用してjavawsを起動してください。この問題はビルド27で解決され、新しい8u40のインストーラが公開されています。この問題が発生した場合は、更新済のJDK 8u40のインストーラをダウンロードして実行してください。8074668を参照してください。
  • Javaパッケージャ・ツールの機能強化
    JDK 8u40リリースには、Javaパッケージャへの次の機能強化が含まれています。
  • 非推奨API
    推奨規格オーバーライド機構と拡張機能機構は非推奨であり、今後のリリースで削除される可能性があります。実行時の変更はありません。「推奨規格オーバーライド」機構または「拡張機能」機構を使用している既存のアプリケーションは、これらの機構を使用しないよう移行することをお薦めします。これらの機構を既存で使用しているかを識別するために、-XX:+CheckEndorsedAndExtDirsコマンド行オプションを使用できます。次のいずれかの条件がtrueの場合、失敗します。
    • -Djava.endorsed.dirsまたは-Djava.ext.dirsシステム・プロパティがデフォルトの場所を変更するために設定されているか、
    • ${java.home}/lib/endorsedディレクトリが存在するか、
    • ${java.home}/lib/extにJDKに同梱されているファイル以外のJARファイルが含まれているか、
    • プラットフォーム固有のシステム全体の拡張ディレクトリにJARファイルが含まれている。
    JDK 8u40以降のリリースで、-XX:+CheckEndorsedAndExtDirsコマンド行オプションがサポートされます。
  • JJSツール・ページの差異
    日本語バージョンのJJSヘルプ・ページは英語バージョンと異なります。一部のサポートされていないオプションが、英語バージョンのJJSツール・ページから削除されています。日本語バージョンのドキュメントは今後更新されます。8062100(非公開)を参照してください。その他のJJSツール・ページの変更については、JDK 8のツールの機能強化を参照してください。
  • G1HeapWastePercentおよびG1MixedGCLiveThresholdPercentのデフォルト値の変更
    G1HeapWastePercentのデフォルト値が、フルGCの必要性を減らすために10から5に変更されました。同じ理由で、G1MixedGCLiveThresholdPercentのデフォルト値が65から85に変更されました。
  • 新規のJavaクラスアクセス・フィルタリング・インタフェース
    jdk.nashorn.api.scripting.ClassFilterインタフェースにより、Nashornスクリプト・エンジンで実行されるスクリプトから指定したJavaクラスへのアクセスを制限できます。詳細は、Nashornユーザーズ・ガイドの指定したJavaクラスへのスクリプト・アクセスの制限に関する項および8043717(非公開)を参照してください。
  • サード・パーティのJCEプロバイダによる問題
    JDK-8023069 (JDK 8u20)の修正で、SunJSSEプロバイダおよびSunJCEプロバイダが更新されました(いくつかの内部インタフェースを含む)。一部のサード・パーティのJCEプロバイダ(RSA JSAFEなど)はsun.* internalインタフェースを使用しているため、更新されたSunJSSEプロバイダで動作しません。このようなプロバイダは、更新されたSunJSSEプロバイダで動作するように更新される必要があります。この問題により影響を受ける場合は、JCEベンダーに更新について問い合せてください。8058731を参照してください。
  • Solaris暗号化フレームワークでの暗号化の再有効化
    Solaris 10を使用している場合、Solaris暗号化フレームワークを介したMD5、SHA1およびSHA2を使用した操作が再有効化される変更が行われました。JDK 8u40でCloneNotSupportedExceptionまたはPKCS11エラーのCKR_SAVED_STATE_INVALIDメッセージが発生する場合は、次のパッチまたはより新しいバージョンのパッチを適用する必要があります。
    • sparcでは、150531-02
    • x86では、150636-01
  • NMTのトラブルシューティング・ガイドの更新
    ネイティブ・メモリー・トラッキング(NMT)はHotSpot JVMの内部メモリー使用状況を追跡するJava Hotspot VM機能です。ネイティブ・メモリー・トラッキングは、VM内部メモリー割当てのモニターおよびVMメモリー・リークの診断に使用できます。VM機能強化ページは、NMT機能について更新されています。Java SE 8のJava Virtual Machineの機能強化を参照してください。トラブルシューティング・ガイドは、NMT機能について更新されています。ネイティブ・メモリー・トラッキングを参照してください。
  • 複数のJREランチャ機能の削除
    記載されているように、起動時のJREバージョンの選択または複数のJREランチャ機能はJDK 8u40で非推奨です。この機能を使用してデプロイされた特定のJavaバージョンを必要とするアプリケーションをJava WebStartなどの代替のデプロイメント・ソリューションに切り替える必要があります。
  • JavaFX拡張機能
    JDK 8u40リリース以降、JavaFXコントロールが拡張されて支援技術をサポートするようになりました。障害のあるユーザーがJavaFXコントロールを利用できるようになりました。また、パブリックAPIが提供され、開発者は独自の障害のあるユーザーが利用できるコントロールを書き込むことができます。アクセシビリティ・サポートがWindowsおよびMac OS Xプラットフォームで提供され、次が含まれます。
    • スクリーン・リーダーによるJavaFXコントロールの読取りのサポート
    • JavaFXコントロールは、キーボードを使用してトラバースできます。
    • ユーザーに対してコントロールをより詳細に表示する特別な高コントラスト・モードのサポート。
    8043344(非公開)を参照してください。

    JDK 8u40リリースには、新しいJavaFX UIコントロール、スピナー・コントロール、書式設定されたテキストのサポート、アラート・ダイアログの標準セットが含まれます。
    • スピナー・コントロール: スピナーは、順序付けられた列からユーザーが数字またはオブジェクトの値を選択できる単一行のテキスト・フィールドです。詳細は、 javafx.scene.control.Spinnerクラスを参照してください。
    • 書式設定されたテキスト: 新しいTextFormatterクラスでは、TextInputControl(TextFieldやTextAreaなど)のサブクラスのテキスト書式設定機能を提供します。詳細は、javafx.scene.control.TextFormatterクラスを参照してください。
    • ダイアログ: ダイアログ・クラスでは、アプリケーションが独自のカスタム・ダイアログを作成できます。また、ダイアログを拡張し、レスポンスを求めるために簡単にユーザーに表示できる事前に作成された多数のダイアログ・タイプのサポートを提供するアラート・クラスも提供されます。詳細は、javafx.scene.control.Dialogjavafx.scene.control.Alertjavafx.scene.control.TextInputDialog javafx.scene.control.ChoiceDialogクラスを参照してください。
    8043350(非公開)を参照してください。
商用機能
  • アプリケーション・クラス・データ共有(AppCDS)
    アプリケーション・クラス・データ共有(AppCDS)ではCDSが拡張され、共有アーカイブの標準拡張ディレクトリおよびアプリケーション・クラス・パスからクラスを配置できます。これは実験的な機能で、商用にはライセンスされません。Javaランチャ・ツール・ページの-XX:+UseAppCDSオプションを参照してください。
  • 協調的メモリー管理
    JDK 8u40以降、"メモリー負荷"という概念がJDKに追加されました。メモリー負荷は、システムの合計メモリー使用量(RAM)を表すプロパティです。メモリー負荷が高まるほど、システムでメモリー不足が発生しやすくなります。これは実験的な機能で、商用にはライセンスされません。増大したメモリー負荷への対応として、JDKはメモリー使用量を減らそうとします。これは主にJavaヒープ・サイズを減らすことで行われます。メモリー使用量を減らすためのJDKのアクションにより、パフォーマンスが低下する可能性があります。これは意図的に選択します。負荷レベルは0 (負荷なし)から10 (ほぼメモリー不足)のスケールで、JMX MXBeanを介してアプリケーションによって指定されます。この機能を有効化するには、jdk.management.cmm.SystemResourcePressureMXBeanを登録する必要があります。次に、"MemoryPressure"属性を使用してメモリー負荷を設定します。
    新規コマンド行フラグ-XX:MemoryRestrictionも使用可能で、これは'none'、'low'、'medium'または'high'のいずれかの引数を取ります。このフラグはJDKでの初期負荷を設定し、MXBeanが登録されていない場合も機能します。協調的メモリー管理には、G1 GC (-XX:+UseG1GC)が必要です。この機能はフラグ-XX:+ExplicitGCInvokesConcurrentと互換性がありません。
  • 新規商用フラグ
    商用ライセンスを持つユーザーは、次の2つの新規VMオプションを使用できます。
    • -XX:+ResourceManagement
    • -XX:ResourceManagementSampleInterval=value(ミリ秒)
    詳細は、Javaランチャのドキュメントを参照してください。
  • MSIインストーラのドキュメントの追加
    Microsoft Windowsインストーラ(MSI) Enterprise JREインストーラ・ガイドが入手可能になりました。MSI Enterprise JREインストーラを本番で使用するには、商用ライセンスが必要です。詳細は、商用機能および有効化する方法を参照してください。
Javaの有効期限

8u40の有効期限は、2015年4月14日です。セキュリティ上の脆弱性の修正を含む新しいリリースが入手可能になると、Javaの有効期限が切れます。Oracle Serverに到達できないシステムの場合、セカンダリ・メカニズムにより、このJRE(バージョン8u40)は2015年5月14日に有効期限が切れます。いずれかの条件(新規リリースが入手可能になるか、有効期限に到達する)が一致した場合、Javaは新しいバージョンにアップデートするよう、追加の警告とリマインダを表示します。

Bug修正

このリリースで行われたbug修正の一覧については、JDK 8u40のBug修正のページを参照してください。

» 8u40リリース・ノート


Java 8 Update 31 (8u31)

リリースのハイライト
  • IANAデータ2014j
    JDK 8u31にはIANAタイム・ゾーン・データのバージョン2014jが含まれています。詳細は、JREソフトウェアのタイムゾーン・データ・バージョンを参照してください。
  • SSLv3はデフォルトで無効
    JDK 8u31リリース以降、SSLv3プロトコル(Secure Socket Layer)は無効になっており、通常は使用できません。\lib\security\java.securityファイルのjdk.tls.disabledAlgorithmsプロパティを参照してください。SSLv3が絶対に必要な場合は、java.securityファイルのjdk.tls.disabledAlgorithmsプロパティから'SSLv3'を削除するか、JSSEが初期化される前にこのセキュリティ・プロパティを動的に設定すれば、プロトコルを再度アクティブにできます。
  • Javaコントロール・パネルの変更点
    JDK 8u31リリース以降、Javaコントロール・パネルの詳細オプションからSSLv3プロトコルが削除されています。ユーザーがアプリケーションでSSLv3を使用する必要がある場合は、次の手順に従って手動で再度有効化してください:
    • SSLv3プロトコルをJREレベルで有効化: 前の項の説明に従います。
    • SSLv3プロトコルをデプロイ・レベルで有効化: deployment.propertiesファイルを編集し、次の記述を追加します:

      deployment.security.SSLv3=true
Javaの有効期限

8u31の有効期限は、2015年4月14日です。セキュリティ上の脆弱性の修正を含む新しいリリースが入手可能になると、Javaの有効期限が切れます。Oracle Serverに到達できないシステムの場合、セカンダリ・メカニズムにより、このJRE(バージョン8u31)は2015年5月14日に有効期限が切れます。いずれかの条件(新規リリースが入手可能になるか、有効期限に到達する)が一致した場合、Javaは新しいバージョンにアップデートするよう、追加の警告とリマインダを表示します。

Bug修正

このリリースには、セキュリティの脆弱性に関する修正が含まれています。詳細は、Oracle Java SEクリティカル・パッチ・アップデート・アドバイザリを参照してください。

このリリースで行われたbug修正の一覧については、JDK 8u31のBug修正のページを参照してください。

» 8u31リリース・ノート


Java 8 Update 25 (8u25)

リリースのハイライト
  • IANAデータ2014c
    JDK 8u25にはIANAタイム・ゾーン・データのバージョン2014cが含まれています。詳細は、JREソフトウェアのタイムゾーン・データ・バージョンを参照してください。
  • Bug修正: 有効になっている暗号スイート・リストでRC4の優先モードを下げます
    この修正により、SunJSSEプロバイダでデフォルトで有効になっている暗号スイートのRC4ベース暗号スイートの優先順位が下がります。8043200(非公開)を参照してください。
  • Bug修正: Windowsでの日本語IMの使用中に、JRE 8u20がクラッシュします。
    Windowsプラットフォームで日本語または中国語の一部の文字を入力する際にSwingコントロールを使用するとVMがクラッシュします。この問題は修正されました。8058858(非公開)を参照してください。
Oracle JDKおよびJREでSSL v3.0を無効化する手順

ユーザーおよび開発者は、SSLv3プロトコルの使用を無効化することをお薦めします。
» Javaユーザーは、SSL V3.0 'Poodle' 脆弱性の影響を受けないことをどのように確認できますか。

Javaの有効期限

8u25の有効期限は、2015年1月20日です。セキュリティ上の脆弱性の修正を含む新しいリリースが入手可能になると、Javaの有効期限が切れます。Oracle Serverに到達できないシステムの場合、セカンダリ・メカニズムにより、このJRE(バージョン8u25)は2015年2月20日に有効期限が切れます。いずれかの条件(新規リリースが入手可能になるか、有効期限に到達する)が一致した場合、Javaは新しいバージョンにアップデートするよう、追加の警告とリマインダを表示します。

Bug修正

このリリースには、セキュリティの脆弱性に関する修正が含まれています。詳細は、Oracle Java SEクリティカル・パッチ・アップデート・アドバイザリを参照してください。

このリリースで行われたbug修正の一覧については、JDK 8u25のBug修正のページを参照してください。

» 8u25リリース・ノート


Java 8 Update 20 (8u20)

リリースのハイライト
  • 新規のフラグがJava管理APIに追加された
    MinHeapFreeRatioおよびMaxHeapFreeRatioのフラグが管理可能になりました。つまり、これらはJavaで管理APIを使用して実行時に変更できます。これらのフラグのサポートは、対応可能サイズ・ポリシーの一環としてParallelGCにも追加されています。
  • Javaインストーラの変更
    • ユーザーが企業全体にJREをインストールできる新しいMicrosoft Windowsインストーラ(MSI) Enterprise JREインストーラが使用可能です。詳細は、Microsoft WindowsのJREインストールインストーラのダウンロードの項を参照してください。MSI Enterprise JREインストーラは、Java SE AdvancedまたはJava SE Suiteの一部としてのみ使用可能です。これらの市販製品の詳細は、Java SE AdvancedおよびJava SE Suiteを参照してください。
    • Javaアンインストール・ツールがインストーラに統合され、システムから古いバージョンのJavaを削除するオプションができました。この変更は、32ビットと64ビットのWindowsプラットフォームに適用されます。JREのアンインストールを参照してください。
  • Javaコントロール・パネルの変更
    • Javaコントロール・パネルの「更新」タブで、32ビット・バージョンのみでなく、システムにインストールされている64ビットJREを自動的に更新できるようになりました。
    • 「中」セキュリティ・レベルは削除されました。使用可能なレベルは、「高」「非常に高」のみになりました。最新のセキュリティ上の措置に従っていないアプレットにも、それをホスティングするサイトを例外サイト・リストに含めることにより、実行権限を付与できます。例外サイト・リストを使用すると、ユーザーは、「中」オプションを選択して許可されるアプレットと同じアプレットをサイトごとで許可できるため、より緩やかな設定を使用する場合のリスクを最小限に抑えられます。
  • Javaコンパイラが更新されました
    javacコンパイラは、"this"を使用したブランクfinalフィールド・アクセスのために有限の割当て分析を実装するように更新されました。詳細は、JDK 8互換性ガイドを参照してください。
  • Java PluginおよびJava Webstartに最小限必要なJavaバージョンの変更
    Java PluginおよびJava Webstartに必要なJavaの最小バージョンはJava 5になりました。Java 5以降で稼働しないアプレットを引き続き機能させるには、新しいバージョンのJavaに移植する必要があります。以前のバージョン用に作成されていても少なくともJava 5で実行できるアプレットは、引き続き動作します。
  • UsageTracker出力形式の変更
    UsageTracker出力形式は、ログ内での混同を避けるために引用符を使用するように変更されました。これには、このような情報の読取り方法の変更が必要な場合があります。機能は以前のバージョンと同様に動作するように構成できますが、新しい形式をお薦めします。Java使用方法トラッカー・ドキュメントを参照してください。
  • Javaパッケージング・ツールの変更
    • javafxpackagerはjavapackagerに名前変更されました
    • javapackagerデプロイ・コマンドに"-B"オプションが追加され、自己完結型アプリケーションの作成に使用される引数をバンドラに渡せるようになりました。詳細は、javapackager (Windows)/(UNIX)ドキュメントを参照してください。
    • ヘルパー・パラメータ引数がJavaFX Antタスク参照に追加されました。これにより、自己完結型アプリケーションの作成に使用されるバンドラ用引数を(要素で)指定できます。
Javaの有効期限

8u20の有効期限は、2014年10月14日です。セキュリティ上の脆弱性の修正を含む新しいリリースが入手可能になると、Javaの有効期限が切れます。Oracle Serverに到達できないシステムの場合、セカンダリ・メカニズムにより、このJRE(バージョン8u20)は2014年11月14日に有効期限が切れます。いずれかの条件(新規リリースが入手可能になるか、有効期限に到達する)が一致した場合、Javaは新しいバージョンにアップデートするよう、追加の警告とリマインダを表示します。

Bug修正

このリリースで行われたbug修正の一覧については、JDK 8u20のBug修正のページを参照してください。

» 8u20リリース・ノート


Java 8 Update 11 (8u11)

このリリースには、セキュリティの脆弱性に関する修正が含まれています。詳細は、Oracleクリティカル・パッチ・アップデート・アドバイザリを参照してください。

このリリースで行われたbug修正の一覧については、JDK 8u11のBug修正のページを参照してください。

» 8u11リリース・ノート


Java 8 Update 5 (8u5)

このリリースには、セキュリティの脆弱性に関する修正が含まれています。詳細は、Oracleクリティカル・パッチ・アップデート・アドバイザリを参照してください。

このリリースで行われたbug修正の一覧については、JDK 8u5のBug修正のページを参照してください。

» 8u5リリース・ノート


Java 8リリース

» JDKおよびJRE 8リリース・ノート


次のものにも関心を持たれるかもしれません:




言語の選択 | Javaについて | サポート | 開発者
プライバシ  | 使用条件 | 商標 | 免責条項

Oracle