Java.com

ダウンロード ヘルプ

印刷可能バージョン

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


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

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


Java 8 Update 221 (8u221)

リリースのハイライト
  • IANA Data 2018i
    JDK 8u221にはIANAタイム・ゾーン・データのバージョン2018iが含まれています。詳細は、JREソフトウェアのタイムゾーン・データ・バージョンを参照してください。
  • 新機能: HotSpot Windows OS検出でWindows Server 2019を正しく識別
    この修正が行われるまで、Windows Server 2019は"Windows Server 2016"と認識され、os.nameシステム・プロパティとhs_err_pidファイルに間違った値が生成されていました。
    JDK-8211106を参照してください
  • 削除された機能およびオプション: 2つのDocuSignルートCA証明書の削除
    2つのDocuSignルートCA証明書が期限切れになり、cacertsキーストアから削除されました。
    • alias name "certplusclass2primaryca [jdk]"
      Distinguished Name: CN=Class 2 Primary CA, O=Certplus, C=FR
    • alias name "certplusclass3pprimaryca [jdk]"
      Distinguished Name: CN=Class 3P Primary CA, O=Certplus, C=FR
    JDK-8223499を参照してください
  • 削除された機能およびオプション: 2つのComodoルートCA証明書の削除
    2つのComodoルートCA証明書が期限切れになり、cacertsキーストアから削除されました。
    • alias name "utnuserfirstclientauthemailca [jdk]"
      Distinguished Name: CN=UTN-USERFirst-Client Authentication and Email, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
    • alias name "utnuserfirsthardwareca [jdk]"
      Distinguished Name: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
    JDK-8222136を参照してください
  • 削除された機能およびオプション: T-Systems Deutsche Telekom Root CA 2証明書の削除
    T-Systems Deutsche Telekom Root CA 2証明書が期限切れになり、cacertsキーストアから削除されました。
    • alias name "deutschetelekomrootca2 [jdk]"
      Distinguished Name: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE
    JDK-8222137を参照してください
  • その他の注意: Java Access Bridgeのインストール回避策
    以前インストールしたバージョンのJavaとJAWSのインスタンスの両方が実行されているWindowsシステムにJavaをインストールする場合、Java Access Bridgeの機能が中断されるリスクがあります。再起動後、64ビットJava製品の場合はシステム・ディレクトリ(C:\Windows\System32)、32ビットJava製品の場合はWOW64によって使用されるシステム・ディレクトリ(C:\Windows\SysWoW64)にWindowsAccessBridge-64.dllがない状態になる可能性があります。
    Java Access Bridgeの機能が中断されるのを防止するには、次のいずれかの回避策を使用します。
    • Javaインストーラを実行する前にJAWSを停止します。
    • 新しいバージョンのJavaをインストールする前に、既存のJREをアンインストールします。
    • 新しいバージョンのJavaがインストールされ、マシンが再起動された後、既存のJREをアンインストールします。
    回避策の目的は、JAWSの実行中にJavaインストーラから既存のJREをアンインストールするシナリオを回避することです。
    JDK-8223293 (非公開)
Javaの有効期限

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

Bug修正

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

» 8u221リリース・ノート


Java 8 Update 211 (8u211)

