What is new in Java 17

Java 17 was made available in September 2021, replacing Java 11 as the most recent LTS (long-term support). The crucial query right now is, "What is new in Java 17?"

JDK (14) Enhancement Proposals (JEP) items are included in Java 17. Ten of those are new features, two are being removed, and two are being deprecated.

We will go over the major updates in Java 17 that affect application developers in this post. We will also include a list of deprecated features and those that have been eliminated.

The most recent version of standard Java with long-term support includes always-strict floating-point semantics, a foreign function, memory API, a consistent API for fake random number generators, and many other features.

A new Long-Term Support (LTS) variant of the Java standard, Java 17, is currently used in production settings. Additionally, Oracle said that LTS releases, which receive at least eight years of product support, would no longer be released every three years but rather every two years going forward. Oracle provides six months of support for versions that are not LTS.

A preview of pattern matching for switch statements and support for context-specific deserialization filters, which improve security, are two of the new features in the upcoming version of standard Java. Everything that has been added since the three-year-old JDK 11 LTS release is included in JDK 17.

According to Georges Saab, vice president of Oracle's Java platform group, more frequent LTS releases will enable businesses that only want to utilize the LTS releases to obtain new features more quickly. In 2023, Java 21 will be the next Long Term Support release. With JDK 17, Oracle will grant unrestricted usage of Oracle JDK binaries in production for three years, one year beyond the following LTS. However, a subscription for enterprise production support is not included in that.

Tens of millions of productions JVMs represented by the client base of application monitoring company New Relic's data reveal that LTS releases are almost universally deployed. According to data from New Relic, the two most recent LTS editions, JDK 11 or JDK 8, are being used by almost all customers. According to New Relic, 90% were using JDK 11 and 10% JDK 8.

Oracle claimed that downloads of the six-month releases have been rising steadily, though. While businesses prefer to deploy the LTS releases, developers enjoy testing out the six-month releases.

Restore Always-Strict Floating-Point Semantics:

Floating-point operations are uniformly made stringent by this JEP, mostly for scientific applications. Strict or StrictFP are the standard floating-point operations, and both ensure that calculations performed using floating-point on every platform will produce the same results.

The default behavior in Java 1.1 and earlier was strictfp. The architects changed, though, due to hardware problems, and the term strictfp was required to enable such behavior once more. As a result, this keyword is no longer necessary.

New macOS Rendering Pipeline:

Since Apple discontinued the OpenGL API, which was utilized internally by Swing GUI, in macOS 10.14, this JEP implements a Java 2D internal rendering pipeline for the operating system. With the exception of the underlying engine, the old APIs have not changed in the new version, which uses the Apple Metal API.

Enhanced Pseudo-Random Number Generators:

JEP 356 offers new interfaces and implementations for pseudo-random number generators, which are also connected to more specific use cases (PRNG).

Therefore, it's simpler to utilize several methods interchangeably, and it also provides greater support for programming that uses streams of data:

public IntStream getPseudoInts(String alg, int sizestream) {
    // returns a stream of randomly produced numbers with a size of @sizestream and a lower and upper bound of 0 and 100, respectively, according to the @alg (exclusive)
    return RandomGeneratorFactory.of(alg)
            .create()
            .ints(sizestream, 0,100);
}

From the above example, we can conclude that the older random classes used, like Java.util.Random and SplittableRandom and SecureRandom are now in the new version and are extended to the new interface known as the RandomGenerator interface.

New macOS Rendering Pipeline:

Since Apple discontinued the internal OpenGL API (in macOS 10.14), which was utilized in Swing GUI, this JEP implements a Java 2D internal rendering pipeline for macOS. Apart from the underlying engine, there were no modifications to the current APIs because the new implementation uses the Apple Metal API.

macOS/AArch64 Port:

Apple made a long-term announcement about switching their computer line from X64 to AArch64. In accordance with this JEP, the JDK can now run on platforms running macOS that use the AArch64 architecture.

