Java 22's New Features and Security Enhancements
Java Development Kit 22 – the next major version of Java Standard Edition – is now fully available as a production release! The newest version includes 12 features and major security enhancements.
You are able to download it from oracle.com right now. This version is a short-term release that will receive Premier Support from Oracle for six months. Long-term support releases such as predecessor Java Development Kit (JDK) 21 will still receive five years of Premier Support. Extended support will remain available for JDK 21 until September 2031.
Want to learn more about programming languages like Java here? We have a small introduction article into programming languages that we recommend you take a look at also along with reading more of this article!
Vhirsion
The New Features
The latest version now offers capabilities from development projects including Amber – which develops smaller, productivity-oriented Java language features; Loom – which develops Java virtual machine features and APIs; and Panama, which develops interconnections between Java and non-Java APIs.
Scoped values enable the safe and efficient sharing of immutable data within and across threads. This is preferred to thread-local variables – especially when using large numbers of thread variables. The main goals are for the ease of use, comprehensibility, robustness, and performance.
Stream gatherers will enhance the stream API to support custom intermediate operations. This preview feature will allow stream pipelines to transform data in ways not easily achievable with existing built-in intermediate operations.
These latest features join a second preview of structured concurrency, a preview of statements before super(…), a preview of a class-file API, region pinning for the G1 garbage collector, a second preview of string templates, unnamed variables and patterns, a foreign function and memory API, and a seventh incubator of a vector API. A second preview of implicitly declared classes and instance main methods, and an enhancement to the Java launcher that would enable it to run multi-file programs, also have been proposed.
With structured concurrency, from Project Loom, concurrent programming is simplified through an API that treats groups of related tasks running in different threads as a single unit of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability.
The enhancement to the Java application launcher will allow it to run a program supplied as multiple files of Java source code. The goal behind the ability to launch multi-file source code programs is to make the transition from small programs to larger programs more gradual, allowing developers to choose whether and when to go to the trouble of configuring a build tool.
// file MainApplication.java
public class MainApplication {
public static void main(String[] args) {
Person p = new Person("Exiled", "Tech");
System.out.println("Hello there! " + p.toString() + "!");
}
}
// file Person.java
record Person(String fName, String lName) {
public String toString(){
return fName + " " + lName;
}
}
$ java MainApplication.java
Hello there! Exiled Tech!
The class-file API will provide a standard API for parsing, generating, and transforming Java class files. It is intended to enable JDK components to migrate to the standard API and eventually remove the JDK’s internal copy of the third-party ASM library. Parsing, generating, and transforming class files is ubiquitous, used by independent tools and libraries to examine and extend programs without jeopardizing maintainability of source code.
However, the Java class-file format evolves more quickly now than previously, due to standard Java’s six-month release cadence. This speed of evolution has resulted in frameworks more frequently encountering class files that are newer than the class-file library. This has resulted in errors and in framework developers trying to write code to parse class files from the future and hoping nothing too serious will change. The plan is to have the Java platform define and implement a standard class-file API to evolve together with the class-file format.
Region pinning for G1 is intended to reduce latency, so that garbage collection (GC) need not be disabled during Java Native Interface (JNI) critical regions. Goals include no stalling of threads due to critical JNI regions, no added latency to start garbage collection due to these regions, no regressions in GC pause times when none of these regions are active, and minimal regressions in GC pause times when these regions are active. Currently, the default GC, G1, disables garbage collection during every critical region, which can have a significant impact on latency. With this change, Java threads will never wait for a G1 GC operation to complete.
Implicitly declared classes and instance methods, from Project Amber, was previewed in JDK 21 as unnamed classes and instance methods. This feature would get the revised title and significant changes in JDK 22 in a second preview. The capability is intended to evolve the Java language so students could write their first programs without needing to understand language features designed for large programs. Students could write streamlined declarations for single-class programs and then seamlessly expand programs to use more advanced features as their skills grow.
void main(){
System.out.println("Hello World!");
}
The Preview Features
The preview of statements before super(…), also from Project Amber, pertains to constructors in the language, allowing statements that do not reference the instance being created to appear before an explicit constructor. A goal of the plan includes giving developers greater freedom to express the behavior of constructors, enabling more natural placement of logic that currently must be factored into auxiliary static methods, auxiliary intermediate constructors, or constructor arguments.
public class PositiveBigInteger extends BigInteger {
public PositiveBigInteger(long value) {
if (value <= 0)
throw new IllegalArgumentException("non-positive value");
super(value);
}
}
Another goal is preserving the existing guarantee that constructors run in top-down order during class instantiation, ensuring that code in a subclass constructor cannot interfere with superclass instantiation. A third stated goal is not requiring any changes to the JVM. This is the only JDK 22 feature, so far, that has not yet been previously previewed or incubated in standard Java.
String templates, another feature from Project Amber, will complement Java’s existing string literals and text blocks by coupling literal text with embedded expressions and template processors to produce specialized results. Goals include:
- Simplifying the writing of Java programs by making it easy to express strings that include values computed at run time.
- Enhancing the readability of expressions that mix text and expressions, whether the text fits on a single source line or spans several source lines.
- Improving security of programs that compose strings from user-provided values and pass them to other systems by supporting validation and transformation of both the template and the values of its embedded expressions.
- Retaining flexibility by allowing Java libraries to define the formatting syntax used in string templates.
- Simplifying the use of APIs that accept strings written in non-Java languages, such as XML and JSON.
- Enabling creation of non-string values computed from literal text and embedded expressions without needing to transit through an intermediate string representation.
String templates appeared in a first preview in JDK 21. The second preview is intended to gain additional experience and feedback. Except for a technical change in the types of template expressions, there are no changes relative to the first preview.
A vector API (seventh incubator), from Project Panama, would express vector computations that reliably compile at runtime to optimal vector instructions on supported CPU architectures, achieving performance superior to equivalent scalar computations. The API provides a way to write complex vector algorithms in Java, using the existing HotSpot auto-vectorization algorithm but with a user model that makes vectorization more predictable and robust.
This capability has been incubated in prior versions of Java dating back to JDK 16 in March 2021. Goals of the API include it being clear and concise, platform-agnostic, and offering reliable runtime compilation and performance on x64 AArch64 architectures as well as graceful degradation.
Unnamed variables and patterns, from Project Amber, can be used when variable declarations or nested patterns are required but never used. Goals of the plan include:
- Capturing developer intent that a given binding or lambda parameter is unused, and enforcing that property to clarify programs and reduce opportunities for error
- Improving code maintainability by identifying variables that must be declared but are not used
- Allowing multiple patterns to appear in a single case label, provided that none of them declares pattern variables
- Improving the readability of record patterns by eliding unnecessary nested type patterns
This proposal was previewed in JDK 21 and will be finalized without change in JDK 22.
The foreign function and memory API, from Project Panama, allows Java programs to interoperate with code and data outside of the Java runtime. By invoking foreign functions and safely accessing foreign memory, Java programs can call native libraries and process native data without the brittleness of JNI (Java Native Interface), the proposal states.
The foreign function and memory API previously was previewed in JDK 19, JDK 20, and JDK 21. It would be finalized in JDK 22. The latest revisions cover four areas: supporting arbitrary charsets for native strings, enabling clients to build C-language function descriptors programmatically, and introducing the Enable-Native-Access JAR-file manifest attribute. The latter allows executable JAR files to call restricted methods without having to use the —enable-native-access command-line option. The fourth area is providing a new linker option that allows clients to pass heap segments to downcall method handles.
The Security Enhancements
In a March 20 blog post on Oracle’s inside.java web page, Sean Mullan, technical lead of the Java Security libraries team and lead of the OpenJDK Security Group, detailed the security enhancements in JDK 22.
The java -Xshowsettings option, which can be used to print system settings and other useful information about the current JDK configuration, has been enhanced to show details about security-related settings. -Xshowsettings:security will show all security settings. Sub-options allow you to display the values of security properties, the installed security providers and their supported algorithms, or the enabled TLS protocols and cipher suites.
For cryptography, a new standard interface, java.security.AsymmetricKey, has been added. It is a sub interface of java.security.key and represents an asymmetric key, which can either be private or public. Existing java.security.PublicKey and java.security.PrivateKey classes have been retrofitted to be sub interfaces of AsymmetricKey. As future asymmetric algorithms are introduced, the AsymmetricKey interface will allow earlier versions of Java SE to more easily support new asymmetric algorithms representing parameters as a NamedParameterSpec, Mullan said.
Also, the jdk.crytpo.ec module has been deprecated, with the intent to eventually remove it. All code from the jdk.crytp.ec module has been moved to the java.base module, including the SunEC security provider. The jdk.crypto.ec module is now empty but still exists. This change will make it easier to deploy applications depending on elliptic curve cryptographic algorithms.
For PKI (public key infrastructure), 10 new root CA certificates have been added to the cacerts keystore, including three eMudhra Technologies root CA certificates, four DigiCert root CA certificates, and one each from Let’s Encrypt, Telia, and Certigna.
For Transport Layer Security (TLS), additional properties were added to control the maximum length of client and server certificate chains. And for XML signatures, the JDK implementation now supports XML signatures signed with RSA signature algorithms with SHA-3 digests.
JDK 22 extends functionality for JCE (Java Cryptography Extension) support for the HSS/LMS signature algorithm, adding HSS/LMS support to jarsigner and keytool utilities. Also, jarsigner now supports signing and verifying JAR files with the HSS/LMS algorithm while keytool now supports generation of HSS/LMS public key pairs. However, JDK only supports HSS/LMS signature verification. Developers will need a third-party provider to sign JAR files with HSS/LMS.
Do you like what you're reading from the CoderOasis Technology Blog? We recommend reading our Implementing RSA in Python from Scratch as your next choice.
ExiledTech
The CoderOasis Community
Did you know we have a Community Forums and Discord Server? which we invite everyone to join us? Want to discuss this article with other members of our community? Want to join a laid back place to chill and discuss topics like programming, cybersecurity, web development, and Linux? Consider joining us today!
Comments ()