リリースのハイライト
  • IANA Data 2018g
    JDK 8u211にはIANAタイム・ゾーン・データのバージョン2018gが含まれています。詳細は、JREソフトウェアのタイムゾーン・データ・バージョンを参照してください。
  • 新機能: 日本の新元号のスクエア文字のサポート
    コード・ポイントU+32FFは、2019年5月に始まる新元号の日本語スクエア文字を表すために、Unicode Consortiumにより予約されています。Characterクラスの関連するメソッドは、日本の既存の元号文字(明治のU+337Eなど)と同じプロパティを戻します。コード・ポイントの詳細は、http://blog.unicode.org/2018/09/new-japanese-era.htmlを参照してください。
    JDK-8211398を参照してください
  • 変更: GlobalSign R6ルート証明書の追加
    OpenJDK cacertsトラストストアに次のルート証明書が追加されました:
    • GlobalSign
      • globalsignrootcar6
        DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R6

    JDK-8216577 (非公開)
  • 変更: SymantecルートによりアンカーされているTLSサーバー証明書の信頼停止
    JDKは、Google、Mozilla、AppleおよびMicrosoftが最近発表したものと同様の計画に沿って、Symantecが発行したTLSサーバー証明書の信頼を停止します。影響を受ける証明書のリストには、Symantecが管理するGeoTrust、Thawte、およびVeriSignなどのブランド名の証明書が含まれます。
    2019年4月16日以前に発行されたTLSサーバー証明書は、有効期限まで引き続き信頼します。この日より後に発行された証明書は拒否します。Symantecの証明書をDigiCertの証明書に置き換える方法の詳細は、DigiCertのサポート・ページをご覧ください(DigiCertは2017年12月1日にSymantec Website Security SSL/TLS証明書の検証および発行を引き継ぎました)。
    下に示す、Appleが管理する2つの下位認証局によって発行されたTLSサーバー証明書はこのポリシーの例外であり、2019年12月31日以前に発行されたものであれば、引き続き信頼します。
    JDK-8207258を参照してください
  • 変更: 日本の新しい元号の名前
    2019年5月1日に始まった日本の元号用のプレースホルダ名"NewEra"を、日本政府が発表した名前"Reiwa"に置き換えました。新しい元号のシングルトン(JapaneseEra.valueOf("NewEra"))の取得を、このプレースホルダ名に依存しているアプリケーションは機能しなくなります。
    JDK-8205432を参照してください
  • 変更: java.time.chrono.JapaneseEraにおける日本の新元号のサポート
    JapaneseEraクラス、およびそのof(int)valueOf(String)values()メソッドは、シングルトン・インスタンスの定義方法や関連付けられる元号の整数値など、今後の日本の元号に関する追加内容に対応するよう明確化されました。
    JDK-8212941を参照してください
Javaの有効期限

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

Bug修正

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

» 8u211リリース・ノート


Java 8 Update 201 (8u201)

リリースのハイライト
  • IANA Data 2018e
    JDK 8u201にはIANAタイム・ゾーン・データのバージョン2018eが含まれています。詳細は、JREソフトウェアのタイムゾーン・データ・バージョンを参照してください。
  • 変更: TLS anonおよびNULL暗号スイートが無効化されました
    TLS anon (匿名)およびNULL暗号スイートがjdk.tls.disabledAlgorithmsセキュリティ・プロパティに追加され、現在はデフォルトで無効化されています。
    JDK-8211883を参照してください
  • 変更: jarsignerがタイムスタンプの有効期限が切れる時期を出力します
    jarsignerツールは、現在、タイムスタンプ付きのJARの存続期間に関する詳細情報を示しています。タイムスタンプの有効期限がすでに切れているか、1年以内に切れる場合、新しい警告およびエラー・メッセージが表示されます。
    JDK-8191438を参照してください
Javaの有効期限

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

Bug修正

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

» 8u201リリース・ノート


Java 8 Update 191 (8u191)

