## New Features Java 22 boasts several significant new features designed to enhance code readability, performance, and developer productivity: + Unnamed Variables and Patterns + Foreign Function and Memory API (aka FFM) + Regional Pinning for G1 + Launch Multi-File Source-Code Programs ### Unnamed Variables and Patterns This feature allows developers to declare variables and parameters without assigning a name in specific contexts. [Unnamed Variables and Patterns][JEP456] improves code conciseness and readability, especially when dealing with unused values. With Java 22, you can now use the **underscore** _(which used to be a reserved variable, by the way)_, to name them: ```java for(final var _: orders) total++; // ^ Since Java 22 countriesStream.filter(_ -> 0.5 < Math.random()).toList(); // ^ Since Java 22 switch(ball) { case RedBall _ -> process(ball); // ^ Since Java 22 case GreenBall _ -> stopProcessing(); // ^ Since Java 22 } var _ = q.remove(); var _ = q.remove(); ``` ### Foreign Function and Memory API _(aka FFM)_ Also known as [FFM][JEP454], it enables developers to seamlessly call code written in other languages like C or C++ directly from Java programs. This enables leveraging existing libraries and functionalities without rewriting them in Java. Additionally, the FFM provides access to raw memory, unlocking performance optimizations for specific use cases. The FFM is a complex feature involving heap, stack, memory allocation and disposal, data layout, garbage collection, concurrent access, and more. The following code only demonstrates Foreign Functions. Here is the file structure, to write some `hello` function in `C` and call it in `Java`, before Java 22: + [x] **jna.jar** - The [Java Native Access API implementation][JNA]. + [x] **hello.c** - The `C` program implementing the function we will be calling from Java. ```c #include #include void sayHello(char* name) { printf("Hello, %s!", name); } ``` + [x] **hello.java** - The `Java` program to actually call the the `C`-written library function. ```java import com.sun.jna.Native; import com.sun.jna.Library; public class hello { public interface HelloLib extends Library { HelloLib INSTANCE = (HelloLib) Native.loadLibrary("hello", HelloLib.class); String sayHello(String name); } public static void main(String[] args) { HelloLib.INSTANCE.sayHello("Java 22"); } } ``` Now, from the command line interface _(I used Ubuntu here)_: ```bash # Compile **hello.c** program into binary **hello.o** gcc -c hello.c -o hello.o # Bundle the binary **hello.o** program into a library **libhello.so** # Notice the `lib` prefix in the library. # I think Microsoft Windows works with **.dll** files instead of **.so** files. gcc -shared -o libhello.so hello.o # Compile **hello.java** into a class file - **hello.class** - for the Java Runtime Environment. # It will also create a file for the inner `HelloLib` interface called **hello$HelloLib.class** javac -cp jna.jar:$PWD hello.java # Run **hello.class** using the **jna.jar** and you natively compiled library **libhello.so** # The `jna.library.path` Java system property is let JNA where to find the native library **libhello.so** java -Djna.library.path=$PWD -cp jna.jar:$PWD hello ``` The output should be something like this: `Hello, Java 22!` Now, with Java 22, it should look like the following: + [x] **hello.c** - unchanged, along with the compilation command + [x] **libhello.so** - same command as before, to build the library + [x] **hello.java** ```java import java.lang.foreign.*; public class hello { public static void main(String[] args) throws Throwable { final var linker = Linker.nativeLinker(); try (final var arena = Arena.ofConfined()) { final var library = SymbolLookup.libraryLookup("./libhello.so", arena); final var handle = library.find("sayHello").orElseThrow(); final var helloSignature = FunctionDescriptor.ofVoid(ValueLayout.ADDRESS); final var hello = linker.downcallHandle(handle, helloSignature); hello.invokeExact(arena.allocateFrom("Java 22")); } } } ``` + [x] Build & Run in Java, for Java ```bash # The build command is simpler, more straightforward, no external dependency javac hello.java # Then run on Java java hello ``` Now, a few comments here: - The path to the library, the library name and file extension are explicit: no hidden voodoo no more - No need for interfaces anymore, to model the library function signatures: we now have the `FunctionDescriptor` for that - At low levels, operating systems understand literal types, arrays, and memory addresses only. Java `String` thus translate to an address _(to the first character of the string)_ and where C use a pointer _(`char*`)_, [FFM][JEP454] let us express that for what it is: a memory address _(`ValueLayout.ADDRESS`)_ - We can now tell Java how to translate our value types to the low-level parameters and return values Furthermore, the JVM concerns for encapsulation, security, memory control and concurrence, now gives us control with `java.lang.foreign.Arena`. While the `Arena` class is a Java resource _(meaning it now implements the `Autoclosable` interface and can go into a try-with-resources block)_ to help the Garbage Collector clean up its resources, Java 22's [FFM][JEP454] introduces the `java.lang.foreign` package that is packaged with the JDK to address these concerns. ### Regional Pinning for G1 When a Java thread interacts with native code, as we have just seen with the Foreign Function and Memory API [FFM] [JEP454], it might temporarily hold references to Java objects. The garbage collector needs to ensure that these objects remain accessible throughout this interaction. Traditionally, the G1 collector would entirely disable garbage collection whenever a thread entered a critical JNI region. This disabling introduced latency issues, as other threads waiting for garbage collection would be stalled. [Region pinning][JEP423] eliminates this problem by allowing specific memory regions to be pinned during both minor and major collections. This ensures critical objects aren't moved. ### Launch Multi-File Source-Code Programs Since Java 11, we've been able to leverage its interpreted nature, see [JEP 330][JEP330]. It introduced a convenient way to run Java source code directly, without prior compilation. This functionality, known as launching single-file source-code programs, brought a new level of ease to specific use cases. In Java 21 introduced us to running Java as a fully interpreted programming language aka [JEP 330: Launch Single-File Source-Code Programs][JEP330]. I personally laughed hard when reading the news because I extensively hated scripting languages back around 2012-13, before JavaScript hit me hard. So, yes, I joined the cabal I was fighting against. Anyway, that JEP came with a major restriction: that your code fits into a single file. [JEP 458: Launch Multi-File Source-Code Programs][JEP458] builds upon this concept by allowing you to run programs from multiple source files. This opens doors for more complex scripting scenarios in Java. Here's an example to illustrate the potential: + [x] **Bye.java** ```java interface Bye { default void bye(String name) { System.out.printf("Bye %s%n", name); } } ``` + [x] **ByeCli.java** ```java class ByeCli { public static void main(String ...args) { new Bye() {}.bye(args[0]); } } ``` + [x] And with Java 22 CLI ```bash java ByeCli.java 'Java 21' # Bye Java 21 ``` Now, with the ability to script in Java and execute it anywhere, combined with the Foreign Function and Memory API, exciting possibilities emerge! However, keep in mind these points when using JEP458: + Classes are compiled incrementally, only when needed, even for referenced classes within the same file. + Unlike single-file sources, shebang lines (`#!` mechanism) are not supported in multi-file sources. + Packages must match a directory structure. + Annotation processing and multi-module projects are not currently supported. ## In Preview But some features are behind the preview flag: + Statement Before super + String Templates + Implicitly Declared Classes and Instance Main Methods + Class-file API + Stream Gatherers + Structured Concurrency + Scoped Values + Vector API > Just remember, to use preview features, you need: > > + `javac --release 22 --enable-preview SomeClass.java` > + `javac --release 22 --enable-preview SomeClass` > + `java --source 22 --enable-preview SomeClass.java` > + Or configure it according to your build tool or IDE ### Statement Before `super` [JEP 447: Statements before super(...) (Preview)][JEP447] is all about improving the developer experience when it comes to Java constructors and inheritance. Namely, by enriching the Java Language Specification (JLS) with the concept of **pre-construction context**, beyond that of the **static context**. + [x] Before Java 22: ```java import java.util.Objects; class Payment extends SomeBigNumber { Payment(long amount) { // e.g: 36 super(amount); // Potentially unnecessary work if (amount < 0) throw new IllegalArgumentException("%s MUST be positive".formatted(amount)); } } class CurrencyPayment extends Payment { Payment(String amount) { // e.g: 36 USD // Would need a static method for custom exception, or fallback value super(Long.parseLong(Objects.requireNonNull(amount).split(" ")[0])); this.currency = Objects.requireNonNull(amount).split(" ")[1]; } } ``` + [x] Since Java 22: ```java import java.util.Objects; class Payment extends SomeBigNumber { Payment(long amount) { // e.g: 36 if (amount < 0) throw new IllegalArgumentException("%s MUST be positive".formatted(amount)); super(amount); } } class CurrencyPayment extends Payment { String currency; Payment(String amount) { // e.g: 36 USD if (Objects.isNull(amount)) throw new RuntimeException("The `amount` cannot be null."); long value; try { value = Long.parseLong(amount.split(" ")[0]); } catch (NumberFormatException _) { throw new RuntimeException("The `amount` MUST look like \" \"."); } super(value); this.currency = Objects.requireNonNull(amount).split(" ")[1]; } } ``` On static contexts: > The purpose of a static context is to demarcate code that must not refer explicitly or implicitly to the current instance of the class whose declaration lexically encloses the static context. > > **Source:** https://docs.oracle.com/javase/specs/jls/se21/html/jls-8.html#jls-8.1.3 On pre-construction context: > Rather than revise the concept of a static context, we define a new, strictly weaker concept of a pre-construction context to cover both the arguments to an explicit constructor invocation and any statements that occur before it. Within a pre-construction context, the rules are similar to normal instance methods, except that the code may not access the instance under construction. > > **Source:** https://openjdk.org/jeps/447#Pre-construction-contexts What it all means is that anything before `super(...)` _(or `this(...)` for that matter)_ that explicitly or implicitly refers to `this` context will be rejected by the compiler/interpreter. ### String Templates Java doesn't support string interpolation due to security concerns. This focus on safety is a core reason why we value and advocate for Java. String interpolation can potentially lead to security vulnerabilities, especially when dealing with structured data formats like SQL, JSON, XML, or YAML. An interpolated value could close a JSON string or an HTML tag unintentionally. A [JEP 459: String Templates (Second Preview)][JEP459] is a language feature that splits a string and exposes its **fragments** and the interpolated **values** to a function that developers control. Where _string format_ simply turns every value into a string and puts it at the placeholder, _string template_ lets you decide whether to convert, replace or ignore some values altogether. At it simplest, a `java.lang.StringTemplate` can be constructed with: ```java final var name = "Java 22 (Preview)"; System.out.println(StringTemplate.RAW."Hello \{name}"); // StringTemplate{ fragments = [ "Hello ", "" ], values = [Java 22 (Preview)] } ``` At its core, the static`StringTemplate.RAW` is an instance of `StringTemplate.Processor`, which is a functional interface that accepts a `StringTemplate` and returns whatever you want it to (it is a generic interface). So then, you have the `StringTemplate.STR` processor that turns your `StringTemplate` into a `StringTemplate`: ```java final var name = "Java 22 (Preview)"; System.out.println(StringTemplate.STR."Hello \{name}"); // Hello Java 22 (Preview) ``` If you long for formatting numbers, padding strings and suchlike, you have `java.util.Formatter.FMT` processor for that: ```java final var name = "Java"; final var version = 22d; final var edition = "(Preview)"; System.out.println(FormatProcessor.FMT."Hello '%-8s\{name}' %3.2f\{version} %s\{edition}"); // Hello 'Java ' 22.00 (Preview) ``` What if none of these matches your need? You can implement your own `StringTemplate.Processor` to return whatever `T` you need: ```java class Main { static final List words = List.of("innit", "yeah", "of course", "f*cking"); public static void main(String[] args) throws Throwable { final var name = "Java"; final var version = 22d; final var edition = "(Preview)"; final StringTemplate.Processor britishSlang = stringTemplate -> { final var fragments = stringTemplate.fragments().iterator(); final var values = stringTemplate.values().iterator(); final var result = new StringBuilder(); while (values.hasNext()) { result.append(fragments.next()); result.append(" %s ".formatted(slang())); result.append(values.next()); } result.append(fragments.next()); return result.toString(); }; System.out.println(britishSlang."Hello \{name} \{version} \{edition}"); // Hello f*cking Java yeah 22.0 of course (Preview) } static String slang() { return words.get((int) Math.floor(words.size() * Math.random())); } } ``` ### Implicitly Declared Classes and Instance Main Methods Have you seen a Java **hello world**? It is literally as follows: ```java public class MyFirstClass { public static void main(String[] args) { System.out.println("Hello world!"); } } ``` Many programming languages do well with oneliners. Say for instance, Python's `print('Hello world!')` or JavaScript `console.log('Hello world')`. And beginners are true testers to simplicity. So [JEP 463: Implicitly Declared Classes and Instance Main Methods (Second Preview)][JEP463] is a confession from Oracle _(Java's editor)_ that they want a simpler Java to the beginners and thus to everyone. Why would beginner deal with `public` and `static` and `String[] args`? Java gets rid of those: ```java public class MyFirstClass { void main() { System.out.println("Hello world!"); } } ``` So much for an improvement! Who needs classes for a **hello world**? ```java void main() { System.out.println("Hello world!"); } ``` But the feature has **implicitly declared classes** right in the name, so can we have other methods? Sure. ```java String formulae = "Hello"; String sayHello(String audience) { return StringTemplate.STR."\{formulae} \{audience}!"; } void main() { System.out.println(sayHello("world")); } ``` > **NOTE:** The methods in implicitly declared classes are not `static`. You can add modifiers to them. It really boils down to: > > ```java > new Object() { > // your implicitly declared classes code, with a main method > }.main(); > ``` > > But: > + naming the entrypoint method of your program is mandatory > + implicitly declared classes does not implement any interface > + they are final and cannot be referenced by name > + they are part of the unnamed package of the unnamed module > + `javadoc` cannot extract its members' documentation ### Class-file API Some of you are familiar with the infamous `asm` library. Famous by its usefulness, infamous because of how we became aware of it: usually after a JDK upgrade followed by Maven related issues. `asm` helps in working with binary Java **.class** files. That binary format is rather specific and sometimes evolves with Java versions. [JEP 457: Class-File API (Preview)][JEP457] is about doing the same, right in Java's JDK, so that the latter can rely on this implementation rather than its copy of the `asm` library. ```java import java.io.IOException; import java.io.Serializable; import java.lang.classfile.ClassFile; import java.nio.file.Path; import java.util.List; public abstract class Main implements Serializable, Comparable { static final List words = List.of("What", "are", "you", "going", "to", "do", "using", "Java", "22"); public static void main(String[] args) throws IOException { final var parse = ClassFile.of().parse(Path.of("./Main.class")); for (final var poolEntry : parse.fields()) System.out.println(STR."F:: \{poolEntry}"); for (final var poolEntry : parse.methods()) System.out.println(STR."M:: \{poolEntry}"); for (final var poolEntry : parse.interfaces()) System.out.println(STR."I:: \{poolEntry}"); } } ``` Then compile **Main.java** into **Main.class**: ```bash $ javac --release 22 --enable-preview Main.java ``` And finally, run the **Main.class** to inspect itself using the Class-File API. ```bash $ java --enable-preview Main F:: FieldModel[fieldName=words, fieldType=Ljava/util/List;, flags=24] M:: MethodModel[methodName=, methodType=()V, flags=1] M:: MethodModel[methodName=main, methodType=([Ljava/lang/String;)V, flags=9] M:: MethodModel[methodName=, methodType=()V, flags=8] I:: 7 java/io/Serializable I:: 7 java/lang/Comparable ``` I barely scratched the surface of the Class-File API here. I recommend you drink from the source directly at [JEP 457][JEP457]. ### Stream Gatherers Since Java 8, we have enjoyed the collection API with `java.util.stream.Stream`s. And they are excellent at what they do. But some operations are still missing: well, many, actually. And [JEP 461: Stream Gatherers (Preview)][JEP461] is coming to address just that. Instead of just adding the many new operations developers could come up with, Java is generalizing the very process of Stream operators through the `java.util.Gatherer` functional interface. ```java public interface Gatherer { default Supplier initializer(); Integrator integrator(); default BinaryOperator combiner(); default BiConsumer> finisher(); } ``` A gatherer is an operator that can accept `element`s (``) from **upStream** and, eventually push some other **downStream** (``) - that is what the `integrator()` method is for. > **NOTE:** Now, some gatherers need to maintain an internal state, thus the need for an `initializer()` to create that state in the first place. Example: finding a maximum. It is optional. > **NOTE:** Some other gatherers only need to produce a value (or more if you care), at the end of the stream only. That would be finding a maximum, again. Thus, the `finalizer()`, which is also optional. > **NOTE:** Finally, some streams can run in parallel, using the MapReduce framework. You'd need a `combiner` to aggregate the sub-result into a higher level one. Useful when aggregating from parallel streams. So, optional as well. + `Integrator` is a functional interface which `boolean integrate(state, element, downStream)`'s method indeed process each element of the upstream. The returned boolean is to tell upstream if the gatherer will be accepting more values. Java will call it with three parameters: + `state`: the state (`STATE`) for this gatherer instance _(or the default, which is null)_ + `element`: the actual element (`ELEMENT`) from upstream + `downStream`: an object representing the downstream. It can tell us if downstream `boolean isRejecting()` more values _(in the case of stream limit, for example)_ or let us `push(OUTPUT element)` new values down the stream Enough theories. Let us see some examples... A **map** gatherer _(useless, I know but for didactics)_: ```java void main() { Stream.of("ABCDEFGHIJKLMNOPQRSTUVWXYZ".split("")) .gather(map(input -> STR."-- \{input} --")) .forEach(System.out::println); // -- A -- // -- B -- // ... // -- Z -- } Gatherer map(Function transform) { // We only need an integrator to transform the upstream element into another value to pass downStream // As long as the downStream accepted the next value, this gatherer signals upStream it can take more return Gatherer.of((_, element, downstream) -> downstream.push(transform.apply(element))); } ``` A **zip** gatherer to make a couple of two streams' elements 1-on-1 until one stream is closed: ```java record Pair(A first, B second) { } void main() { final var indexes = IntStream.range(0, 26).boxed(); final var letters = Stream.of("ABCDEFGHIJKLMNOPQRSTUVWXYZ".split("")); indexes .gather(zip(letters, Pair::new)) .forEach(System.out::println); // Pair[first=0, second=A] // Pair[first=1, second=B] // ... // Pair[first=25, second=Z] } Gatherer, O> zip(Stream other, BiFunction couple) { // Yes, sequential... This isn't an operation you want in parallel return Gatherer.ofSequential( // The other's iterator will be our state. We need to stop at its end other::iterator, // If the state has another value, couple it to upStream current element and accept the next upStream element // Otherwise, return `false` to signal upStream that this gatherer is done (thus the shortcut AND) (iterator, element, downstream) -> iterator.hasNext() && downstream.push(couple.apply(element, iterator.next()))); } ``` Last example, a **max** gatherer, which can run in parallel: ```java void main() { Stream.of("ZYXWVUTSRQPONMLKJIHGFEDCBA".split("")) .gather(max()) .forEach(System.out::println); } > Gatherer, I> max() { return Gatherer.of( AtomicReference::new, // Use an atomic reference for our state, to hold the highest-ranking element so far (state, element, _) -> { // ^ We ignore the dowStream here because we will emit the maximum once, when finalizing if (Objects.nonNull(element)) { // We try to update state only for non-null elements final var MISSING_STATE = Objects.isNull(state.get()); final var NEW_MAXIMUM = !MISSING_STATE && element.compareTo(state.get()) > 0; if (MISSING_STATE || NEW_MAXIMUM) { state.set(element); } } return true; // Always signal that the gather can accept the next value }, // Now, combiner, for resolving max from subsets' max, when running in parallel (a, b) -> b.get().compareTo(a.get()) > 0 ? b : a, // When upStream has completed, finally emit the max value, if any (state, downStream) -> Optional.ofNullable(state.get()).ifPresent(downStream::push)); } ``` ### Structured Concurrency In modern programming, concurrency has been a corner stone. It is the ability to switch to the next task at hand when the current task we were working on get stuck or pending. In this analogy, we are the threads and tasks are logical groups each of instruction set. Still with that analogy, when the previously stuck/pending task is ready to continue, we can switch back to it at the next opportunity. And since some tasks have some dependency between them (example: although you can chew and drink alternatively, you chew before you swallow). And Java 22's structured concurrency build on Java 21's virtual threads to let us express just this fork and joint points. ```java interface Preparation { String prepareFeature(); String prepareEnvironment(); } void main() { new Thread(preparation::prepareEnvironment).start(); // run in a separate thread new Thread(preparation::prepareFeature).start(); // run in a separate thread // 1. How do we wait for both threads to complete? // Before we continue from down here... // They could be two or more. // 2. What if this outer thread is interrupted? How does it affect our two children threads up there? } ``` If the two children needed not be terminated should their parent thread be terminated, the [java.util.concurrent.ExecutorService](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/ExecutorService.html), introduced to Java 5 as part of the **unstructured concurrency** would have been perfect. Moreover, what if: + we want to stop the other if one thread fails + we only need one of both to succeed and ignore the other [JEP 462: Structured Concurrency (Second Preview)][JEP462] is here to address just that. To let us express with simplicity about forking points and joining points. For our example, I prepared two implementations of the `Preparation` interface. One where methods fail, others where methods succeed, after some delay in either case. I wrapped them in methods, for reuse convenience. ```java Preparation setUpForSuccess() { return new Preparation() { final String feature = UUID.randomUUID().toString(); @Override public String prepareFeature() { try { Thread.sleep(Math.round(Math.round(5_000 * Math.random()))); } catch (InterruptedException exception) { throw new RuntimeException(exception); } return feature; } @Override public String prepareEnvironment() { try { Thread.sleep(Math.round(Math.round(5_000 * Math.random()))); } catch (InterruptedException exception) { throw new RuntimeException(exception); } return STR."\{feature}-READY"; } }; } Preparation destinedForFailure() { return new Preparation() { @Override public String prepareFeature() { try { Thread.sleep(Math.round(Math.round(5_000 * Math.random()))); } catch (InterruptedException exception) { throw new RuntimeException(exception); } throw new UnsupportedOperationException("Developers need more details to implement the feature."); } @Override public String prepareEnvironment() { try { Thread.sleep(Math.round(Math.round(5_000 * Math.random()))); } catch (InterruptedException exception) { throw new RuntimeException(exception); } throw new UnsupportedOperationException("Operations need more compute power to have a ready environment."); } }; } ``` Using `StructureadTaksScope`, we can express disjunction and junction points as follows: ```java void main() throws InterruptedException, ExecutionException { final Preparation preparation = setUpForSuccess(); try (final var preparationScope = new StructuredTaskScope.ShutdownOnFailure()) { final StructuredTaskScope.Subtask environment = preparationScope.fork(preparation::prepareEnvironment); final StructuredTaskScope.Subtask feature = preparationScope.fork(preparation::prepareFeature); preparationScope.join(); // We wait for both feature AND environment subtasks at this point. // Using `ShutdownOnFailure` means the first subtask to fail will take us past this wait-point. preparationScope.throwIfFailed(); // With feature and environment both ready, we can trigger testing. Haha if (environment.get().equals(STR."\{feature.get()}-READY")) { System.out.println(environment.get()); } else { throw new RuntimeException(STR."The environment '\{environment}' is not ready to accept the feature '\{feature}'."); } } } ``` ```bash $ java --source 22 --enable-preview Main.java 6db565cd-7417-4aa2-89f1-cc5f84571832-READY ``` Should we replace `setUpForSuccess()` with `destinedForFailure()`, we could get the following error and stacktrace, depending on which method fails first: ```bash $ java --source 22 --enable-preview Main.java Exception in thread "main" java.util.concurrent.ExecutionException: java.lang.UnsupportedOperationException: Developers need more details to implement the feature. at java.base/java.util.concurrent.StructuredTaskScope$ShutdownOnFailure.throwIfFailed(StructuredTaskScope.java:1323) at java.base/java.util.concurrent.StructuredTaskScope$ShutdownOnFailure.throwIfFailed(StructuredTaskScope.java:1300) at Main.main(Main.java:18) Caused by: java.lang.UnsupportedOperationException: Developers need more details to implement the feature. at Main$2.prepareFeature(Main.java:61) at java.base/java.util.concurrent.StructuredTaskScope$SubtaskImpl.run(StructuredTaskScope.java:892) at java.base/java.lang.VirtualThread.run(VirtualThread.java:329) ``` The stacktrace indicating `at Main.main(Main.java:18)` corresponds to my source file `preparationScope.throwIfFailed();`. What line does is wrapping any first subtask that fails' exception into as `ExecutionException` and throw the new exception. But should we need to customize the exception or even handle it, we could replace `preparationScope.throwIfFailed();` with: ```java if (StructuredTaskScope.Subtask.State.FAILED == environment.state()) { throw new RuntimeException("Uh. Broken testing environment", environment.exception()); } else if (StructuredTaskScope.Subtask.State.FAILED == feature.state()) { throw new RuntimeException("Oops. Broken feature", feature.exception()); } ``` Also, I relied on `StructuredTaskScope.ShutdownOnFailure` to express that I wanted to shut down the task scope whenever any of its subtasks fail. But if we were interested in a race, where the task scope should be shutdown as soon as either subtask successfully complete, we would have used the `StructuredTaskScope.ShutdownOnSuccess` scope instead. No-args built-in task scope use virtual threads. They both have a constructor overload that accepts a `name` for debugging and a `java.util.concurrent.ThreadFactory`. And if you want to a custom task scope behaviour, you can still implement yours by extending `StructuredTaskScope`. > In the current API, Subtask::get() behaves exactly as Future::resultNow() did when the API was incubating. > > **Source:** [JEP 462][JEP462] ### Scoped Values Java has had `ThrealLocal` since Java 2 aka 1.2. It helps share information to every code running on the same thread: ```java void main() { final var names = List.of("lorem", "ipsum", "dolor", "sit", "amet", "consectetur", "adiscipin", "elit", "asperiores", "atque"); final var threadLocalIterator = names.iterator(); for (int i = 0; i < 10; i++) new Thread(() -> { final var name = threadLocalIterator.next(); final var NAME = ThreadLocal.withInitial(name::toString); for (int j = 0; j < 2; j++) { try { Thread.sleep(Math.round(1_000 * Math.random())); } catch (InterruptedException e) { throw new RuntimeException(e); } System.out.println(FMT."%11s\{name} [%11s\{NAME.get()}] \{j}"); } }).start(); } ``` And here is a plausible output: ```bash $ java --source 22 --enable-preview Main.java adiscipin [ adiscipin] 0 sit [ sit] 0 atque [ atque] 0 asperiores [ asperiores] 0 adiscipin [ adiscipin] 1 lorem [ lorem] 0 elit [ elit] 0 asperiores [ asperiores] 1 sit [ sit] 1 dolor [ dolor] 0 consectetur [consectetur] 0 ipsum [ ipsum] 0 amet [ amet] 0 atque [ atque] 1 amet [ amet] 1 elit [ elit] 1 consectetur [consectetur] 1 lorem [ lorem] 1 dolor [ dolor] 1 ipsum [ ipsum] 1 ``` > But here is the catch: Java introduced virtual threads officially in Java 21. These are threads that give up the CPU during I/O operations (network read/write, file read/write, some system/kernel calls) but also sleep and more. And when they resume, they may well run on a different thread than when they went off the CPU. > > So `ThreadLocal` are not a good fit for these. That is one of the reasons why Java is incubating [JEP 464: Scoped Values (Second Preview)][JEP464]. But `ScopedValue`s usage is not limited to virtual threads. To be sure: ```java void main() { final var names = List.of("lorem", "ipsum", "dolor", "sit", "amet", "consectetur", "adiscipin", "elit", "asperiores", "atque"); final var threadScopeIterator = names.iterator(); for (int i = 0; i < 10; i++) new Thread(() -> { final var name = threadScopeIterator.next(); final var J = ScopedValue.newInstance(); final var NAME = ScopedValue.newInstance(); for (int j = 0; j < 2; j++) { ScopedValue.where(NAME, name).where(J, j).run(() -> { try { Thread.sleep(Math.round(1_000 * Math.random())); } catch (InterruptedException e) { throw new RuntimeException(e); } System.out.println(FMT."%11s\{name} %-11s\{NAME.get()} \{J.get()}"); }); } }).start(); } ``` And the result: ```bash $ java --source 22 --enable-preview Main.java adiscipin adiscipin 0 asperiores asperiores 0 dolor dolor 0 elit elit 0 asperiores asperiores 1 consectetur consectetur 0 adiscipin adiscipin 1 amet amet 0 amet amet 1 sit sit 0 consectetur consectetur 1 ipsum ipsum 0 atque atque 0 lorem lorem 0 dolor dolor 1 elit elit 1 ipsum ipsum 1 lorem lorem 1 sit sit 1 atque atque 1 ``` > You use `ScopedValue.newInstance()` to create a scope identifier. Then, `ScopedValue.where(identifier, value)` to bind a value to that scoped identifier, and finally, within the `run` or `call` lambda, you use `identifier.get()` to get the current value scoped to that `identifier`. > > And yes, you can chain calls to `.where(...)` before either `.call(Callable)` or `.run(Runnable)` So how would we achieve a similar feat with virtual threads? ```java void main() throws InterruptedException { final var names = List.of("lorem", "ipsum", "dolor", "sit", "amet", "consectetur", "adiscipin", "elit", "asperiores", "atque"); final var virtualThreadScopeIterator = names.iterator(); final var virtualThreads = new LinkedList(); for (int i = 0; i < 10; i++) virtualThreads.add(Thread.ofVirtual().start(() -> { final var name = virtualThreadScopeIterator.next(); final var J = ScopedValue.newInstance(); final var NAME = ScopedValue.newInstance(); for (int j = 0; j < 2; j++) { ScopedValue.where(NAME, name).where(J, j).run(() -> { try { Thread.sleep(Math.round(1_000 * Math.random())); } catch (InterruptedException e) { throw new RuntimeException(e); } System.out.println(FMT."%11s\{name} %-11s\{NAME.get()} \{J.get()}"); }); } })); for (final var thread : virtualThreads) thread.join(); } ``` The output: ```text $ java --source 22 --enable-preview Main.java elit elit 0 sit sit 0 atque atque 0 adiscipin adiscipin 0 amet amet 0 asperiores asperiores 0 adiscipin adiscipin 1 elit elit 1 consectetur consectetur 0 dolor dolor 0 ipsum ipsum 0 lorem lorem 0 atque atque 1 amet amet 1 sit sit 1 ipsum ipsum 1 lorem lorem 1 asperiores asperiores 1 consectetur consectetur 1 dolor dolor 1 ``` > But why is it **scoped**? Right? Because it otherwise looks like a glorified `ThreadLocal` to me... Wait for it! For one thing, it does not for you to set an initial value: ```java final var random = randomUUID(); final var RANDOM = ScopedValue.newInstance(); // System.out.println(STR."BEFORE.OUT \{random} vs. \{RANDOM.get()}"); // java.util.NoSuchElementException ScopedValue.where(RANDOM, random).run(() -> System.out.println(STR."\{random} vs. \{RANDOM.get()}")); // System.out.println(STR."BEFORE.IN \{random} vs. \{RANDOM.get()}"); // java.util.NoSuchElementException ``` Output: ```bash $ java --source 22 --enable-preview Main.java 933630ee-f74f-4686-bc05-b4d05de47a9d vs. 933630ee-f74f-4686-bc05-b4d05de47a9d ``` > **NOTE:** So you may want to check for a bounded value to that scope identifier of yours, using `identifier.isBound()` as in `RANDOM.isBound()`. But for another reason, and I hope you will like it... ```java final var random = randomUUID(); final var RANDOM = ScopedValue.newInstance(); ScopedValue.where(RANDOM, random).run(() -> { System.out.println(STR."BEFORE \{random} vs. \{RANDOM.get()}"); ScopedValue.where(RANDOM, randomUUID()).run(() -> { System.out.println(STR."NESTED \{random} vs. \{RANDOM.get()}"); }); System.out.println(STR."AFTER \{random} vs. \{RANDOM.get()}"); }); ``` Output: ```text $ java --source 22 --enable-preview Main.java BEFORE 65414be7-85d0-4bcc-9610-9d391588a6bd vs. 65414be7-85d0-4bcc-9610-9d391588a6bd NESTED 65414be7-85d0-4bcc-9610-9d391588a6bd vs. 50112001-97fc-4ff3-961b-0aba531073d8 # Different here AFTER 65414be7-85d0-4bcc-9610-9d391588a6bd vs. 65414be7-85d0-4bcc-9610-9d391588a6bd ``` > Rebounding a scope identifier to a new value, nested in another scope, will result is a change of value, but only within that nested scope. And it beats `ThreadLocal` to it, by limiting the lifetime of thread-bonds. I certainly see the value for transactions here. > > For this nest-then-undo reason, and unlike `ThreadLocal`, `ScopedValue` is said to be immutable. If you need one last straw to consider adopting `ScopedValue`, then what about this? `ThreadLocal` are local only by name: in effect, children threads inherit those values, and it is very expensive to copy those data around threads. That is a wrap of the major changes brought with Java 22. Some smaller more can be found in [the release notes][Java22]. [JEP330]: https://openjdk.org/jeps/330 [JEP423]: https://openjdk.org/jeps/423 [JEP447]: https://openjdk.org/jeps/447 [JEP454]: https://openjdk.org/jeps/454 [JEP456]: https://openjdk.org/jeps/456 [JEP457]: https://openjdk.org/jeps/457 [JEP458]: https://openjdk.org/jeps/458 [JEP459]: https://openjdk.org/jeps/459 [JEP461]: https://openjdk.org/jeps/461 [JEP462]: https://openjdk.org/jeps/462 [JEP463]: https://openjdk.org/jeps/463 [JEP464]: https://openjdk.org/jeps/464 [Java22]: https://jdk.java.net/22/release-notes [JNI]: https://en.wikipedia.org/wiki/Java_Native_Interface [JNA]: https://en.wikipedia.org/wiki/Java_Native_Access [MaurizioCIMADAMORE_ProjectPanama]: https://www.youtube.com/watch?v=kUFysMkMS00