Deprecate the Applet API for Removal:

Although many web browsers have already stopped supporting Java plugins, this may be disappointing for many Java developers who began their development careers using Applet APIs. Although it has been marked as deprecated since version 9, this release marked the API for removal because it was no longer necessary.

Strongly Encapsulate JDK Internals:

Due to the removal of the flag -illegal-access in JEP 403, this represents another step toward strongly encapsulating JDK internals. In the event that the flag is present, the console will send a message informing the platform that the flag has been discontinued. The platform will disregard the flag in that case.

This feature will make it impossible for JDK users to access internal APIs other than vital ones like sun.misc.Unsafe.

Context-specific deserialization filters:

Through the use of a JVM-wide filter factory that is used to choose a filter for each serialization operation, context-specific deserialization filters enable applications to set context-specific and dynamically selected deserialization filters. Oracle stated that the reason for this suggestion was that it is intrinsically harmful to deserialize untrusted data because the incoming data streams' content dictates the objects that are formed, the values of their fields, and the relationships between them. The bytes in the stream are frequently obtained from an unidentified, unreliable, or unauthenticated client. An adversary can execute code from any class with malevolent intent if the stream is well constructed.

The security of application objects, library objects, and the Java runtime may all be at risk if object formation has unintended consequences that alter the state or trigger additional actions. Preventing the deserialization of instances of any class and, subsequently, the direct or indirect execution of its methods is the key to defeating serialization assaults. With the introduction of deserialization filters in Java 9, application and library code can now evaluate incoming data streams before deserializing them. When a deserialization stream is created, this code provides validation logic as a java.io.ObjectInputFilter. However, there are drawbacks to relying on the creator of a stream to request validation specifically.

By providing a JVM-wide deserialization filter that can be adjusted via an API, system properties, or security properties, JDK Enhancement Proposal 290 attempted to solve these constraints. However, this method is not without its drawbacks, especially for complicated applications. A better strategy is to set up per-stream filters so that they don't need the involvement of each stream developer. The intended improvement ought to make it easier for developers to create and utilize the proper filters for each deserialization context and use case.

For straightforward situations, the filter factory can provide an application-wide fixed filter. Here is an illustration of a filter that accepts example classes and classes from the Java.base module while rejecting all other classes:

var filteredobject = ObjectInputFilter.Config.createFilter("examplesoffilter.*;java.base/*;!*")

Our ObjectInputFilter defines two methods. JVM-wide filter factory configuration class for setting and retrieving. A filter is returned by the function known as the filter factory, which takes two arguments: the current filter and the next filter.

/**
 * The JVM's global deserialization filter factory should be returned.
 *
 * @in response, non-null, return the JVM's global serialization filter factory.
 */
public static BinaryOperator<ObjectInputFilter> getSerialFilterFactory();

/**
 * A deserialization filter factory for the entire JVM can be set.
The filter factory is a function that takes two inputs?the current filter and the next filter?and outputs the filter that will be applied to the stream.
to set as the JVM-wide filter factory is the parameter filterFactory, which should not be null.
 */
public static void setSerialFilterFactory(BinaryOperator<ObjectInputFilter> filterFactory);

Remove the Experimental AOT and JIT Compiler:

The Ahead-Of-Time (AOT) compilation (JEP 295) and Just-In-Time (JIT) compiler from GraalVM (JEP-317), which were introduced into JDK 9 and JDK 10, respectively, as experimental features, had a significant maintenance cost.

However, they didn't have any large adoptions. This JEP removed them from the platform as a result, but developers can still utilise GraalVM to make use of them.

Sealed Classes and interfaces:

Although they were accessible in preview mode in JDK versions 15 and 16, sealed classes, a component of Project Amber, are now officially introduced in this JEP.

A sealed component's ability to be extended or implemented by other classes or interfaces is constrained by the feature. Combining the JEP 406 with another pattern-matching advancement will provide a more complex and clean inspection of the type, cast, and act code pattern.