リリースのハイライト
  • IANA Data 2018e
    JDK 8u191にはIANAタイム・ゾーン・データのバージョン2018eが含まれています。詳細は、JREソフトウェアのタイムゾーン・データ・バージョンを参照してください。
  • 変更: usagetracker.propertiesファイルのファイル・システム内の中央の場所が変更されました
    usagetracker.propertiesファイルのWindows内のファイル・システムの場所が%ProgramData%\Oracle\Java\から%ProgramFiles%\Java\confに変更されました
    Linux、SolarisまたはmacOSのファイル・パスに変更はありません。JDK-8204901 (非公開)
  • 変更: すべてのDES TLS暗号スイートが無効化されました
    DESベースのTLS暗号スイートは廃止とみなされるため、今後使用しないでください。"DES"識別子をjdk.tls.disabledAlgorithmsセキュリティ・プロパティに追加することによって、DESベースの暗号スイートはSunJSSEE実装においてデフォルトで非アクティブ化されました。java.securityファイルのjdk.tls.disabledAlgorithmsセキュリティ・プロパティから"DES"を削除するか、Security.setProperty()メソッドを動的に呼び出すことで、これらの暗号スイートを再度アクティブにできます。いずれの場合も、DESを再度有効化した後は、SSLSocket.setEnabledCipherSuites()またはSSLEngine.setEnabledCipherSuites()メソッドを使用して、有効化されている暗号スイートのリストにDESベースの暗号スイートを追加する必要があります。
    この変更の前に、DES40_CBC (すべてのDESではありません)スイートはjdk.tls.disabledAlgorithmsセキュリティ・プロパティによって無効化されていたことに注意してください。
    JDK-8208350を参照してください
  • 変更: 複数のSymantecルートCAの削除
    次のSymantecルート証明書は使用されなくなり、削除されています。
    • Symantec
      • equifaxsecureca
        DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
      • equifaxsecureglobalebusinessca1
        DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
      • equifaxsecureebusinessca1
        DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US
      • verisignclass1g3ca
        DN: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
      • verisignclass2g3ca
        DN: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
      • verisignclass1g2ca
        DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
      • verisignclass1ca
        DN: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US

    JDK-8191031を参照してください
  • 変更: Baltimore Cybertrustコード署名証明書発行局の削除
    次のBaltimore CyberTrustコード署名ルート証明書は使用されなくなり、削除されています。
    • baltimorecodesigningca
      DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE

    JDK-8189949を参照してください
  • Bug修正: LDAPS通信障害
    ソケット接続タイムアウトが<= 0 (デフォルト値)のLDAPSを使用するアプリケーション・コードが、20018年7月版のCPU(8u181、7u191および6u201)で実行される場合、接続を確立しようとすると例外が発生することがあります。
    このような問題が発生するアプリケーションの例外スタック・トレースの最上位のフレームは、次のようになります。
    javax.naming.ServiceUnavailableException: ; socket closed
    at com.sun.jndi.ldap.Connection.readReply(Unknown Source)
    at com.sun.jndi.ldap.LdapClient.ldapBind(Unknown Source) ...
    問題は解決済であり、次のリリースで修正を入手できます。
    • 8u181
    • 7u191

    JDK-8211107を参照してください
Javaの有効期限

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

Bug修正

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

» 8u191リリース・ノート


Java 8 Update 181 (8u181)

リリースのハイライト
  • IANA Data 2018e
    JDK 8u181にはIANAタイム・ゾーン・データのバージョン2018eが含まれています。詳細は、JREソフトウェアのタイムゾーン・データ・バージョンを参照してください。
  • 削除された機能: Java DBの削除
    Apache Derbyとも呼ばれるJava DBはこのリリースで削除されました。
    次の場所にあるApacheプロジェクトから最新のApache Derbyを直接入手することをお薦めします。
    https://db.apache.org/derby
    JDK-8197871 (非公開)
  • 変更: LDAPサポートの向上
    LDAPS接続でエンドポイント識別が有効になりました。
    LDAPS (セキュリティで保護されたLDAP over TLS)接続の堅牢性を向上させるために、エンドポイント識別アルゴリズムがデフォルトで有効になりました。
    以前はLDAPSサーバーに正常に接続できた一部のアプリケーションが接続できなくなる状況が発生する場合があります。このようなアプリケーションでは、新しいシステム・プロパティcom.sun.jndi.ldap.object.disableEndpointIdentificationを使用してエンドポイント識別を無効にできます(適切と思える場合)。
    このシステム・プロパティを定義(またはtrueに設定)して、エンドポイント識別アルゴリズムを無効にします。
    JDK-8200666 (非公開)
  • 変更: スタック・ウォーキングの向上
    デシリアライズのオブジェクト作成フェーズ中に新しいアクセス・チェックが追加されました。これは、通常のデシリアライズの使用には影響しません。ただし、JDK内部APIを利用するリフレクティブ・フレームワークは影響を受ける可能性があります。新しいチェックは、システム・プロパティjdk.disableSerialConstructorChecksの値を"true"に設定することで必要に応じて無効にできます。これは、引数-Djdk.disableSerialConstructorChecks=trueをJavaコマンドラインに追加することで行う必要があります。
    JDK-8197925 (非公開)
  • Bug修正: G1 GC中のJVMクラッシュ
    G1の同時マーキングによって到達不能とみなされたクラスをClassLoaderData/SystemDictionaryで参照でき、その_java_mirrorまたは_class_loaderフィールドをルートまたは他の到達可能オブジェクトに格納して再度有効にできます。クラスがこの方法で復元されるたびに、これについてG1のSATB部分に通知する必要があり、そうしないと同時マーキングの注釈フェーズでそのクラスが間違ってアンロードされます。
    JDK-8187577を参照してください
  • Bug修正: 古いNUMAライブラリ(-XX+UseNuma)の安定性の向上
    JDK 8 Update 152に含まれる修正により、libnumaのバージョンが2.0.9より前のLinuxシステムでUseNUMAフラグが使用されている場合に、起動時にHotSpot JVMがクラッシュする可能性があるという退行が導入されました。この問題は解決されています。
    JDK-8198794を参照してください
