Java.com

下載 說明

可列印版本

Java 8 發行版本重點


本文適用於:
  • Java 版本: 8.0

此頁面針對每一個 Java 發行版本,重點列出影響一般使用者的變更。您可以在版本注意事項中找到變更的相關詳細資訊。
» Java 發行日期


Java 8 Update 251 (8u251)

發行版本重點
  • IANA Data 2019c
    JDK 8u251 包含 IANA 時區資料 2019c 版。如需詳細資訊,請參閱 JRE 軟體中的時區資料版本
  • 新功能:新增對 PKCS#1 v2.2 演算法的支援 (包括 RSASSA-PSS 簽章)
    SunRsaSign 和 SunJCE 提供者已增強支援 PKCS#1 v2.2 中定義的更多演算法,例如 RSASSA-PSS 簽章和使用 FIPS 180-4 摘要演算法的 OAEP。已在 java.security.specjavax.crypto.spec 套裝軟體下的相關 JCA/JCE 類別新增新的建構子和方法,以支援額外的 RSASSA-PSS 參數。
    請參閱 JDK-8146293
  • 其他注意事項:WebEngine 會限制特定類別的 JavaScript 方法呼叫
    在 WebEngine 所載入網頁相關資訊環境中執行的 JavaScript 程式,可以和應用程式傳送至 JavaScript 程式的 Java 物件通訊。參照 java.lang.Class 物件的 JavaScript 程式目前限為以下方法:
    getCanonicalName
    getEnumConstants
    getFields
    getMethods
    getName
    getPackageName
    getSimpleName
    getSuperclass
    getTypeName
    getTypeParameters
    isAssignableFrom
    isArray
    isEnum
    isInstance
    isInterface
    isLocalClass
    isMemberClass
    isPrimitive
    isSynthetic
    toGenericString
    toString

    以下類別無法呼叫任何方法:
    java.lang.ClassLoader
    java.lang.Module
    java.lang.Runtime
    java.lang.System

    java.lang.invoke.*
    java.lang.module.*
    java.lang.reflect.*
    java.security.*
    sun.misc.*

    JDK-8236798 (未公開)
  • 其他注意事項:新的 Oracle 特定 JDK 8 將系統特性更新為使用傳統 Base64 編碼格式
    Oracle JDK 8u231 已將 Apache Santuario 程式庫升級為 v2.1.3。此升級會導致一個問題,使用 Base64 編碼的 XML 簽章會發生將 &#xd&#13 附加至編碼輸出的情形。此行為變更是在 Apache Santuario 程式碼庫中進行,以符合 RFC 2045。Santuario 團隊已採取相關措施,以使其程式庫符合 RFC 2045 規範。
    請參閱 JDK-8236645
將 JDK 保持在最新狀態

Oracle 建議使用每個重大修正程式更新 (CPU) 更新 JDK。為了判斷版本是否為最新版本,可以使用下列「安全基準」頁面判斷是否使用每個版本系列的最新版本。

包含安全漏洞修正的重大修正程式更新會提前一年在重大修正程式更新、安全性警示以及電子佈告欄發布。不建議在下一版重大修正程式更新發行之後 (目前排定的發行日期為 2020 年 7 月 14 日) 使用此 JDK (版本 8u251)。

對於無法連線至 Oracle 伺服器的系統,次級機制會讓本 JRE (版本 8u251) 在 2020 年 8 月 14 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),JRE 將會提供額外的警告和提醒來通知使用者更新為較新的版本。如需詳細資訊,請參閱 Java Platform, Standard Edition Deployment Guide 中的 23.1.2 JRE Expiration Date

問題修正

此發行版本同時包含 Oracle Critical Patch Update 中所述的安全漏洞修正。如需此發行版本所含問題修正的完整清單,請參閱 JDK 8u251 問題修正網頁。

» 8u251 版本注意事項


Java 8 Update 241 (8u241)

發行版本重點
  • IANA Data 2019c
    JDK 8u241 包含 IANA 時區資料 2019c 版。如需詳細資訊,請參閱 JRE 軟體中的時區資料版本
  • 新功能:允許限制 SASL 機制
    新增了可用於停用 SASL 機制的 jdk.sasl.disabledMechanisms 安全特性。在 Sasl.createSaslClientmechanisms 引數或 Sasl.createSaslServermechanism 引數中指定但停用的任何機制都會被忽略。此安全特性的預設值是空的,代表預設不會停用任何機制。
    請參閱 JDK-8200400
  • 新功能:SunPKCS11 提供者已升級為支援 PKCS#11 v2.40
    SunPKCS11 提供者已升級為支援 PKCS#11 v2.40。底層的 PKCS11 安全庫若支援相對應的 PKCS11 機制,此版本新增了更多的演算法支援,例如 AES/GCM/NoPadding 密碼、使用 SHA-2 系列訊息摘要的 DSA 簽章以及 RSASSA-PSS 簽章。
    請參閱 JDK-8080462
  • 其他注意事項:新的信任錨點憑證檢查
    新增了新的檢查,以確保信任錨點為 CA 憑證且包含正確的擴充功能。信任錨點主要用於驗證 TLS 和已簽署程式碼中所使用的憑證鏈。信任錨點憑證必須包含 cA 欄位設為 true 的基本限制條件擴充功能。此外,若包含金鑰使用擴充功能的話,必須設定 keyCertSign 位元。
    JDK-8230318 (未公開)
  • 其他注意事項:必須完全符合信任的 TLS 伺服器憑證
    TLS 伺服器憑證必須是從屬端上的信任憑證,建立 TLS 連線時才會受到信任。
    JDK-8227758 (未公開)
  • 其他注意事項:增加 LuxTrust Global Root 2 憑證
    cacerts 信任存放區新增了 LuxTrust 根憑證
    請參閱 JDK-8232019
  • 其他注意事項: 增加 4 個 Amazon 根 CA 憑證
    cacerts 信任存放區新增了 Amazon 根憑證
    請參閱 JDK-8233223
  • 問題修正:支援 OpenType CFF 字型
    之前,Oracle JDK 8 並未在標準邏輯字型 (例如 "Dialog" 和 "SansSerif") 中包含 OpenType CFF 字型 (.otf 字型)。這導致在呈現文字時遺漏字形。在系統上只安裝 CFF 字型的最極端情況下,可能會發生 Java 異常狀況。
    數個 Linux 發行版本均受到此問題的影響,因為這些發行版本仰賴 CFF 字型來支援部分語言,此情形常見於 CJK (中文、日文及韓文) 語言。
    Oracle JDK 8 現在使用這些 CFF 字型,並已解決此問題。
    請參閱 JDK-8209672
  • 問題修正:更佳的序列篩選處理
    jdk.serialFilter 系統特性只能在命令行設定。若未在命令行設定此篩選,可以使用 java.io.ObjectInputFilter.Config.setSerialFilter 設定。使用 java.lang.System.setProperty 設定 jdk.serialFilter 無效。
    JDK-8231422 (未公開)
Java 到期日

8u241 的到期日為 2020 年 4 月 14 日。每當具有安全漏洞修正的新版本可供使用時,Java 便會到期。對於無法連線至 Oracle 伺服器的系統,次級機制會讓本 JRE (版本 8u241) 在 2020 年 5 月 14 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),JRE 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

此發行版本同時包含 Oracle Critical Patch Update 中所述的安全漏洞修正。如需此發行版本所含問題修正的完整清單,請參閱 JDK 8u241 問題修正網頁。

» 8u241 版本注意事項


Java 8 Update 231 (8u231)

發行版本重點
  • IANA Data 2019b
    JDK 8u231 包含 IANA 時區資料 2019b 版。如需詳細資訊,請參閱 JRE 軟體中的時區資料版本
  • 新功能:新的 jdk.jceks.iterationCount 系統特性
    導入新的系統特性,以控制用於 jceks 金鑰儲存庫的迭代計數值。預設值維持在 200000,但是可以指定 10000 到 5000000 之間的值。新的系統特性名為 jdk.jceks.iterationCount,提供的值必須是可接受範圍內的整數。如果發生剖析錯誤,則將會使用預設值。
    JDK-8223269 (未公開)
  • 新功能:新的 Java Flight Recorder (JFR) 安全事件
    在安全庫區域新增了四種新的 JFR 事件。這些事件預設為停用,可以透過 JFR 組態檔或標準 JFR 選項加以啟用。
    請參閱 JDK-8148188
  • 移除的功能和選項:從 JavaFX 移除了 T2K 光柵化程式和 ICU 版面配置引擎
    已經從 JavaFX 移除了 T2K 光柵化程式和 ICU 版面配置引擎。
    請參閱 JDK-8187147
  • 其他注意事項:[client-libs 和 javaFX] GTK3 現在是 Linux/Unix 上的預設版本
    較新版本的 Linux、Solaris 及其他 Unix 桌面環境會使用 GTK3,但仍然支援 GTK2。
    以前 JDK 預設會載入舊版的 GTK2 程式庫。然而在此發行版本中,預設將載入 GTK3 程式庫。通常是藉由使用 Swing GTK Look And Feel 來觸發載入程序。
    可以使用以下系統特性來復原舊的行為方式:-Djdk.gtk.version=2.2
    請參閱 JDK-8222496
  • 其他注意事項:從預設的 TLS 演算法移除過時的 NIST EC 曲線
    這項變更從 TLS 交涉期間使用的預設具名群組移除了過時的 NIST EC 曲線。移除的曲線包括 sect283k1、sect283r1、sect409k1、sect409r1、sect571k1、sect571r1 及 secp256k1。
    若要重新啟用這些曲線,請使用 jdk.tls.namedGroups 系統特性。此特性包含啟用的具名群組清單,依照偏好的順序,使用雙引號括起來並且以逗號區隔。例如:
    java -Djdk.tls.namedGroups="secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1" ...
    JDK-8228825 (未公開)
Java 到期日

8u231 的到期日為 2020 年 1 月 14 日。每當具有安全漏洞修正的新版本可供使用時,Java 便會到期。對於無法連線至 Oracle 伺服器的系統,次級機制會讓本 JRE (版本 8u231) 在 2020 年 2 月 14 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),JRE 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

此發行版本同時包含 Oracle Critical Patch Update 中所述的安全漏洞修正。如需此發行版本所含問題修正的更完整清單,請參閱 JDK 8u231 問題修正網頁。

» 8u231 版本注意事項


Java 8 Update 221 (8u221)

發行版本重點
  • IANA Data 2018i
    JDK 8u221 包含 IANA 時區資料版本 2018i。如需詳細資訊,請參閱 JRE 軟體中的時區資料版本
  • 新功能:HotSpot Windows 作業系統偵測可正確識別 Windows Server 2019
    本次修正之前,Windows Server 2019 被辨識為 "Windows Server 2016",因而導致 os.name 系統特性和 hs_err_pid 檔案中的值不正確。
    請參閱 JDK-8211106
  • 移除的功能和選項:移除兩個 DocuSign Root CA 憑證
    有兩個 DocuSign Root CA 憑證都已過期,因此已自 cacerts 金鑰儲存庫中移除:
    • 別名名稱 "certplusclass2primaryca [jdk]"
      辨別名稱:CN=Class 2 Primary CA, O=Certplus, C=FR
    • 別名名稱 "certplusclass3pprimaryca [jdk]"
      辨別名稱:CN=Class 3P Primary CA, O=Certplus, C=FR
    請參閱 JDK-8223499
  • 移除的功能和選項:移除兩個 Comodo Root CA 憑證
    有兩個 Comodo Root CA 憑證都已過期,因此已自 cacerts 金鑰儲存庫中移除:
    • 別名名稱 "utnuserfirstclientauthemailca [jdk]"
      辨別名稱:CN=UTN-USERFirst-Client Authentication and Email, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
    • 別名名稱 "utnuserfirsthardwareca [jdk]"
      辨別名稱: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 金鑰儲存庫中移除:
    • 別名名稱 "deutschetelekomrootca2 [jdk]"
      辨別名稱: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 功能的風險。重新開機之後,系統目錄 C:\Windows\System32 (若為 64 位元 Java 產品) 或 WOW64 所使用的系統目錄 C:\Windows\SysWoW64 (若為 32 位元 Java 產品) 中,會沒有 WindowsAccessBridge-64.dll
    為了避免破壞 Java Access Bridge 功能,請採用下列其中一種解決方法:
    • 先停止 JAWS 後,再執行 Java 安裝程式。
    • 先解除安裝現有的 JRE 後,再安裝新版本的 Java。
    • 安裝新版本的 Java 並且將機器重新開機之後,解除安裝現有的 JRE。
    這些解決方法的目標是為避免 JAWS 在執行中時,發生 Java 安裝程式解除安裝現有 JRE 的情形。
    JDK-8223293 (未公開)