Let us check it with an example of action how it works:

int NumberofSides(Shape Area) 
{
    return switch (Area) 
    {
        case scalentriangle st -> st.NumberOfSides();
        case Pyramid p -> p.NumberOfSides();
        case Circle ct -> ct.NumberOfSides();
        case Rectagle re -> re.NumberOfSides();
        case Square se -> se.NumberOfSides();
    };
}

The types of classes and interfaces that can extend or implement sealed classes and interfaces are limited. The proposal's objectives include enabling the author of a class or interface to control which code is in charge of implementing it, offering a more declarative way to limit the use of a superclass than access modifiers, and supporting future directions in pattern matching by laying the groundwork for the thorough analysis of patterns. This functionality aids API designers in creating more durable programming.

JEP 409's sealed classes and interfaces place limitations on which other classes or interfaces may extend or implement them.

Note: Java 15 offered a sneak peek into sealed classes and interfaces.

The classes and interfaces that can extend or implement sealed classes are specified using the permit keyword.

The ability to extend a sealed class is restricted to sealed, final, and non-sealed classes.

Classes that are sealed prevent pointless class hierarchies. But this is not the only driving force. You can offer an "escape hatch" for extension in sealed classes. This is the rationale behind the introduction of open classrooms.

package com.example.geometry;
public abstract sealed class Area
    permits scalentriangle,Pyramid,Circle,Rectangle, Square {...}
public final class scalentriangle extends Area 
{
    ...
    
}
public final class Pyramid extends Area 
{
    ...
    
}
public final class Circle extends Area 
{
    ...
    
}
public sealed class Rectangle extends Area 
{
    ...
    
}
public non-sealed class Square extends Area
{
    ...
    
}

Shape is a sealed class in the aforementioned code fragment. These classes can be extended by this class: scalentriangle, pyramid, circle, rectangle, and square.

The code designates the Square class as non-sealed and the Circle, Scalentriangle, and Pyramid classes as final.

Other classes similar to this one may be permitted by the sealed Rectangle class.

package com.example.geometry;
public abstract sealed class Area
    permits scalentriangle,Pyramid,Circle, Rectangle, Square {...}
public final class Circle extends Area {...}
public sealed class Rectangle extends Area 
permits TransparentRectangle, FilledRectangle {...}
public final class TransparentRectangle extends Rectangle {...}
public final class FilledRectangle extends Rectangle {...}
public non-sealed class Square extends Area {...}

TransparentRectangle and FilledRectangle are the two last classes in the code excerpt above. The sealed Rectangle class is extended by both classes.

A non-sealed Square class is also offered. The "escape hatch" in this case suggests unbounded subclasses.

Notably, employing a sealed class has the restriction that all permissible subclasses must be members of the same module. It should be in the same package if it is declared in an unnamed module.

Pattern Matching instanceof switch:

A sneak peek of pattern matching for switches allows the testing of switch expressions and statements against a variety of patterns, each of which has a distinct action. This makes it possible to describe sophisticated data-oriented queries clearly and securely. This feature aims to, among other things, introduce two types of patterns: guarded patterns, which allow pattern matching logic to be refined with arbitrary Boolean expressions, and parenthesized patterns, which clear up some parsing ambiguities. It also allows patterns to appear in case labels and relaxes switch's historical null hostility when desired.

The improvement of pattern matching for switch expressions and statements is another step toward pattern matching. The language becomes more expressive and less boilerplate is needed to specify those expressions.

static record Man (String name, int age, String qualification) {}

public String checkObj(Object object) {
    return switch (object) {
        case Man m -> "Name: %s, age: %s and qualification: %s".formatted(m.name(), m.age(), m.qualification());
        case Circle c -> "This is known as  circle";
        case Area a -> "It is just a Area";
        case null -> "It is null";
        default -> "It is known as object";
    };
}

