Migrating to Red Hat build of OpenJDK 21 from earlier versions

OpenJDK is the free and open source reference implementation of the Java Platform, Standard Edition (Java SE). Red Hat build of OpenJDK distributions are based on the upstream OpenJDK 8u, OpenJDK 11u, OpenJDK 17u, and OpenJDK 21u projects. The Shenandoah Garbage Collector is included in all supported versions of Red Hat build of OpenJDK.

All versions of Red Hat build of OpenJDK provide the following benefits:

Certain minor cryptography and security differences exist between Red Hat build of OpenJDK 8 and Red Hat build of OpenJDK 11. However, both versions of Red Hat build of OpenJDK have many similar cryptography and security behaviors.

Red Hat builds of OpenJDK use system-wide certificates, and each build obtains its list of disabled cryptographic algorithms from a system’s global configuration settings. These settings are common to all versions of Red Hat build of OpenJDK, so you can easily change from Red Hat build of OpenJDK 8 to Red Hat build of OpenJDK 11 or later.

In FIPS mode, Red Hat build of OpenJDK 8 and Red Hat build of OpenJDK 11 releases are self-configured, so that either release uses the same security providers at startup.

The TLS stacks in Red Hat build of OpenJDK 8 and Red Hat build of OpenJDK 11 are identical, because the SunJSSE engine from Red Hat build of OpenJDK 11 was backported to Red Hat build of OpenJDK 8. Both Red Hat build of OpenJDK versions support the TLS 1.3 protocol.

The following minor cryptography and security differences exist between Red Hat build of OpenJDK 8 and Red Hat build of OpenJDK 11:

For garbage collection, Red Hat build of OpenJDK 8 uses the Parallel collector by default, whereas Red Hat build of OpenJDK 11 uses the Garbage-First (G1) collector by default.

Before you choose a garbage collector, consider the following details:

You can select the garbage collector type that you want to use by specifying the ‑XX:+<gc_type> JVM option at startup. For example, the ‑XX:+UseParallelGC option switches to the Parallel collector.

Red Hat build of OpenJDK 11 includes a new and more powerful logging framework that works more effectively than the old logging framework. Red Hat build of OpenJDK 11 also includes unified JVM logging options and unified GC logging options.

The logging system for Red Hat build of OpenJDK 11 activates the -XX:+PrintGCTimeStamps and -XX:+PrintGCDateStamps options by default. Because the logging format in Red Hat build of OpenJDK 11 is different from Red Hat build of OpenJDK 8, you might need to update any of your code that parses garbage collector logs.

The following table outlines the changes in garbage collector logging options between Red Hat build of OpenJDK versions 8 and 11:

When using the -XX:+PrintGCDetails option, pass the -Xlog:gc* flag, where the asterisk (*) activates more detailed logging. Alternatively, you can pass the -Xlog:gc+$tags flag.

When using the -Xloggc option, append the :file=$FILE suffix to redirect log output to the specified file. For example -Xlog:gc:file=$FILE.

Red Hat build of OpenJDK 11 also removes the following options because the printing of timestamps and datestamps is automatically enabled:

Before version 8u252, Red Hat build of OpenJDK 8 used Pisces as the default rendering engine. From version 8u252 onward, Red Hat build of OpenJDK 8 uses Marlin as the new default rendering engine. Red Hat build of OpenJDK 11 and later releases also use Marlin by default. Marlin improves the handling of intensive application graphics.

Because the rendering engines produce the same results, users should not observe any changes apart from improved performance.

You can use Java WebStart by using the IcedTea-Web plug-in with Red Hat build of OpenJDK 8 or Red Hat build of OpenJDK 11 on RHEL 7, RHEL 8, and Microsoft Windows operating systems. The IcedTea-Web plug-in requires that Red Hat build of OpenJDK 8 is installed as a dependency on the system.

