3478
Java
Java 8 發行版要點說明
Java 8 發行版要點說明
本文適用於:
- Java 版本: 8.0
本頁著重說明了各 Java 發行版中影響最終用戶的更改。有關更改的詳細信息,請參見各發行版的發行說明。
» Java 發行日期
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 代理時某些驗證方案可能不是所希望的驗證方案。相應地,默認情況下在 Oracle Java 運行時中已停用“基本”驗證方案,方法為將 Basic 添加到jdk.http.auth.tunneling.disabledSchemes
網絡屬性。現在,在為 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 文件的禁用算法列表和密鑰大小。
以下算法和密鑰大小在此發行版中受到限製:- MD2(在摘要或簽名算法中)
- 小於 1024 位的 RSA 密鑰
要檢查是否已使用弱算法或密鑰對 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'
請定期在 https://java.comhttps://www.java.com/cryptoroadmap 上檢查 Oracle JRE 和 JDK 加密路線圖,了解計劃對已簽名 JAR 文件和其他安全組件進行的限製。特別是,請注意當前計劃是在 2017 年 4 月版 CPU 中限製已簽名 JAR 文件中的基於 MD5 的簽名。
要測試是否已使用 MD5 對 JAR 進行簽名,可將MD5
添加到jdk.jar.disabledAlgorithms
安全屬性,例如:
jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize <>
,
然後按照上麵所述對 JAR 文件運行jarsigner -verify -J-Djava.security.debug=jar
。
JDK-8155973(非公共) -
警告消息已添加到部署驗證程序對話框
已將一條警告添加到插件驗證對話框中,在使用代理或不使用 SSL/TLS 協議的情況下使用 HTTP 基本驗證(身份證明在不加密的情況下發送)時,將會顯示該警告:
“警告:基本驗證方案將有效地以明文方式傳輸身份證明。是否確實要執行此操作?”
JDK-8161647(非公共)
已知問題
在 Windows 上,一些事件在 JFR 錄製中不可用
對於發行版 8u111,以下事件在 Windows 上的 JFR 錄製中不可用:hotspot/jvm/os/processor/cpu_load
os/processor/context_switch_rate
這是由於在帶有 JDK-8162419 更改的 8u111 中引入了回歸 JDK-8063089 所致。8u111 發行版中無法包含 JDK-8063089 的修複。它將包含在下一個 8u111 BPR 工作版本以及下一個公開發行版中。
JDK-8063089(非公共)
JVM 在 macOS Sierra 10.12 上引發了 NullPointerExceptions
在 macOS Sierra 10.12 上,當小應用程序正在瀏覽器中運行時,如果用戶按功能鍵(例如 Command、Shift 或 Alt),則可能會顯示名為“內部錯誤”的錯誤框。它還將在 macOS 停靠欄中顯示 "exec" 圖標。用戶可以關閉小應用程序,或者嚐試在未按功能鍵的情況下重新運行小應用程序。要修複此問題,用戶可安裝 JRE 8u112。請參閱 JDK-8165867。
Java 到期日期
8u111 的到期日期是 2017 年 1 月 17 日。隻要具有安全漏洞修複的新發行版可用,Java 就會到期。對於無法訪問 Oracle 服務器的係統,輔助機製將使此 JRE(版本 8u111)於 2017 年 2 月 17 日到期。滿足兩個條件中的任何一個(新發行版可用或到達到期日期)後,Java 將向用戶提供其他警告和提醒以更新到較新版本。
Bug 修複
本發行版包含對安全漏洞的修複。有關詳細信息,請參閱 Oracle Java SE Critical Patch Update Advisory。有關此發行版中包含的 Bug 修複列表,請參閱 JDK 8u111 Bug 修複頁。
Java 8 Update 101 (8u101)
發行要點說明
- IANA Data 2016d
JDK 8u101 包含 IANA 時區數據版本 2016d。有關詳細信息,請參閱 JRE 軟件中的時區數據版本。請參閱 JDK-8151876。 - 證書更改
新 DTrust 證書已添加到根 CA
已添加兩個新的根證書:
-
D-TRUST Root Class 3 CA 2 2009
別名: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
別名:dtrustclass3ca2ev
DN:CN=D-TRUST Root Class 3 CA 2 EV 2009,O=D-Trust GmbH,C=DE
新 Iden 證書已添加到根 CA
已添加三個新的根證書:
-
IdenTrust Public Sector Root CA 1
別名:identrustpublicca
DN:CN=IdenTrust Public Sector Root CA 1,O=IdenTrust,C=US -
IdenTrust Commercial Root CA 1
別名:identrustcommercial
DN:CN=IdenTrust Commercial Root CA 1,O=IdenTrust,C=US -
IdenTrust DST Root CA X3
別名:identrustdstx3
DN:CN=DST Root CA X3,O=Digital Signature Trust Co.
已刪除 Comodo 根 CA
已從 cacerts 文件中刪除 Comodo "UTN - DATACorp SGC" 根 CA 證書。請參閱 JDK-8141540
已刪除 Sonera Class1 CA
已從 cacerts 文件中刪除 "Sonera Class1 CA" 根 CA 證書。請參閱 JDK-8141276。 -
- 改進對 javax.rmi.CORBA.ValueHandler 的訪問控製
javax.rmi.CORBA.Util
類提供了可供存根和綁定使用的方法來執行常見操作。它還用作 ValueHandlers 的工廠。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"
來覆蓋此權限檢查行為。
因此,如果已安裝 SecurityManager 並且不滿足以下兩個要求,則需要對顯式調用javax.rmi.CORBA.Util.createValueHandler
的外部應用程序執行配置更改:- SecurityManager 未對
java.io.SerializablePermission("enableCustomValueHanlder")
進行授權。 - 當應用程序在 JDK8u 和之前的版本上運行時,係統屬性
"jdk.rmi.CORBA.allowCustomValueHandler"
未定義或者已定義為 "false"(不區分大小寫)。
請注意,"enableCustomValueHanlder"
拚寫錯誤將在 2016 年 10 月的發行版中更正。在這些及未來的 JDK 發行版中,"enableCustomValueHandler"
將作為正確的 SerializationPermission 來使用。
JDK-8079718(非公共) - SecurityManager 未對
- 在 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。 - 部署工具包 API 方法不再安裝 JRE
對於來自deployJava.js
的部署工具包 APIinstallLatestJRE()
和installJRE(requestedVersion)
方法,以及來自dtjava.js
的install()
方法,不再安裝 JRE。如果用戶的 Java 版本低於安全基線,則會將用戶重定向到java.com
以獲取更新後的 JRE。JDK-8148310(非公共) - 與 ProtectionDomain 對象結合時,DomainCombiner 不再谘詢靜態 ProtectionDomain 對象的運行時策略
通過此修複,使用權限集不足的靜態 ProtectionDomain 對象(使用雙參數構造器創建)的應用程序現在會遇到 AccessControlException。它們應使用其權限集可通過當前策略擴展的動態對象(使用四參數構造器)來替換靜態 ProtectionDomain 對象,或者構造具有所有必需權限的靜態 ProtectionDomain 對象。JDK-8147771(非公共)
已知問題
在使用靜態類 ID 時,Internet Explorer (IE) 無法識別 JRE 8u101
使用 JRE 8u101 時,如果使用靜態類 ID 來啟動小應用程序或 Web Start 應用程序,則用戶會看到意外的對話框,說明應該使用最新的 JRE 或取消啟動,即使用戶已安裝並正在使用最新的 JRE (JRE 8u101) 也是如此。這種特殊情況僅在 Windows 和 IE 中發生。
根據 https://www.oracle.com/technetwork/java/javase/family-clsid-140615.html,我們建議不為 JRE 版本選擇使用靜態類 ID(自 2005 年 12 月 JDK 5u6 起)。
要解決此問題,用戶可以執行以下兩種操作之一:- 使用最新版本 (8u101) 啟動並忽略警告。
- 安裝 JRE 8u102 而非 JRE 8u101 以避免出現此問題。
- 使用動態類 ID 而非靜態類 ID。
- 在使用 HTML 小應用程序時或者在將 JNLP 描述符用於 JNLP 時,使用 java_version。
Java 到期日期
8u101 的到期日期為 2016 年 10 月 19 日。隻要具有安全漏洞修複的新發行版可用,Java 就會到期。對於無法訪問 Oracle 服務器的係統,輔助機製將使此 JRE(版本 8u101)於 2016 年 11 月 19 日到期。滿足兩個條件中的任何一個(新發行版可用或到達到期日期)後,Java 將向用戶提供其他警告和提醒以更新到較新版本。
Bug 修複
本發行版包含對安全漏洞的修複。有關詳細信息,請參閱 Oracle Java SE Critical Patch Update Advisory。有關此發行版中包含的 Bug 修複列表,請參閱 JDK 8u101 Bug 修複頁。
Java 8 Update 91 (8u91)
發行版要點說明
- IANA Data 2016a
JDK 8u91 包含 IANA 時區數據版本 2016a。有關詳細信息,請參閱 JRE 軟件中的時區數據版本。 - Bug 修複:小應用程序啟動時間衰退已修複
JDK-8080977 針對小應用程序啟動引入了延遲。此延遲僅在 IE 上出現且持續約 20 秒。JDK-8136759 刪除了此延遲。請參閱 JDK-8136759 - Bug 修複:現在,生成 DSA 簽名時需要進行密鑰強度檢查
對於簽名生成,如果摘要算法的安全強度弱於簽名時所用密鑰的安全強度(例如,使用(2048,256)位 DSA 密鑰的 SHA1withDSA 簽名),則操作將失敗,出現錯誤消息:“SHA1 摘要算法的安全強度對於此密鑰大小不足。”JDK-8138593(非公共) - Bug 修複:Firefox 42 實時連接問題
因為這可能導致瀏覽器掛起,在從plugin-container.exe
啟動 Java 插件(Firefox 42 的默認行為)並且小應用程序狀態不是就緒 (2) 時,我們不處理 JavaScript-to-Java 調用。如果小應用程序未就緒(狀態不是 2),則我們不執行實際的 Java 方法,僅返回空值。
如果從plugin-container.exe
啟動插件,則不使用可能需要超過 11 秒時間(dom.ipc.plugins.hangUITimeoutSecs
的默認值)來完成的 JavaScript-To-Java 調用,或者在 JavaScript-To-Java 調用期間顯示模態對話框。在這種情況下,必須阻止主瀏覽器線程,這可能會導致瀏覽器掛起和插件終止。
針對 Firefox 42 的解決方法:用戶可以設置dom.ipc.plugins.enabled=false
。此解決方法的副作用是會更改所有插件的設置。JDK-8144079(非公共) - Bug 修複: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(非公共) - Bug 修複:在 JSSE 提供程序中禁用 MD5withRSA 簽名算法
現在認為 MD5withRSA 簽名算法不安全,不應再使用。相應地,默認情況下,在 Oracle JSSE 實現中通過將 "MD5withRSA" 添加到 "jdk.tls.disabledAlgorithms" 安全屬性來停用 MD5withRSA。現在,默認情況下不再接受使用 MD5withRSA 算法簽名的 TLS 握手消息和 X.509 證書。此更改擴展以前基於 MD5 的證書限製 ("jdk.certpath.disabledAlgorithms"),以在其中另外包括 TLS 版本 1.2 中的握手消息。如果需要,可以通過從 "jdk.tls.disabledAlgorithms" 安全屬性中刪除 "MD5withRSA" 來重新激活此算法。JDK-8144773(非公共) - Bug 修複:新證書已添加到根 CA
已添加八個新的根證書:-
QuoVadis Root CA 1 G3
別名:quovadisrootca1g3
DN:CN=QuoVadis Root CA 1 G3,O=QuoVadis Limited,C=BM -
QuoVadis Root CA 2 G3
別名:quovadisrootca2g3
DN:CN=QuoVadis Root CA 2 G3 -
QuoVadis Root CA 3 G3
別名:quovadisrootca3g3
DN:CN=QuoVadis Root CA 3 G3,O=QuoVadis Limited,C=BM -
DigiCert Assured ID Root G2
別名:digicertassuredidg2
DN:CN=DigiCert Assured ID Root G2,OU=www.digicert.com,O=DigiCert Inc,C=US -
DigiCert Assured ID Root G3
別名:digicertassuredidg3
DN:CN=DigiCert Assured ID Root G3,OU=www.digicert.com,O=DigiCert Inc,C=US -
DigiCert Global Root G2
別名:digicertglobalrootg2
DN:CN=DigiCert Global Root G2,OU=www.digicert.com,O=DigiCert Inc,C=US -
DigiCert Global Root G3
別名:digicertglobalrootg3
DN:CN=DigiCert Global Root G3,OU=www.digicert.com,O=DigiCert Inc,C=US -
DigiCert Trusted Root G4
別名:digicerttrustedrootg4
DN:CN=DigiCert Trusted Root G4,OU=www.digicert.com,O=DigiCert Inc,C=US
-
注釋
刪除靜態 JRE
對於在版本 8u91 之前發行的 Windows 版 Java 安裝程序,默認情況下不刪除靜態安裝的 JRE。要刪除靜態安裝的 JRE,用戶必須在 Java 安裝程序的用戶界麵中手動選擇這些 JRE。現在,在 Java 發行版 8u91 和更高版本中,靜態安裝的 JRE 在低於安全基線時將被自動刪除。有關靜態安裝的詳細信息,請參閱 Java 運行時環境配置。
Java 到期日期
8u91 的到期日期為 2016 年 7 月 19 日。隻要具有安全漏洞修複的新發行版可用,Java 就會到期。對於無法訪問 Oracle 服務器的係統,輔助機製將使此 JRE(版本 8u91)於 2016 年 8 月 19 日到期。滿足兩個條件中的任何一個(新發行版可用或到達到期日期)後,Java 將向用戶提供其他警告和提醒以更新到較新版本。
Bug 修複
本發行版包含對安全漏洞的修複。有關詳細信息,請參閱 Oracle Java SE Critical Patch Update Advisory。有關此發行版中包含的 Bug 修複列表,請參閱 JDK 8u91 Bug 修複頁。
Java 8 Update 77 (8u77)
- IANA Data 2016a
JDK 8u77 包含 IANA 時區數據版本 2016a。有關詳細信息,請參閱 JRE 軟件中的時區數據版本。
Java 到期日期
8u77 的到期日期是 2016 年 4 月 19 日。隻要具有安全漏洞修複的新發行版可用,Java 就會到期。對於無法訪問 Oracle 服務器的係統,輔助機製將使此 JRE(版本 8u77)於 2016 年 5 月 19 日到期。滿足兩個條件中的任何一個(新發行版可用或到達到期日期)後,Java 將向用戶提供其他警告和提醒以更新到較新版本。
注釋
此安全預警 (8u77) 基於早期 8u74 PSU 發行版。所有使用早期 JDK 8 發行版的用戶都應更新到此發行版。有關關鍵補丁程序更新和補丁程序集更新之間的差異的詳細信息,請訪問 Java CPU 和 PSU 發行版介紹。
8u77 的演示、示例和文檔包不受 CVE-2016-0636 安全預警的影響,因此在發布四月的關鍵補丁程序更新之前,8u73 版本的演示、示例和文檔包即為最新的版本。
Bug 修複
本發行版包含安全漏洞的修複。有關詳細信息,請參閱 Oracle Java SE Critical Patch Update Advisory。
Java 8 Update 73 (8u73)
發行要點說明
- IANA Data 2015g
JDK 8u73 包含 IANA 時區數據版本 2015g。有關詳細信息,請參閱 JRE 軟件中的時區數據版本。
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 版本的演示、示例和文檔包會保持最新的版本。
Bug 修複
本發行版包含安全漏洞的修複。有關詳細信息,請參閱 Oracle Java SE Critical Patch Update Advisory。請注意,8u73 不包含在 8u72 中找到的 PSU 工作版本。需要 8u72 中包含的附加 Bug 修複的客戶應升級到 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 增強安全配置 (ESC) 的用戶,在交互模式下安裝 Java 時可能會遇到問題。此問題已在 8u71 發行版中得到解決。在交互模式下執行的安裝程序對 ESC 配置不會再顯示為已過期。請參閱 JDK-8140197。 - Bug 修複:使用 AES 加密的 PBE 算法中的問題已得到更正
已更正使用 256 位 AES 密碼的 PBE 錯誤,這樣派生的密鑰會有所不同,並且不等於以前從同一口令派生的密鑰。JDK-8138589(非公共)。 - Bug 修複:為 XML 最大實體大小增加了默認限製
已為最大實體大小增加了默認限製。有關 XML 處理限製的詳細信息,請參閱 Java 教程中的處理限製。JDK-8133962(非公共) - Bug 修複:企業 MSI 開關 'REMOVEOLDERJRES' 文檔中的問題已得到更正
企業 MSI 文檔列出了配置選項。以前缺少用來卸載舊 JRE 的 REMOVEOLDERJRES 選項。已添加此選項,並提供以下說明:
如果設置為 1,則刪除係統上安裝的較舊發行版的 JRE。
默認值:0 不刪除任何舊 JRE
JDK-8081237(非公共)
Java 到期日期
8u71 的到期日期是 2016 年 4 月 19 日。隻要具有安全漏洞修複的新發行版可用,Java 就會到期。對於無法訪問 Oracle 服務器的係統,輔助機製將使此 JRE(版本 8u71)於 2016 年 5 月 19 日到期。滿足兩個條件中的任何一個(新發行版可用或到達到期日期)後,Java 將向用戶提供其他警告和提醒以更新到較新版本。
Bug 修複
本發行版包含安全漏洞的修複。有關詳細信息,請參閱 Oracle Java SE Critical Patch Update Advisory。
有關此發行版中包含的 Bug 修複列表,請參閱 JDK 8u71 Bug 修複頁。
Java 8 Update 66 (8u66)
發行要點說明
8u66 工作版本 18 解決了有關 Firefox 的一個問題。
- Bug 修複:從錯誤的線程調用
_releaseObject
近期對 Firefox 的一項更改導致從主線程之外的其他線程調用_releaseObject
。這可能會導致爭用情況,從而可能無意中使瀏覽器崩潰。在 8u66 的工作版本 18 中已經解決了這個問題。有關詳細信息,請參閱 Bugs@Mozilla 1221448。請參閱 JDK-8133523。
安裝 Java 之後,Java 插件在 Firefox 中不工作
在嚐試運行 Java 插件時 Firefox 42 可能會崩潰。常見問題中列出了解決方法選項。請參閱 JDK-8142908(非公共)。
Java 到期日期
8u66 的到期日期是 2016 年 1 月 19 日。隻要具有安全漏洞修複的新發行版可用,Java 就會到期。對於無法訪問 Oracle 服務器的係統,輔助機製將使此 JRE(版本 8u66)於 2016 年 2 月 19 日到期。滿足兩個條件中的任何一個(新發行版可用或到達到期日期)後,Java 將向用戶提供其他警告和提醒以更新到較新版本。
Bug 修複
本發行版包含安全漏洞的修複。有關詳細信息,請參閱 Oracle Java SE Critical Patch Update Advisory。
有關此發行版中包含的 Bug 修複列表,請參閱 JDK 8u66 Bug 修複頁。
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
8u65 發行版中引入了新的安裝程序以將 OS X 用戶更新到最新版本。安裝程序同時適用於計劃的更新和手動更新,並且在 java.com 和 OTN 上提供了軟件包。用戶在遇到新安裝程序的兼容性問題時,可手動下載和安裝 My Oracle Support 上提供的 ".pkg" 安裝程序。 - Bug 修複:Hotspot 應使用 PICL 接口獲取 SPARC 上的高速緩存行大小
目前在 Solaris/SPARC 上需要使用 libpicl 庫來確定高速緩存行大小。如果庫不存在或者 PICL 服務不可用,JVM 將顯示一條警告,並且將關閉利用 BIS(塊初始化存儲)指令的編譯器優化。請參閱 JDK-8056124。 - Bug 修複:dns_lookup_realm 默認情況下應為 false
Kerberos krb5.conf 文件中的 dns_lookup_realm 設置默認情況下為 false。請參閱 JDK-8080637。 - Bug 修複:調用
signal()
期間預加載libjsig.dylib
時會導致死鎖
應用程序需要預加載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,則從命令行運行 Java 或雙擊 JAR 文件時,可能會從環境中刪除一些用於調試應用程序的特定環境變量,例如 DYLD_LIBRARY_PATH
。在生產環境中應用程序不應依賴於這些變量,這些變量僅用於在開發期間進行調試。
MD5 不能用於需要阻止衝突的數字簽名。為了防止在執行 X.509 證書操作時將 MD5 用作數字簽名算法,我們將 MD5 添加到 jdk.certpath.disabledAlgorithms
安全屬性。對於仍在使用 MD5 簽名證書的應用程序,請盡快升級弱證書。
已知問題
[macosx] 讚助商產品屏幕可訪問性 (a11y) 問題
用戶在使用鍵盤訪問 Java 安裝程序中的用戶界麵時,將無法在軟件加載項產品屏幕中訪問超鏈接和複選框。作為在用戶界麵中設置與加載項軟件相關的首選項的一種解決方法,用戶可以通過在 Java 控製麵板中禁用此類產品或通過命令行傳遞 SPONSORS=0
來禁用這些產品。有關詳細信息,請參閱安裝不帶讚助商產品的 Java 的常見問題。
Java 到期日期
8u65 的到期日期是 2016 年 1 月 19 日。隻要具有安全漏洞修複的新發行版可用,Java 就會到期。對於無法訪問 Oracle 服務器的係統,輔助機製將使此 JRE(版本 8u65)於 2016 年 2 月 19 日到期。滿足兩個條件中的任何一個(新發行版可用或到達到期日期)後,Java 將向用戶提供其他警告和提醒以更新到較新版本。
Bug 修複
本發行版包含安全漏洞的修複。有關詳細信息,請參閱 Oracle Java SE Critical Patch Update Advisory。
有關此發行版中包含的 Bug 修複列表,請參閱 JDK 8u65 Bug 修複頁。
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)。相應地,默認情況下,在 Oracle JSSE 實現中通過將 "RC4" 添加到 "jdk.tls.disabledAlgorithms" 安全屬性,並將其從默認啟用的密碼套件列表中刪除,已停用了基於 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 發行版中不安全的監視方法已過時
sun.misc.Unsafe
上的方法monitorEnter
、monitorExit
和tryMonitorEnter
在 JDK 8u60 中被標記為已過時,將在以後的發行版中刪除。這些方法不在 JDK 自身內部使用,也極少在 JDK 之外使用。請參閱 8069302。 - Bug 修複:使用 SA 從核心文件提取 JFR 記錄
DumpJFR 是基於可服務性代理的工具,可用於從核心文件和實時 Hotspot 進程提取 Java 飛行記錄器 (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 附加到實時進程:
- Bug 修複:名為 "enum" 的本地變量導致虛假的編譯器崩潰
javac
語法分析器未正確對名為 "enum" 的本地變量進行語法分析;當程序包含此類本地變量時,如果在編譯過程中使用的 "source" 標記對應於不支持枚舉構造的發行版(例如 "-source 1.4"),則會產生虛假的失敗。請參閱 8069181。
用於 ARM 的 Java 開發工具包發行版 8u60
此發行版包含用於 ARM 的 Java 開發工具包發行版 8u60(用於 ARM 的 JDK 8u60)。有關 ARM 設備支持信息,請參閱用於 ARM 的 JDK 下載頁。有關係統要求、安裝說明和故障排除提示,請參閱安裝說明頁。
限製:本機內存跟蹤支持僅限於用於 ARM 的 JDK。ARM 目標不支持 Java 命令行選項 XX:NativeMemoryTracking=detail
(會向用戶顯示一條錯誤消息)。請改為使用以下選項:
XX:NativeMemoryTracking=summary
針對 Nashorn 增強功能對文檔進行了更新
JDK 8u60 包括針對 Nashorn 的全新增強功能。因此,應該隨最新 Nashorn 文檔一起閱讀以下文檔更改:- 補充:在以前的章節中,我們提到了每個 JavaScript 對象在公開到 Java API 時會實現
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.List
、java.util.Collection
、java.util.Queue
和java.util.Deque
等等。
對部署規則集 v1.2 進行了更改
JDK 8u60 實現了部署規則集 (DRS) 1.2,其中包括以下更改:- 添加
"checksum"
元素作為"id"
的子元素,這可允許通過未解壓縮形式 jar 的 SHA-256 校驗和來標識未簽名的 jar:"checksum"
元素隻與未簽名的 jar 匹配,指定的散列將隻與未解壓縮形式的 jar 比較。"checksum"
元素(類似於"certificate"
元素)具有兩個參數"hash"
和"algorithm"
,但是,與"certificate"
元素不同,"algorithm"
唯一支持的值為 "SHA-256"。將忽略提供的所有其他值。
- 允許將
"message"
元素應用到所有規則類型,而以前隻能應用到阻塞規則:- 在一個運行規則中,message 子元素將導致顯示消息對話框,而在沒有運行規則時,默認行為是顯示證書或未簽名對話框。消息將顯示在消息對話框中。
- 在默認規則中,隻有在默認操作為“阻塞”時才會顯示消息。在這種情況下,消息將包括在阻塞對話框中。
- 在 Java 控製台、跟蹤文件和 Java Usage Tracker 記錄中回顯
"customer"
塊。- 在 DRS 1.2 之前,
"customer"
元素(以及任意子元素)可以包括在ruleset.xml
文件中。忽略此元素及其所有子元素。在 DRS 1.2 中,仍會從功能方麵忽略這些元素。但是:
- 對
ruleset.xml
文件進行語法分析時,所有"customer"
塊都將回顯到 Java 控製台和部署跟蹤文件(如果啟用了“控製台”和“跟蹤”)。 - 使用規則時,包括在該規則中的所有
"customer"
記錄都將添加到 Java Usage Tracker (JUT) 記錄中(如果啟用了 JUT)。
- 對
- 在 DRS 1.2 之前,
<!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 將向用戶提供其他警告和提醒以更新到較新版本。
Bug 修複
有關此發行版中包含的 Bug 修複列表,請參閱 JDK 8u60 Bug 修複頁。
Java 8 Update 51 (8u51)
發行要點說明
- IANA Data 2015d
JDK 8u51 包含 IANA 時區數據版本 2015d。有關詳細信息,請參閱 JRE 軟件中的時區數據版本。 -
Bug 修複:將新的 Comodo 根證書添加到根 CA
已為 Commodo 添加四個新的根證書:COMODO ECC 證書頒發機構
別名:comodoeccca
DN:CN=COMODO ECC Certification Authority,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GBCOMODO RSA 證書頒發機構
別名:comodorsaca
DN:CN=COMODO RSA Certification Authority,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GBUSERTrust ECC 證書頒發機構
別名:usertrusteccca
DN:CN=USERTrust ECC Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=USUSERTrust RSA 證書頒發機構
別名:usertrustrsaca
DN:CN=USERTrust RSA Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US
-
Bug 修複:將新的 GlobalSign 根證書添加到根 CA
已為 GlobalSign 添加兩個根證書:GlobalSign ECC 根 CA - R4
別名:globalsigneccrootcar4
DN:CN=GlobalSign,O=GlobalSign,OU=GlobalSign ECC Root CA - R4GlobalSign ECC 根 CA - R5
別名:globalsigneccrootcar5
DN:CN=GlobalSign,O=GlobalSign,OU=GlobalSign ECC Root CA - R5
-
Bug 修複:將 Actalis 添加到根 CA
添加了一個新的根證書:
Actalis 驗證根 CA
別名:actalisauthenticationrootca
DN:CN=Actalis Authentication Root CA,O=Actalis S.p.A./03358520967,L=Milan,C=IT
請參閱 JDK-8077903(非公共)。 -
Bug 修複:添加新的 Entrust ECC 根證書
添加了一個新的根證書:
Entrust 根證書頒發機構 - EC1
別名: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 1 和 2 類策略根證書
刪除了兩個包含 1024 位密鑰的根證書:ValiCert 1 類策略驗證權威機構
別名:secomvalicertclass1ca
DN:EMAILADDRESS=info@valicert.com,CN=https://www.valicert.com/,OU=ValiCert Class 1 Policy Validation Authority,O="ValiCert, Inc.",L=ValiCert Validation NetworkValiCert 2 類策略驗證權威機構
別名:valicertclass2ca
DN:EMAILADDRESS=info@valicert.com,CN=https://www.valicert.com/,OU=ValiCert Class 2 Policy Validation Authority,O="ValiCert, Inc.",L=ValiCert Validation Network
-
Bug 修複:刪除舊的 Thawte 根證書
刪除了兩個包含 1024 位密鑰的根證書:Thawte 服務器 CA
別名: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=ZAThawte 個人免費郵件 CA
別名: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
-
Bug 修複:刪除更多舊的 Verisign、Equifax 和 Thawte 根證書
刪除了五個包含 1024 位密鑰的根證書:Verisign 3 類公共主證書頒發機構 - G2
別名: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=USThawte 高級服務器 CA
別名: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=ZAEquifax Secure 證書頒發機構
別名:equifaxsecureca
DN:OU=Equifax Secure Certificate Authority,O=Equifax,C=USEquifax Secure 電子商務 CA-1
別名:equifaxsecureebusinessca1
DN:CN=Equifax Secure eBusiness CA-1,O=Equifax Secure Inc.,C=US-
Equifax Secure 全球電子商務 CA-1
別名:equifaxsecureglobalebusinessca1
DN:CN=Equifax Secure Global eBusiness CA-1,O=Equifax Secure Inc.,C=US
-
Bug 修複:從 cacerts 中刪除 TrustCenter CA 根證書
刪除了三個根證書:-
TC TrustCenter 通用 CA I
別名:trustcenteruniversalcai
DN:CN=TC TrustCenter Universal CA I,OU=TC TrustCenter Universal CA,O=TC TrustCenter GmbH,C=DE -
TC TrustCenter 2 類 CA II
別名:trustcenterclass2caii
DN:CN=TC TrustCenter Class 2 CA II,OU=TC TrustCenter Class 2 CA,O=TC TrustCenter GmbH,C=DE -
TC TrustCenter 4 類 CA II
別名:trustcenterclass4caii
DN:CN=TC TrustCenter Class 4 CA II,OU=TC TrustCenter Class 4 CA,O=TC TrustCenter GmbH,C=DE
-
-
Bug 修複:SunJSSE 提供方中的 RC4 已過時
RC4 現在已被視為弱密碼。除非在客戶機請求的密碼套件中沒有其他更強的密碼可用,否則服務器不應選擇 RC4。增加了新的安全屬性jdk.tls.legacyAlgorithms
來定義 Oracle JSSE 實現中的傳統算法。RC4 相關算法已添加到傳統算法列表中。請參閱 JDK-8074006(非公共)。 -
Bug 修複:禁止使用 RC4 密碼套件
RC4 現在已被視為弱密碼。在 Oracle JSSE 實現中,RC4 密碼套件已從客戶機和服務器的默認啟用密碼套件列表中刪除。這些密碼套件仍可以通過SSLEngine.setEnabledCipherSuites()
和SSLSocket.setEnabledCipherSuites()
方法啟用。請參閱 JDK-8077109(非公共)。 -
Bug 修複:改進的認證檢查
在進行此修複後,默認情況下,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 將向用戶提供其他警告和提醒以更新到較新版本。
Bug 修複
本發行版包含安全漏洞的修複。有關詳細信息,請參閱 Oracle Java SE Critical Patch Update Advisory。
有關此發行版中包含的 Bug 修複列表,請參閱 JDK 8u51 Bug 修複頁。
最後更新:2017-01-12 10:53:03
上一篇:
為什麼會顯示 "Java Update Needed"(需要 Java Update)消息:"Your Java version is out of date"(您的 Java 版本已過期)或 "Your Java version is insecure"
下一篇:
Amazon 可選產品
Java 8 發行版要點說明
錯誤:Java 搜索到可能導致安全問題的應用程序組件。
為什麼會顯示 "Java Update Needed"(需要 Java Update)消息:"Your Java version is out of date"(您的 Java 版本已過期)或 "Your Java version is insecure"
在運行帶有已過期證書的應用程序時,會顯示什麼樣的其他對話框?
運行使用可信證書簽名的應用程序時,為什麼顯示未簽名的安全提示?
Java 下載內容是否會受病毒感染?
授權和分發常見問題解答
可從何處獲得 Minecraft?
卸載 Java 之後,如何刪除在 Windows 的“卸載/刪除程序”中列出的條目?
安裝 Java 期間顯示“錯誤:25099”消息
熱門內容
有關在 Mac OS X 上安裝和使用 Oracle Java 的信息和係統要求
為什麼應該從係統卸載 Java 的早期版本?
為什麼會顯示 "Java Update Needed"(需要 Java Update)消息:"Your Java version is out of date"(您的 Java 版本已過期)或 "Your Java version is insecure"
Java 8 發行版要點說明
Amazon 可選產品
什麼是 Java 技術?為何需要 Java?
開發人員 - 瀏覽器中的 Java 內容 - 安全清單更改
錯誤:安裝過程中出現 \bin\hotspot\jvm.dll 錯誤消息
更新到 macOS Sierra 10.12 後,為什麼會在運行 Java 時出現問題?
Java 和 Google Chrome 瀏覽器