public String checkArea(Area area) {
    return switch (area) {
        case Triangle tri && (tri.NumberOfSides() != 3) -> "This is a scalentriangle";
        case Circle c && (c.NumberOfSides() != 0) -> "This is a known as weird circle";
        default -> "Just a normal Area";
    };
}

Switch expression was made available as a Preview feature in Java 12. Java 14 later codified switch expression. Switch expressions can be used in statements just like any other expression and evaluate to a single value. Break statements are no longer required to avoid fall through because switch expressions support "arrow case" labels.

A switch expression can be tested using pattern matching against a variety of patterns, each of which has a distinct action.Complex data-oriented queries can be succinctly and securely expressed using pattern matching.

public void LettersSwitchPattern() {
    Status result = Status.CLOSE;
    System.out.println(
    switch (status) {
        case FIX,WIP -> 3;
        case OPEN -> 4;
        case CLOSE -> 5;
        default ->throw new IllegalStateException("Invalid result: " + result);
    }
  );
}

Instead of saving the amount of characters in a variable, the aforementioned code snippet returns it directly. Additionally, there are no break statements in the code sample to avoid fall through. Break statements are prone to mistakes and are simple to overlook, thus this change was much-needed.

Rendering pipelines from macos:

The Java 2D API is used for rendering by the Swing APIs. Until Java 17, OpenGL APIs are used for rendering in MacOS. You can use the brand-new Apple Metal accelerated rendering API for macOS with Java 17.

Right now, this is, by default, disabled. Therefore, rendering continues to use OpenGL APIs, which are still readily available despite Apple's deprecation.

Set this system property to true to activate Metal.

-Dsun.java2d.metal=true

Your code won't be impacted as a coder. This is due to the fact that OpenGL or Metal are transparent to apps. The Java APIs are unaffected because there is only a difference in internal implementation.

For the metal pipeline, macOS 10.14.x or later is required. The pipeline will not be configured for earlier Operating System releases.

Remove the Experimental AOT and JIT Compiler:

However, there were no notable adoptions made by them. This JEP removed them from the platform as a result. However, developers can still make use of them by utilizing GraalVM.

Deprecate the Security Manager for Removal:

Another feature that has been flagged for removal since it is no longer necessary is the security manager, which was created to safeguard client-side Java programmes.

Strong encapsulation:

JDK internals are strongly encapsulated, with the exception of crucial internal APIs like sun.misc. Unsafe, would prevent the strong encapsulation of internal parts from being relaxed through a single command-line option, as was permitted in JDK 9 through JDK 16. The initiative aims to make the JDK more secure and maintainable while encouraging developers to switch from internal components to standard APIs.

Enhanced pseudo-random number generators:

Pseudo-random number generators (PRNGs) that are improved to offer new interface types and implementations, such as jumpable PRNGs and an extra class of splittable PRNG algorithms (LXM). All current and future PRNGs would have a standardized API provided by a new interface called RandomGenerator. There would be four unique RandomGenerator interfaces available. A focus on numerous areas for development in Java's pseudorandom number generation is what inspired the concept. It is not necessary to provide implementations for many different PRNG algorithms in this endeavour. However, three typical algorithms that are already commonly used in other programming language settings have been added.

Making it simpler for apps to interchange different PRNG algorithms is one of the plan's objectives.
Streams of PRNG objects are provided, improving support for stream-based programming.
removing redundant code from current PRNG classes.
Preservation of the class java.util.current Random's behavior

Accessing the large icons:

The Swing library now has access to a new API in Java 17 for big icons.

JDK 17 adds a new method called javax.swing.filechooser.FileSystemView.getSystemIcon(File, int, int). Access to better-looking icons is made possible by this technique.

The Windows platform has a full implementation. Results on other platforms, however, could be different, and improvements will come later.

Here is one illustration:

FileSystemView iconicview = FileSystemView.getFileSystemView();
  Icon image = iconicview.getSystemIcon(new File("appli.exe"), 64, 64);
  JLabel label = new JLabel(image);

