JEP 415 : Context-Specific Deserialization Filters

Allow applications to configure context-specific and dynamically-selected deserialization filters using a JVM-wide filter factory that is used to choose a filter for each each deserialization operation.

Motivation:

• Deserialization of untrusted data is an operation that is intrinsically risky, because the contents of incoming data streams are obtained in many cases via an unknown or unauthenticated client.
• The key to preventing serialisation attacks is to prohibit instances of arbitrary classes from being deserialized, which prevents the execution of their methods either directly or indirectly.
• An attacker can run code from any class with bad intent by carefully constructing the stream. The integrity of application objects, library objects, and the Java runtime could be compromised if object construction involves side effects that change state or trigger other operations.

JEP 414: Vector API (Second Incubator)

Introduce an platform-agnostic vector API first integrated into JDK 16 and will be incubated again in JDK 17 to express vector computations that reliably compile to optimal vector instructions on supported CPU architectures at runtime, outperforming equivalent scalar computations.

The vector API in JDK 17 has been improved for performance and implementation, including enhancements to translate byte vectors to and from boolean arrays.

Goals:

• Clear and concise API : The API should be capable of expressing a broad variety of vector computations in a clear and concise manner.
• Platform agnostic : The API should be independent of CPU architecture, allowing implementations on a variety of architectures that support vector instructions.
• Reliable runtime compilation and performance on x64 and AArch64 architectures
• Graceful degradation : If a vector computation cannot be efficiently compiled to vector instructions, warnings can be issued.

JEP 412: Foreign Function & Memory API (Incubator)

Introduce an API that allows Java programmes to call up native libraries and process native data without the risk of JNI, by efficiently invoking foreign functions (i.e., code outside of the JVM) and securely accessing foreign memory (i.e. memory not handled by the JVM).

In this JEP proposal is evolution of earlier two incubating APIs: the Foreign-Memory Access API and the Foreign Linker API. which was previously targeted in Java 14, 15 and Java 16

Goals:

• Ease of use : Replace a superior pure Java development model with the Java Native Interface (JNI).
• Performance : Performance that is similar to existing APIs like JNI or sun.misc.Unsafe, if not better. Performance.
• General : Provided ways to work on various types of external memory (for example, native memory, persistent memory and heap memory) and to accommodate other platforms over time (for example, x86 32-bit) and foreign functions written in languages other than C (for example, C++, FORTAN).
• Safety : Deactivate default unsecure operations only when the application developers or end users have expressly opted in.

JEP 411: Deprecate the Security Manager for Removal

Since Java 1.0, there has been a Security Manager. However, it has been rarely used for many years. In order to move Java forward, Security Manager has been deprecated in Java 17 and will be removed in a future version, along with the legacy Applet API (JEP 398).

Goals:

• Prepare developers for the Security Manager's removal in a future version of Java.
• If a user's Java programme relies on the Security Manager, issue an alert.
• Evaluate if new APIs or mechanisms are required to fix unique, limited use cases where the Security Manager has been used, such as blocking System::exit.

JEP 410: Remove the Experimental AOT and JIT Compiler

Remove the experimental Java-based ahead-of-time (AOT) and just-in-time (JIT) compiler because of limited usage and effort required to maintain it is significant.

Even though retain the experimental Java-level JVM compiler interface (JVMCI) such that developers can continue to use externally-built versions of the compiler for JIT compilation with use of Graal compiler (GraalVM).

Motivation:

As the experimental feature JDK 9 has been integrated with ahead-of time compilation (the jaotc tool). For AOT compilation, the jaotc uses the Java-written Graal compiler. Since these experimental characteristics have not been used, and there is a considerable effort to maintain and improve them. The JDK 16 builds released by Oracle did not have these functions, neither did anyone complain.

JEP 409: Sealed Classes

Sealed Classes were proposed and delivered as a

second preview feature in JDK 16.

Enhance Java programming language with sealed classes and interfaces. Sealed classes and interfaces restrict which other classes or interfaces can extend or implement.

Goals:

• Enable the class or interface author to control which code to implement it.
• Provide a more declarative approach than access modifiers to limit the use of a superclass.
• Support future pattern matching directions with a basis to examine trends thoroughly.

Refinement:

• In the JLS, describe the definition of a contextual keyword, which replaces the previous definitions of restricted identifier and restricted keyword.
• Introduce sealed, non-sealed character sequences and allow them as contextual keywords.
• As with anonymous classes and lambda expressions, local classes may not be sealed class subclasses when deciding the implicitly declared allowed subclasses of a sealed class or sealed interface.