Applets are not supported on any version of Red Hat build of OpenJDK. Even though some applets can be run on RHEL 7 by using the IcedTea-web plug-in with OpenJDK 8 on a Netscape Plugin Application Programming Interface (NPAPI) browser, Red Hat build of OpenJDK does not support this behavior.

The Java Platform Module System (JPMS), which was introduced in OpenJDK 9, limits or prevents access to non-public APIs. JPMS also impacts how you can start and compile your Java application (for example, whether you use a class path or a module path).

For example:

--add-opens java.base/jdk.internal.math=ALL-UNNAMED

Additionally, you can check illegal access cases by passing the ‑‑illegal-access=warn option to the java command. This option changes the default behavior of Red Hat build of OpenJDK.

In Red Hat build of OpenJDK 11, the system class loader is no longer an instance of URLClassLoader. Existing application code that invokes ClassLoader::getSystemClassLoader and casts the result to a URLClassLoader in Red Hat build of OpenJDK 11 will result in a runtime exception.

In Red Hat build of OpenJDK 8, when you create a class loader, you can pass null as the parent of this class loader instance. However, in Red Hat build of OpenJDK 11, applications that pass null as the parent of a class loader might prevent the class loader from locating platform classes.

Red Hat build of OpenJDK 11 includes a new class loader that can control the loading of certain classes. This improves the way that a class loader can locate all of its required classes. In Red Hat build of OpenJDK 11, when you create a class loader instance, you can set the platform class loader as its parent by using the ClassLoader.getPlatformClassLoader() API.

In Red Hat build of OpenJDK 11, both the extension mechanism, which supported optional packages, and the endorsed standards override mechanism are no longer available.

These changes mean that any libraries that are added to the <JAVA_HOME>/lib/ext or <JAVA_HOME>/lib/endorsed directory are no longer used, and Red Hat build of OpenJDK 11 generates an error if these directories exist.

JDK Flight Recorder (JFR) support was backported to Red Hat build of OpenJDK 8 starting from version 8u262. JFR support was subsequently enabled by default from Red Hat build of OpenJDK 8u272 onward.

JDK Mission Control, which is distributed separately, was also updated to be compatible with Red Hat build of OpenJDK 8.

To aid this effort, Red Hat has developed a special compatibility layer that provides an empty implementation of JFR, which behaves as if JFR was disabled at runtime. For more information about the JFR compatibility API, see openjdk8-jfr-compat. You can install the resulting .jar file in the jre/lib/ext directory of an OpenJDK 8 distribution.

Some applications might need to be updated if these applications were filtering out OpenJDK 8 by checking only for the version number instead of querying the MBeans interface.

All Red Hat build of OpenJDK versions for RHEL platforms are separated into the following types of packages. The following list of package types is sorted in order of minimality, starting with the most minimal.

Red Hat build of OpenJDK versions for Windows platforms do not support headless packages. However, the Red Hat build of OpenJDK packages for Windows platforms are also divided into JRE and JDK components, similar to the packages for RHEL platforms.

OpenJDK 9 introduced a modularised version of the JDK class libraries divided by their namespaces. From Red Hat build of OpenJDK 11 onward, these libraries are packaged into jmods modules. For more information, see Jmods.

OpenJDK 9 introduced jmods, which is a modularized version of the JDK class libraries, where each module groups classes from a set of related packages. You can use the jlink tool to create derivative runtimes that include only some subset of the modules that are needed to run selected applications.

From Red Hat build of OpenJDK 11 onward, Red Hat build of OpenJDK versions for RHEL platforms place the jmods files into a separate RPM package that is not installed by default. If you want to create standalone OpenJDK images for your applications by using jlink, you must manually install the jmods package (for example, java-11-openjdk-jmods).

Red Hat build of OpenJDK 11 has either deprecated or removed some features that Red Hat build of OpenJDK 8 supports.

Red Hat build of OpenJDK 17 no longer includes the Concurrent Mark Sweep (CMS) garbage collector, which was commonly used in earlier releases for workloads sensitive to pause times and latency.

