Take a look at the new features of Java17

“This is the 26th day of my participation in the Gwen Challenge in November. Check out the details: The Last Gwen Challenge in 2021.”

Java 17 is a new long Term Support (LTS) version of standard Java that is now available for production. Oracle also announced that the LTS version, which has at least eight years of product support, will be released every two years instead of every three years in the past. Non-lts versions received six months of support from Oracle.

Among the new features in the new version of standard Java are support for context-specific deserialization filters, a security improvement, and pattern matching for preview switch statements. JDK 17 has all the functionality that has been added since the last LTS release (JDK 11) three years ago.

Georges Saab, vice president of Oracle’s Java Platform group, says the more frequent LTS releases will provide faster access to new features for companies that just want to use the LTS version. The next LTS release will be Java 21 in 2023. With JDK 17, Oracle will allow free use of Oracle JDK binaries in production for three years, one year after the next LTS release. But this does not include enterprise production support subscriptions.

Data from application monitoring provider New Relic’s customer base, which represents tens of millions of production JVMS, shows a nearly uniform deployment of THE LTS version. New Relic found that almost 100% of its users were running JDK 11 or JDK 8, the two most recent LTS releases. New Relic says 90% of people are running JDK 11 and 10% are running JDK 8.

However, Oracle says downloads of the six-month version have been steadily increasing. Developers like to try out six-month versions, while businesses want to deploy LTS versions.

A production build of JDK 17 can be found at oracle.com. An open source version of OpenJDK is also available. New features in JDK 17 include the following.