Java 到期日

8u221 的到期日為 2019 年 10 月 15 日。每當具有安全漏洞修正的新版本可供使用時,Java 便會到期。對於無法連線 Oracle 伺服器的系統,次級機制會讓此 JRE (版本 8u221) 在 2019 年 11 月 15 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),JRE 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

此發行版本同時包含 Oracle Critical Patch Update 中所述的安全漏洞修正。如需本發行版本所含問題修正的更完整清單,請參閱 JDK 8u221 問題修正網頁。

» 8u221 版本注意事項


Java 8 Update 211 (8u211)

發行版本重點
  • IANA Data 2018g
    JDK 8u211 包含 IANA 時區資料 2018g 版。如需詳細資訊,請參閱 JRE 軟體中的時區資料版本
  • 新功能:日本新年號的方形字元支援
    Unicode 聯盟已保留字碼點 U+32FF,代表自 2019 年 5 月開始使用的日本新年號日文方形字元。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 將停止信任 Symantec 核發的 TLS 伺服器憑證,與 Google、Mozilla、Apple 和 Microsoft 最近發布的類似計畫相符。受影響憑證的清單包括由 Symantec 管理、標記為 GeoTrust、Thawte 和 VeriSign 的憑證。
    於 2019 年 4 月 16 日當日或之前核發的 TLS 伺服器憑證將繼續受到信任,直到到期為止。該日期之後核發的憑證將被拒絕。請參閱 DigiCert 支援頁面取得相關資訊,瞭解如何將 Symantec 憑證取代為 DigiCert 憑證 (DigiCert 已於 2017 年 12 月 1 日接管了所有 Symantec 網站安全性 SSL/TLS 憑證的驗證與核發作業)。
    此政策的一項例外是,由 Apple 管理的兩個從屬憑證授權單位所核發的 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 伺服器的系統,次級機制會讓本 JRE (版本 8u211) 在 2019 年 8 月 16 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),JRE 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

此發行版本包含 Oracle Java SE Critical Patch Update Advisory 中所述的安全漏洞修正。如需此發行版本所含問題修正的更完整清單,請參閱 JDK 8u211 問題修正網頁。

» 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 的存留時間詳細資訊。時間戳記若已到期或將於一年內到期時,會顯示新的警告和錯誤訊息。
    請參閱 JDK-8191438
Java 到期日

8u201 的到期日為 2019 年 4 月 16 日。每當具有安全漏洞修正的新版本可供使用時,Java 便會到期。對於無法連線至 Oracle 伺服器的系統,次級機制會讓本 JRE (版本 8u201) 在 2019 年 5 月 16 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),JRE 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

此發行版本包含 Oracle Java SE Critical Patch Update Advisory 中所述的安全漏洞修正。如需此發行版本所含問題修正的完整清單,請參閱 JDK 8u201 問題修正網頁。

» 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 密碼套件已淘汰,不應該再使用。因此,已在 jdk.tls.disabledAlgorithms 安全特性加上 "DES" ID,讓 SunJSSE 實行預設停用 DES 型密碼套件。若要重新啟用這些密碼套件,只要移除 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 程式碼簽章 CA
    以下 Baltimore CyberTrust 程式碼簽章根憑證已移除,不再提供使用:
    • baltimorecodesigningca
      DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE

    請參閱 JDK-8189949
  • 問題修正:LDAPS 通訊錯誤
    應用程式程式碼使用 LDAPS 時,若通訊埠連線逾時 <= 0 (預設值),在 2018 年 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 伺服器的系統,次級機制會讓本 JRE (版本 8u191) 在 2019 年 2 月 15 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),JRE 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

此發行版本包含 Oracle Java SE Critical Patch Update Advisory 中所述的安全漏洞修正。如需此發行版本所含問題修正的更完整清單,請參閱 JDK 8u191 問題修正網頁。

» 8u191 版本注意事項


Java 8 Update 181 (8u181)

發行版本重點
  • IANA Data 2018e
    JDK 8u181 包含 IANA 時區資料 2018e 版。如需詳細資訊,請參閱 JRE 軟體中的時區資料版本
  • 移除的功能: 移除 Java DB
    此發行版本移除了 Java DB (又稱為 Apache Derby)。
    建議您直接從 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",即可停用新的檢查。必須在 Java 命令行加上 -Djdk.disableSerialConstructorChecks=true 引數才能完成設定。
    JDK-8197925 (未公開)
  • 問題修正: JVM 在 G1 GC 期間當機
    被認為無法以並行標記 G1 的方式連線的 klass,現在可以在 ClassLoaderData/SystemDictionary 中查尋,而且可以將它的 _java_mirror_class_loader 欄位儲存在根目錄,或任何其他可讓其再次執行的可連線物件。每當 klass 以這種方式恢復時,就必須通知 G1 的 SATB 部分,否則並行標記的重新標記階段將會錯誤地卸載該 klass。
    請參閱 JDK-8187577
  • 問題修正: 改善舊版 NUMA 程式庫 (-XX+UseNuma) 的穩定性
    JDK 8 Update 152 中的一項修正所導入的回歸,讓版本低於 2.0.9 之 libnuma 的 Linux 系統在使用 UseNUMA 旗標時,可能導致 HotSpot JVM 在啟動期間當機。此問題已經解決。
    請參閱 JDK-8198794
Java 到期日

8u181 的到期日為 2018 年 10 月 16 日。每當具有安全漏洞修正的新版本可供使用時,Java 便會到期。對於無法連線至 Oracle 伺服器的系統,次級機制會讓本 JRE (版本 8u181) 在 2018 年 11 月 16 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),JRE 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

此發行版本包含 Oracle Java SE Critical Patch Update Advisory 中所述的安全漏洞修正。如需此發行版本所含問題修正的更完整清單,請參閱 JDK 8u181 問題修正網頁。

» 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$Typejavax.crypto.spec.SecretKeySpec,但會拒絕所有其他樣式。
    客戶儲存的 SecretKey 若尚未序列化為上述類型,則必須修改篩選,才能擷取金鑰。
    JDK-8189997 (未公開)
  • 新功能:用於停用 JRE 上次使用狀況追蹤的系統特性
    導入新系統特性 jdk.disableLastUsageTracking,以停用執行中 VM 的 JRE 上次使用狀況追蹤。您可以使用 -Djdk.disableLastUsageTracking=true-Djdk.disableLastUsageTracking 在命令行中設定此特性。設定此系統特性之後,無論 usagetracker.properties 中設定的 com.oracle.usagetracker.track.last.usage 特性值為何,都將會停用 JRE 上次使用狀況追蹤。
    JDK-8192039 (未公開)
  • 注意:CipherOutputStream 用法
    闡明 javax.crypto.CipherOutputStream 的規格,指示此類別會擷取 BadPaddingException 和解密過程中完整性檢查失敗時所發生的其他異常狀況。這些異常狀況不會重複發生,因此從屬端不會獲得完整性檢查已失敗的相關通知。基於此行為的緣故,如果應用程式需要在認證失敗時獲得明確通知,此類別就可能不適合在認證的作業模式 (例如 GCM) 中與解密搭配使用。這些應用程式可以直接使用 Cipher API 作為使用此類別的替代方案。
    JDK-8182362 (未公開)
  • 變更:額外的 TeliaSonera 根憑證
    已將 "TeliaSonera Root CA v1" 新增至 cacerts 金鑰儲存庫。
    JDK-8190851 (未公開)
  • 變更:已停用使用小於 224 位元 EC 金鑰簽署的 XML 簽章
    為了提升 SSL/TLS 連線的強度,已透過 jdk.tls.disabledAlgorithms 安全特性,在 JDK 中停用 SSL/TLS 連線中使用的 3DES 密碼套件。
    JDK-8175075 (未公開)
  • 問題修正:已停用伺服器端 HTTP 通道 RMI 連線
    此發行版本中已預設停用伺服器端 HTTP 通道 RMI 連線。可透過將程式實際執行特性 sun.rmi.server.disableIncomingHttp 特性設為 false 以回復此行為。注意,請勿將上述特性與 sun.rmi.server.disableHttp 特性混淆,此特性會停用從屬端的 HTTP 通道且預設為 false
    JDK-8193833 (未公開)
Java 到期日

8u171 的到期日為 2018 年 7 月 17 日。每當具有安全漏洞修正的新版本可供使用時,Java 便會到期。對於無法連線至 Oracle 伺服器的系統,次級機制會讓本 JRE (版本 8u171) 在 2018 年 8 月 17 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),JRE 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

此發行版本包含 Oracle Java SE Critical Patch Update Advisory 中所述的安全漏洞修正。如需此發行版本所含問題修正的更完整清單,請參閱 JDK 8u171 問題修正網頁。

» 8u171 版本注意事項


Java 8 Update 161 (8u161)

發行版本重點
  • IANA Data 2017c
    JDK 8u161 包含 IANA 時區資料 2017c 版。如需詳細資訊,請參閱 JRE 軟體中的時區資料版本
  • 新功能:支援高達 8192 位元的 DHE 和 3072 位元的 DSA
    強化 JDK 安全提供者以支援產生 3072 位元的 DiffieHellman 和 DSA 參數,預先計算的 DiffieHellman 參數最高可達 8192 位元,而預先計算的 DSA 參數最高可達 3072 位元。
    請參閱 JDK-8072452
  • 新功能:TLS 的議定有限體 Diffie-Hellman 短暫參數
    JDK SunJSSE 實行現在支援 RFC 7919 中定義的 TLS FFDHE 機制。如果伺服器無法處理 supported_groups TLS 擴充功能或擴充功能中的具名群組,應用程式可以使用 jdk.tls.namedGroups 自訂支援的群組名稱,或是將系統特性 jsse.enableFFDHEExtension 設為 false 以關閉 FFDHE 機制。
    請參閱 JDK-8140436
  • 新功能:在 org.omg.CORBA.ORBstring_to_object 方法新增額外的 IDL stub 類型檢查
    明確或隱含呼叫 org.omg.CORBA.ORB.string_to_object 的應用程式若要確定 ORB::string_to_object 呼叫流程中呼叫 IDL stub 類型的完整性,可以指定額外的 IDL stub 類型檢查。這是一個選用功能,預設不會啟用。
    若要利用此額外類型檢查,請使用下列其中一種方式設定 IDL stub 類別的有效 IDL 介面類別名稱清單:
    • 指定安全特性 com.sun.CORBA.ORBIorTypeCheckRegistryFilter。若為 Java SE 9,此特性位於 conf/security/java.security 檔案;若為 Java SE 8 和舊版,則此特性位於 jre/lib/security/java.security 檔案。
    • 在類別清單指定系統特性 com.sun.CORBA.ORBIorTypeCheckRegistryFilter。若已設定系統特性,其值會覆寫 java.security 組態中定義的相對應特性。

    若未設定 com.sun.CORBA.ORBIorTypeCheckRegistryFilter 特性,則只會針對內建 IDL stub 類別相對應的一組 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 連線中應預設限制使用。因此,透過在 java.security 檔案中的 "jdk.tls.disabledAlgorithms" 安全特性新增 "DH keySize < 1024",預設停用小於 1024 位元的 Diffie-Hellman 金鑰。雖然不建議這樣做,但是管理員仍可更新安全特性 ("jdk.tls.disabledAlgorithms") 允許使用較小的金鑰大小 (例如透過設定 "DH keySize < 768")。
    JDK-8148108 (未公開)
  • 變更:提供者預設金鑰大小已更新
    當應用程式未明確指定金鑰大小來起始 java.security.KeyPairGeneratorjava.security.AlgorithmParameterGenerator 物件時,此變更會將 JDK 提供者更新為使用 2048 位元 (而非 1024 位元) 作為 DSA 的預設金鑰大小。
    如果發生相容性問題,現有應用程式可以使用該演算法和其所需的預設金鑰大小,設定 JDK-8181048 中介紹的系統特性 jdk.security.defaultKeySize
    JDK-8178466 (未公開)
Java 到期日

8u161 的到期日為 2018 年 4 月 17 日。每當具有安全漏洞修正的新版本可供使用時,Java 便會到期。對於無法連線至 Oracle 伺服器的系統,次級機制會讓本 JRE (版本 8u161) 在 2018 年 5 月 17 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),JRE 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