If you have been using the CMS collector, switch to one of the following collectors based on your workload before migrating to Red Hat build of OpenJDK 17 or later.

For more information, see JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector.

Red Hat build of OpenJDK 17 no longer includes any of the following features:

The use of these tools and APIs has been limited since the introduction of the JMOD module format in OpenJDK 9.

For more information, see JEP 367: Remove the Pack200 Tools and API.

Red Hat build of OpenJDK 17 no longer includes any of the following features:

The scripting API, javax.script, is still available in Red Hat build of OpenJDK 17 or later. Similar to releases before OpenJDK 8, you can use the javax.script API with a JavaScript engine of your choice, such as Rhino or the now externally maintained Nashorn JavaScript engine.

For more information, see JEP 372: Remove the Nashorn JavaScript Engine.

Red Hat build of OpenJDK 17 introduces strong encapsulation of all internal elements of the JDK, apart from critical internal APIs such as sun.misc.Unsafe. From Red Hat build of OpenJDK 17 onward, you cannot relax the strong encapsulation of internal elements by using a single command-line option. This means that Red Hat build of OpenJDK 17 and later versions prevent reflective access to JDK internal types apart from critical internal APIs.

For more information, see JEP 403: Strongly Encapsulate JDK Internals.

Red Hat build of OpenJDK 17 disables biased locking by default. In Red Hat build of OpenJDK 17, you can enable biased locking by setting the -XX:+UseBiasedLocking JVM option at startup. However, the -XX:+UseBiasedLocking option is deprecated in Red Hat build of OpenJDK 17 and planned for removal in OpenJDK 18.

For more information, see JEP 374: Deprecate and Disable Biased Locking.

Red Hat build of OpenJDK 17 removes the java.rmi.activation package and its associated rmid activation daemon for Java remote method invocation (RMI). Other RMI features are still available in Red Hat build of OpenJDK 17 and later versions.

For more information, see JEP 407: Remove RMI Activation.

Red Hat build of OpenJDK 17 removes the Graal compiler, which comprises the jaotc tool and the jdk.internal.vm.compiler and jdk.internal.vm.compiler.management modules. From Red Hat build of OpenJDK 17 onward, if you want to use ahead-of-time (AOT) compilation, you can use GraalVM.

For more information, see JEP 410: Remove the Experimental AOT and JIT Compiler.

From Red Hat build of OpenJDK 21 onward, UTF-8 is the default character set when using the APIs for reading and writing files and for processing text. In earlier releases, if no character set was passed as an argument, the character set was based on the runtime environment and depended on the specific method being called. To ensure that your applications are not expecting a different character encoding, review your application source code and environment.

For more information, see JEP 400: UTF-8 by Default.

Red Hat build of OpenJDK 21 extends the Z Garbage Collector (ZGC) to maintain separate allocation regions (that is, generations) for young and old objects. This enhancement allows ZGC to collect young objects more frequently, which helps to improve application performance.

You can enable generational ZGC by specifying the -XX:+UseZGC and -XX:+ZGenerational JVM options at startup.

For more information, see JEP 439: Generational ZGC.

Red Hat build of OpenJDK 21 issues warnings when agents are loaded dynamically into a running JVM. The dynamic loading of agents will be disallowed by default in a future release. If your applications currently rely on the dynamic loading of agents into the JVM, consider updating your application code to use a different approach.

For more information, see JEP 451: Prepare to Disallow the Dynamic Loading of Agents.

Red Hat build of OpenJDK 21 deprecates the finalization feature, which is used for performing cleanup operations before an object is destroyed. The finalization feature is planned to be removed in a future release.

Red Hat build of OpenJDK 21 still enables finalization by default. To facilitate early testing, you can disable finalization by setting the --finalization=disabled command-line option.