A class can be sealed by using the sealed modifier - permits to its declaration. After which any extends and implements clauses, the permits clause specifies the classes that are permitted/allowed to extend the sealed class.

package com.techgeeknext.example.species;

public sealed class Animal
permits Dog, Monkey, Leopard {...}

package com.techgeeknext.example.species;

public sealed class Animal
com.techgeeknext.example.species.canis.Dog,
com.techgeeknext.example.species.macaca.Monkey,
com.techgeeknext.example.species.rana.Leopard
{....}

JEP 407: Remove RMI Activation

The Remote Method Invocation (RMI) Activation mechanism will be removed, but the rest of RMI should be preserved. The RMI Activation mechanism has become redundant and is no longer in use. JEP 385 in Java SE 15 deprecated it and recommended that it be removed.

JEP 406: Pattern Matching for switch (Preview)

Pattern matching for switch expands Java's pattern language to allow switch expressions and statements to be verified against a variety of patterns, each with a different action. This makes it possible to express complex data-oriented queries in a simplistic and secure manner.

The instanceof operator in JDK 16 has been expanded to accept a type pattern and perform pattern matching. The modest extension proposed simplifies the well-known instanceof-and-cast idiom.

Goals:

• Allowing patterns to appear in case labels increases the expressiveness and applicability of switch phrases and statements.
• Let the null-hostility of the historical turning point be relaxed if needed.
• Two new patterns will be introduced:
  1. Guarded patterns: to refine pattern matching logic using arbitrary boolean expressions.
  2. Parenthesized patterns: to clear up parsing ambiguities.
• Ensure that all existing switch expressions and statements compile with identical semantics and perform them without any modification.

JEP 403: Strongly Encapsulate JDK Internals

Strongly encapsulate all internal elements of the JDK, except for critical internal APIs such as sun.misc.Unsafe. It will no longer be possible to relax the strict encapsulation of internal parts with a single command-line option, as it was from JDK 9 to JDK 16.

JEP 398: Deprecate the Applet API for Removal

Applet API is effectively useless, because all web browser vendors have either removed or revealed plans to drop support for Java browser plug-ins . While the Applet API was deprecated in Java 9, it was not removed earlier.

JEP 391: macOS/AArch64 Port

Port the JDK to the new architecture macOS/AArch64 expecting future demand

Motivation:

• Apple's decision to move from x64 to AArch64 on its Macintosh computers. For Linux, an AArch64 version of Java is already available, and development on a Windows port is currently underway.
• Because of discrepancies in low-level conventions such as the programme binary interface and the collection of reserved processor registers, Java developers plan to reuse existing AArch64 code from these ports by using conditional compilation, as is standard in JDK ports.
• Changes for MacOS/AArch64 have the potential to split current Linux/AArch64, Windows/AArch64, and MacOS/x64 ports, although this possibility can be mitigated by pre-integration testing.

JEP 382: New macOS Rendering Pipeline

Need for new Java 2D rendering pipeline for macOS using the new Apple Metal framework. As today, Java 2D is totally reliant on OpenGL. While Apple deprecated the OpenGL rendering library in macOS 10.14, but the Metal framework replaces the OpenGL rendering library.

Goals:

• Provide a completely functioning rendering pipeline for the macOS Metal framework-based Java 2D API.
• In select real-world applications and benchmarks, provide performance comparable to or better than the OpenGL pipeline.
• Coexist with the OpenGL pipeline until it is discontinued.

JEP 356: Enhanced Pseudo-Random Number Generators

Introduces new interface and implementations for pseudorandom number generators (PRNGs), which including jumpable PRNGs and a new class of splittable PRNG algorithms (LXM).

Motivating the plan is a focus on multiple areas for improvement in the area of pseudorandom number generation in Java. RandomGenerator, a modern interface, will have a uniform API for all current and new PRNGs, as well as four specialised RandomGenerator interfaces.

Goals:

• Make it simpler to use different PRNG algorithms in different applications.
• By providing streams of PRNG objects, you can better support stream-based programming.
• Remove redundant code from current PRNG groups.
• Maintain the actions of the java.util.Random class as far as possible.

JEP 306: Restore Always-Strict Floating-Point Semantics

Rather of having both severe floating-point semantics (strictfp) and significantly different default floating-point semantics, make floating-point operations uniformly strict. This will return the language and virtual machine to their original floating-point semantics, as they were before the introduction of strict and default floating-point modes in Java SE 1.2.

Goals:

• Continue to improve the JDK's security and maintainability, which is one of Project Jigsaw's primary objectives.
• Encourage developers to move away from internal parts and toward standard APIs so that they and their users can upgrade to future Java releases with ease.