此發行版本包含 Oracle Java SE Critical Patch Update Advisory 中所述的安全漏洞修正。如需此發行版本所含問題修正的更完整清單,請參閱 JDK 8u161 問題修正網頁。

» 8u161 版本注意事項


Java 8 Update 151 (8u151)

發行版本重點
  • IANA Data 2017b
    JDK 8u151 包含 IANA 時區資料 2017b 版。如需詳細資訊,請參閱 JRE 軟體中的時區資料版本
  • 憑證變更:移除已撤銷的 Swisscom 根憑證 "swisscomrootevca2"
    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 管轄區原則檔案。在較舊的發行版本中,您需要另行下載並安裝 JCE 管轄區檔案,才能讓 JDK 使用無限制加密法。下載及安裝步驟再也不需要了。若要啟用無限制加密法,現在可以使用新的 crypto.policy 安全特性。若在 java.security 檔案中設定了這個新安全特性 (crypto.policy),或是已在起始 JCE 架構之前使用 Security.setProperty() 呼叫動態設定,便會採用此設定。預設不會定義此特性。若未定義此特性且舊版的 lib/security 目錄中沒有舊版的 JCE 管轄區檔案,預設的加密層次將維持在 'limited'。若要將 JDK 設定成使用無限加密法,請將 crypto.policy 的值設為 'unlimited'。請參閱本發行版本隨附之 java.security 檔案中的注意事項以瞭解詳細資訊。

    注意:在 Solaris 系統上,建議您先將舊的 SVR4 套裝軟體移除後,再安裝新的 JDK 更新。如果要執行 SVR4 升級 (未解除安裝舊的套裝軟體) 的 JDK 發行版本比 6u131、7u121、8u111 更舊,則必須在 java.security 檔案中設定此新的 crypto.policy 安全特性。

    因為舊的 JCE 管轄區檔案仍留在 <java-home>/lib/security 中,因此可能不符合 6u131、7u121、8u111 以及更新版本中已更新的最新安全 JAR 簽署標準。如果使用舊檔案,可能會發生類似下列的異常狀況:

    原因:java.lang.SecurityException:javax.crypto.JceSecurity.loadPolicies(JceSecurity.java:593) 和 javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:524) 的管轄區原則檔案不是由信任的簽署者簽署!

    請參閱 JDK-8157561
  • 變更 重構現有的提供者,讓其參照相同的金鑰長度預設值常數
    針對此問題進行了兩項重要變更:
    1. 導入新的系統特性,讓使用者能夠設定 KeyPairGenerator 和 AlgorithmParameterGenerator 的 JDK 提供者實行所使用的預設金鑰大小。此特性的名稱為 "jdk.security.defaultKeySize",其值是以逗號區隔的項目清單。每個項目均由以 ':' 區隔的演算法名稱 (不區分大小寫) 和相對應的預設金鑰大小 (十進位數字) 組成。此外,會忽略空格。

    此特性預設不包含任何值,JDK 提供者將會使用自己的預設值。系統將忽略內含無法辨識的演算法名稱項目。如果指定的預設金鑰大小不是可剖析的十進位整數,該項目也會被忽略。

    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 伺服器的系統,次級機制會讓本 JRE (版本 8u151) 在 2018 年 2 月 16 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),JRE 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

此發行版本包含 Oracle Java SE Critical Patch Update Advisory 中所述的安全漏洞修正。如需本發行版本所含問題修正的更完整清單,請參閱 JDK 8u151 問題修正網頁。

» 8u151 版本注意事項


Java 8 Update 144 (8u144)

發行版本重點
  • IANA Data 2017b
    JDK 8u144 包含 IANA 時區資料 2017b 版。如需詳細資訊,請參閱 JRE 軟體中的時區資料版本
  • 問題修正:java.util.zip.ZipFile.getEntry() 現在一律會以 / 為結尾的目錄項目名稱傳回 ZipEntry 執行處理
    java.util.zip.ZipEntry API 文件指示目錄項目的定義是目錄名稱須以 / 為結尾。但是在之前的 JDK 發行版本中,java.util.zip.ZipFile.getEntry(String entryName)entryName 引數中所傳送不是以 / 為結尾,且 zip 檔案中有名稱為 entryName + / 的相符 zip 目錄項目時,對於現有的 zip 目錄項目會傳回項目名稱不是以 / 為結尾的 ZipEntry 執行處理。使用此版本,對於任何 zip 目錄項目,從 java.util.zip.ZipFile.getEntry() 傳回的 ZipEntry 執行處理名稱一律會以 / 為結尾。
    若要回復先前的行為方式,請將 jdk.util.zip.ensureTrailingSlash 系統特性設為 'false'。

    進行此變更是為了在驗證已簽署的 JAR 時,修正 JDK 8u141 中所導入的回歸,此問題已導致部分 WebStart 應用程式無法載入。
    請參閱 JDK-8184993
Java 到期日

8u144 的到期日為 2017 年 10 月 17 日。每當具有安全漏洞修正的新版本可供使用時,Java 便會到期。對於無法連線至 Oracle 伺服器的系統,次級機制會讓本 JRE (版本 8u144) 在 2017 年 11 月 17 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),JRE 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

此發行版本包含 Oracle Java SE Critical Patch Update Advisory 中所述的安全漏洞修正。如需此發行版本所含問題修正的更完整清單,請參閱 JDK 8u144 問題修正網頁。

» 8u144 版本注意事項


Java 8 Update 141 (8u141)

發行版本重點
  • IANA Data 2017b
    JDK 8u141 包含 IANA 時區資料 2017b 版。如需詳細資訊,請參閱 JRE 軟體中的時區資料版本
  • 憑證變更:增加新的 Let's Encrypt 憑證至根 CA
    新增了 1 個新的根憑證:
    ISRG Root X1
    alias: letsencryptisrgx1
    DN: CN=ISRG Root X1, O=Internet Security Research Group, C=US

    JDK-8177539 (未公開)
  • JMX Diagnostic 改進項目
    com.sun.management.HotSpotDiagnostic::dumpHeap API 已修改為當提供的檔案名稱不是以 “.hprof” 字尾結尾時,會發出 IllegalArgumentException。現有應用程式的檔案名稱若未以 “.hprof” 副檔名結尾將會失敗,並發出 IllegalArgumentException。在此情況下,應用程式可以選擇處理此異常狀況,或是藉由將系統特性 'jdk.management.heapdump.allowAnyFileSuffix' 設為 true 來復原舊的行為方式。
    JDK-8176055 (未公開)
  • 使用 wsimport 工具處理 WSDL 檔案時有更嚴密的安全檢查
    wsimport 工具已變更為不允許在 Web 服務描述中使用 DTD,具體而言如下:
    • 文件中不允許使用 DOCTYPE 宣告
    • 預設不會包含外部一般實體
    • 預設不會包含外部參數實體
    • 外部 DTD 會完全被忽略
    若要復原之前的行為方式:
    • 將系統特性 com.sun.xml.internal.ws.disableXmlSecurity 設為 true
    • 使用 wsimport 工具命令行選項 –disableXmlSecurity
      注意:將會透過 7 月 CPU 之後的修正程式發行版本來提供 JDK 7 和 JDK 6 在 wsimport 對此選項的支援
    JDK-8182054 (未公開)
  • 自訂 HostnameVerifier 啟用 SNI 擴充功能
    舊版的 JDK 8 更新在使用自訂主機名稱驗證程式時,並非一律會在 TLS ClientHello 階段傳送伺服器名稱指示 (SNI) 擴充功能。此驗證程式是透過 HttpsURLConnection 中的 setHostnameVerifier(HostnameVerifier v) 方法來設定。此修正可確保現在會在 ClientHello 內文中傳送伺服器名稱。
    請參閱 JDK-8144566
  • 改進演算法限制條件檢查
    由於低強度演算法容易受到攻擊,必須限制低強度演算法的使用,因此在設定 java.security 檔案中的 jdk.certpath.disabledAlgorithmsjdk.jar.disabledAlgorithms 安全特性時,新增了額外的功能。

    jdk.certpath.disabledAlgorithms:certpath 特性的變更最為明顯。以前只有兩種限制條件類型;在檢查憑證、憑證鏈及憑證簽章時,會依名稱或依金鑰大小完全停用某個演算法。這造成使用時的絕對性且缺乏彈性。現在新增了 3 種新的限制條件,提供更多的彈性來允許和拒絕憑證。

    "jdkCA" 會檢查關於 cacerts 檔案的憑證鏈終止。如果是 "SHA1 jdkCA",系統會透過憑證鏈檢查 SHA1 的使用,但憑證鏈必須在要拒絕之 cacerts 金鑰儲存庫中標記的信任錨點處終止。對於擁有自己的專用 CA (信任搭配其信任錨點使用 SHA1),但不想要讓由公用 CA 設定錨點之憑證鏈使用 SHA1 的組織而言,這非常實用。

    "denyAfter" 會檢查指定的日期是否在目前日期或 PKIXParameter 日期之前。例如 "SHA1 denyAfter 2018-01-01",在 2018 之前可以使用使用 SHA1 的憑證,但是在此日期之後將會拒絕該憑證。這可以運用在整個組織的原則中,使用終止日期來逐漸停用演算法。對於已簽署的 JAR 檔案,會將日期與 TSA 時間戳記比較。此日期是以 GMT 指定。

    "usage" 會檢查指定演算法的指定用法。無法全面停用某個演算法時,可以使用此限制條件。有三種用法可以指定:

    • 'TLSServer' 可在伺服器認證是以從屬端方式執行時,限制 TLS 伺服器憑證鏈中的演算法。
    • 'TLSClient' 可在從屬端認證是以伺服器方式執行時,限制 TLS 從屬端憑證鏈中的演算法。
    • 'SignedJAR' 可限制已簽署 JAR 檔案之憑證中的演算法。用法類型是接在關鍵字之後,可以使用空格分界字元指定一種以上的用法類型。
      例如,"SHA1 usage TLSServer TLSClient" 會讓 TLSServer 和 TLSClient 作業不能使用 SHA1 憑證,但是 SignedJars 則可以使用。

    您可以使用 '&' 區隔來結合這些限制條件以限制演算法。例如,若要針對 TLSServer 作業停用在標記的信任錨點終止的 SHA1 憑證鏈,限制條件將會是 "SHA1 jdkCA & usage TLSServer"。

    jdk.jar.disabledAlgorithms:新增了一個額外限制條件至此 .jar 特性,以限制 JAR 資訊清單演算法。

    "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 伺服器的系統,次級機制會讓本 JRE (版本 8u141) 在 2017 年 11 月 17 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),JRE 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

此發行版本包含 Oracle Java SE Critical Patch Update Advisory 中所述的安全漏洞修正。如需此發行版本所含問題修正的更完整清單,請參閱 JDK 8u141 問題修正網頁。

» 8u141 版本注意事項


Java 8 Update 131 (8u131)