If you are maintaining libraries and applications that rely on finalization, consider migrating to other resource management techniques, such as cleaners or the try-with-resources statement. Due to this change, maintainers of libraries and applications are advised to test their code as soon as possible.

For more information, see JEP 421: Deprecate Finalization for Removal.

Red Hat build of OpenJDK 21 includes a service provider interface (SPI) for host name and address resolution that supports the use of different resolver providers. From Red Hat build of OpenJDK 21 onward, the InetAddress API uses a service loader to locate a resolver provider. Similar to previous releases, if no provider is found, the JDK uses the built-in implementation.

For more information, see JEP 418: Internet-Address Resolution SPI.

Red Hat build of OpenJDK 21 includes a jwebserver command-line tool that you can use to start a simple web server. The aim of this feature is to support prototyping, ad-hoc coding, and testing, especially for an educational purpose.

The jwebserver tool supports the HTTP 1.1 protocol and serves static files only. The simple web server does not support the secure HTTPS protocol and is not suitable for production services.

To run the simple web server, you can use the following command:

$ jwebserver

By default, files are served from the current directory. If the requested resource is a directory that contains an index file, the index file is served.

In addition to the jwebserver tool, this feature also includes an API to support enhanced request handling that can be used to return HTTP headers.

For example:

jshell> var h = HttpHandlers.handleOrElse(r -> r.getRequestMethod().equals("PUT"),
   ...> new SomePutHandler(), new SomeHandler());
jshell> var f = Filter.adaptRequest("Add Foo header", r -> r.with("Foo", List.of("Bar")));
jshell> var s = HttpServer.create(new InetSocketAddress(8080),
   ...> 10, "/", h, f);
jshell> s.start();

For more information, see JEP 408: Simple Web Server.

Red Hat build of OpenJDK 21 introduces a sequenced collections feature that adds new interfaces to represent ordered collections, where each collection has a range of elements with a well-defined encounter order. This feature unifies how each ordered collection accesses its first, last, and other specific elements.

interface SequencedCollection<E> extends Collection<E> {
    // new method
    SequencedCollection<E> reversed();
    // methods promoted from Deque
    void addFirst(E);
    void addLast(E);
    E getFirst();
    E getLast();
    E removeFirst();
    E removeLast();
}

The SequencedCollection interface is implemented by the SortedSet, NavigableSet, LInkedHashSet, List, and Deque interfaces.

interface SequencedMap<K,V> extends Map<K,V> {
    // new methods
    SequencedMap<K,V> reversed();
    SequencedSet<K> sequencedKeySet();
    SequencedCollection<V> sequencedValues();
    SequencedSet<Entry<K,V>> sequencedEntrySet();
    V putFirst(K, V);
    V putLast(K, V);
    // methods promoted from NavigableMap
    Entry<K, V> firstEntry();
    Entry<K, V> lastEntry();
    Entry<K, V> pollFirstEntry();
    Entry<K, V> pollLastEntry();
}

The SequencedMap interface is implemented by the SortedMap, NavigableMap, and LInkedHashMap interfaces.

For more information, see JEP 431: Sequenced Collections.

Red Hat build of OpenJDK 21 enhances the Java programming language with pattern matching for switch statements. This enhancement enables you to test switch expressions against different patterns that each have a specific action, to ensure that complex data-oriented queries are expressed concisely and safely.

You can implement a switch statement that is based on the class of an object.

For example:

switch (obj) {
		case Integer i -> String.format("int %d", i);
		case String s  -> String.format("String %s", s);
		default        -> obj.toString();
	};

You can also implement more complex switch statements by nesting a when guard inside the case block of the switch statement.

For example:

switch (response) {
    	case null -> { }
    	case String s when s.equalsIgnoreCase("YES") -> {
        	System.out.println("You got it");
    	}
    	case String s when s.equalsIgnoreCase("NO") -> {
        	System.out.println("Shame");
    	}
    	case "n", "N" -> {
        	System.out.println("Shame");
    	}
    	case String s -> {
        	System.out.println("Sorry?");
    	}
}

