Page 2: Additions for concurrent programs

Java 21 brought significant innovations for concurrent programming in Project Loom. Two of these still have preview status in JDK 23. Loom means loom, i.e. the tool for weaving the threads together to form a large whole.

Structured Concurrency helps to manage tasks from different threads in one unit to improve the maintainability and reliability of concurrent code. It was originally included as JEP 428 in JDK 19 in the incubator –, an experimental stage before the preview –, where it remained as JEP 437 in Java 20. It was not until Java 21 that the concept reached the preview phase in JEP 453 and is now moving to the third preview as "JEP 480: Structured Concurrency" without any changes.

JEP 481: Scoped Values" also enters the third preview and brings a minimal change for exception handling in ScopedValue.callWhere.

Scoped values, which were introduced in OpenJDK 20 as JEP 429 in the incubator, are a concept for exchanging immutable values within and between threads. They are a more efficient alternative to ThreadLocal variables. Like these, the values only apply to the respective thread. The same ScopedValue can take on different values in different threads. In this context, scope is not the lexical scope of a class or function, as is usually the case in Java, but a dynamic scope that the runtime specifies by binding the value.

CPU architecture in view

The Vector API has still not made it into the preview phase, but has now reached its eighth run in the incubator in JDK 23. It will remain there until the required features in Project Valhalla for Value and Primitive Types reach preview status. "JEP 469: Vector API" is used to utilize current CPU architectures and instruction extensions such as Single Instruction Multiple Data (SIMD) and vector processors for vector calculation.

Documentation and garbage collector

Beyond the language and libraries, there are two further additions to Java 23: "JEP 467: Markdown Documentation Comments" is included in Java 23 without an incubator or preview phase. It makes it possible to write Java Doc comments in Markdown instead of using the usual mixture of HTML and JavaDoc tags. JavaDoc inline tags such as @see or @return are still allowed. The proposal shows a comparison between a conventional and a Markdown comment using the example of the JavaDoc comment for java.lang.Object.hashCode:

// Klassische Variante:

/**
 * Returns a hash code value for the object. This method is
 * supported for the benefit of hash tables such as those provided by
 * {@link java.util.HashMap}.
 * <p>
 * The general contract of {@code hashCode} is:
 * <ul>
 * <li>Whenever it is invoked on the same object more than once during
 *     an execution of a Java application, the {@code hashCode} method
 *     must consistently return the same integer, provided no information
 *     used in {@code equals} comparisons on the object is modified.
 *     This integer need not remain consistent from one execution of an
 *     application to another execution of the same application.
 * ...
 * </ul>
 *
 * @implSpec
 * As far as is reasonably practical, the {@code hashCode} method defined
 * by class {@code Object} returns distinct integers for distinct objects.
 *
 * @return  a hash code value for this object.
 * @see     java.lang.Object#equals(java.lang.Object)
 * @see     java.lang.System#identityHashCode
 */
 
// Markdown-Variante:

/// Returns a hash code value for the object. This method is
/// supported for the benefit of hash tables such as those provided by
/// [java.util.HashMap].
///
/// The general contract of `hashCode` is:
///
///   - Whenever it is invoked on the same object more than once during
///     an execution of a Java application, the `hashCode` method
///     must consistently return the same integer, provided no information
///     used in `equals` comparisons on the object is modified.
///     This integer need not remain consistent from one execution of an
///     application to another execution of the same application.
/// ...
///
/// @implSpec
/// As far as is reasonably practical, the `hashCode` method defined
/// by class `Object` returns distinct integers for distinct objects.
///
/// @return  a hash code value for this object.
/// @see     java.lang.Object#equals(java.lang.Object)
/// @see     java.lang.System#identityHashCode

Java 21 introduced the "generational mode" for the ZGC garbage collector, which managed different spaces: a "young space" for new objects and an "old space" for old objects. This mode was initially considered experimental and required manual activation via a command line parameter. With "JEP 474: ZGC: Generational Mode by Default", the generational mode is now the standard procedure, and the non-generational mode is to disappear completely in future releases.

No more old-fashioned memory access

Finally, "JEP 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal" cuts out old habits: Access via the methods in sun.misc.Unsafe are considered outdated (deprecated) and should disappear in future releases. Instead, applications and especially libraries should use the methods in the VarHandle API and the Foreign Function & Memory API finalized in Java 22.

Break for string templates

It is worth mentioning that the string templates, which were included in Java 22 as a second preview, are not to be found in Java 23. They are intended to supplement string literals and text blocks and enable the interpolation of strings. Shortly after the release of Java 22, however, the decision was made to pause the proposal for now, as the design was to change significantly. Originally planned as the third preview in OpenJDK 23, "JEP 465: String Templates", originally planned as the third preview in OpenJDK 23, has therefore been withdrawn.

Java 23 replaces Java 22, as the official support for the regular JDK releases runs until the release of the successor – The successor Java 24, which will end support for Java 23, is expected in March. For Java 21, there are LTS releases designed for longer use: Oracle offers support for five years and extended support for eight years. Adoptium guarantees at least four years of support for the LTS releases. As the providers bring out LTS releases every two years, Java 25, scheduled for September 2025, will be the next Java release for which extensive long-term support can be expected.

(rme)