Java Development Kit (64-bit)

最新版本 Java JDK 8 Update 131 (64-bit)

Java JDK 8 Update 131 (64-bit)

Java JDK 8 Update 131 (64-bit)
Java Development Kit 64 位(也稱為 JDK)包含編譯,調試和運行使用 Java 編程語言編寫的小應用程序和應用程序所需的軟件和工具。 JDK 的主要組件是一組編程工具,包括 javac,jar 和 archiver,它們把相關的類庫打包成一個 JAR 文件。這個工具還有助於管理 JAR 文件,javadoc - 文檔生成器,它自動從源代碼註釋生成文檔,jdb - 調試器,jps - 進程狀態工具,顯示當前 Java 進程的進程信息,javap - 類文件反彙編程序,以及其他很多組件。

JDK 64 位還附帶了一個完整的 Java 運行時環境,通常稱為私有運行時。它由 Java 虛擬機和生產環境中存在的所有類庫以及僅對開發人員有用的附加庫(例如國際化庫和 IDL 庫)組成。下載 Java 開發工具包離線安裝程序安裝 64bit for Windows

JDK 內容:

開發工具
(在 bin / 子目錄中)將幫助您開發,執行,調試和編寫用 JavaTM 編程語言編寫的程序的工具和實用程序。

Runtime Environment
(在 jre / 子目錄中)供 JDK 使用的 Java 運行時環境(JRE)的實現。 JRE 包括一個 Java 虛擬機(JVM),類庫和其他支持執行用 Java 編程語言編寫的程序的文件.

附加庫
(在 lib / 子目錄中)開發工具需要的附加類庫和支持文件.

Demo 小應用程序和應用程序
(在演示 / 子目錄中)Java 平台編程的示例,包括源代碼。這些包括使用 Swing 和其他 Java 基礎類的示例,以及 Java 平台調試器體系結構.

示例代碼
(在示例子目錄中)帶有源代碼的樣本,用於某些 Java API 的編程。

C 頭文件
(在 include / 子目錄中)支持使用 Java 本地接口,JVM 工具接口和 Java 平台的其他功能進行本地代碼編程的頭文件。下載 Java 開發工具包離線安裝程序安裝程序 64bit for Windows

源代碼
(在 src.zip 中)構成 Java 核心 API 的所有類的 Java 編程語言源文件(即 java。*,javax。* 和某些 org 的源文件。* 包,但不包括 com.sun。* 包)。此源代碼僅供參考,旨在幫助開發人員學習和使用 Java 編程語言。這些文件不包括平台特定的實現代碼,不能用於重建類庫。要提取這些文件,請使用任何常用的 zip 實用程序。或者,您可以在 JDK 的 bin / 目錄中使用 Jar 實用程序:jar xvf src.zip.

也可以:下載適用於 Mac

的 Java Development Kit

ScreenShot

軟體資訊
檔案版本 Java JDK 8 Update 131 (64-bit)

檔案名稱 jdk-8u131-windows-x64.exe
檔案大小 198.03 MB
系統 Windows Vista64 / Windows 7 64 / Windows 8 64 / Windows 10 64
軟體類型 免費軟體
作者 Oracle
官網 http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
更新日期 2017-04-18
更新日誌

What's new in this version:

CHANGES:
MD5 added to jdk.jar.disabledAlgorithms Security property:
This JDK release introduces a new restriction on how MD5 signed JAR files are verified. If the signed JAR file uses MD5, signature verification operations will ignore the signature and treat the JAR as if it were unsigned. This can potentially occur in the following types of applications that use signed JAR files:
- Applets or Web Start Applications
- Standalone or Server Applications that are run with a SecurityManager enabled and are configured with a policy file that grants permissions based on the code signer(s) of the JAR file.
- The list of disabled algorithms is controlled via the security property, jdk.jar.disabledAlgorithms, in the java.security file. This property contains a list of disabled algorithms and key sizes for cryptographically signed JAR files.
- To check if a weak algorithm or key was used to sign a JAR file, one can use the jarsigner binary that ships with this JDK. Running "jarsigner -verify" on a JAR file signed with a weak algorithm or key will print more information about the disabled algorithm or key.