If your applications use switch statements, ensure that these statements are up to date.

For more information, see JEP 441: Pattern Matching for switch.

Red Hat build of OpenJDK 21 introduces an API for a key encapsulation mechanism (KEM). KEM is an encryption technique for securing symmetric keys by using public key cryptography. The KEM API facilitates the use of public key cryptography and helps to improve security when handling secrets and messages.

For more information, see JEP 452: Key Encapsulation Mechanism API.

Red Hat build of OpenJDK 21 includes a @snippet tag for the Javadoc tool’s standard doclet. The @snippet tag helps to simplify the inclusion of example source code in API documentation.

For example:

/**
 * The following code shows how to use {@code Optional.isPresent}:
 * {@snippet :
 * if (v.isPresent()) {
 * 	System.out.println("v: " + v.get()); // @highlight substring="println"
 * }
 * }
 */

/**
 * The following code shows how to use {@code Optional.isPresent}:
 * {@snippet :
 * if (v.isPresent()) {
 * 	System.out.println("v: " + v.get()); // @highlight substring="println"
 * }
 * }
 */

For example:

/**
 * The following code shows how to use {@code Optional.isPresent}:
 * {@snippet file="ShowOptional.java" region="example"}
 */

In the preceding example, ShowOptional.java is a file that contains the following code:

public class ShowOptional {
	void show(Optional<String> v) {
    	// @start region="example"
    	if (v.isPresent()) {
        	System.out.println("v: " + v.get());
    	}
    	// @end
	}
}

You can specify the location of the external code either as a class name by using the class attribute or as a relative file path by using the file attribute.

For more information, see JEP 413: Code Snippets in Java API Documentation.

Red Hat build of OpenJDK 21 introduces virtual threads, which are lightweight threads that reduce the effort of writing, maintaining, and observing high-throughput concurrent applications. If your application uses more than a few thousand concurrent threads and your workload is not CPU-bound, the use of virtual threads can optimize your application.

Virtual threads support thread-local variables and interruptions. Virtual threads can also run any code that traditional threads can run. Therefore, you can migrate your source code to use only virtual threads by changing the way the threads are created.

The following example creates a virtual thread that executes a runnable instance:

Thread thread = Thread.ofVirtual().name("example").unstarted(runnable);

The following example shows how to create virtual threads by using a loop. Because virtual threads do not require pooling, no thread pool is created. If you want to limit concurrency, you can use semaphores instead.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
	IntStream.range(0, 10000).forEach(i -> {
    	  executor.submit(() -> {
        	  Thread.sleep(Duration.ofSeconds(1));
        	  return i;
    	});
    });
}  // executor.close() is called implicitly, and waits

The preceding example creates 10,000 virtual threads to run concurrently. The JDK can run the code on a small number of operating system threads or perhaps only one thread, which reduces the overhead.

For more information, see JEP 444: Virtual Threads.

OpenJDK 16 initially introduced the Vector API as an incubating feature. Red Hat build of OpenJDK 21 includes several enhancements to the Vector API based on a sixth round of incubation. The Vector API expresses a wide range of vector computations that can be reliably compiled at runtime to optimal vector instructions on supported CPU architectures. This API achieves better performance levels than equivalent scalar computations.

The latest enhancements ensure the reliability and efficiency of the Vector API in all architectures while also ensuring a graceful degradation of the API in any architecture that does not support all the expected native instructions. Future enhancements to the Vector API might also include alignment with Project Valhalla by defining vector classes as primitive classes.

For more information, see JEP 448: Vector API (Sixth Incubator).

Red Hat build of OpenJDK 21 includes a reimplementation of the java.lang.reflect.Method, java.lang.reflect.Constructor, and java.lang.reflect.Field classes on top of java.lang.invoke method handles. This reimplementation of the core reflection functionality helps to reduce the maintenance and development costs of the java.lang.reflect and java.lang.invoke APIs.