Javaの有効期限

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

Bug修正

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

» 8u181リリース・ノート


Java 8 Update 171 (8u171)

リリースのハイライト
  • IANA Data 2018c
    JDK 8u171にはIANAタイム・ゾーン・データのバージョン2018cが含まれています。詳細は、JREソフトウェアのタイムゾーン・データ・バージョンを参照してください。
  • 新機能: 拡張キーストア・メカニズム
    jceks.key.serialFilterという名前の新しいセキュリティ・プロパティが導入されました。このフィルタが構成されている場合は、SecretKeyEntryの内部に格納されている暗号化されたキー・オブジェクトのデシリアライズ中にJCEKSキーストアによって使用されます。構成されていないかフィルタ結果がUNDECIDEDの場合(たとえば、いずれのパターンも一致しない場合)は、jdk.serialFilterによって構成されたフィルタが確認されます。
    システム・プロパティjceks.key.serialFilterも指定されている場合は、ここで定義されているセキュリティ・プロパティ値よりも優先されます。
    フィルタ・パターンでは、jdk.serialFilterと同じ形式が使用されます。デフォルトのパターンでは、java.lang.Enum、java.security.KeyRep、java.security.KeyRep$Typeおよびjavax.crypto.spec.SecretKeySpecが許可されますが、他はすべて拒否されます。
    上のタイプにシリアライズしないSecretKeyを格納している顧客は、フィルタを変更してキーを抽出可能にする必要があります。
    JDK-8189997 (非公開)
  • 新機能: JRE最終使用追跡を無効にするシステム・プロパティ
    実行中のVMのJRE最終使用追跡を無効にする新しいシステム・プロパティjdk.disableLastUsageTrackingが導入されました。このプロパティは、コマンド・ラインで-Djdk.disableLastUsageTracking=trueまたは-Djdk.disableLastUsageTrackingを使用して設定できます。このシステム・プロパティが設定されている場合、JRE最終使用追跡は、usagetracker.propertiesで設定されたcom.oracle.usagetracker.track.last.usageプロパティ値に関係なく無効になります。
    JDK-8192039 (非公開)
  • 注意: CipherOutputStream Usage
    javax.crypto.CipherOutputStreamの指定が明確化され、BadPaddingExceptionおよび暗号化中に失敗した整合性チェックによってスローされたその他の例外がこのクラスによって捕捉されることを指定します。これらの例外は再スローされないため、クライアントは整合性チェックが失敗したことを通知されません。この動作により、このクラスは、認証が失敗したときにアプリケーションが明示的な通知を必要とする場合に、操作の認証モード(たとえば、GCMなど)の暗号化で使用するのには適していない可能性があります。これらのアプリケーションは、このクラスを使用するかわりにCipher APIを直接使用できます。
    JDK-8182362 (非公開)
  • 変更: 追加のTeliaSoneraルート証明書
    "TeliaSonera Root CA v1"がcacertsキーストアに追加されました。
    JDK-8190851 (非公開)
  • 変更: 224ビット未満のECキーで署名されたXML署名は無効になりました
    SSL/TLS接続の強度を高めるために、3DES暗号スイートはjdk.tls.disabledAlgorithmsセキュリティ・プロパティを介してJDKのSSL/TLS接続で無効にされました。
    JDK-8175075 (非公開)
  • Bug修正: サーバー側HTTPトンネリングRMI接続は無効になりました
    サーバー側HTTPトンネリングRMI接続は、このリリースではデフォルトで無効になりました。この動作は、ランタイム・プロパティsun.rmi.server.disableIncomingHttpfalseに設定すると元に戻すことができます。このプロパティを、クライアント側でHTTPトンネリングを無効にし、デフォルトでfalseになるsun.rmi.server.disableHttpプロパティと混同しないでください。
    JDK-8193833 (非公開)
