bamboo.bamboo
Senior Member
Nguồn:Always-strict floating point semantics, a foreign function and memory API, and a uniform API for pseudo random number generators are planned for the Java long-term support release due in September.
The feature set for Java 17 is now frozen, with the next version of standard Java due to have 10 new features plus two feature removals and two feature deprecations. Among capabilities set for Version 17 are context-specific deserialization filters support, which is a security enhancement, and a preview of pattern matching for switch statements and expressions.
Due as a production release on September 14, Java Development Kit (JDK) 17 will be a long-term-support (LTS) release, with extended support from Oracle expected for several years. The feature set was frozen on June 10 when JDK 17 reached an initial rampdown phase. The stabilization repo, jdk17, is open for select bug fixes and, with approval, late enhancements. Features filed as part of OpenJDK’s JDK 17 include the following:
- Context-specific deserialization filters allow applications to configure context-specific and dynamically selected deserialization filters via a JVM-wide filter factory invoked to select a filter for each serialization operation. In explaining the motivation behind this proposal, Oracle said deserializing untrusted data is an inherently dangerous activity because the content of the incoming data streams determines the objects that are created, the values of their fields, and references between them. In many uses, the bytes in the stream are received from an unknown, untrusted, or unauthenticated client. With careful construction of the stream, an adversary can cause code in arbitrary classes to be executed with malicious intent. If object construction has side effects that change state or invoke other actions, those actions could compromise the integrity of application objects, library objects, and the Java runtime. The key to disabling serialization attacks is to prevent instances of arbitrary classes from being deserialized, thereby preventing the direct or indirect execution of their methods. Deserialization filters were introduced in Java 9 to enable application and library code to validate incoming data streams before deserializing them. This code supplies validation logic as a java.i
bjectInputFilter when it creates a deserialization stream. However, relying on a stream’s creator to explicitly request validation has limitations. JDK Enhancement Proposal 290 addressed these limitations by introducing a JVM-wide deserialization filter that can be set via an API, system properties, or security properties, but this approach also has limits, particularly in complex applications. A better approach is to configure per-stream filters such that they do not require the participation of every stream creator. The planned enhancement should help developers construct and apply appropriate filters for each deserialization context and use case.
- Deprecation of the Security Manager, preparing for removal in a future release. Dating back to Java 1.0, Security Manager has been the primary means of securing client-side Java code and has rarely been used to secure server-side code. A goal of the proposal is evaluating whether new APIs or mechanisms are needed to address specific narrow use cases for which Security Manager has been used, such as blocking System::exit. Plans call for deprecating the Security Manager for removal in concert with the legacy Applet API, which also is slated to be deprecated in JDK 17.
- A preview of pattern matching for switch extends the language of patterns in Java to allow switch expressions and statements to be tested against a number of patterns, each with a specific action. This enables complex data-oriented queries to be expressed concisely and safely. Among the goals of this feature include expanding the expressiveness and application of switch expressions and statements by enabling patterns to appear in case labels, relaxing the historical null-hostility of switch when desired, and introducing two kinds of patterns: guarded patterns, which allow pattern matching logic to be refined with arbitrary Boolean expressions, and parenthesized patterns, which resolve some parsing ambiguities. In JDK 16, the instanceof operator was extended to take a type pattern and perform pattern matching. The modest extension proposed allows the familiar instanceof-and-cast idiom to be simplified.
- Strong encapsulation for JDK internals, except for critical internal APIs such as sun.misc.Unsafe, would make it no longer be possible to relax the strong encapsulation of internal elements via a single command-line option, as was doable in JDK 9 through JDK 16. Goals of the plan include improving security and maintainability of the JDK and encouraging developers to migrate from internal elements to standard APIs.
- Removal of the Remote Method Invocation (RMI) Activation mechanism while preserving the rest of RMI. The RMI Activation mechanism is obsolete and disused and was deprecated for removal in JDK 15.
- The foreign function and memory API, introduced an incubator stage, allows Java programs to interoperate with code and data outside of the Java runtime. By efficiently invoking foreign functions, i.e., code outside the JVM, and safely accessing foreign memory, i.e., memory not managed by the JVM, the API enables Java programs to call native libraries and process native data without the brittleness and risk of JNI (Java Native Interface). The API proposed is the evolution of two APIs — the foreign memory access API and the foreign linker API. The foreign memory access API was targeted to Java 14 in 2019 as an incubating API and re-incubated in Java 15 and Java 16. The foreign linker API was targeted to Java 16 as an incubating API in late-2020. Goals of the API plan include ease of use, performance, generality, and safety.
- Integrated into JDK 16 as an incubating API, the platform-agnostic vector API will be incubated again in JDK 17, providing a mechanism to express vector computations that reliably compile at run time to optimal vector instructions on supported CPU architectures. This achieves better performance than equivalent scalar computations. In JDK 17, the vector API has been enhanced for performance and implementation, including enhancements to translate byte vectors to and from boolean arrays.
- Sealed classes and interfaces restrict which other classes or interfaces may extend or implement them. Goals of the proposal include allowing the author of a class or interface to control which code is responsible for implementing it, providing a more declarative way than access modifiers to restrict the use of a superclass, and supporting future directions in pattern matching by providing a foundation for the exhaustive analysis of patterns.
- Removal of the experimental AOT and JIT compiler, which has seen little use but requires significant maintenance effort. The plan calls for maintaining the Java-level JVM compiler interface so developers can keep using externally built versions of the compiler for JIT compilation. AOT compilation (the jaotc tool) was incorporated into JDK 9 as an experimental feature. The tool uses the Graal compiler, which is itself written in Java, for AOT compilation. These experimental features were not included in JDK 16 builds published by Oracle and no one complained. Under the plan prescribed, three JDK modules would be removed: jdk.aot (the jaotc tool); internal.vm.compiler, the Graal compiler; and jdk.internal.vm.compiler.management, the Graal MBean. HotSpot code related to AOT compilation also would be removed.
- Porting the JDK to MacOS/AArch64 in response to Apple’s plan to transition its Macintosh computers from x64 to AArch64. An AArch64 port for Java already exists for Linux and work is underway for Windows. Java builders expect to reuse existing AArch64 code from these ports by employing conditional compilation, as is the norm in ports of the JDK, to accommodate differences in low-level conventions such as the application binary interface and the set of reserved processor registers. Changes for MacOS/AArch64 risk breaking the existing Linux/AArch64, Windows/AArch64, and MacOS/x64 ports, but the risk will be reduced through pre-integration testing.
https://www.infoworld.com/article/3606833/jdk-17-the-new-features-in-java-17.html
Ngôn ngữ kĩ thuật quá nên e ko dịch sang tiếng Việt mà để tóm tắt cho các thím dễ hiểu.
Phiên bản hỗ trợ dài hạn mới nhất của Java - Java 17 LTS sẽ được hỗ trợ một loạt nâng cấp/thay đổi như sau:
JEP 415: Context-Specific Deserialization Filters
JEP 414: Vector API (Second Incubator)
JEP 412: Foreign Function & Memory API (Incubator)
JEP 411: Deprecate the Security Manager for Removal
JEP 410: Remove the Experimental AOT and JIT Compiler
JEP 409: Sealed Classes
JEP 407: Remove RMI Activation
JEP 406: Pattern Matching for switch (Preview)
JEP 403: Strongly Encapsulate JDK Internals
JEP 398: Deprecate the Applet PI for Removal
JEP 391: macOS/AArch64 Port
JEP 382: New macOS Rendering Pipeline
JEP 356: Enhanced Pseudo-Random Number Generators
JEP 306: Restore Always-Strict Floating-Point Semantics
or Golang