For more information, see JEP 416: Reimplement Core Reflection with Method Handles.

Red Hat build of OpenJDK 21 includes a Foreign Function and Memory (FFM) API, which is a preview feature that enables Java programs to interoperate with code and data that is outside the Java runtime. The FFM API can efficiently invoke foreign functions that are outside the JVM and safely access foreign memory that the JVM does not manage.

The FFM API replaces the existing Java Native Interface (JNI) with a pure Java development model that provides a more efficient, cleaner, and safer way to call native libraries and process native data.

The FFM API defines classes and interfaces that enable client code in libraries and applications to perform the following tasks:

The FFM API is located in the java.lang.foreign package of the java.base module.

For more information, see JEP 442: Foreign Function & Memory API (Third Preview).

Red Hat build of OpenJDK 21 introduces record patterns, which is a preview feature that enhances the Java programming language to deconstruct record values. This feature allows declaration and assignment variables that use the instanceof operator.

Consider the following declaration for a record named Point with attributes x and y:

record Point(int x, int y) {}

Based on the preceding declaration, the following code can test whether a value is an instance of Point and also extract the x and y components from the value directly:

if (obj instanceof Point(int x, int y)) {
    	System.out.println(x+y);
}

You can also use this feature in records that are nested inside other records. For example, consider the following declarations for a record named Rectangle with attributes of a ColoredPoint record with attributes of a Point record and Color enum:

record Point(int x, int y) {}
enum Color { RED, GREEN, BLUE }
record ColoredPoint(Point p, Color c) {}
record Rectangle(ColoredPoint upperLeft, ColoredPoint lowerRight) {}

Based on the preceding declarations, the following code can test whether a value is an instance of Rectangle and extract the color from the upper-left point:

if (r instanceof Rectangle(ColoredPoint ul, ColoredPoint lr)) {
     	System.out.println(ul.attribute());
}

For more information, see JEP 440: Record Patterns.

Red Hat build of OpenJDK 21 introduces unnamed patterns and variables, which is a preview feature that enhances the Java programming language:

You can denote unnamed patterns and unnamed variables by using an underscore (_) character. When a variable is not relevant and will not be used, you do not need to name the variable. In this situation, you can use an underscore character to denote that the variable exists but is not for use.

In the following example of a lambda expression, the parameter is irrelevant, which means that the JVM does not need to create a variable for this parameter:

...stream.collect(Collectors.toMap(String::toUpperCase, _ -> "NODATA"))

In the following example of a switch statement, the variables need to match the case but these variables will not be used:

switch (b) {
	case Box(RedBall _), Box(BlueBall _) -> processBox(b);
	case Box(GreenBall _)            	-> stopProcessing();
	case Box(_)                      	-> pickAnotherBox();
}

In the preceding example, the first two cases use unnamed pattern variables because their right-hand sides do not use the Box record’s component. The third case, which is new, uses the unnamed pattern to match a Box record with a null component.

For more information, see JEP 443: Unnamed Patterns and Variables (Preview).

Red Hat build of OpenJDK 21 introduces string templates, which is a preview feature that enhances the Java programming language. String templates complement Java’s existing string literals and text blocks by coupling literal text with embedded expressions and template processors to produce specialized results.

The string templates feature includes an STR utility, which is a template processor that supports validation and transformation, helping to improve the security of Java programs that compose strings. The STR utility also facilitates code readability. You can compose strings by using other variables, attributes, or functions.

For example, consider the following template expression:

STR."\{username} access at \{req.date} from \{getLocation()}"

The preceding expression produces the following example string:

“Guest access at 12/1/2024 from 127.0.0.1”

The preview features are experimental additions to the Java language that might be subject to improvements in future versions, where no backwards compatibility is guaranteed.

For more information, see JEP 430: String Templates (Preview).