發行版本重點
  • IANA Data 2016j
    JDK 8u131 包含 IANA 時區資料版本 2016j。如需詳細資訊,請參閱 JRE 軟體中的時區資料版本
  • 問題修正:導入新的視窗排列模型
    在 OS X 平台上,AWT 架構會使用原生服務實行視窗的父子關係。因此有時會導致視覺效果不佳 (尤其是在多監視器環境中)。為避免此方法所造成的不良影響,我們已在 JDK 層完全實行新的視窗排列模型。主要原則如下:
    • 視窗必須放置在最近的父視窗上。
    • 如果視窗有數個子視窗,則所有子視窗都必須位於同一層,且作用中的子視窗必須在其他子視窗之上。
    • 如果視窗處於圖示化狀態或正在轉換為圖示化,請勿對其執行排列動作。
    上述規則適用於包含目前作用中視窗的視窗階層中的每個框架或對話方塊。請參閱 JDK-8169589
  • 問題修正:修正 TLS 交握式確認的 IllegalArgumentException
    JDK-8173783 修正中最近發生的問題可能導致部分 TLS 伺服器發生問題。此問題源自於 TLS 交握式確認程式碼所發出的 IllegalArgumentException:

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


    若因伺服器不支援橢圓形曲線加密法,而無法處理橢圓形曲線名稱擴充欄位 (若有的話) 時,便可能發生此問題。建議使用者升級為此發行版本。SunEC 安全提供者隨附的 JDK 7 Update 和更新的 JDK 系列預設提供橢圓形曲線加密法支援。除非修改安全提供者,否則這些發行版本應該不會受到影響。請參閱 JDK-8173783
  • jdk.jar.disabledAlgorithms 安全特性增加了 MD5
    本 JDK 版本針對驗證以 MD5 簽署的 JAR 檔案導入新的限制。如果已簽署的 JAR 檔案使用 MD5,簽章驗證作業將忽略該簽章並將 JAR 視為未簽署。這種情形可能發生在下列使用已簽署 JAR 檔案的應用程式類型:
    • Applet 或 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'

    請定期至 http://java.com/cryptoroadmap 檢查 Oracle JRE and JDK Cryptographic Roadmap,瞭解針對已簽署 JAR 和其他安全性元件的規劃限制。JDK-8171121 (未公開)
  • 可控制 HTTP SPNEGO 連線快取功能的新系統特性。
    導入新的 JDK 實行特定系統特性,可控制 HTTP SPNEGO (Negotiate/Kerberos) 連線快取功能。系統仍預設啟用 HTTP SPNEGO 連線快取功能,因此如果未明確指定特性,就不會變更行為。當連線至使用 SPNEGO 進行交涉認證的 HTTP 伺服器並順利完成連線和認證作業時,系統會隨即快取認證資訊並將其重複用於與同一個伺服器的其他連線。此外,連線至使用 SPNEGO 的 HTTP 伺服器時,通常會保持底層連線不中斷,並將其重複用於對同一個伺服器的其他要求。部分應用程式可能會建議停用 HTTP SPNEGO (Negotiate/Kerberos) 協定的所有快取功能,以強制要求每次向伺服器發出新要求時都使用新的認證。

    為因應這項變更,我們現在提供新的系統特性,可讓您控制 HTTP SPNEGO 連線的快取原則。若已定義 jdk.spnego.cache 並評估為 false,系統就會停用 HTTP SPNEGO 連線的所有快取功能。不過,將此系統特性設為 false 會造成不良影響:
    • 每次提出與伺服器進行多個通訊交換的新要求時,都必須重新認證連線,因此 HTTP SPNEGO 連線的效能會大幅降低。
    • 視通透認證是否可用和全域認證程式實行而定,畫面上可能會顯示即現式視窗要求使用者提供證明資料,讓系統為每個新要求重新取得證明資料。
    JDK-8170814 (未公開)
  • 可控制 HTTP NTLM 連線快取功能的新系統特性。
    導入新的 JDK 實行特定系統特性,可控制 HTTP NTLM 連線快取功能。系統仍預設啟用 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 伺服器的系統,次級機制會讓本 JRE (版本 8u131) 在 2017 年 8 月 18 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),Java 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

此發行版本包含安全漏洞的修正。如需詳細資訊,請參閱 Oracle Java SE Critical Patch Update Advisory。如需此發行版本所含的問題修正清單,請參閱 JDK 8u131 問題修正網頁。

» 8u131 版本注意事項


Java 8 Update 121 (8u121)

發行版本重點
  • IANA Data 2016i
    JDK 8u121 包含 IANA 時區資料版本 2016i。如需詳細資訊,請參閱 JRE 軟體中的時區資料版本
  • 問題修正:在 OS X 10.12 Sierra 上 Trackpad 捲動文字的速度非常快
    在 Mac OS X 上,MouseWheelEvent.getWheelRotation() 方法會傳回四捨五入的原生 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")。JDK 的 SSL/TLS 實行中已移除小於 256 位元的 EC 曲線。新的系統特性 jdk.tls.namedGroups 定義了一個啟用的 EC 密碼套件具名曲線清單,此清單會以偏好設定順序排列。如果應用程式需要自訂預設啟用的 EC 曲線或曲線偏好設定,請視需要更新系統特性。例如:
        jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1"
    

    注意,預設啟用或自訂的 EC 曲線會遵循演算法限制條件。例如,自訂的 EC 曲線不能重新啟用已由 Java 安全特性定義為停用的 EC 金鑰。請參閱 JDK-8148516
  • javadoc 有新的 --allow-script-in-comments 選項
    除非指定命令行選項 --allow-script-in-comments,否則 javadoc 工具現在會拒絕 javadoc 文件註解和命令行選項中的任何 JavaScript 程式碼。使用 --allow-script-in-comments 選項,javadoc 工具將會保留文件註解和命令行選項中的 JavaScript 程式碼。若未設定此命令行選項,但發現有 JavaScript 程式碼,則 javadoc 工具便會發出錯誤。
    JDK-8138725 (未公開)
  • 將 XML 簽章的最小金鑰長度提高為 1024
    XML 簽章實行的安全驗證模式已經增強,預設會限制小於 1024 位元的 RSA 和 DSA 金鑰,因為太小的金鑰已不足以保護數位簽章。此外,java.security 檔案已增加一個新的安全特性 jdk.xml.dsig.SecureValidationPolicy,此特性可以在啟用安全驗證時,用來控制所施行的不同強制限制。透過 javax.xml.crypto.XMLCryptoContext.setProperty 方法將 xml 簽章特性 org.jcp.xml.dsig.secureValidation 設為 true,或以 SecurityManager 執行此程式碼,即可啟用安全驗證模式。如果使用強度較低的 RSA 或 DSA 金鑰產生或驗證 XML 簽章,將會發生 XMLSignatureException 異常狀況,並顯示「啟用安全驗證時,禁止使用小於 1024 位元的 RSA 金鑰」或「啟用安全驗證時,禁止使用小於 1024 位元的 DSA 金鑰」訊息。
    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 清單載入類別。如果呼叫程式碼不能存取一或多個 URL,而且可存取的 URL 使用者自建物件未包含必要類別的話,將會發生 ClassNotFoundException 或類似的異常狀況。以往存取 URL 被拒絕時,會發生 SecurityException。如果要回復舊的行為,可以設定 jdk.net.URLClassPath.disableRestrictedPermissions 系統特性以停用此變更。JDK-8151934 (未公開)
  • logging.properties 中有新的可設定特性 java.util.logging.FileHandler.maxLocks
    java.util.logging.FileHandler 增加了一個新的可設定特性 "java.util.logging.FileHandler.maxLocks"。您可以在日誌記錄組態檔定義這個新的日誌記錄特性,並且可以設定一個 FileHandler 處理並行記錄檔鎖定的最大數量。預設值為 100。在高度並行的環境中,若多個 (超過 101 個) 獨立從屬端應用程式會同時使用 JDK 日誌記錄 API 與 FileHandler,可能會達到預設限制 100,而導致無法取得 FileHandler 檔案鎖定,並且引發 IO 異常狀況。在此情況下,新的日誌記錄特性可以在部署應用程式之前,用來提高鎖定數量的上限。如果沒有覆寫,maxLocks 的預設值 (100) 會維持不變。請參閱 java.util.logging.LogManagerjava.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 結合了整個 JDK,而非只是 JRE

適用於 Mac 的 Java Packager 有一個已知問題,即整個 JDK 可能會與應用程式組合結合在一起,而產生異常大型的組合。解決方法是使用包裝程式的 -Bruntime 選項。例如:-Bruntime=JavaAppletPlugin.plugin,其中要與所需 JRE 組合的 JavaAppletPlugin.plugin 位於目前的目錄。請參閱 JDK-8166835

在關閉 UAC 的情況下,非管理員使用者進行 Java 安裝將會失敗

在 Windows 停用「使用者存取控制 (UAC)」的情況下,非管理員使用者進行 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 都會將已設定的篩選套用至串流內容。您可以使用系統特性或設定安全特性來設定篩選。JEP 290 Serialization Filtering 和 <JRE>/lib/security/java.security 中都提供 "jdk.serialFilter" 樣式的值描述。篩選動作會記錄到 'java.io.serialization' 日誌記錄器 (若已啟用)。請參閱 JDK-8155760

RMI 提供更好的限制條件檢查

RMI 登錄和分散式資源回收會使用 JEP 290 Serialization Filtering 的機制來提高服務的穩定性。RMI 登錄和 DGC 實行內建白名單篩選,可供預期要與每個服務搭配的一般類別使用。您可以使用系統特性或安全特性來設定其他篩選樣式。JEP 290 和 <JRE>/lib/security/java.security 中描述了 "sun.rmi.registry.registryFilter" 和 "sun.rmi.transport.dgcFilter" 特性樣式語法。JDK-8156802 (未公開)

新增讓非預設根 CA 不受限於演算法限制的機制

java.security 檔案中的 jdk.certpath.disabledAlgorithms 特性,新增了一個名為 "jdkCA" 的額外限制條件。此限制條件唯有在於 lib/security/cacerts 金鑰儲存庫中標記的信任錨點處終止的憑證鏈中使用指定的演算法時,才會禁止該演算法。若未設定 jdkCA 限制條件,使用指定演算法的所有憑證鏈都會受到限制。jdkCA 只能在 DisabledAlgorithm 表示式中使用一次。範例:若要對 SHA-1 憑證套用此限制條件,請包含下列這行:SHA1 jdkCA
請參閱 JDK-8140422

Java 到期日

8u121 的到期日為 2017 年 4 月 18 日。每當具有安全漏洞修正的新版本可供使用時,Java 便會到期。對於無法連線至 Oracle 伺服器的系統,次級機制會讓本 JRE (版本 8u121) 在 2017 年 5 月 18 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),Java 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

此發行版本包含安全漏洞的修正。如需詳細資訊,請參閱 Oracle Java SE Critical Patch Update Advisory。如需此發行版本所含的問題修正清單,請參閱 JDK 8u121 問題修正網頁。

» 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 提供者簽署程序的詳細資訊,請參閱 How to Implement a Provider in the Java Cryptography Architecture 文件。JDK-8141340 (未公開)
  • 「服務功能表」服務
    在特定平台上,AWT 功能表元件的生命週期管理會發生問題。此修正改進了功能表和其容器之間的狀態同步。JDK-8158993 (未公開)
  • 停用 HTTPS 通道的基本認證
    在某些環境中,使用代理 HTTPS 時並不需要特定的認證配置。因此,已將 Basic 加到 jdk.http.auth.tunneling.disabledSchemes 網路特性中,使 Oracle Java Runtime 中預設為停用基本認證配置。現在設定 HTTPS 通道時,將代理主機設為需要 Basic 認證,預設將不會成功。如有必要,只要在 jdk.http.auth.tunneling.disabledSchemes 網路特性中移除 Basic,或是在命令行上設定相同名稱的系統特性並設為 "" (空白),即可重新啟用此認證配置。此外,jdk.http.auth.tunneling.disabledSchemesjdk.http.auth.proxying.disabledSchemes 網路特性,以及相同名稱的系統特性,都可分別用來在設定 HTTPS 通道或一般 HTTP 代理時,停用可能作用中的其他認證配置。JDK-8160838 (未公開)
  • 限制以強度較低之演算法和金鑰簽署的 JAR
    本 JDK 版本針對已簽署之 JAR 檔案的驗證方式導入新的限制。如果已簽署的 JAR 檔案使用已停用的演算法或金鑰大小小於最小長度,簽章驗證作業將會忽略該簽章並將 JAR 檔案視為未簽署。這種情形可能發生在下列使用已簽署 JAR 檔案的應用程式類型:
    1.Applet 或 Web Start 應用程式
    2.啟用 SecurityManager 且設定了依據 JAR 的程式碼簽署者授予權限之原則檔案的獨立安裝或伺服器應用程式。

    停用的演算法清單透過 java.security 檔案中的新安全特性 jdk.jar.disabledAlgorithms 控制。此特性包含停用的演算法清單和加密編碼之已簽署 JAR 檔案的金鑰大小。

    下列演算法和金鑰大小在本發行版本中受到限制:
    1. MD2 (在摘要或簽章演算法中)
    2. 少於 1024 位元的 RSA 金鑰
    注意:我們計畫在 2017 年 4月的 CPU 中限制已簽署 JAR 中的 MD5 型簽章。

    若要檢查是否使用強度較低之演算法或金鑰簽署 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 可能使用現已停用之強度較低的演算法來簽署。如需詳細資訊,請重新執行 jarsigner 並啟用除錯模式 (-J-Djava.security.debug=jar)」

    若要解決此問題,JAR 檔案必須要使用強度較高的演算法或金鑰大小重新簽署。或者,可以將欲使用之強度較低的演算法或金鑰大小自 jdk.jar.disabledAlgorithms 安全特性中移除以取消限制;但是,並不建議採取此做法。重新簽署受影響的 JAR 檔案之前,必須將現有的簽章自 JAR 中移除。這可以透過 zip 公用程式完成,如下所示:

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

    請定期至 http://java.com/cryptoroadmap 檢查 Oracle JRE and JDK Cryptographic Roadmap,瞭解針對已簽署 JAR 檔案和其他安全性元件的規劃限制。請特別注意,目前的計畫是將於 2017 年 4 月的 CPU 中限制已簽署 JAR 檔案中的 MD5 型簽章。

    若要測試您的 JAR 是否使用 MD5 簽署,請將 MD5 加到 jdk.jar.disabledAlgorithms 安全特性,例如:

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

    然後依上述對您的 JAR 檔案執行 jarsigner -verify -J-Djava.security.debug=jar
    JDK-8155973 (未公開)
  • 在部署認證程式對話方塊新增警告訊息
    已在外掛程式認證對話方塊新增一個警告,若在使用代理主機或未使用 SSL/TLS 通訊協定時使用 HTTP 基本認證 (傳送未加密的證明資料),便會顯示此警告:
    「警告:基本認證配置將有效地以純文字傳輸您的證明資料。確定要這麼做嗎?」
    JDK-8161647 (未公開)