Javaの有効期限

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

Bug修正

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

» 8u171リリース・ノート


Java 8 Update 161 (8u161)

リリースのハイライト
  • IANA Data 2017c
    JDK 8u161にはIANAタイム・ゾーン・データのバージョン2017cが含まれています。詳細は、JREソフトウェアのタイムゾーン・データ・バージョンを参照してください。
  • 新機能: 最大8192ビットのDHEサイズと最大3072ビットのDSAサイズのサポート
    3072ビットのDiffieHellmanとDSAパラメータの生成、最大8192ビットの事前に計算されたDiffieHellmanパラメータおよび最大3072ビットの事前に計算されたDSAパラメータをサポートするようにJDKセキュリティ・プロバイダを拡張します。
    JDK-8072452を参照してください
  • 新機能: ネゴシエーションされたTLS用Finite Field Diffie-Hellman Ephemeral Parameters
    JDK SunJSSE実装は、RFC 7919で定義されているTLS FFDHEメカニズムをサポートするようになりました。サーバーがsupported_groups TLS拡張または拡張内の名前付きグループを処理できない場合、アプリケーションはサポートされるグループ名をjdk.tls.namedGroupsでカスタマイズするか、システム・プロパティjsse.enableFFDHEExtensionfalseに設定してFFDHEメカニズムをオフにできます。
    JDK-8140436を参照してください
  • 新機能: org.omg.CORBA.ORBstring_to_objectメソッドへの追加のIDLスタブ・タイプ・チェックの追加
    org.omg.CORBA.ORB.string_to_objectを明示的または暗黙的に呼び出し、ORB::string_to_object呼出しフローに含まれるIDLスタブ・タイプの整合性の確保が必要なアプリケーションでは、追加のIDLスタブ・タイプ・チェックを指定する必要があります。これは"オプト・イン"機能であり、デフォルトでは有効になりません。
    追加のタイプ・チェックを利用するために、IDLスタブ・クラスの有効なIDLインタフェース・クラス名のリストが次のいずれかで構成されます。
    • Java SE 9のファイルconf/security/java.securityまたはJava SE 8以前のjre/lib/security/java.securityにあるセキュリティ・プロパティcom.sun.CORBA.ORBIorTypeCheckRegistryFilterの指定。
    • クラスのリストでのシステム・プロパティcom.sun.CORBA.ORBIorTypeCheckRegistryFilterの指定。システム・プロパティが設定されている場合、その値はjava.security構成で定義されている対応するプロパティを上書きします。

    com.sun.CORBA.ORBIorTypeCheckRegistryFilterプロパティが設定されていない場合、タイプ・チェックは組込みIDLスタブ・クラスに対応するIDLインタフェース・タイプのクラス名のセットに対してのみ実行されます。
    JDK-8160104 (非公開)
  • 変更: RSA公開キーの検証
    8u161では、SunRsaSignプロバイダのRSA実装は、PKCS#1バージョン2.2で定義された有効な範囲内にない指数を持つRSA公開キーを拒否します。この変更は、JSSE接続およびJCEに構築されたアプリケーションに影響します。
    JDK-8174756 (非公開)
  • 変更: 1024ビット未満のDiffie-Hellmanキーの制限
    1024ビット未満のDiffie-Hellmanキーは、実際に使用するには脆弱すぎると考えられるため、SSL/TLS/DTLS接続ではデフォルトで制限する必要があります。そのため、1024ビット未満のDiffie-Hellmanキーは、"DH keySize < 1024"をjava.securityファイルの"jdk.tls.disabledAlgorithms"セキュリティ・プロパティに追加することで、デフォルトで無効にされています。推奨はされませんが、管理者はセキュリティ・プロパティ("jdk.tls.disabledAlgorithms")を更新し、より小さいキー・サイズを(たとえば、"DH keySize < 768"を設定して)許可できます。
    JDK-8148108 (非公開)
  • 変更: プロバイダのデフォルト・キー・サイズが更新されました
    この変更により、アプリケーションがjava.security.KeyPairGeneratorおよびjava.security.AlgorithmParameterGeneratorオブジェクトをキー・サイズで明示的に初期化していない場合に、DSAのデフォルト・キー・サイズとして1024ビットではなく2048ビットを使用するようにJDKプロバイダが更新されます。
    互換性の問題が発生した場合、既存のアプリケーションはJDK-8181048で導入されたシステム・プロパティjdk.security.defaultKeySizeをアルゴリズムと目的のデフォルト・キー・サイズで設定できます。
    JDK-8178466 (非公開)