The ability to obtain a better-quality icon for an application executable (exe) file is a frequent use case for this functionality. This icon is appropriate for designing a label that can be scaled more effectively in a high DPI setting.

LTS definition:

Changes aren't limited to the code; processes are also evolving.

It is well known that Java platform releases have a history of being lengthy and inaccurate. Although it was intended for releases to occur every three years, the procedure frequently took four years to complete. The team in charge of the platform's evolution also chose to alter the release cadence in order to accommodate the current market dynamics, where innovation and prompt action have become essential.

Since Java 10, a new six-month feature-release model has been implemented as a result (released on March 20, 2018).

Feature release model in six-month:

The platform developers are free to deploy features when they are prepared thanks to the new six-month feature-release strategy. As a result, there is no longer any urgency to rush the feature into the release. To make the capability available to platform users, they would otherwise have to wait three to four years.

The feedback loop between users and the platform's architects is also improved by the new paradigm. This is so that features can be made available while still in the incubation stage and only become generally usable after a number of interactions.

LTS model:

Java is frequently used in enterprise applications; therefore, stability is important. Additionally, maintaining support for all of these versions and offering patch updates is expensive.

The Long-Term Support (LTS) versions were developed. As a result, giving users more support. As a result of bug corrections, performance upgrades, and security patches, these versions inevitably grow more reliably and securely. This support typically lasts for eight years in the case of Oracle.

Java SE 11 (issued in September 2018) and Java SE 17 were the LTS versions following the introduction of the modifications to the release model (released in September 2021). However, the model added something new in version 17. In other words, instead of three years, there are now two years between LTS versions, making Java 21 (scheduled for September 2023) the likely candidate for the following LTS.

It's also important to note that this release model is not brand-new. It was blatantly lifted and modified from other projects where the model had already proven itself, like Mozilla Firefox, Ubuntu, and others.

Foreign Function and Memory API

Java programmers can access code from outside the JVM and control memory outside of the heap thanks to the Foreign Function and Memory API. The intention is to replace the JNI API and enhance its performance and security over the previous version.

This API is yet another function created by Project Panama, and JEPs 393-389-383-370 evolved and replaced it.

private static final SymbolLookup libLookup;

static {
    // c library associated with it is loaded
    var link = JEP412.class.getResource("/print_names.so").getPath();
    System.load(link);
    libLookup = SymbolLookup.loaderLookup();
}

The target library that we want to use to call the API must first be loaded.

The destination method's signature must then be specified before we can finally call it:

public String getNameFormat(String name) {

    var priMethod = libLookup.lookup("Name");

    if (priMethod.isPresent()) {
        var methodReference = CLinker.getInstance()
            .downcallHandle(
                priMethod.get(),
                MethodType.methodType(MemoryAddress.class, MemoryAddress.class),
                FunctionDescriptor.of(CLinker.C_POINTER, CLinker.C_POINTER)
            );

        try {
            var nativeString = CLinker.toCString(name, newImplicitScope());
            var invokeReturn = methodReference.invoke(nativeString.address());
            var memoryAddress = (MemoryAddress) invokeReturn;
            return CLinker.toJavaString(memoryAddress);
        } catch (Throwable throwable) {
            throw new RuntimeException(throwable);
        }
    }
    throw new RuntimeException("Name not found in the function");
}

Java programmes may interact with code and data outside of the Java runtime thanks to the external function and memory API, which was introduced when Java was still in its incubator stage. The API enables Java programs to call native libraries and handle native data without the brittleness and risk of JNI by effectively executing foreign functions, i.e., code outside the JVM, and safely accessing foreign memory, i.e., memory not maintained by the JVM (Java Native Interface). The API that is being suggested is the development of two other APIs, the foreign memory access API and the foreign linker API.

The foreign memory access API was designed as an incubating API for Java 14 in 2019 and was re-incubated for Java 15 and Java 16. The external linker API was intended to be a developing API for Java 16 in late 2020. The API plan seeks to achieve performance, generality, usability, and safety.