• Context-specific deserialization filters allow applications to configure context-specific and dynamically selected deserialization filters by calling jVM-wide filter factories to select filters for each serialization operation. In explaining the motivation behind the proposal, Oracle said that deserializing untrusted data is an inherently dangerous activity because the content of the incoming data stream determines the objects created, the values of their fields, and the references between them. In many cases, bytes in a data stream are received from an unknown, untrusted, or unauthenticated client. With careful construction of convection, an adversary can cause code in any class to execute maliciously. If an object’s build has the side effect of changing state or invoking other actions, those actions may 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 their methods from being executed directly or indirectly. Deserialization filters were introduced in Java 9 to enable application and library code to validate incoming data streams before deserialization. This code as a Java. When creating the deserialization stream. IO ObjectInputFilter provide validation logic. However, relying on the creator of a flow to explicitly request validation has its limitations. JDK Enhancement Proposal 290 addresses these limitations by introducing a JVM-wide deserialization filter that can be set through APIS, system properties, or security properties, but this approach has limitations, especially in complex applications. A better approach is to configure filters for each stream so that they do not require the participation of each stream creator. Planned enhancements should help developers build and apply appropriate filters for each deserialization environment and use case.
• Instead of having both strict floating-point semantics (STRICTFP) and subtly different default floating-point semantics, floating-point operations become consistently strict with the restoration of the always strict floating-point semantics. This restores the original floating-point semantics of the language and virtual machine, matching the semantics prior to the introduction of the strict and default floating-point schema in Java Standard Version 1.2. The goals of this work include simplifying the development of number-sensitive libraries, including java.lang.Math and java.lang.StrictMath. In the late 1990s, the impetus to change the default floating-point semantics stemmed from an undesirable interaction between the semantics of the original Java language and JVM and some peculiarities of the popular X86 x87 floating-point coprocessor instruction set. Matching accurate floating-point semantics in all cases, including abnormal operands and results, requires significant overhead of additional instructions. Matching results can be done with less overhead without overflows or underflows, as allowed by the revised default floating-point semantics introduced in Java SE 1.2. However, the SSE2 (Streaming SIMD Extensions 2) extension, which has been shipping on Pentium 4 processors since around 2001 and later, can directly support strict JVM floating-point operations without incurring excessive overhead. Because Intel and AMD support SSE2 and later extensions that allow for natural support for strict floating-point semantics, there is no longer a technical motivation other than the strict default floating-point semantics.
• The security manager has been deprecated and will be deleted in a future release. Dating back to Java 1.0, security managers have been the primary means of securing client-side Java code and have rarely been used to secure server-side code. One goal of the proposal is to evaluate whether new apis or mechanisms are needed to address specific narrow use cases used by security managers, such as blocking System::exit. The plan calls for the security manager to be deprecated in order to be removed along with the traditional Applet API, which will also be deprecated in JDK 17.
• Switch’s Pattern Match preview extends the pattern language in Java so that switch expressions and statements can be tested against a number of patterns, each with a specific action. This enables complex data-oriented queries to be expressed concisely and safely. The goals of this feature include: to extend the expressiveness and application of switch expressions and statements by making patterns appear in case tags, to relax the historical invalidity of the switch when needed, and to introduce two modes: a guarded mode, which allows arbitrary Boolean expressions to perfect pattern matching logic; And the parenthesis pattern, which resolves some ambiguity in parsing. In JDK 16, the instanceof operator was extended to accept a type pattern and perform pattern matching. The proposed modest extension allows simplification of the familiar instanceof-and-cast idiom.
• In addition to key internal apis such as sun.misc.unsafe, strong encapsulation of JDK internal elements will make it no longer possible to loosen it with a command-line option, as was possible in JDK 9 through JDK 16. The goals of the initiative include improving the security and maintainability of the JDK and encouraging developers to migrate from internal elements to standard apis.
• The remote method call (RMI) activation mechanism was removed, while preserving the rest of RMI. The RMI activation mechanism is outdated and deprecated, deprecated and removed in JDK 15.
• Foreign function and memory apis were introduced during the incubation phase to allow Java programs to interoperate with code and data outside of the Java runtime. By efficiently calling foreign functions, that is, code outside the JVM, and securely accessing foreign memory, that is, memory not managed by the JVM, the API enables Java programs to call local libraries and work with local data without the brittleness and risk of JNI (Java Native Interface). The proposed API evolved from two apis — the foreign memory access API and the foreign linker API. The foreign memory Access API was targeted as an incubation API for Java 14 in 2019 and re-incubated in Java 15 and Java 16. The foreign linker API is targeted for Java 16 as an incubation API by the end of 2020. The API program’s goals include ease of use, performance, versatility, and security.
• Integrated into JDK 16 as an incubation API, the platform-independent vector API will be incubated again in JDK 17, providing a mechanism to express vector computations that are reliably compiled at run time into the best vector instructions on the supported CPU architecture. This achieves better performance than equivalent scalar computations. In JDK 17, the vector API was enhanced in terms of performance and implementation, including the ability to convert byte vectors to and from Boolean arrays.
• Enclosing classes and interfaces restrict which other classes or interfaces can extend or implement them. The 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 explicit way to restrict the use of superclasses than access modifiers, and supporting the future direction of pattern matching by providing a basis for an exhaustive analysis of patterns. This ability helps API designers build more resilient code.
• Remove the experimental AOT and JIT compilers, which are used sparingly but require a lot of maintenance work. The plan calls for maintaining a Java-level JVM compiler interface so that developers can continue JIT compilation using externally built versions of the compiler. AOT compilation (the JAOTC tool) was included as an experimental feature in JDK 9. The tool uses the Graal compiler, which is itself written in Java for AOT compilation. These experimental features were not included in the JDK 16 build released by Oracle, and no one complained. According to the specified plan, three JDK modules will be removed: jdk.aot (jAOTC tool); Internal.vm.com Piler, Graal compiler; And jdk.internal.vm.com piler. Management, Graal an. HotSpot code related to AOT compilation will also 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 developers want to reuse existing AArch64 code from these migrations by using conditional compilation, just like the JDK migration, to accommodate differences in low-level conventions, such as application binary interfaces and reserved processor register sets. Changes made for MacOS/AArch64 have the potential to break existing Linux/AArch64, Windows/AArch64, and MacOS/ X64 ports, but this risk will be reduced through pre-integration testing.
• Delete the obsolete Applet API. This API is essentially irrelevant, as all web browser vendors have either removed support for Java browser plug-ins or announced plans to do so. Previously, the Applet API was deprecated in Java 9 in September 2017, but not for removal.
• A new MacOS rendering pipeline that uses the Apple Metal API as an alternative to the existing pipeline that uses the deprecated OpenGL API. This proposal aims to provide a fully functional rendering pipeline for the Java 2D API that uses the MacOS Metal framework and is ready in case Apple removes the OpenGL API from future MacOS releases. The pipeline is intended to be functionally equivalent to existing OpenGL pipelines with equal or better performance in selected applications and benchmarks. A clean architecture will be created that fits the current Java 2D model. The pipe will coexist with the OpenGL pipe until it is phased out. The goal of this proposal is not to add any new Java or JDK APIs.
• The enhanced pseudorandom number generator will provide new interface types and implementations for pseudorandom number generators (PRNGs), including jump-able PRNGs and another class of separable PRNG algorithms (LXM). A new interface, RandomGenerator, will provide a unified API for all existing and new PRNGs. Four specialized RandomGenerator interfaces will be provided. The motivation for this initiative is to focus on several areas of improvement in the pseudo random number generation area in Java. This work does not require many implementations of other PRNG algorithms. But it adds three common algorithms that are already widely deployed in other programming language environments. The goals of the program include
• • It makes it easier to use various PRNG algorithms interchangeably in applications.
  • Improved support for stream-based programming, providing streams of PRNG objects.
  • Eliminates code duplication in existing PRNG classes.
  • Retain the Java. Util. Random. The Category of existing behavior.

Thank you for watching, if you are interested, you can pay attention to me, convenient to check the follow-up articles, learn together, common progress, thank you!