已知問題
某些事件並不適用於 Windows 的 JFR 錄製
下列事件不適用於發行版本 8u111 之 Windows 的 JFR 錄製:
  1. hotspot/jvm/os/processor/cpu_load
  2. os/processor/context_switch_rate

這是因為 8u111 中導入的回歸 JDK-8063089 含有 JDK-8162419 的變更。8u111 發行版本不包括 JDK-8063089 的修正。下一版 8u111 BPR build 和下一個公開發行版本將提供此修正。
JDK-8063089 (未公開)

JVM 在 macOS Sierra 10.12 會發出 NullPointerExceptions

在 macOS Sierra 10.12 上,使用者若在瀏覽器執行 Applet 時按附加鍵 (例如 Command、Shift 或 Alt),可能會顯示「內部錯誤」錯誤方塊。macOS Dock 列中也會顯示 "exec" 圖示。使用者可以關閉 Applet,或嘗試在不按附加鍵的情況下重新執行 Applet。請參閱 JDK-8165867

Java 到期日

8u111 的到期日為 2017 年 1 月 17 日。每當具有安全漏洞修正的新版本可供使用時,Java 便會到期。對於無法連線至 Oracle 伺服器的系統,次級機制會讓本 JRE (版本 8u111) 在 2017 年 2 月 17 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),Java 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

此發行版本包含安全漏洞的修正。如需詳細資訊,請參閱 Oracle Java SE Critical Patch Update Advisory。如需此發行版本所含的問題修正清單,請參閱 JDK 8u111 問題修正網頁。

» 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 Root CA 已移除
    Comodo "UTN - DATACorp SGC" Root CA 憑證已自 cacerts 檔案中移除。請參閱 JDK-8141540

    Sonera Class1 CA 已移除
    "Sonera Class1 CA" Root CA 憑證已自 cacerts 檔案中移除。請參閱 JDK-8141276
  • 增強對 javax.rmi.CORBA.ValueHandler 的存取控制
    javax.rmi.CORBA.Util 類別提供可供 Stub 和連結用於執行一般作業的方法。同時也可作為 ValueHandler 的處理站。javax.rmi.CORBA.ValueHandler 介面提供支援讀取 GIOP 串流的值類型及將值類型寫入 GIOP 串流的服務。這些公用程式的安全認知在導入權限 java.io.SerializablePermission("enableCustomValueHanlder") 後已獲得改善。這主要用來在 javax.rmi.CORBA.Util 的使用者與 javax.rmi.CORBA.ValueHandler API 的使用者之間建立信任關係。

    必要的權限為 "enableCustomValueHanlder" SerializablePermission。在呼叫 Util.createValueHandler() 時,已安裝之 SecurityManager 所執行的第三方程式碼若無此新的權限,將會發生 AccessControlException 而導致失敗。

    在 JDK8u 和先前版本中,可以定義系統特性 "jdk.rmi.CORBA.allowCustomValueHandler",以覆寫此權限檢查行為。

    因此,在已安裝 SecurityManager 且以下兩項要求都不符合的情況下,明確呼叫 javax.rmi.CORBA.Util.createValueHandler 的外部應用程式都需要進行組態變更才能夠運作:
    1. java.io.SerializablePermission("enableCustomValueHanlder") 不是由 SecurityManager 授權。
    2. 應用程式若是執行 JDK8u 和更舊版本,系統特性 "jdk.rmi.CORBA.allowCustomValueHandler" 有可能未定義或定義成 "false" (沒有大小寫之分)。

    請注意,"enableCustomValueHanlder" 拼字錯誤將在 2016 年 10 月的發行版本中更正。在從此之後的 JDK 發行版本中,正確使用的 SerializationPermission 將會是 "enableCustomValueHandler"
    JDK-8079718 (未公開)
  • 新增供 jarsigner 指定時間戳記雜湊演算法的支援
    jarsigner 新增了一個新的 -tsadigestalg 選項,以指定用於產生要傳送至 TSA 伺服器之訊息印記的訊息摘要演算法。舊的 JDK 發行版本所使用的訊息摘要演算法為 SHA-1。若未指定這個新選項,JDK 7 Update 和更新的 JDK 系列版本將會使用 SHA-256。JDK 6 Update 的預設值將仍是 SHA-1,但是會在標準輸出串流顯示警告。請參閱 JDK-8038837
  • MSCAPI 金鑰儲存庫可以處理相同名稱的憑證
    Java SE 金鑰儲存庫不允許有別名相同的憑證。但是在 Windows 上,儲存於同一金鑰儲存庫中的多個憑證可有非唯一的易記名稱。JDK-6483657 修正透過 Java API 以人為方式讓可見的別名成為唯一,使得處理這類非唯一命名的憑證變得可行。請注意,此修正並不允許使用 Java API 建立相同名稱的憑證。純粹只是讓使用者能夠處理由第三方工具新增至金鑰儲存庫之相同名稱的憑證。仍然建議使用者不要使用多個相同名稱的憑證。特別是下面這句將不會從 Java 文件中移除:
    為了避免發生問題,建議不要在金鑰儲存庫中使用只有大小寫不同的別名。
    請參閱 JDK-6483657
  • Deployment Tookit API 方法不再安裝 JRE
    deployJava.js 的 Deployment Toolkit API installLatestJRE()installJRE(requestedVersion) 方法,以及 dtjava.jsinstall() 方法,都不再安裝 JRE。如果使用者的 Java 版本低於安全基準,系統會將使用者重導至 java.com 取得最新版本的 JRE。JDK-8148310 (未公開)
  • DomainCombiner 在合併 ProtectionDomain 物件時將不再參考靜態 ProtectionDomain 物件的程式實際執行原則
    經過此修正後,使用權限不足之靜態 ProtectionDomain 物件 (以 2 個引數的建構子建立) 的應用程式,現在會發生 AccessControlException。應用程式必須將靜態 ProtectionDomain 物件取代為動態 ProtectionDomain 物件 (使用 4 個引數的建構子且其權限集將由目前的原則擴充),或是建構具備所有必要權限的靜態 ProtectionDomain 物件。JDK-8147771 (未公開)
已知問題
若使用靜態類別 ID,Internet Explorer (IE) 無法辨識 JRE 8u101

若在使用 JRE 8u101 的同時,使用靜態類別 ID 啟動 Applet 或 Web Start 應用程式,即使使用者已經安裝並使用最新的 JRE (JRE 8u101),還是會見到多餘的對話方塊,說明請使用最新的 JRE 或請取消啟動。這是 Windows 和 IE 才會發生的特定案例。

根據 http://www.oracle.com/technetwork/java/javase/family-clsid-140615.html,我們不建議在 JRE 版本使用靜態類別 ID (起自 2005 年 12 月發行的 JDK 5u6)。

若要解決此問題,使用者可以採行下列其中一種分式:
  • 使用最新的版本 (8u101) 啟動,並忽略警告訊息。
  • 改為安裝 JRE 8u102 (而非 JRE 8u101) 以避免此問題。
若要解決此問題,開發人員可以採行下列其中一種分式:
  • 改為使用動態類別 ID,而不要使用靜態類別 ID。
  • 若使用 HTML Applet,請使用 java_version;若使用 JNLP,請使用 JNLP 描述區。
JDK-8147457 (未公開)

問題修正

此發行版本包含安全漏洞的修正。如需詳細資訊,請參閱 Oracle Java SE Critical Patch Update Advisory。如需本發行版本所含的問題修正清單,請參閱 JDK 8u101 問題修正網頁。

Java 到期日

8u101 的到期日為 2016 年 10 月 19 日。每當具有安全漏洞修正的新版本可供使用時,Java 便會到期。對於無法連線至 Oracle 伺服器的系統,次級機制會讓本 JRE (版本 8u101) 在 2016 年 11 月 19 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),Java 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

» 8u101 版本注意事項


Java 8 Update 91 (8u91)

發行版本重點
  • IANA Data 2016a
    JDK 8u91 包含 IANA 時區資料版本 2016a。如需詳細資訊,請參閱 JRE 軟體中的時區資料版本
  • 問題修正:Applet 啟動時間中的回歸已修正
    JDK-8080977 已在 Applet 啟動導入延遲。延遲只會顯示在 IE 上,且時間大約維持 20 秒。JDK-8136759 已移除此延遲。請參閱 JDK-8136759
  • 問題修正:現在產生 DSA 簽章時,必須通過金鑰強度檢查
    在產生簽章時,摘要演算法的安全強度若低於簽署簽章所使用之金鑰的安全強度 (例如使用 (2048, 256)-位元 DSA 金鑰的 SHA1withDSA 簽章),作業將會無法執行並顯示以下錯誤訊息:SHA1 摘要演算法的安全強度不適合此金鑰大小。JDK-8138593 (未公開)
  • 問題修正:Firefox 42 LiveConnect 問題
    由於此問題可能會導致瀏覽器停滯,因此當 Java 外掛程式從 plugin-container.exe 啟動 (Firefox 42 的預設行為) 且 Applet 狀態不是就緒 (2) 時,我們不會處理 JavaScript 對 Java 的呼叫。Applet 若未就緒 (即狀態不是 2),我們並不會執行實際的 Java 方法,只會傳回空值。

    外掛程式若是從 plugin-container.exe 啟動,請勿使用可能需要超過 11 秒 (dom.ipc.plugins.hangUITimeoutSecs 的預設值) 才能完成的 JavaScript 對 Java 的呼叫,或是在進行 JavaScript 對 Java 的呼叫期間顯示限制形式對話方塊。在此種情形下,主要瀏覽器執行緒必定會被封鎖,因而可能導致瀏覽器停滯,而外掛程式終止的情況。

    Firefox 42 的解決方法:使用者可以設定 dom.ipc.plugins.enabled=false。不過,此解決方法會變更所有外掛程式的設定。JDK-8144079 (未公開)
  • 問題修正:JMX RMI JRMP 伺服器有新的屬性,供用於指定還原序列化伺服器證明資料時可使用的類別名稱清單。
    替環境定義了一個新的 java 屬性,讓 JMX RMI JRMP 伺服器能夠指定類別名稱清單。這些名稱相對應於伺服器在還原序列化證明資料時所預期的封閉類別名稱。例如,若預期的證明資料為
     List<string>
    ,那麼封閉項目會組成所有具體類別,而且為序列形式的字串清單。

    依照預設,此屬性僅供下列預設代理程式使用:
     {   
       "[Ljava.lang.String;",   
       "java.lang.String" 
     } 
    
    還原序列化證明資料時,系統只接受字串陣列和字串。屬性名稱為:
    "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 (未公開)
  • 問題修正:停用 JSSE 提供者中的 MD5withRSA 簽章演算法
    MD5withRSA 簽章演算法已不安全,不應該再使用。因此,已透過將 "MD5withRSA" 加到 "jdk.tls.disabledAlgorithms" 安全特性,讓 Oracle JSSE 實行預設停用 MD5withRSA。現在,預設已不再接受使用 MD5withRSA 演算法簽署的 TLS 交握式確認訊息和 X.509 憑證。這項變更將先前的 MD5 型憑證限制 ("jdk.certpath.disabledAlgorithms") 加以延伸,如今也包括 TLS 版本 1.2 的交握式確認訊息。如有必要重新啟用此演算法,只要移除 "jdk.tls.disabledAlgorithms" 安全特性中的 "MD5withRSA" 即可。JDK-8144773 (未公開)
  • 問題修正:增加新的憑證至根 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-8145954JDK-8145955
