這是歷史版本頁面 — 看 Java Runtime Environment (64-bit) 最新版本
程式打不開一直說要裝 Java?JRE 是什麼、裝了能解決嗎
你剛從某個網站下載了一個軟體,雙擊安裝檔卻跳出錯誤視窗,說「需要 Java Runtime Environment」;或者你打開某個老牌網路銀行、公家機關系統,畫面一片空白,只有一行字叫你安裝 Java。你只是想趕快把事情辦完,卻卡在一個聽過名字、但從來不知道它是什麼的東西上。
你直覺的反應是上網搜尋 Java 下載,裝完卻發現問題沒解決,甚至跳出更多看不懂的錯誤訊息。這是因為這類工具不是一般應用程式,它是一個「執行環境」——負責讓用 Java 寫的程式在你的電腦上跑起來。裝錯版本、裝到開發工具、或沒注意系統位元數,都會讓你白忙一場。這篇文章要講清楚的,就是這個執行環境到底解決什麼問題、什麼時候你才真的需要它。
01Java Runtime Environment 到底是做什麼用的?裝了它能幹嘛?
它是一套讓 Java 程式能在你的 Windows 電腦上執行的必備元件,包含 Java 虛擬機(JVM)和一堆程式庫。白話來說,很多軟體、網頁元件、遊戲是用 Java 寫的,你的電腦沒有這套環境,那些程式就跑不起來。裝了之後,這些應用程式才能正常開啟,例如線上遊戲、3D 圖片檢視、某些企業內部系統。
02我怎麼知道電腦裡有沒有裝這套軟體?
打開命令提示字元(cmd),輸入 `java -version` 後按 Enter。如果有安裝,畫面上會顯示 Java 的版本資訊;如果顯示「不是內部或外部命令」之類的訊息,就代表沒裝。另外,也可以到 Windows 的「控制台 → 程式和功能」裡找有沒有 Java 相關的項目。
03這套軟體和 Java Development Kit(JDK)有什麼不同?
JRE 是拿來「執行」Java 程式的,JDK 是拿來「開發」Java 程式的。JDK 裡面包含了 JRE,但另外還有編譯器、除錯器等開發工具。如果你只是要跑別人寫好的 Java 軟體,裝 JRE 就夠了;如果你要自己寫 Java 程式,才需要裝 JDK。裝錯的話,只是佔用硬碟空間,不會造成系統問題。
04裝了這套軟體之後,還需要做什麼設定嗎?
一般情況下不需要。安裝完成後,Java 程式就能直接執行。不過,有些瀏覽器基於安全考量,預設會擋掉 Java 外掛,如果你需要透過瀏覽器使用 Java 應用程式(例如某些舊的網路銀行系統),可能要在瀏覽器的外掛管理或 Java 控制面板裡調整安全性設定,允許執行。
05這套軟體可以同時裝好幾個版本嗎?
可以。官方說明指出,你可以在同一台電腦上安裝多個版本的 JRE。不過,官方也建議只保留最新版本,因為舊版本可能含有未修補的安全性漏洞。如果你不確定某個舊版是不是還有程式在用,可以先保留,等確認沒問題後再移除。
06我只是想玩個遊戲或開個文書軟體,為什麼還要裝這個?
因為那個遊戲或軟體是用 Java 寫的。Java 的設計理念是「一次編寫,到處執行」,所以很多跨平台的應用程式會用它開發。開發者把程式包裝好之後,使用者的電腦必須有 JRE 才能把程式跑起來。這不是你的問題,而是軟體本身的技術需求。
07我的電腦是 64 位元的 Windows,該裝哪一個版本?
這套軟體名稱就標明是 64-bit,支援 Windows 7 到 Windows 11 的 64 位元系統。安裝前可以先確認你的 Windows 是 64 位元還是 32 位元(在「設定 → 系統 → 關於」裡可以查到)。如果你的系統是 32 位元,這套 64 位元版本就無法安裝,需要另外找 32 位元的版本。
08這套軟體的介面是英文的,我看不懂怎麼辦?
這套軟體的介面語系是英文,安裝過程和 Java 控制面板都是英文介面。不過,安裝完成後,你平常使用 Java 程式時並不會看到它的介面——它是在背景運作的。只有當你需要調整 Java 的安全性設定或更新時,才會需要面對英文介面。如果完全無法理解,可以找線上翻譯或請熟人協助。
09我裝了這套軟體之後,電腦變慢或出現安全警告,是正常的嗎?
Java 本身具備安全模型,包含沙箱(sandbox)、程式碼簽章和權限控管,目的是讓 Java 程式在受控的環境中執行。但因為 Java 曾多次被發現安全漏洞,所以有些防毒軟體或瀏覽器會對 Java 外掛發出警告。建議你只從官方網站下載,並保持軟體更新,以降低風險。
10我是一個程式設計師,裝這套軟體夠用嗎?
不夠。JRE 只能執行 Java 程式,不能編寫和編譯程式碼。如果你要開發 Java 應用程式,需要的是 JDK(Java Development Kit),它包含了編譯器(javac)和除錯工具。官方說明也明確指出,JDK 是用來開發的,JRE 是用來執行的。如果你只是要跑別人寫好的工具,JRE 就夠了。
11這套軟體一直叫我更新,不更新會怎樣?
官方建議定期更新,因為更新通常包含錯誤修正、安全性修補和效能改善。如果你不更新,舊版本可能無法執行某些新開發的 Java 程式,也可能暴露在已知的安全風險中。不過,更新與否最終取決於你使用的程式是否需要新版本——如果現有程式都跑得好好的,短期內不更新不會立刻出問題。
12有沒有其他軟體可以取代這套軟體?
如果你要執行 Java 程式,JRE 是必要的,沒有其他軟體可以完全取代它。資料中列出的相近軟體,例如 .NET Framework,是微軟開發的執行環境,用途不同,無法互相替代。如果你是要開發 Java 程式,可以考慮 NetBeans IDE 或 JDK,但這些是開發工具,不是執行環境。
下載與官方連結
前往官方網站 下載 Java Runtime Environment (64-bit)
jre-9_windows-x64_bin.exe · 88.7 MB · 連結指向軟體原廠
版本紀錄
- 2026-10-21 Java JRE 8 Update 511 (64-bit) 75.31 MB
- 2026-08-19 Java JRE 8 Update 503 (64-bit) 69.02 MB
- 2026-07-22 Java JRE 8 Update 501 (64-bit) 69.02 MB
再看 5 筆
- 2026-04-22 Java JRE 8 Update 491 (64-bit) 69 MB
- 2026-01-21 Java JRE 8 Update 481 (64-bit) 38.5 MB
- 2025-10-22 Java JRE 8 Update 471 (64-bit) 38.48 MB
- 2025-07-16 Java JRE 8 Update 461 (64-bit) 38.48 MB
- 2025-04-16 Java JRE 8 Update 451 (64-bit) 38.41 MB
這一版改了什麼
What's new in this version:
KEY CHANGES:
Java Platform Module System:
Introduces a new kind of Java programing component, the module, which is a named, self-describing collection of code and data. This module system:
- Introduces a new optional phase, link time, which is in-between compile time and run time, during which a set of modules can be assembled and optimized into a custom runtime image; see the jlink tool in Java Platform, Standard Edition Tools Reference
- Adds options to the tools javac, jlink, and java where you can specify module paths, which locate definitions of modules
- Introduces the modular JAR file, which is a JAR file with a module-info.class file in its root directory
- Introduces the JMOD format, which is a packaging format similar to JAR except it can include native code and configuration files; see the jmod tool
The JDK itself has been divided into a set of modules. This change enables you to combine the JDK's modules into a variety of configurations, including:
- Configurations corresponding to the JRE and the JDK
- Configurations roughly equivalent in content to each of the Compact Profiles defined in Java SE 8
- Custom configurations that contain only a specified set of modules and their required modules
- Restructures the JDK and JRE runtime images to accommodate modules and improve performance, security, and maintainability
- Defines a new URI scheme for naming modules, classes, and resources stored in a runtime image without revealing the internal structure or format of the image
- Removes the endorsed-standards override mechanism and the extension mechanism
- Removes rt.jar and tools.jar from the Java runtime image
- Makes most of the JDK's internal APIs inaccessible by default but leaves a few critical, widely used internal APIs accessible until supported replacements exist for all or most of their functionality
JEP 223: New Version-String Scheme:
- Provides a simplified version-string format that helps to clearly distinguish major, minor, security, and patch update releases.
Installer Enhancements for Microsoft Windows:
Enable or Disable Web Deployment with Installer's UI:
- Provides the option to enable or disable web deployment in the Welcome page of the installer. To enable web deployment, in the Welcome page, select Custom Setup , click Install, and select the Enable Java content in the Browser check box.
WHAT'S NEW FOR TOOLS:
JEP 222: jshell: The Java Shell (Read-Eval-Print Loop):
- Adds Read-Eval-Print Loop (REPL) functionality to the Java platform.
JEP 228: Add More Diagnostic Commands:
- Defines additional diagnostic commands to improve the ability to diagnose issues with Hotspot and the JDK.
JEP 231: Remove Launch-Time JRE Version Selection:
- Removes the ability to request a version of the JRE that is not the JRE being launched at launch time. Modern applications are typically deployed through Java Web Start (with a JNLP file), native OS packaging systems, or active installers. These technologies have their own methods to manage the JREs needed by finding or downloading and updating the required JRE as needed. This makes launch-time JRE version selection obsolete.
JEP 238: Multi-Release JAR Files:
- Extends the JAR file format to enable multiple, Java release-specific versions of class files to coexist in a single archive. A multirelease JAR (MRJAR) contains additional, versioned directories for classes and resources specific to particular Java platform releases. Specify versioned directories with the jar tool's --release option.
JEP 240: Remove the JVM TI hprof Agent:
- Removes the hprof agent from the JDK. The hprof agent was written as demonstration code for the JVM Tool Interface and not intended to be a production tool. The useful features of the hprof agent have been superseded by better alternatives.
JEP 241: Remove the jhat Tool:
- Removes the jhat tool from the JDK. The jhat tool was an experimental and unsupported tool added in JDK 6. It is out of date; superior heap visualizers and analyzers have been available for many years.
JEP 245: Validate JVM Command-Line Flag Arguments:
- Validates arguments to all numerical JVM command-line flags to avoid failures and instead displays an appropriate error message if they are found to be invalid. Range and optional constraint checks have been implemented for arguments that require a user-specified numerical value.
JEP 247: Compile for Older Platform Versions:
- Enhances javac so that it can compile Java programs to run on selected earlier versions of the platform. When using the -source or -target options, the compiled program might accidentally use APIs that are not supported on the given target platform. The --release option will prevent accidental use of APIs.
JEP 282: jlink: The Java Linker:
- Assembles and optimizes a set of modules and their dependencies into a custom runtime image as defined in JEP 220. The jlink tool defines a plug-in mechanism for transformation and optimization during the assembly process, and for the generation of alternative image formats. It can create a custom runtime optimized for a single program. JEP 261 defines link time as an optional phase between the phases of compile time and run time. Link time requires a linking tool that assembles and optimizes a set of modules and their transitive dependencies to create a runtime image or executable
WHAT'S NEW FOR SECURITY:
JEP 219: Datagram Transport Layer Security (DTLS):
- Enables Java Secure Socket Extension (JSSE) API and the SunJSSE security provider to support DTLS Version 1.0 and DTLS Version 1.2 protocols
JEP 244: TLS Application-Layer Protocol Negotiation Extension:
- Enables the client and server in a Transport Layer Security (TLS) connection to negotiate the application protocol to be used. With Application-Layer Protocol Negotiation (ALPN), the client sends the list of supported application protocols as part of the TLS ClientHello message. The server chooses a protocol and returns the selected protocol as part of the TLS ServerHello message. The application protocol negotiation can be accomplished within the TLS handshake, without adding network round-trips
JEP 249: OCSP Stapling for TLS:
- Enables the server in a TLS connection to check for a revoked X.509 certificate revocation. The server does this during TLS handshaking by contacting an Online Certificate Status Protocol (OCSP) responder for the certificate in question. It then attaches or "staples" the revocation information to the certificate that it returns to the client so that the client can take appropriate action. Enables the client to request OCSP stapling from a TLS server. The client checks stapled responses from servers that support the feature.
JEP 246: Leverage CPU Instructions for GHASH and RSA:
- Improves performance ranging from 34x to 150x for AES/GCM/NoPadding using GHASH HotSpot intrinsics. GHASH intrinsics are accelerated by the PCLMULQDQ instruction on Intel x64 CPU and the xmul/xmulhi instructions on SPARC. Improves performance up to 50% for BigInteger squareToLen and BigInteger mulAdd methods using RSA HotSpot intrinsics. RSA intrinsics apply to the java.math.BigInteger class on Intel x64. A new security property jdk.security.provider.preferred is introduced to configure providers that offer significant performance gains for specific algorithms.
JEP 273: DRBG-Based SecureRandom Implementations:
- Provides the functionality of Deterministic Random Bit Generator (DRBG) mechanisms as specified in NIST SP 800-90Ar1 in the SecureRandom API
- The DRBG mechanisms use modern algorithms as strong as SHA-512 and AES-256. Each of these mechanisms can be configured with different security strengths and features to match user requirements
JEP 288: Disable SHA-1 Certificates:
- Improves the security configuration of the JDK by providing a more flexible mechanism to disable X.509 certificate chains with SHA-1-based signatures.
- Disables SHA-1 in TLS Server certificate chains anchored by roots included by default in the JDK; local or enterprise certificate authorities (CAs) are not affected. The jdk.certpath.disabledAlgorithms security property is enhanced with several new constraints that allow greater control over the types of certificates that can be disabled.
JEP 229: Create PKCS12 Keystores by Default:
- Modifies the default keystore type from JKS to PKCS12. PKCS#12 is an extensible, standard, and widely supported format for storing cryptographic keys. PKCS12 keystores improve confidentiality by storing private keys, trusted public key certificates, and secret keys. This feature also opens opportunities for interoperability with other systems such as Mozilla, Microsoft's Internet Explorer, and OpenSSL that support PKCS12. The SunJSSE provider supplies a complete implementation of the PKCS12 java.security.KeyStore format for reading and writing PKCS12 files. See Key Management in Java Platform, Standard Edition Security Developer's Guide. The keytool key and certificate management utility can create PKCS12 keystores.
JEP 287: SHA-3 Hash Algorithms:
- Supports SHA-3 cryptographic hash functions as specified in NIST FIPS 202.
- The following additional standard algorithms are supported by the java.security.MessageDigest API: SHA3-224, SHA3-256, SHA3-384, and SHA3-512
The following providers support SHA-3 algorithm enhancements:
- SUN provider: SHA3-224, SHA3-256, SHA3-384, and SHA3-512
- OracleUcrypto provider: SHA-3 digests supported by Solaris 12.0
WHAT'S NEW FOR DEPLOYMENT:
Deprecate the Java Plug-in:
- Deprecates the Java Plug-in and associated applet technologies in Oracle's JDK 9 builds. While still available in JDK 9, these technologies will be considered for removal from the Oracle JDK and JRE in a future release. Applets and JavaFX applications embedded in a web page require the Java Plug-in to run. Consider rewriting these types of applications as Java Web Start or self-contained applications.
Enhanced Java Control Panel:
- Improves the grouping and presentation of options within the Java Control Panel. Information is easier to locate, a search field is available, and modal dialog boxes are no longer used. Note that the location of some options has changed from previous versions of the Java Control Panel
JEP 275: Modular Java Application Packaging:
- Integrates features from Project Jigsaw into the Java Packager, including module awareness and custom runtime creation. Leverages the jlink tool to create smaller packages. Creates applications that use the JDK 9 runtime only. Cannot be used to package applications with an earlier release of the JRE.
JEP 289: Deprecate the Applet API:
- Deprecates the Applet API, which is becoming less useful as web browser vendors remove support for Java browser plug-ins. While still available in JDK 9, the Applet class will be considered for removal in a future release. Consider rewriting applets as Java Web Start or self-contained applications
WHAT'S NEW FOR THE JAVA LANGUAGE:
JEP 213: Milling Project Coin. Identifies a few small changes:
- Allow @SafeVargs on private instance methods
- Allow effectively final variables to be used as resources in the try-with-resources statement
- Allow the diamond with anonymous classes if the argument type of the inferred type is denotable
- Complete the removal, begun in Java SE 8, of the underscore from the set of legal identifier names
- Add support for private interface methods
WHAT'S NEW FOR JAVADOC:
JEP 221: Simplified Doclet API:
- Replaces the old Doclet API with a new simplified API that leverages other standard, existing APIs. The standard doclet has been rewritten to use the new Doclet API.
JEP 224: HTML5 Javadoc:
- Supports generating HTML5 output. To get fully compliant HTML5 output, ensure that any HTML content provided in documentation comments are compliant with HTML5.
JEP 225: Javadoc Search:
- Provides a search box to the generated API documentation. Use this search box to find program elements, tagged words, and phrases within the documentation.
JEP 261: Module System:
- Supports documentation comments in module declarations. Includes new command-line options to configure the set of modules to be documented and generates a new summary page for any modules being documented.
WHAT'S NEW FOR THE JVM:
JEP 165: Compiler Control:
- Provides a way to control JVM compilation through compiler directive options. The level of control is runtime-manageable and method-specific. Compiler Control supersedes, and is backward compatible, with CompileCommand.
JEP 197: Segmented Code Cache:
- Divides the code cache into distinct segments, each of which contains compiled code of a particular type, to improve performance and enable future extensions.
JEP 276: Dynamic Linking of Language-Defined Object Models:
- Dynamically links high-level object operations at run time, such as read a property, write a property, and invoke a function, to the appropriate target method handles. It links these operations to target method handles based on the actual types of the values passed. These object operations are expressed as invokedynamic sites.
- While java.lang.invoke provides a low-level API for dynamic linking of invokedynamic call sites, it doesn't provide a way to express higher level operations on objects nor methods that implement them.
- With the package jdk.dynalink, you can implement programming languages whose expressions contain dynamic types (types that cannot be determined statically) and whose operations on these dynamic types are expressed as invokedynamic call sites (because the language's object model or type system doesn't closely match that of the JVM).
WHAT'S NEW FOR JVM TUNING:
Improve G1 Usability, Determinism, and Performance:
- Enhances the Garbage-First (G1) garbage collector to automatically determine several important memory-reclamation settings. Previously these settings had to be set manually to obtain optimal results. In addition, fixes issues with the usability, determinism, and performance of the G1 garbage collector.
JEP 158: Unified JVM Logging:
- Introduces a common logging system for all components of the JVM
- JEP 214: Remove GC Combinations Deprecated in JDK 8"
- Removes garbage collector (GC) combinations that were deprecated in JDK 8
- This means that the following GC combinations no longer exist: DefNew + CMS ParNew + SerialOld, Incremental CMS
The "foreground" mode for Concurrent Mark Sweep (CMS) has also been removed. The following command-line flags have been removed:
- -Xincgc
- -XX:+CMSIncrementalMode
- -XX:+UseCMSCompactAtFullCollection
- -XX:+CMSFullGCsBeforeCompaction
- -XX:+UseCMSCollectionPassing
- The command line flag -XX:+UseParNewGC no longer has an effect. ParNew can only be used with CMS and CMS requires ParNew. Thus, the -XX:+UseParNewGC flag has been deprecated and will likely be removed in a future release.
JEP 248: Make G1 the Default Garbage Collector:
- Makes Garbage-First (G1) the default garbage collector (GC) on 32- and 64-bit server configurations. Using a low-pause collector such as G1 provides a better overall experience, for most users, than a throughput-oriented collector such as the Parallel GC, which was previously the default.
JEP 271: Unified GC Logging:
- Reimplements Garbage Collection (GC) logging using the unified JVM logging framework introduced in JEP 158. GC logging is re-implemented in a manner consistent with the current GC logging format; however, some differences exist between the new and old formats.
JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector:
- Deprecates the Concurrent Mark Sweep (CMS) garbage collector. A warning message is issued when it is requested on the command line, using the -XX:+UseConcMarkSweepGC option. The Garbage-First (G1) garbage collector is intended to be a replacement for most uses of CMS
WHAT'S NEW FOR CORE LIBRARIES:
JEP 102: Process API Updates:
- Improves the API for controlling and managing operating system processes.
- The ProcessHandle class provides the process's native process ID, arguments, command, start time, accumulated CPU time, user, parent process, and descendants. The class can also monitor processes' liveness and destroy processes. With the ProcessHandle.onExit method, the asynchronous mechanisms of the CompletableFuture class can perform an action when the process exits.
JEP 193: Variable Handles:
- Defines a standard means to invoke the equivalents of java.util.concurrent.atomic and sun.misc.Unsafe operations upon object fields and array elements.
- Defines a standard set of fence operations, which consist of VarHandle static methods that enable fine-grained control of memory ordering. This is an alternative to sun.misc.Unsafe, which provides a nonstandard set of fence operations.
- Defines a standard reachability fence operation to ensure that a referenced object remains strongly reachable.
JEP 254: Compact Strings:
- Adopts a more space-efficient internal representation for strings. Previously, the String class stored characters in a char array, using two bytes (16 bits) for each character. The new internal representation of the String class is a byte array plus an encoding-flag field.
- This is purely an implementation change, with no changes to existing public interfaces.
JEP 264: Platform Logging API and Service:
- Defines a minimal logging API that platform classes can use to log messages, together with a service interface for consumers of those messages. A library or application can provide an implementation of this service to route platform log messages to the logging framework of its choice. If no implementation is provided, then a default implementation based on the java.util.logging API is used.
JEP 266: More Concurrency Updates:
- Adds further concurrency updates to those introduced in JDK 8 in JEP 155: Concurrency Updates, including an interoperable publish-subscribe framework and enhancements to the CompletableFuture API.
JEP 268: XML Catalogs:
- Adds a standard XML Catalog API that supports the Organization for the Advancement of Structured Information Standards (OASIS) XML Catalogs version 1.1 standard. The API defines catalog and catalog-resolver abstractions that can be used as an intrinsic or external resolver with the JAXP processors that accept resolvers.
- Existing libraries or applications that use the internal catalog API will need to migrate to the new API to take advantage of the new features.
JEP 269: Convenience Factory Methods for Collections:
- Makes it easier to create instances of collections and maps with small numbers of elements. New static factory methods on the List, Set, and Map interfaces make it simpler to create immutable instances of those collections.
JEP 274: Enhanced Method Handles:
Enhances the MethodHandle, MethodHandles, and MethodHandles.Lookup classes of the java.lang.invoke package to ease common use cases and enable better compiler optimizations. Additions include:
- In the MethodHandles class in the java.lang.invoke package, provide new MethodHandle combinators for loops and try/finally blocks.
- Enhance the MethodHandle and MethodHandles classes with new MethodHandle combinators for argument handling.
- Implement new lookups for interface methods and, optionally, super constructors in the MethodHandles.Lookup class.
JEP 277: Enhanced Deprecation:
Revamps the @Deprecated annotation to provide better information about the status and intended disposition of an API in the specification. Two new elements have been added:
- Deprecated(forRemoval=true) indicates that the API will be removed in a future release of the Java SE platform
- Deprecated(since="version") contains the Java SE version string that indicates when the API element was deprecated, for those deprecated in Java SE 9 and beyond
JEP 285: Spin-Wait Hints:
- Defines an API that enables Java code to hint that a spin loop is executing. A spin loop repeatedly checks to see if a condition is true, such as when a lock can be acquired, after which some computation can be safely performed followed by the release of the lock. This API is purely a hint, and carries no semantic behavior requirements. See the method Thread.onSpinWait
JEP 290: Filter Incoming Serialization Data:
- Allows incoming streams of object-serialization data to be filtered to improve both security and robustness. Object-serialization clients can validate their input more easily, and exported Remote Method Invocation (RMI) objects can validate invocation arguments more easily as well
- Serialization clients implement a filter interface that is set on an ObjectInputStream. For RMI, the object is exported through a RemoteServerRef that sets the filter on the MarshalInputStream to validate the invocation arguments as they are unmarshalled
JEP 259: Stack-Walking API:
- Provides a stack-walking API that allows easy filtering and lazy access to the information in stack traces
- The API supports both short walks that stop at a frame that matches given criteria, and long walks that traverse the entire stack. Stopping at a frame that matches a given criteria avoids the cost of examining all the frames if the caller is interested only in the top frames on the stack. The API enables access to Class objects when the stack walker is configured to do so. See the class java.lang.Stackwalker
JEP 255: Merge Selected Xerces 2.11.0 Updates into JAXP:
Updates the JDK to support the 2.11.0 version of the Xerces parser. There is no change to the public JAXP API
The changes are in the following categories of Xerces 2.11.0: Datatypes, DOM L3 Serializer, XPointer, Catalog Resolver, and XML Schema Validation (including bug fixes, but not the XML Schema 1.1 development code)
WHAT'S NEW FOR NASHORN:
JEP 236: Parser API for Nashorn:
- Enables applications, in particular IDEs and server-side frameworks, to parse and analyze ECMAScript code
- Parse ECMAScript code from a string, URL, or file with methods from the Parser class. These methods return an instance of CompilationUnitTree, which represents ECMAScript code as an abstract syntax tree
- The package jdk.nashorn.api.tree contains the Nashorn parser API
JEP 292: Implement Selected ECMAScript 6 Features in Nashorn: Implements many new features introduced in the 6th edition of ECMA-262, also known as ECMAScript 6, or ES6 for short. Implemented features include the following:
- Template strings
- let, const, and block scope
- Iterators and for..of loops
- Map, Set, WeakMap, and WeakSet
- Symbols
- Binary and octal literals
WHAT'S NEW FOR CLIENT TECHNOLOGIES:
JEP 251: Multi-Resolution Images:
- Enables a set of images with different resolutions to be encapsulated into a single multiresolution image. This could be useful for applications to adapt to display devices whose resolutions may vary from approximately 96dpi to 300dpi during run time
- The interface java.awt.image.MultiResolutionImage encapsulates a set of images with different resolutions into a single multiresolution image, which enables applications to easily manipulate and display images with resolution variants
JEP 253: Prepare JavaFX UI Controls and CSS APIs for Modularization:
- Provides public APIs for JavaFX UI controls and CSS functionality that were previously available only through internal packages but are now inaccessible due to modularization
- The new package javafx.scene.control.skin consists of a set of classes that provides a default implementation for the skin (or the look) of each UI control
- The new class CssParser is a CSS parser that returns a Stylesheet object, which gives you more control over the CSS styling of your application. It’s part of the CSS API (the javafx.css package). The CSS API includes new support classes, including a set of standard converters used by the parser; see the javafx.css.converter package
JEP 256: BeanInfo Annotations:
- Replaces the @beaninfo Javadoc tag with the annotation types JavaBean, BeanProperty, and SwingContainer
- These annotation types set the corresponding feature attributes during BeanInfo generation at runtime. Thus, you can more easily specify these attributes directly in Bean classes instead of creating a separate BeanInfo class for every Bean class. It also enables the removal of automatically generated classes, which makes it easier to modularize the client library
JEP 262: TIFF Image I/O:
- Adds Tag Image File Format (TIFF) reading and writing as standard to the package javax.imageio. The new package javax.imageio.plugins.tiff provides classes that simplify the optional manipulation of TIFF metadata
JEP 263: HiDPI Graphics on Windows and Linux:
- Automatically scales and sizes AWT and Swing components for High Dots Per Inch (HiDPI) displays on Windows and Linux. Prior to this release, on Windows and Linux, Java applications were sized and rendered based on pixels, even on HiDPI displays that can have pixel densities two to three times as high as traditional displays. This led to GUI components and windows that were too small to read or use
JEP 272: Platform-Specific Desktop Features:
Adds additional methods to the class java.awt.Desktop that enable you to interact with the desktop, including the following:
- Show custom About and Preferences windows
- Handle requests to open or print a list of files
- Handle requests to open a URL
- Open the native help viewer application
- Set the default menu bar
- Enable or disable the application to be suddenly terminated
- These new methods replace the functionality of the internal APIs contained in the OS X package com.apple.eawt, which are not accessible by default in JDK 9. Note that the package com.apple.eio is no longer accessible
WHAT'S NEW FOR INTERNATIONALIZATION:
JEP 267: Unicode 8.0:
- Supports Unicode 8.0. JDK 8 supported Unicode 6.2
- The Unicode 6.3, 7.0 and 8.0 standards combined introduced 10,555 characters, 29 scripts, and 42 blocks, all of which are supported in JDK 9
JEP 252: CLDR Locale Data Enabled by Default:
- Uses the Common Locale Data Repository's (CLDR) XML-based locale data, first added in JDK 8, as the default locale data in JDK 9. In previous releases, the default was JRE
- To enable behavior compatible with JDK 8, set the system property java.locale.providers to a value with COMPAT ahead of CLDR
JEP 226: UTF-8 Properties Files:
- Loads properties files in UTF-8 encoding. In previous releases, ISO-8859-1 encoding was used when loading property resource bundles. UTF-8 is a much more convenient way to represent non-Latin characters
- Most existing properties files should not be affected