Red Hat build of OpenJDK 21 introduces unnamed classes and instance main() methods, which is a preview feature that enhances the Java programming language for an educational purpose.

Unnamed classes and instance main() methods enable students to start writing basic Java programs in a concise manner without needing to understand Java language features for large complex programs. Rather than use a separate dialect of Java, students can write streamlined declarations for single-class programs and seamlessly modify their programs to use more advanced features as their Java knowledge increases.

To simplify the source code and allow students to focus on their own code, Java allows students to launch instance main() methods that meet the following criteria:

For example:

class HelloWorld {
	void main() {
    		System.out.println("Hello, World!");
	}
}

To allow students to start writing code before learning the object orientation concept, Red Hat build of OpenJDK 21 also introduces unnamed classes to make the class declaration implicit. For example:

void main() {
	System.out.println("Hello, World!");
}

To test this feature, ensure that you enable preview features. For example:

For more information, see JEP 445: Unnamed Classes and Instance Main Methods (Preview).

Red Hat build of OpenJDK 21 introduces scoped values, which is a preview feature that provides an API to support scoped value variables. Typically, a scoped value variable is declared as a final static field that is accessible from many methods.

Scoped values provide a safe and efficient way to share variables across methods without needing to use method parameters. A scoped value is comparable with an implicit method parameter that a method can use without having to declare the parameter within the method itself. Only the methods that have access to the scoped value object can access its data. Scoped values enable applications to pass data securely from a caller to a callee through other intermediate methods that do not declare a parameter for this data and cannot access it. Scoped values are a preferred alternative to thread-local variables, especially when using large numbers of virtual threads.

Consider the following example code where a callee method (bar) can use the same scoped value in a nested binding to send a different value to another callee method (baz):

private static final ScopedValue<String> X = ScopedValue.newInstance();

void main() {
	ScopedValue.where(X, "hello").run(() -> bar());
}

void bar() {
	System.out.println(X.get()); // prints hello
	ScopedValue.where(X, "goodbye").run(() -> baz());
	System.out.println(X.get()); // prints hello
}

void baz() {
	System.out.println(X.get()); // prints goodbye
}

In the preceding example, the main() method sets the scoped value X to hello and sends this value to the bar() method. The bar() method prints hello (the value of X) and then uses a nested binding to change the value of X and send the changed value to the baz() method. Once the baz() method returns, the rest of the bar() method still has the original hello value of X.

For more information, see JEP 446: Scoped Values (Preview).

Red Hat build of OpenJDK 21 introduces structured concurrency, which is a preview feature that provides an API to treat groups of related tasks running in different threads as a single unit of work. This API simplifies concurrent programming and helps to streamline error handling and cancellation, improve readability, and enhance observability.

In the structured concurrency paradigm, tasks (that is, threads) can be subdivided into subtasks, which can also be nested into further subtasks. This type of task hierarchy enables both cancellation propagation (that is, canceling a task automatically cancels its subtasks) and better control of how tasks interact with each other.

For example:

Response handle() throws ExecutionException, InterruptedException {
	try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    	Supplier<String>  user  = scope.fork(() -> findUser());
    	Supplier<Integer> order = scope.fork(() -> fetchOrder());

    	scope.join()        	// Join both subtasks
         	.throwIfFailed();  // ... and propagate errors

    	// Here, both subtasks have succeeded, so compose their results
    	return new Response(user.get(), order.get());
	}
}

The preceding example first creates a scope and then forks this scope to create the subtasks. At any time, the original thread or any of the subtasks can request a shutdown of the scope, to cancel all unfinished tasks and prevent new subtasks from being created. The scope.join() method ensures that the scope must wait for all subtasks to finish running. The .get() method returns the results of each subtask.

Each subtask can also create its own StructuredTaskScope to divide the workload into further subtasks. In this situation, the additional subtasks are nested under their parent subtask within the overall hierarchy.

For more information, see JEP 453: Structured Concurrency (Preview).