New system property to control caching for HTTP SPNEGO connection:
- A new JDK implementation specific system property to control caching for HTTP SPNEGO (Negotiate/Kerberos) connections is introduced. Caching for HTTP SPNEGO connections remains enabled by default, so if the property is not explicitly specified, there will be no behavior change.
- When connecting to an HTTP server that uses SPNEGO to negotiate authentication, and when connection and authentication with the server is successful, the authentication information will then be cached and reused for further connections to the same server. In addition, connecting to an HTTP server using SPNEGO usually involves keeping the underlying connection alive and reusing it for further requests to the same server. In some applications, it may be desirable to disable all caching for the HTTP SPNEGO (Negotiate/Kerberos) protocol in order to force requesting new authentication with each new request to the server.

With this change, we now provide a new system property that allows control of the caching policy for HTTP SPNEGO connections. If jdk.spnego.cache is defined and evaluates to false, then all caching will be disabled for HTTP SPNEGO connections. Setting this system property to false may, however, result in undesirable side effects:
- Performance of HTTP SPNEGO connections may be severely impacted as the connection will need to be re-authenticated with each new request, requiring several communication exchanges with the server.
- Credentials will need to be obtained again for each new request, which, depending on whether transparent authentication is available or not, and depending on the global Authenticator implementation, may result in a popup asking the user for credentials for every new request.

New system property to control caching for HTTP NTLM connection:
- A new JDK implementation specific system property to control caching for HTTP NTLM connection is introduced. Caching for HTTP NTLM connection remains enabled by default, so if the property is not explicitly specified, there will be no behavior change
- On some platforms, the HTTP NTLM implementation in the JDK can support transparent authentication, where the system user credentials are used at system level. When transparent authentication is not available or unsuccessful, the JDK only supports getting credentials from a global authenticator. If connection to the server is successful, the authentication information will then be cached and reused for further connections to the same server. In addition, connecting to an HTTP NTLM server usually involves keeping the underlying connection alive and reusing it for further requests to the same server. In some applications, it may be desirable to disable all caching for the HTTP NTLM protocol in order to force requesting new authentication with each new requests to the server

With this change, we now provide a new system property that allows control of the caching policy for HTTP NTLM connections. If jdk.ntlm.cache is defined and evaluates to false, then all caching will be disabled for HTTP NTLM connections. Setting this system property to false may, however, result in undesirable side effects:
- Performance of HTTP NTLM connections may be severely impacted as the connection will need to be re-authenticated with each new request, requiring several communication exchanges with the server
- Credentials will need to be obtained again for each new request, which, depending on whether transparent authentication is available or not, and depending on the global Authenticator implementation, may result in a popup asking the user for credentials for every new request

New version of VisualVM:
- VisualVM 1.3.9 was released on October 4th, 2016 and has been integrated into 8u131

BUG FIXES:
Correction of IllegalArgumentException from TLS handshake:
- A recent issue from the JDK-8173783 fix can cause issue for some TLS servers. The problem originates from an IllegalArgumentException thrown by the TLS handshaker code: java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves. The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified

DETAILED BUG FIX LIST:
- JDK-7155957: client‑libs: java.awt: closed/java/awt/MenuBar/MenuBarStress1/MenuBarStress1.java hangs on win 64 bit with jdk8
- JDK-8035568: client‑libs: java.awt: [macosx] Cursor management unification
- JDK-8079595: client‑libs: java.awt: Resizing dialog which is JWindow parent makes JVM crash
- JDK-8169589: client‑libs: java.awt: [macosx] Activating a JDialog puts to back another dialog
- JDK-8147842: client‑libs: javax.swing: IME Composition Window is displayed at incorrect location
- JDK-7167293: core‑libs: java.net: FtpURLConnection connection leak on FileNotFoundException
- JDK-8169465: core‑libs: javax.naming: Deadlock in com.sun.jndi.ldap.pool.Connections
- JDK-8133045: deploy: deployment_toolkit: java.lang.SecurityException: Failed to extract baseline.versions error
- JDK-8028538: deploy: webstart: Fedora Linux issue with jnlp‑servlet.jar demo source code license
- JDK-8170646: deploy: webstart: JNLP fails to get loaded with old javaws when multiple jres (jre9 and jre8u111) installed
- JDK-8075196: docs: guides: CosNaming's implementation doesn't comply with the specification
- JDK-8161147: hotspot: compiler: jvm crashes when ‑XX:+UseCountedLoopSafepoints is enabled
- JDK-8161993: hotspot: gc: G1 crashes if active_processor_count changes during startup
- JDK-8147910: hotspot: runtime: Cache initial active_processor_count
- JDK-8150490: hotspot: runtime: Update OS detection code to recognize Windows Server 2016
- JDK-8170888: hotspot: runtime: [linux] Experimental support for cgroup memory limits in container (ie Docker) environments
- JDK-8166208: hotspot: svc: FlightRecorderOptions settings for defaultrecording ignored.
- JDK-8161945: install: install: REGRESSION: 8u91 update of 32 bit JRE removes preferences of the 64 bit JRE
- JDK-8172932: install: install: JRE installation fails with 1603 on Windows 10 with enabled Deviceguard
- JDK-8089915: javafx: web: Input of type file doesn't honor "accept" attribute.
- JDK-8090216: javafx: web: HTMLEditor: font bold doesn't work when an indent is set
- JDK-8144263: javafx: web: [WebView, OS X] Webkit rendering artifacts with inertia scrolling
- JDK-8150982: javafx: web: Crash when calling WebEngine.print on background thread
- JDK-8164314: javafx: web: [WebView] Debug build is no longer working after JDK‑8089681
- JDK-8165098: javafx: web: WebEngine.print will attempt to print even if the printer job is complete or has an error
- JDK-8165173: javafx: web: canvas/philip/tests/2d.path.clip.empty.html fails with 8u112
- JDK-8165508: javafx: web: Incorrect Bug ID in comment for JDK-8164076
- JDK-8166231: javafx: web: use @Native annotation in web classes
- JDK-8166677: javafx: web: HTMLEditor freezes after restoring previously maximized window
- JDK-8166775: javafx: web: Audio slider works incorrectly for short files
- JDK-8166999: javafx: web: Update to newer version of WebKit
- JDK-8167098: javafx: web: Backport of JDK‑8158926 to JDK 8u mistakenly used preliminary patch
- JDK-8167100: javafx: web: Minor source diffs introduced in backports of JDK-8160837 and JDK-8163582
- JDK-8167675: javafx: web: Animated gifs are not working
- JDK-8169204: javafx: web: Need to document JSObject Call and setSlot APIs to use weak references
- JDK-8170585: javafx: web: Fix PlatformContextJava type leaking to GraphicsContext
- JDK-8170938: javafx: web: Memory leak in JavaFX WebView
- JDK-8173783: security‑libs: javax.net.ssl: IllegalArgumentException: jdk.tls.namedGroups
- JDK-6474807: security‑libs: javax.smartcardio: (smartcardio) CardTerminal.connect() throws CardException instead of CardNotPresentException
- JDK-8168774: tools: javac: Polymorhic signature method check crashes javac
- JDK-8167485: tools: visualvm: Integrate new version of Java VisualVM based on VisualVM 1.3.9 into JDK
- JDK-8167179: xml: jaxp: Make XSL generated namespace prefixes local to transformation process

Java JDK 8 Update 131 (64-bit) 相關參考資料
Download Java Development Kit (64bit) 8 Update 131 for ...

2017年4月18日 — Developed by Oracle Corporation, JDK equips developers with all the necessary tools and resources to create, test, and deploy Java applications ...

https://www.filepuma.com

Download Java Development Kit 64-bit 8 Update 131 for ...

2021年3月30日 — Download Java Development Kit 64-bit 8 Update 131 for Windows. Fast downloads of the latest free software! Click now.

https://filehippo.com

Java 8 發行版本變更

... JDK 8 將系統特性更新為使用傳統Base64 編碼格式 ... Java 8 Update 131 (8u131) ... 「Java 控制面板」中的 更新 標籤除了32 位元版本以外,還可以讓使用者自動更新已安裝在 ...

https://java.com

Java SE 8 Archive Downloads (JDK 8u202 and earlier)

Solaris SPARC 64-bit (SVR4 package), 125.09 MB. jdk ... jdk-8u131-linux-arm64-vfp-hflt.tar.gz. Linux x86 ... jdk-8-solaris-x64.tar.Z. Solaris x64, 93.15 MB. jdk-8 ...

https://www.oracle.com

下載適用於所有作業系統的Java

2024年4月16日 — 安裝Java 之後,可能需要重新啟動瀏覽器,才能在瀏覽器啟用Java。 macOS ARM64 ((12 和更新版本)) 檔案大小: 85.08 MB, 指示. Oracle Java 8 需要管理員 ...

https://www.java.com