Java Advancement Package 19, a non-LTS (long-lasting assistance) release due in September, has actually reached the release candidate stage. 7 features target the release consisting of structured concurrency, record patterns, a preview of a foreign function and memory API, and assistance for the open source Linux/RISC-V instruction set architecture (ISA).
With the feature set for JDK 19 now frozen, other prepared abilities such as universal generics and worth items will have to wait for a later version of the platform. JDK 19 follows the March 22 arrival of JDK 18. Requirement Java is on a six-month release cadence.JDK 19 is slated to
be officially released for production use on September 20. An initial release candidate was published August 11, preceded by 2 rampdown stages in June and July. A second release candidate is due August 25. Early access constructs of JDK 19 can be downloaded from jdk.java.net/19. The JDK 19 functions include: Structured concurrency, in an incubator phase, is meant to simplify multithreaded programs through a structured concurrency API. This
- concurrencytreats numerous tasks running in various threads as a single unit of work, to enhance mistake handling and cancellation. Dependability and observability are improved. A preview of record patterns, to deconstruct record worths. Tape patterns and type patterns can be nested to make it possible for a declarative, effective, and composable
- kind of information navigation and processing. Goals of the proposal include extending pattern matching to express more advanced, composable information questions while not altering the syntax or semantics of type patterns. This proposition develops on pattern matching for instanceof, delivered in JDK 16 in March 2021. Future plans may call for record patterns to be extended with capabilities such as array patterns and vararg patterns. Tape patterns belongs to Task Amber, an effort to check out and nurture smaller sized, productivity-oriented Java functions. A sneak peek of a foreign function and memory API, which would present an API by which Java programs can interoperate with code and data outside the Java runtime. By effectively invoking foreign functions( i.e., code outside the JVM )and safely accessing foreign memory(i.e., memory not managed by the
- JVM)the API allows Java programs to call native libraries and procedure native information without the risk and
brittleness of the Java Native User Interface(JNI ). The foreign function and memory API combines 2 earlier breeding APIs: the foreign memory gain access to API and the foreign linker API. The foreign function and memory API was formerly incubated in JDK 17 and reincubated in JDK 18. The proposal’s goals include ease of usage, performance, generality, and security. A sneak peek of virtual threads, which are light-weight threads that drastically reduce the effort of writing, maintaining, and observing high-throughput, concurrent applications. Goals consist of enabling server applications written in the easy thread-per-request style to scale with near-optimal hardware utilization, enabling existing code that uses the java.lang Thread API to embrace virtual threads with minimal modification, and allow troubleshooting, debugging, and profiling of virtual threads with existing JDK tools. It is not a goal of this proposalto change the fundamental concurrency design in Java or offer a brand-new data parallelism construct in either the Java language or Java libraries. Nor is it a goal to eliminate the conventional application of threads or to silently move existing applications to utilize virtual threads. A third sneak peek of pattern matching for switch expressions and declarations, extending pattern matching to change, to enable an expression to be evaluated versus a number of patterns, each with a specific action, so complicated data-oriented queries can be expressed concisely and securely. This capability formerly was previewed in JDK 17 and JDK 18. The 3rd sneak peek would include refinements including the replacement of protected patterns with when clauses in switch blocks. Also, the runtime semantics of a pattern switch when the worth of the selector expression is null are more closely lined up with tradition switch semantics. The strategy’s objectives consist of broadening the expressiveness and applicability of switch expressions and declarations by permitting patterns to appear in - case labels. Other goals include enabling designers to unwind the historic null-hostility of switch when wanted, increasing thesecurity of switch statements and ensuring that existing switch expressions and statements continue to put together with no changes and carry out with identical semantics. A 4th incubation of a vector API that would express vector computations that dependably put together at runtime to optimum vector guidelines on supported CPU architectures, hence attaining efficiency remarkable to equivalent scalar calculations. Designers using the API acquire a method to compose complex vector algorithms in Java, using the HotSpot auto-vectorizer but with a user model that makes vectorizations more foreseeable and robust. The vector API previously was nurtured into JDK 16, JDK 17, and JDK 19. Improvements to the API proposed for JDK 19 include improvements to load and store vectors to and from MemorySegments, as defined by the Foreign Function and Memory API preview. JDK 19 would also add 2 cross-lane vector operations, compress and expand, together with a complementary vector mask compress operation. The compress vector operation maps lanes of a source vector, picked by a mask, to a location vector in lane order, while the broaden operation does the inverted. The compress operation is useful in filtering question results.In another addition to the vector API, bitwise essential lanewise operations would be expanded, including operations such counting the variety of one bits, reversing the order of bits, and compressing and expanding bits. Objectives of the API consisted of being clear and concise, platform-agnostic, having dependable runtime and collection performance on x64 and AArch64 architectures, and enabling “stylish”destruction, for scenarios in which a vector computation can not be completely revealed at
runtime as a series of vector operations. With the Linux/RISC-V port, Java would acquire support for a hardware instruction set that is currently supported by a wide range of language toolchains. RISC-V really is a household of associated ISAs. The Linux/RISC-V port would just support the RV64GV setup of RISC-V, a general purpose 64-bit ISA that consists of vector instructions. The designers of Java may think about other RISC-V setups in the future. The port would support the following HotSpot VM choices: the template interpreter, C1(customer)JIT compiler, C2 (server)JIT compiler, and all present mainline garbage collectors consisting of ZGC and Shenandoah. The real porting is nearly complete; the focus of the JDK Enhancement Proposition(JEP )is integration of the port into the JDK mainline repository.Like JDK 18, JDK 19 is due to be a short-term release, with only 6 months of high-level, Premier support.The preceding release, JDK 17, was a Long Term Support(LTS)release, with a number of years of support. It got here September 14, 2021. Copyright © 2022 IDG Communications, Inc. Source