Javaの有効期限

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

Bug修正

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

» 8u161リリース・ノート


Java 8 Update 151 (8u151)

リリースのハイライト
  • IANA Data 2017b
    JDK 8u151にはIANAタイム・ゾーン・データのバージョン2017bが含まれています。詳細は、JREソフトウェアのタイムゾーン・データ・バージョンを参照してください。
  • 証明書の変更: 失効したSwisscomルート証明書"swisscomrootevca2"の削除
    1つのSwisscomルート証明書がSwisscomによって失効され、削除されました: Swisscom Root EV CA 2
    alias: "swisscomrootevca2 [jdk]"
    DN: CN=Swisscom Root EV CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch
    JDK-8186330 (非公開)
  • 新機能 暗号ポリシーを制御するための新規セキュリティ・プロパティ
    このリリースでは、JDKで使用されるJCE管轄ポリシー・ファイルを新規セキュリティ・プロパティによって制御できる新機能が導入されます。旧リリースでは、無制限の暗号化をJDKで使用できるように、JCE管轄ファイルを別途ダウンロードおよびインストールする必要がありました。ダウンロードおよびインストールの手順は不要になりました。無制限の暗号化を有効にするには、新規のcrypto.policyセキュリティ・プロパティを使用できます。新規のセキュリティ・プロパティ(crypto.policy)がjava.securityファイルで設定されている場合、またはJCEフレームワークが初期化される前にSecurity.setProperty()コールを使用して動的に設定されている場合、その設定は有効です。デフォルトでは、プロパティは未定義です。プロパティが未定義で、レガシーJCE管轄ファイルがレガシーlib/securityディレクトリに存在しない場合、デフォルト暗号化レベルは'limited'のままです。無制限の暗号化を使用するようにJDKを構成するには、crypto.policyを'unlimited'の値に設定します。詳細は、このリリースに付属するjava.securityファイルのノートを参照してください。

    注意: Solarisの場合、新規のJDKアップデートをインストールする前に旧SVR4パッケージを削除することをお薦めします。(旧パッケージをアンインストールしないで)SVR4ベースのアップグレードが6u131、7u121、8u111より前のJDKリリースで行われる場合は、新規のcrypto.policyセキュリティ・プロパティをjava.securityファイルで設定する必要があります。

    旧JCE管轄ファイルは<java-home>/lib/securityに残されるため、6u131、7u121、8u111およびさらに最新のアップデートでリフレッシュされている、最新のセキュリティJAR署名標準を満たさない可能性があります。旧ファイルが使用されている場合、次のような例外が表示される可能性があります:

    Caused by: java.lang.SecurityException: Jurisdiction policy files are not signed by trusted signers! at javax.crypto.JceSecurity.loadPolicies(JceSecurity.java:593) at javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:524)

    JDK-8157561を参照してください
  • 変更点 キーの長さのデフォルト値に同じ定数を参照するように、既存のプロバイダをリファクタします
    2つの重要な変更がこの問題のために実施されています:
    1. KeyPairGeneratorおよびAlgorithmParameterGeneratorのJDKプロバイダ実装によって使用されるデフォルト・キー・サイズをユーザーが構成できるようになる、新規のシステム・プロパティが導入されています。これは"jdk.security.defaultKeySize"というプロパティで、このプロパティの値はカンマ区切りされたエントリのリストです。各エントリは、大/小文字を区別しないアルゴリズム名と、':'で区切られた対応するデフォルト・キー・サイズ(10進数)で構成されています。また、空白は無視されます。

    デフォルトでは、このプロパティには値がなく、JDKプロバイダは固有のデフォルト値を使用します。認識できないアルゴリズム名が含まれるエントリは無視されます。指定されたデフォルト・キー・サイズが解析可能な10進整数ではない場合、そのエントリは同様に無視されます。

    1. SUNプロバイダのDSA KeyPairGenerator実装では、java.security.interfaces.DSAKeyPairGeneratorはもう実装されません。SUNプロバイダのDSA KeyPairGeneratorオブジェクトをjava.security.interfaces.DSAKeyPairGeneratorにキャストするアプリケーションは、システム・プロパティ"jdk.security.legacyDSAKeyPairGenerator"を設定できます。このプロパティの値が'true'の場合、SUNプロバイダは、java.security.interfaces.DSAKeyPairGeneratorインタフェースを実装するDSA KeyPairGeneratorオブジェクトを返します。このレガシー実装では、インタフェースのjavadocで指定されているのと同じデフォルト値が使用されます。
    デフォルトではこのプロパティに値はなく、SUNプロバイダはDSA KeyPairGeneratorオブジェクトを返します。このオブジェクトは前述したインタフェースを実装しないため、java.security.KeyPairGeneratorクラスに示されているとおりに、または'jdk.security.defaultKeySize'システム・プロパティ(設定されている場合)によって、プロバイダ固有のデフォルト値を決定できます。
    JDK-8181048 (非公開)