注意事項

移除靜態 JRE
在版本 8u91 以前發行之 Windows 適用的 Java 安裝程式預設並不會移除靜態安裝的 JRE。若要移除靜態安裝的 JRE,使用者必須在 Java 安裝程式的使用者介面中手動選取這些 JRE。但現在,在 Java 發行版本 8u91 和更新版本中,系統將會自動移除低於安全基準的靜態安裝 JRE。如需關於靜態安裝的資訊,請參閱 Java Runtime Environment 組態

Java 到期日

8u91 的到期日為 2016 年 7 月 19 日。每當具有安全漏洞修正的新版本可供使用時,Java 便會到期。對於無法連線至 Oracle 伺服器的系統,次級機制會讓本 JRE (版本 8u91) 在 2016 年 8 月 19 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),Java 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

此發行版本包含安全漏洞的修正。如需詳細資訊,請參閱 Oracle Java SE Critical Patch Update Advisory。如需此發行版本所含的問題修正清單,請參閱 JDK 8u91 問題修正網頁。

» 8u91 版本注意事項


Java 8 Update 77 (8u77)

發行版本重點
Java 到期日

8u77 的到期日為 2016 年 4 月 19 日。每當具有安全漏洞修正的新版本可供使用時,Java 便會到期。對於無法連線至 Oracle 伺服器的系統,次級機制會讓本 JRE (版本 8u77) 在 2016 年 5 月 19 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),Java 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

注意事項

此安全性警示 (8u77) 係根據舊版的 8u74 PSU 發行版本所發布。使用舊 JDK 8 發行版本的所有使用者均應更新至此發行版本。如需重大修正程式更新和修正程式集更新兩者之間差異的詳細資訊,請瀏覽 Java CPU and PSU Releases Explained

8u77 的示範、範例及文件組合並未受到 CVE-2016-0636 安全性警示的影響,所以在四月重大修正程式更新發行前,8u73 版本的示範、範例及文件組合仍是最新的版本。

問題修正

此發行版本包含安全漏洞的修正。如需詳細資訊,請參閱 Oracle Java SE Critical Patch Update Advisory

» 8u77 版本注意事項


Java 8 Update 73 (8u73)

發行版本重點
Java 到期日

8u73 的到期日為 2016 年 4 月 19 日。每當具有安全漏洞修正的新版本可供使用時,Java 便會到期。對於無法連線至 Oracle 伺服器的系統,次級機制會讓本 JRE (版本 8u73) 在 2016 年 5 月 19 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),Java 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

注意事項

Oracle 強烈建議已下載受影響版本及計畫使用這些下載版本進行安裝的 Java 使用者,捨棄這些舊的下載。已安裝 Java SE 6、7 或 8 的 2016 年 1 月重大修正程式更新版本的 Java 使用者,無須採取任何動作。尚未安裝 Java SE 6、7 或 8 的 2016 年 1 月重大修正程式更新版本的 Java 使用者,應從 CVE-2016-0603 的安全性警示升級至 Java SE 6、7 或 8 發行版本。

8u73 的示範、範例及文件組合並未受到 CVE-2016-0603 安全性警示的影響,所以在四月重大修正程式更新發行前,8u71 版本的示範、範例及文件組合仍是最新的版本。

問題修正

此發行版本包含安全漏洞的修正。如需詳細資訊,請參閱 Oracle Java SE Critical Patch Update Advisory。請注意,8u73 不包含 8u72 的 PSU 組建。需要 8u72 所包含之其他問題修正的客戶,請改升級至 8u74,不要升級至 8u73。

» 8u73 版本注意事項


Java 8 Update 71 (8u71)

發行版本重點
  • IANA Data 2015g
    JDK 8u71 包含 IANA 時區資料版本 2015g。如需詳細資訊,請參閱 JRE 軟體中的時區資料版本
  • 問題修正:以 root 身分執行 jps 不會顯示所有資訊
    JDK-8050807 修正之後 (已於 8u31、7u75 及 6u91 中修正),以 root 身分執行 jps 時,不會顯示部分系統上其他使用者所啟動之 Java 處理作業的所有資訊。此情況現已修正。請參閱 JDK-8075773
  • 問題修正:安裝程式因 ESC 組態而停滯
    在 Windows Server 2008 R2 執行 Internet Explorer 增強式安全性組態 (ESC) 的使用者可能會在互動模式下安裝 Java 時發生問題。此問題已經在 8u71 發行版本中解決。在互動模式下執行的安裝程式已經不會因 ESC 組態而停滯。請參閱 JDK-8140197
  • 問題修正:已更正使用 AES 加密之 PBE 演算法的問題
    已更正使用 256 位元 AES 密碼之 PBE 的問題,此問題會造成產生的金鑰可能會和之前使用相同密碼所產生的金鑰不相同。JDK-8138589 (未公開)。
  • 問題修正: 已新增 XML 實體大小上限的預設限制
    已經新增實體大小上限的預設限制。如需有關 XML 處理限制的詳細資訊,請參閱 The Java Tutorials - Processing Limits。JDK-8133962 (未公開)
  • 問題修正: 已更正 Enterprise MSI 參數 'REMOVEOLDERJRES' 的文件問題
    Enterprise MSI 文件列出了組態選項。遺漏了用來解除安裝舊版 JRE 的 REMOVEOLDERJRES 選項。已新增此選項,其描述為:
    若設為 1,會移除系統上已安裝的舊版 JRE。
    預設值:0,不移除任何舊版 JRE
    JDK-8081237 (未公開)
Java 到期日

8u71 的到期日為 2016 年 4 月 19 日。每當具有安全漏洞修正的新版本可供使用時,Java 便會到期。對於無法連線至 Oracle 伺服器的系統,次級機制會讓本 JRE (版本 8u71) 在 2016 年 5 月 19 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),Java 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

此發行版本包含安全漏洞的修正。如需詳細資訊,請參閱 Oracle Java SE Critical Patch Update Advisory

如需此發行版本所含的問題修正清單,請參閱 JDK 8u71 問題修正網頁。

» 8u71 版本注意事項


Java 8 Update 66 (8u66)

發行版本重點

8u66 build 18 解決了 Firefox 的問題。

  • 錯誤修正:從錯誤的執行緒呼叫 _releaseObject
    Firefox 最近的變更讓主要執行緒以外的執行緒可以呼叫 _releaseObject。這可能會造成競爭情況,使瀏覽器意外發生當機。8u66 的 build 18 已經解決了此問題。如需詳細資訊,請參閱 Bugs@Mozilla 1221448。請參閱 JDK-8133523
安裝 Java 之後,Java 外掛程式無法在 Firefox 中運作

Firefox 42 在嘗試執行 Java 外掛程式時可能會當機。解決方法選項已列於常見問題中。請參閱 JDK-8142908 (未公開)。

Java 到期日

8u66 的到期日為 2016 年 1 月 19 日。每當具有安全漏洞修正的新版本可供使用時,Java 便會到期。對於無法連線至 Oracle 伺服器的系統,次級機制會讓本 JRE (版本 8u66) 在 2016 年 2 月 19 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),Java 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

此發行版本包含安全漏洞的修正。如需詳細資訊,請參閱 Oracle Java SE Critical Patch Update Advisory

如需此發行版本所含的問題修正清單,請參閱 JDK 8u66 問題修正網頁。

» 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
  • 問題修正: [mac osx] 安裝的 JRE AU 用戶端無法在 Mac 10.11 中更新 NEXTVER
    在 8u65 版本中導入了可將 OS X 使用者更新為最新版本的新安裝程式。此安裝程式可排定更新也可手動更新,您可以在 java.com 和 OTN 取得其包裝程式。使用者在使用新安裝程式時若發生相容性問題,可以手動從 My Oracle Support 下載並安裝 ".pkg" 安裝程式。
  • 問題修正: Hotspot 應使用 PICL 介面來取得 SPARC 的快取行大小
    Solaris/SPARC 現在必須有 libpicl 程式庫才能判斷快取行的大小。如果沒有程式庫或無法使用 PICL 服務,JVM 將顯示警告,並關閉使用 BIS (區塊起始存放區) 指示的編譯器最佳化功能。請參閱 JDK-8056124
  • 問題修正:dns_lookup_realm 預設應為 false
    Kerberos 的 krb5.conf 檔案中,dns_lookup_realm 設定現已預設為 false。請參閱 JDK-8080637
  • 問題修正:預先載入 libjsig.dylib 會導致呼叫 signal() 時發生鎖死情況
    應用程式必須預先載入 libjsig 程式庫才能啟用訊號鏈結。以往在 OS X 中預先載入 libjsig.dylib 之後,任何來自原始程式碼的 signal() 呼叫都會導致鎖死情況。此情況已經更正。請參閱 JDK-8072147
  • 問題修正:更佳的群組動態安全性
    在 OpenJDK SSL/TLS/DTLS 實行中 (SunJSSE 提供者),預設即使用安全質數 Diffie-Hellman 群組。使用者可以透過 jdk.tls.server.defaultDHEParameters 安全特性來自訂 Diffie-Hellman 群組。
  • 問題修正:Instrumentation.redefineClasses 重新定義類別時會導致 VM 當機
    Instrumentation.redefineClasses() 重新定義類別時可能導致 JVM 當機。當機可能源自於 SystemDictionary::resolve_or_null 發生記憶體區段錯誤,或是發生訊息為 'tag mismatch with resolution error table' 的內部錯誤。此情況現已修正。請參閱 JDK-8076110
注意事項

在 OSX 10.11 El Capitan 上執行時,若在啟用 SIP 時從命令行執行 Java 或按兩下 JAR 檔案,可能自環境中移除部分用於應用程式除錯的環境變數 (例如 DYLD_LIBRARY_PATH)。應用程式不該在生產環境中使用這些變數,這些變數僅能在開發期間供除錯之用。

不得在有抗碰撞性需求的數位簽章上使用 MD5。為了避免在 X.509 憑證作業期間使用 MD5 作為數位簽章演算法,已將 MD5 加入 jdk.certpath.disabledAlgorithms 安全特性中。若應用程式仍使用 MD5 簽署憑證,請儘速將弱式憑證升級。

已知問題

[macosx] 贊助商提供項目畫面存取性 (a11y) 問題
若使用者利用鍵盤存取 Java 安裝程式中的使用者介面,將無法存取軟體附加元件提供項目畫面中的超連結和核取方塊。解決方法除了在使用者介面中設定與附加元件軟體相關的偏好設定之外,使用者還可以在 Java 控制面板停用它們,或在命令行傳送 SPONSORS=0 來停用這些軟體。如需詳細資訊,請參閱常見問題 - 安裝 Java 但不安裝贊助商提供項目。請參閱 JDK-8061886 (未公開)。

Java 到期日

8u65 的到期日為 2016 年 1 月 19 日。每當具有安全漏洞修正的新版本可供使用時,Java 便會到期。對於無法連線至 Oracle 伺服器的系統,次級機制將讓本 JRE (版本 8u65) 在 2016 年 2 月 19 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),Java 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

此發行版本包含安全漏洞的修正。如需詳細資訊,請參閱 Oracle Java SE Critical Patch Update Advisory

如需此發行版本所含的問題修正清單,請參閱 JDK 8u65 問題修正網頁。

» 8u65 版本注意事項


Java 8 Update 60 (8u60)