Vector API:

The platform-neutral vector API, which was implemented as an incubating API in JDK 16 and will be reincubated in JDK 17, offers a way to define vector computations that will consistently compile at runtime to the best possible vector instructions on supported CPU architectures. Performance is improved over comparable scalar computations thanks to this. JDK 17 includes speed and implementation improvements to the vector API, as well as improvements to convert byte vectors into and out of boolean arrays.

The SIMD (Single Instruction, Multiple Data) procedures, which involve multiple sets of instructions being executed concurrently, are what the Vector API works with. It makes use of specialized CPU hardware that enables the execution of such instructions as pipelines and supports vector instructions.

By utilizing the capability of the underlying hardware, the new API will permit developers to design more effective code.

Applications that need to apply an operation to numerous independent operands frequently include image processing, character processing, intensive arithmetic applications, and linear applications of scientific algebra.

The features which are Removed are:

The following are the two crucial aspects that were eliminated that are important to application developers:

Strongly Encapsulate JDK Internals: JDK has internal APIs that aren't meant to be used by outside parties. However, throughout time, the JDK's underlying components have been used by creators of a variety of libraries, frameworks, tools, and software programmes. Security and maintainability may be jeopardised as a result. Ones of these APIs is:

a few of the Java.* packages' private classes, methods, and fields.
The fields, classes, and methods of all sun.* package types.

The majority of the org.*, jdk.*, and com.sun.* package classes, methods, and fields.
RMI Activation is no longer used as a component of RMI: Since Java 8, it is an optional feature. Due to the fact that web technology currently underpins dispersed systems, this has been done. There is evidence that just a small number of currently available applications use RMI Activation. In addition, keeping RMI Activation up and running is complicated and expensive.

New Release Process:

This article is based on the JEP 3 because it covers all process changes. Here, we'll make an effort to summarise it succinctly.

Given the new architecture mentioned above, the platform's ongoing development, and the new six-month release cycles (typically June and December), Java will advance more quickly. Following the procedure outlined below, the JDK development team will start the release cycle for the upcoming feature release.

The main line's fork is where the process starts. Then, JDK/JDK$N is used as a stabilization repository to continue development (for example, JDK17). The development there keeps concentrating on stabilizing the release.

Let's define a few terms before we continue with the process:

Bugs: This term refers to duties or tickets:
Current: These are either fixes for newly added features that are already present in this version or genuine bugs linked to the current version (the one that is about to be released) (new JEPs).
Targeted: Associated with previous iterations and slated for improvement or resolution in this new iteration
Priorities: Ranging from P1 to P5, with P1 being the most significant and P5 having the least significant importance.
New Format:
At the present time, no new JEPs of new JEPs are added to the JDK/JDK$N repository, which functions like a release branch.
Following stabilization, the developments in this repository will be moved to the mainline, where new developments will continue.
Approximately four to five weeks are spent in Ramp Down Phase 1 (RDP 1). Developers abandon the targeted P1-P3 and all currents P4-P5 (depending on deferring, fixing or enhancement). Therefore, P5+ test/docs bugs and focused P3+ code issues are not required.
Phase 2 of the ramp-down process (RDP 2) lasts three to four weeks. They are currently delaying the current P3-P5 and the targeted P1-P3 (depending on deferring, fix or enhancement).

What's next?

JDK architects are still working on numerous initiatives aimed at updating the platform. Better developer tools and faster, more reliable APIs are the main objectives.

The JDK 18 should therefore be available in six months, even though it is unlikely to have any large or disruptive modifications. The official OpenJDK project portal has a list of suggested JEPs aimed at this version that we can monitor.

Conclusion

In this article, we discussed the news regarding the new Java 17 version, going over its most recent improvements, new features, definition of support, and release cycle procedure.

Next TopicHow to Find the Java Version in Linux

← prev next →