Javaの有効期限

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

Bug修正

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

» 8u151リリース・ノート


Java 8 Update 144 (8u144)

リリースのハイライト
  • IANA Data 2017b
    JDK 8u144にはIANAタイム・ゾーン・データのバージョン2017bが含まれています。詳細は、JREソフトウェアのタイムゾーン・データ・バージョンを参照してください。
  • Bug修正: java.util.zip.ZipFile.getEntry()が、常に、ディレクトリ・エントリの/で終わるエントリ名で、ZipEntryインスタンスを戻すようになりました
    java.util.zip.ZipEntry APIドキュメントでは、「ディレクトリ・エントリは、名前が/で終わるように定義されている」と指定されています。ただし、旧リリースのJDKでは、渡された引数entryName/で終わっておらず、zipファイルにentryName + /という名前の一致するzipディレクトリ・エントリがある場合、java.util.zip.ZipFile.getEntry(String entryName)は、既存のzipディレクトリ・エントリの/で終わらない名前でZipEntryインスタンスを戻します。このリリースでは、どのzipディレクトリ・エントリの場合でも、java.util.zip.ZipFile.getEntry()から戻されるZipEntryインスタンスの名前は、常に/で終わります。
    以前の動作に戻す場合は、システム・プロパティjdk.util.zip.ensureTrailingSlashを'false'に設定します。

    この変更は、署名付きJARの検証が、一部のWebStartアプリケーションのロード失敗の原因になるという、JDK 8u141で発生したリグレッションを修正するために行われました。
    JDK-8184993を参照してください
Javaの有効期限

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

Bug修正

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

» 8u144リリース・ノート


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 (非公開)
  • 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 (非公開)
  • カスタムHostnameVerifierでSNI拡張が可能に
    旧リリースのJDK 8 Updateでは、カスタム・ホスト名検証を使用した場合に、TLS ClientHelloフェーズでServer Name Indication (SNI)拡張が送信されない場合がありました。この検証は、HttpsURLConnectionsetHostnameVerifier(HostnameVerifier v)メソッドで設定します。この修正により、サーバー名がClientHello本文で確実に送信されるようになりました。
    JDK-8144566を参照してください
  • アルゴリズム制約チェックの改善
    弱いアルゴリズムが最も脆弱になる状況で、その使用を制限する必要性を受けて、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ファイルの証明書内のアルゴリズムを制限します。使用方法タイプはキーワードの後ろで、1つ以上の使用方法タイプを空白で区切って指定できます。
      たとえば、"SHA1 usage TLSServer TLSClient"では、TLSServerおよびTLSClient操作ではSHA1証明書は使用できませんが、SignedJarは許可されます

    これらの制約はいずれも、組み合せて'&'で区切ると、特定のアルゴリズムを制約することができます。たとえば、マーク済のトラスト・アンカーで終了する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のような弱い署名アルゴリズムで署名されていた場合、出力は次のようになります:

    このjarは、現在無効になっている弱いアルゴリズムで署名されているため、署名なしとして扱われます。詳細は、-verboseオプションを使用してjarsignerを再実行してください。

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

    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を参照してください

既知の問題
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 (非公開)

Bug修正

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

Javaの有効期限

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

» 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を参照してください。JDK-8061886(非公開)を参照してください。

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