發行版本重點
  • IANA Data 2015e
    JDK 8u60 包含 IANA 時區資料版本 2015e。如需詳細資訊,請參閱 JRE 軟體中的時區資料版本
  • 問題修正:dns_lookup_realm 預設應為 false
    Kerberos 的 krb5.conf 檔案中,dns_lookup_realm 設定現已預設為 false。請參閱 8080637
  • 問題修正:停用 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
  • 問題修正:支援對 JKS 及 PKCS12 金鑰儲存庫的金鑰儲存庫類型偵測
    金鑰儲存庫相容性模式:為了有助於互通性,Java 金鑰儲存庫類型 JKS 現在預設支援金鑰儲存庫相容性模式。此模式讓 JKS 金鑰儲存庫能夠存取 JKS 及 PKCS12 的檔案格式。若要停用金鑰儲存庫相容性模式,請將「安全」特性 keystore.type.compat 設為字串值 false。請參閱 8062552
  • 問題修正:JDK 8u 發行版本中不再使用「不安全」監督方法
    在 JDK 8u60 中,已將 sun.misc.UnsafemonitorEntermonitorExit 以及 tryMonitorEnter 方法標記為不再使用,並將於未來的發行版本中移除。這些方法並未用於 JDK 本身,在 JDK 之外也極少使用。請參閱 8069302
  • 問題修正:使用 SA 從核心檔案擷取 JFR 錄製
    DumpJFR 是一個以 Serviceability Agent 為基礎的工具,可用於從核心檔案與即時 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 工具會將 JFR 資料傾印至目前工作目錄中名稱為 recording.jfr 的檔案。請參閱 8065301 (未公開)。
  • 問題修正:名稱為 'enum' 的區域變數導致假性編譯器當機
    javac 剖析器會錯誤剖析名稱為 'enum' 的區域變數;當含有這類區域變數的程式使用與某版本相對應的 'source' 旗標進行編譯,而該版本並無 enum 建構可用 (例如 '-source 1.4'),就會產生假性失敗。請參閱 8069181
ARM 適用的 Java 開發套件發行版本 8u60

此發行版本包括 ARM 適用的 Java 開發套件發行版本 8u60 (JDK 8u60 for ARM)。如需 ARM 裝置支援資訊,請參閱 JDK for ARM Downloads 頁面。如需系統需求、安裝說明以及疑難排解秘訣的相關資訊,請參閱 Installation Instructions 頁面。

限制:「原生記憶體追蹤」支援僅限於 ARM 適用的 JDK。ARM 目標不支援 Java 命令行選項 XX:NativeMemoryTracking=detail (將會對使用者顯示錯誤訊息)。請改用下列選項:
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.Queue 以及 java.util.Deque 等等。
部署規則集 v1.2 中的變更
JDK 8u60 導入了「部署規則集 (DRS) 1.2」,其中包含下列變更:
  • 新增 "checksum" 元素作為 "id" 的子元素,讓未簽署的 jar 可藉由未壓縮形式之 jar 的 SHA-256 總和檢驗進行識別:
    • "checksum" 元素將只會比對未簽署的 jar,而指定的雜湊將只會與未壓縮形式的 jar 進行比較。
    • "checksum" 元素 (與 "certificate" 元素相似) 有 "hash""algorithm" 兩個引數,但與 "certificate" 元素不同的是,"algorithm" 僅支援值 "SHA-256"。如果提供任何其他值,都會被忽略。
  • 允許 "message" 元素套用至所有的規則類型 (之前只能套用到一個封鎖規則):
    • 在執行規則中,訊息的子元素會使訊息對話方塊不經執行規則即顯示,而預設的行為應該是顯示憑證或未簽署的對話方塊。訊息會顯示在訊息對話方塊中。
    • 在預設規則中,只有當預設動作是封鎖時才會顯示訊息。在這種情況下,訊息會包含在封鎖對話方塊中。
  • "customer" 封鎖項目回應至「Java 主控台」、追蹤檔以及 Java Usage Tracker 記錄。
    • 在 DRS 1.2 之前,可以在 ruleset.xml 檔案中包括 "customer" 元素 (以及任何子元素)。這個元素及其所有子元素現在都會被忽略。在 DRS 1.2 中,這些元素在功能上仍會被忽略。不過:
      • 剖析 ruleset.xml 檔案時,所有的 "customer" 封鎖項目都會回應至「Java 主控台」和部署追蹤檔案 (若已啟用「主控台」和「追蹤」)。
      • 使用規則時,該規則內包括的所有 "customer" 記錄都會新增至 Java Usage Tracker (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 伺服器的系統,次級機制會讓本 JRE (版本 8u60) 在 2015 年 11 月 20 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),Java 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

如需此發行版本所含的問題修正清單,請參閱 JDK 8u60 問題修正網頁。

» 8u60 版本注意事項


Java 8 Update 51 (8u51)

發行版本重點
  • IANA Data 2015d
    JDK 8u51 包含 IANA 時區資料版本 2015d。如需詳細資訊,請參閱 JRE 軟體中的時區資料版本
  • 問題修正:增加新的 Comodo 根憑證至根 CA
    為 Commodo 新增了 4 個新的根憑證:
    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 (未公開)。
  • 問題修正:增加新的 GlobalSign 根憑證至根 CA
    為 GlobalSign 新增了 2 個根憑證:
    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 (未公開)。
  • 問題修正:增加 Actalis 至根 CA
    新增了一個新的根憑證:
    Actalis Authentication Root CA
    alias: actalisauthenticationrootca
    DN: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT

    請參閱 JDK-8077903 (未公開)。
  • 問題修正:增加新的 Entrust ECC 根憑證
    新增了一個新的根憑證:
    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 (未公開)。
  • 問題修正:移除舊的 Valicert Class 1 Policy 和 Class 2 Policy 根憑證
    移除了兩個 1024 位元金鑰的根憑證:
    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 (未公開)。
  • 問題修正:移除舊的 Thawte 根憑證
    移除了兩個 1024 位元金鑰的根憑證:
    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 (未公開)。
  • 問題修正:移除較舊的 Verisign、Equifax 及 Thawte 根憑證
    移除了 5 個 1024 位元金鑰的根憑證:
    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 (未公開)。
  • 問題修正:移除 cacerts 中的 TrustCenter CA 根憑證
    移除了 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 (未公開)。
  • 問題修正:已不再使用 SunJSSE 提供者中的 RC4
    RC4 現在已被視為強度較低的加密方式。除非用戶端要求的密碼套件中沒有其他較強的密碼套件可供選用,否則伺服器不應選取 RC4。已新增一個新的安全特性 jdk.tls.legacyAlgorithms,在 Oracle JSSE 實行中定義傳統演算法。RC4 相關演算法會新增至傳統演算法清單中。請參閱 JDK-8074006 (未公開)。
  • 問題修正:禁用 RC4 密碼套件
    RC4 現在已被視為有缺陷的加密方式。在 Oracle JSSE 實行中,RC4 密碼套件已經從用戶端和伺服器預設啟用的密碼套件清單中移除。這些密碼套件仍可透過 SSLEngine.setEnabledCipherSuites()SSLSocket.setEnabledCipherSuites() 方法來啟用。請參閱 JDK-8077109 (未公開)。
  • 問題修正:改進憑證檢查
    透過此修正,JSSE 端點身分識別不會執行 JDK 中預設執行的反向名稱查詢以取得 IP 位址。如果應用程式必須執行反向名稱查詢,以便在 SSL/TLS 連線中取得原始 IP 位址,且發生端點身分識別相容性問題,可以使用系統特性 "jdk.tls.trustNameService" 來開啟反向名稱查詢。請注意,如果名稱服務不可信賴,啟用反向名稱查詢可能會易於受到 MITM 攻擊。請參閱 JDK-8067695 (未公開)。
Java 到期日

8u51 的到期日為 2015 年 10 月 20 日。每當具有安全漏洞修正的新版本可供使用時,Java 便會到期。對於無法連線至 Oracle 伺服器的系統,次級機制會讓本 JRE (版本 8u51) 在 2015 年 11 月 20 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),Java 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

此發行版本包含安全漏洞的修正。如需詳細資訊,請參閱 Oracle Java SE Critical Patch Update Advisory

如需此發行版本所含的問題修正清單,請參閱 JDK 8u51 問題修正網頁。

» 8u51 版本注意事項


Java 8 Update 45 (8u45)

發行版本重點
  • IANA Data 2015a
    JDK 8u45 包含 IANA 時區資料版本 2015a.如需詳細資訊,請參閱 JRE 軟體中的時區資料版本
  • 問題修正:增強 jar 檔案處理功能。從 JDK 8u45 發行版本開始,jar 工具在建立新的 zip 與 jar 檔案及/或解壓縮 zip 與 jar 檔案時,不再允許 zip 項目檔案名稱開頭使用斜線 "/" 與 ".." (兩個點) 的路徑元件。如果有需要,請明確使用命令行選項 "-P" 以保留兩個點 (..) 及/或絕對路徑元件。請參閱 8064601 (未公開)。
  • 問題修正:jre8u40 載入 jnlp 應用程式時,應用程式若使用巢狀 "resource" 區段會發生 NPE 錯誤。jnlp 應用程式若在 <java> 標籤中巢狀使用 標籤,會發出 NPE 錯誤。此問題現已修正。 標籤只有在實際使用 <java> 時才能使用。請參閱 8072631 (未公開)。
Java 到期日

8u45 的到期日為 2015 年 7 月 14 日。每當具有安全漏洞修正的新版本可供使用時,Java 便會到期。對於無法連線至 Oracle 伺服器的系統,次級機制會讓本 JRE (版本 8u45) 在 2015 年 8 月 14 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),Java 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

此發行版本包含安全漏洞的修正。如需詳細資訊,請參閱 Oracle Java SE Critical Patch Update Advisory

如需此發行版本所含的問題修正清單,請參閱 JDK 8u45 問題修正網頁。

» 8u45 版本注意事項


Java 8 Update 40 (8u40)

發行版本重點
  • IANA Data 2014j
    JDK 8u40 包含 IANA 時區資料版本 2014j。如需詳細資訊,請參閱 JRE 軟體中的時區資料版本
  • 問題修正:JDI、JDWP 和 JDB 中的預設和靜態介面方法。從 JDK 8 發行版本開始,介面中就有可直接執行的靜態和預設方法。這些方法無法透過 JDWP 或 JDI 執行,因此無法正確除錯。請參閱 JDK 8 相容性指南以瞭解詳細資訊。請參閱 8042123
  • 問題修正:32 位元的 JRE 可以從「控制面板」啟用 Java Access Bridge。之前解除安裝 64 位元 JRE 時,即使系統中仍有 32 位元 JRE 存在,但還是會從「Java 控制面板」移除「啟用 Java Access Bridge」核取方塊。自 JDK 8u40 發行版本起,如果 32 位元 JRE 存在的話,將保留位於控制面板 -> 輕鬆存取 -> 輕鬆存取中心 -> 使用不含顯示器的電腦的「啟用 Java Access Bridge」核取方塊。讓使用者可以透過控制面板來啟用 Java Access bridge,請參閱 8030124
  • 問題修正:將 Mac OS X 上的「JavaFX 媒體堆疊」現代化。JavaFX 媒體新增以 AVFoundation 為基礎的播放器平台。為了與 Mac App Store 的相容性,現在可以移除以 QTKit 為基礎的舊平台。請參閱 8043697 (未公開)
  • 問題修正:遺漏 DOM API。JDK 8u40 發行版本不慎移除了舊版 Plugin DOM API。如果 Applet 需要使用 com.sun.java.browser.dom.DOMService 與瀏覽器進行溝通,使用者需要更新 Applet 改使用 netscape.javascript.JSObject,或繼續使用 JDK 8 Update 31。這個問題已經在 build 26 解決,並已發布了新的 8u40 安裝程式。如果您遭遇此問題,請下載並執行更新的 JDK 8u40 安裝程式。請參閱 8074564
  • 問題修正:Mac 10.10:以 Splash 畫面執行的應用程式會發生焦點問題。透過 Webstart 啟動或獨立安裝的應用程式,若使用 Splash 畫面將無法取得鍵盤焦點。解決方法:使用 -Xnosplash 選項啟動 javaws。這個問題已經在 build 27 解決,並已發布了新的 8u40 安裝程式。如果您遭遇此問題,請下載並執行更新的 JDK 8u40 安裝程式。請參閱 8074668
  • Java Packager 工具增強功能
    JDK 8u40 發行版本的 Java Packager 包含以下增強功能:
  • 已不再使用的 API
    背書標準覆寫機制和擴充機制已不再使用,並且可能會在未來發行版本中移除。沒有執行階段的變更。建議將使用「背書標準覆寫」或「擴充」機制的現有應用程式移轉為不使用這些機制。-XX:+CheckEndorsedAndExtDirs 命令行選項可協助您識別這些機制目前的使用狀況。當下列任一條件為真時,將會失敗:
    • 已設定 -Djava.endorsed.dirs-Djava.ext.dirs 系統特性以更改預設位置;或
    • ${java.home}/lib/endorsed 目錄存在;或
    • ${java.home}/lib/ext 包含的所有 JAR 檔案中,沒有隨著 JDK 一起安裝的版本;或
    • 任何平台特定的全系統擴充目錄包含任一 JAR 檔案。
    JDK 8u40 和更新版本支援 -XX:+CheckEndorsedAndExtDirs 命令行選項。
  • JJS 工具頁面差異
    日文版的 jjs 說明頁面與英文版不同。英文版的 jjs 工具頁面中已移除部分不支援的選項。日文版文件將於未來更新。請參閱 8062100 (未公開)。其他 jjs 工具頁面的變更,請參閱 JDK 8 中的工具增強功能
  • G1HeapWastePercent 和 G1MixedGCLiveThresholdPercent 預設值的變更
    G1HeapWastePercent 的預設值已經從 10 變更為 5,以降低對完整 GC 的需求。基於相同的原因,G1MixedGCLiveThresholdPercent 的預設值已從 65 變更為 85。
  • 新的 Java 類別存取篩選介面
    jdk.nashorn.api.scripting.ClassFilter 介面可以讓您限制從透過 Nashorn 命令檔引擎執行的命令檔存取指定的 Java 類別。請參閱 Nashorn User's Guide 中的 Restricting Script Access to Specified Java Classes 和 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 訊息,則應驗證並套用以下修正程式或其更新版本:
    • 150531-02 (SPARC)
    • 150636-01 (x86)
  • Troubleshooting Guide 更新 NMT
    原生記憶體追蹤 (NMT) 是 Java Hotspot VM 功能,可追蹤 HotSpot JVM 的內部記憶體用量。「原生記憶體追蹤」可用於監督 VM 內部記憶體配置和診斷 VM 記憶體洩漏。VM 增強功能頁面已更新具備 NMT 功能。請參閱 Java SE 8 中的 Java 虛擬機器增強功能。Troubleshooting Guide 已更新了 NMT 功能。請參閱原生記憶體追蹤
  • 多個 JRE 啟動器功能已不再使用
    JDK 8u40 中已不再使用啟動時選取的 JRE 版本或多個 JRE 啟動器功能。使用此功能部署需要特定 Java 版本的應用程式時,必須切換至替代的部署解決方案 (例如 Java WebStart)。
  • JavaFX 增強功能
    自 JDK 8u40 發行版本起,已增強 JavaFX 控制項以支援輔助技術,亦即現在已經可以在 JavaFX 控制項提供輔助功能。此外,開發人員可以使用提供的公用 API 來寫入自己的輔助功能控制項。Windows 和 Mac OS X 平台上會提供輔助功能支援,包括:
    • 藉由螢幕助讀程式提供讀取 JavaFX 控制項的支援
    • 可使用鍵盤來傳遞 JavaFX 控制項
    • 支援特殊高對比模式,讓使用者更容易看到控制項。
    請參閱 8043344 (未公開)。

    JDK 8u40 發行版本包括新的 JavaFX UI 控制項:一個微調控制項、文字格式設定支援和一組標準的警示對話方塊。 請參閱 8043350 (未公開)。
商業功能
  • 應用程式類別資料共用 (AppCDS)
    應用程式類別資料共用 (AppCDS) 擴充 CDS,可以讓您將標準擴充目錄中的類別和應用程式類別路徑放置在共用存檔中。這是一項實驗性質的功能,不授權供商業使用。請參閱 java 啟動器工具頁面中的 -XX:+UseAppCDS 選項。
  • 合作式記憶體管理
    自 JDK 8u40 起,JDK 已新增「記憶體壓力」的概念。記憶體壓力是代表系統上總記憶體用量 (RAM) 的特性。記憶體壓力愈高,表示系統愈接近記憶體耗盡。這是一項實驗性質的功能,不授權供商業使用。JDK 將嘗試減少其記憶體用量,作為記憶體壓力增加後的反應。主要是透過減少 Java 堆集大小來達成。JDK 為減少記憶體用量所採取的動作,可能會導致效能降低。這是有意的選擇。應用程式是透過 JMX MXBean,使用 0 (無壓力) 到 10 (幾乎記憶體耗盡) 的級別來提供壓力層次。若要啟用此功能,則應註冊 jdk.management.cmm.SystemResourcePressureMXBean。系統便會使用 "MemoryPressure" 屬性設定記憶體壓力。
    同時提供接受 'none'、'low'、'medium' 或 'high' 其中一個引數的新命令行旗標 -XX:MemoryRestriction。此旗標將在 JDK 中設定初始壓力,在 MXBean 未註冊的情況下也會運作。「合作式記憶體管理」需要 G1 GC (-XX:+UseG1GC)。此功能與 -XX:+ExplicitGCInvokesConcurrent 旗標不相容。
  • 新的商業旗標
    商業授權持有者現在可以使用兩個新的 VM 選項:
    • -XX:+ResourceManagement
    • -XX:ResourceManagementSampleInterval=值 (毫秒)
    如需詳細資訊,請參閱 Java 啟動器文件。
  • 新的 MSI 安裝程式文件:
    已提供 Microsoft Windows Installer (MSI) Enterprise JRE Installer Guide。您需要有商業授權,才能在生產環境中使用「MSI Enterprise JRE 安裝程式」。深入瞭解商業功能以及如何啟用
Java 到期日

8u40 的到期日為 2015 年 4 月 14 日。每當具有安全漏洞修正的新版本可供使用時,Java 便會到期。對於無法連線至 Oracle 伺服器的系統,次級機制會讓本 JRE (版本 8u40) 在 2015 年 5 月 14 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),Java 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

如需此發行版本所含的問題修正清單,請參閱 JDK 8u40 問題修正網頁。

» 8u40 版本注意事項


Java 8 Update 31 (8u31)

發行版本重點
  • IANA Data 2014j
    JDK 8u31 包含 IANA 時區資料版本 2014j。如需詳細資訊,請參閱 JRE 軟體中的時區資料版本
  • 預設停用 SSLv3
    從 JDK 8u31 發行版本開始,SSLv3 通訊協定 (安全通訊埠層) 已停用,且一般來說無法使用。請參閱 \lib\security\java.security 檔案中的 jdk.tls.disabledAlgorithms 特性。若確實需要使用 SSLv3,您可以從 java.security 檔案的 jdk.tls.disabledAlgorithms 特性中移除 'SSLv3',或是在起始 JSSE 之前動態設定此安全特性來重新啟用此通訊協定。
  • Java 控制面板的變更
    從 JDK 8u31 發行版本開始,已從 Java 控制面板 - 進階選項中移除 SSLv3 通訊協定。如果使用者需要在應用程式使用 SSLv3,請使用下列方式進行手動重新啟用:
    • 在 JRE 層次啟用 SSLv3 通訊協定:如上一節所述。
    • 在部署層次啟用 SSLv3 通訊協定:編輯 deployment.properties 檔案,並新增下列項目:

      deployment.security.SSLv3=true
Java 到期日

8u31 的到期日為 2015 年 4 月 14 日。每當具有安全漏洞修正的新版本可供使用時,Java 便會到期。對於無法連線至 Oracle 伺服器的系統,次級機制會讓本 JRE (版本 8u31) 在 2015 年 5 月 14 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),Java 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

此發行版本包含安全漏洞的修正。如需詳細資訊,請參閱 Oracle Java SE Critical Patch Update Advisory

如需此發行版本所含的問題修正清單,請參閱 JDK 8u31 問題修正網頁。

» 8u31 版本注意事項


Java 8 Update 25 (8u25)

發行版本重點
  • IANA Data 2014c
    JDK 8u25 包含 IANA 時區資料版本 2014c。如需詳細資訊,請參閱 JRE 軟體中的時區資料版本
  • 問題修正:減少啟用之密碼套件清單中的 RC4 偏好設定模式
    此修正會在 SunJSSE 提供者預設會啟用之密碼套件清單中減少 RC4 密碼套件的偏好設定。請參閱 8043200 (未公開)。
  • 問題修正:在 Windows 上使用日文 IM 時,JRE 8u20 會當機
    在 Windows 平台上輸入某些日文或中文字元時,VM 會在使用 Swing 控制項時當機。此問題現已修正。請參閱 8058858 (未公開)。
停用 Oracle JDK 和 JRE 中 SSL v3.0 的指示

Oracle 建議使用者和開發人員停用 SSLv3 通訊協定。
» Java 使用者如何確認自己不會受 SSL V3.0 'Poodle' 漏洞影響?

Java 到期日

8u25 的到期日為 2015 年 1 月 20 日。每當具有安全漏洞修正的新版本可供使用時,Java 便會到期。對於無法連線至 Oracle 伺服器的系統,次級機制會讓本 JRE (版本 8u25) 在 2015 年 2 月 20 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),Java 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

此發行版本包含安全漏洞的修正。如需詳細資訊,請參閱 Oracle Java SE Critical Patch Update Advisory

如需此發行版本所含的問題修正清單,請參閱 JDK 8u25 問題修正網頁。

» 8u25 版本注意事項


Java 8 Update 20 (8u20)

發行版本重點
  • 已將新的旗標加入 Java 管理 API
    MinHeapFreeRatioMaxHeapFreeRatio 旗標已成為可供管理。這表示可以在執行階段使用 Java 中的管理 API 來變更這些旗標。對這些旗標的支援同時也已新增至 ParallelGC,作為適應大小原則的一部分。
  • Java 安裝程式變更
    • 現在提供能夠讓使用者在整個企業安裝 JRE 的新 Microsoft Windows Installer (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。
    • 安全層次已經移除。現在只有非常高層次可供選擇。不符合最新安全做法的 Applet 仍可授權執行,方法是將裝載這些 Applet 的網站加入例外網站清單中。例外網站清單會提供相關選項讓使用者可以根據各個網站來一一允許過去選取選項所允許的 Applet,因此能夠將使用較寬鬆設定值會有的風險降到最低。
  • Java 編譯器已更新
    javac 編譯器已經更新,使用 "this" 來實行空白 final 欄位存取的明確指定分析。請參閱 JDK 8 相容性指南以瞭解詳細資訊。
  • Java Plugin 和 Java Webstart 的最低 Java 版本需求變更
    Java Plugin 和 Java Webstart 的最低 Java 版本需求現在為 Java 5。不是使用 Java 5 或更新版本的 Applet 必須以較新版本的 Java 加以改寫後才能繼續運作。以舊版 Java 撰寫但能夠在 Java 5 執行的 Applet 將可繼續運作。
  • UsageTracker 輸出格式的變更
    UsageTracker 輸出格式已變更為使用「引號」,以避免在日誌中發生混淆。這可能需要變更讀取此類資訊的方式。雖然建議使用新的格式,但此功能仍可設為使用先前版本的行為方式。請參閱 Java Usage Tracker 文件。
  • Java 封裝工具的變更
    • javafxpackager 已經重新命名為 javapackager
    • javapackager 部署命令新增了 "-B" 選項,可讓您將引數傳送至用來建立獨立應用程式的包裝程式。請參閱 javapackager (Windows)/(Unix) 文件以瞭解相關資訊
    • 協助程式參數引數已經新增至 JavaFX Ant Task Reference。它可讓您指定用來建立獨立應用程式之包裝程式的引數 (在 元素中)。
Java 到期日

8u20 的到期日為 2014 年 10 月 14 日。每當具有安全漏洞修正的新版本可供使用時,Java 便會到期。對於無法連線至 Oracle 伺服器的系統,次級機制會讓本 JRE (版本 8u20) 在 2014 年 11 月 14 日到期。符合其中一項條件之後 (有新的版本可供使用或是已達到期日),Java 將會提供額外的警告和提醒來通知使用者更新為較新的版本。

問題修正

如需此發行版本所含的問題修正清單,請參閱 JDK 8u20 問題修正網頁。

» 8u20 版本注意事項


Java 8 Update 11 (8u11)

此發行版本包含安全漏洞的修正。如需詳細資訊,請參閱 Oracle Critical Patch Update Advisory

如需此發行版本所含的問題修正清單,請參閱 JDK 8u11 問題修正網頁。

» 8u11 版本注意事項


Java 8 Update 5 (8u5)

此發行版本包含安全漏洞的修正。如需詳細資訊,請參閱 Oracle Critical Patch Update Advisory

如需此發行版本所含的問題修正清單,請參閱 JDK 8u5 問題修正網頁。

» 8u5 版本注意事項


Java 8 發行版本

» JDK 與 JRE 8 版本注意事項


您可能也會對下列項目感興趣::




選擇語言 | 關於 Java | 支援 | 開發人員
隱私權  | 使用條款 | 註冊商標 | 免責聲明

Oracle