**update** I've since published a _Spring Tips_ video on this very topic! If you'd prefer, you could watch that instead. Hi, Spring fans! Happy [Java 22]() release day, to those who celebrate! Did you get the bits already? Go, go, go! Java 22 is a _significant_ improvement that I think is a worthy upgrade for everyone. There are some big, final released features, like Project Panama, and a slew of even-better preview features. I couldn't hope to cover them all, but I did want to touch on a few of my favorites. We're going to touch on a number of features. The code, if you want to follow along at home, [is here (`https://github.com/spring-tips/java22`)](). I love Java 22, and of course, I love GraalVM, and both have releases today! Java is of course our favorite runtime and language, and GraalVM is a high-performance JDK distribution that supports additional languages and allows ahead-of-time (AOT) compilation (they're called GraalVM native images). GraalVM includes all the niceties of the new Java 22 release, with some extra utilities, so I always recommend just downloading that one. I'm interested, specifically, in the GraalVM native image capability. The resulting binaries start almost instantly and take considerably less RAM compared to their JRE cousins. GraalVM isn't new, but it's worth remembering that Spring Boot has a great engine to support turning your Spring Boot applications into GraalVM native images. ## Installation Here's what I did. I'm using the fantastic [SDKMAN]() package manager for Java. I'm also running on an Apple Silicon chip running macOS. This, and the fact that I like and encourage the use of GraalVM, will be somewhat important later, so don't forget. There'll be a test! sdk install java 22-graalce I'd also make it your default: sdk default java 22-graalce Open up a new shell before continuing and then verify everything's working by running `javac --version`, `java --version`, and `native-image --version`. f you're reading this in the far-flung future (do we have flying cars yet?) and there's `50-graalce`, then by all the means install that! Bigger versions are better! ## You Gotta Start Somewhere... At this point, I wanted to start building! So, I went to my second favorite place on the internet, the Spring Initializr - [start.spring.io]() \- and generated a new project, using the following specifications: * I selected the `3.3.0-snapshot` version of Spring Boot. 3.3 is not yet GA, but it should be in a few short months. In the meantime, onward and upward! This release has better support for Java 22. * I selected `Maven` as the build tool. * I added `GraalVM Native Support` support, `H2 Database`, and `JDBC API` support. I opened the project in my IDE, like this: `idea pom.xml`. Now I needed to configure a few of the Maven plugins to support both Java 22 and some of the preview features we're going to look at in this article. Here's my fully configured `pom.xml`. It's a little dense, so I'll see you after the code for the walkthrough. 4.0.0 org.springframework.boot spring-boot-starter-parent 3.3.0-SNAPSHOT com.example demo 0.0.1-SNAPSHOT demo Demo project for Spring Boot 22 org.springframework.boot spring-boot-starter-jdbc com.h2database h2 runtime org.springframework.boot spring-boot-starter org.graalvm.sdk graal-sdk 23.1.2 org.graalvm.nativeimage svm 23.1.2 provided org.springframework.boot spring-boot-starter-test test org.graalvm.buildtools native-maven-plugin 0.10.1 --features=com.example.demo.DemoFeature --enable-native-access=ALL-UNNAMED -H:+ForeignAPISupport -H:+UnlockExperimentalVMOptions --enable-preview org.apache.maven.plugins maven-surefire-plugin --enable-preview org.apache.maven.plugins maven-compiler-plugin true org.springframework.boot spring-boot-maven-plugin --enable-preview --enable-preview io.spring.javaformat spring-javaformat-maven-plugin 0.0.41 validate true validate spring-milestones Spring Milestones https://repo.spring.io/milestone false spring-snapshots Spring Snapshots https://repo.spring.io/snapshot false spring-milestones Spring Milestones https://repo.spring.io/milestone false spring-snapshots Spring Snapshots https://repo.spring.io/snapshot false I know, I know! There's a lot! But, not really. This `pom.xml` is almost identical to what I got from the Spring Initializr. The main changes are: * I redefined the `maven-surefire-plugin` and `maven-compiler-plugin` to support preview features. * I added the `spring-javaformat-maven-plugin` to support formatting my source code. * I added two new dependencies: `org.graalvm.sdk:graal-sdk:23.1.2` and `org.graalvm.nativeimage:svm:23.1.2`, both of which are exclusively for the creation of the GraalVM `Feature` implementation that we will need later. * I added configuration stanzas to the `` sections of the `native-maven-plugin`, and the `spring-boot-maven-plugin`. In no time at all, Spring Boot 3.3 will be GA and support Java 22, and so maybe half of this build file will disappear. (Talk about _Spring cleaning_!) ## A Quick Programming Note Throughout this article, I'm going to refer to a functional interface type called `LanguageDemonstrationRunner`. It's just a functional interface I created that is declared to throw a `Throwable`, so that I don't have to worry about it. package com.example.demo; @FunctionalInterface interface LanguageDemonstrationRunner { void run() throws Throwable; } I have an `ApplicationRunner` which in turn injects all implementations of my functional interface and then invokes their `run` method, catching and handling `Throwable`. // ... @Bean ApplicationRunner demo(Map demos) { return _ -> demos.forEach((_, demo) -> { try { demo.run(); } // catch (Throwable e) { throw new RuntimeException(e); } }); } // ... OK, that established.. onward! ## Bye, JNI! This release sees the long-awaited release of [Project Panama](). This is one of the three features I've most been waiting for. The other two features, virtual threads and GraalVM native images, have been a reality for at least six months now. Project Panama is the thing that lets us leverage the galaxy of C, C++ code that's been so long denied us. Come to think of it, it probably supports basically any kind of binary if it supports [ELF](), I'd imagine. Rust programs and Go programs can be compiled to C-compatible binaries, for example, so I imagine (but haven't tried) that this means easy enough interop with those languages, too. Broadly, in this section, when I talk about "native code," I'm talking about binaries that are compiled in such a way that they can be invoked like a C library might. Historically, Java has been very insular. It has _not_ been easy for Java developers to repurpose native C and C++ code. It makes sense. Native, operating system-specific code would only serve to undermine Java's promise of _Write Once, Run Anywhere_. It's always been a bit taboo. But I don't see why it should be. To be fair, we've done alright, despite the absence of easy native code interop. There is [JNI](), which stands for _Joylessly Navigating the Inferno_, I'm pretty sure. In order to use JNI, you must write more, _new_ C/C++ code to glue together whatever language you want to use with Java. (How is this productive? Who thought this was a good idea?) Most people _want_ to use JNI like they _want_ a root canal! Most people don't. We've simply had to reinvent everything in an idiomatic, Java-style way. For nearly anything you could want to do, there is probably a pure Java solution out there that runs anywhere Java does. It works fine until it doesn't. Java has missed out on key opportunities here. Imagine if Kubernetes had been built in Java? Imagine if the current AI revolution was powered by Java? There are a lot of reasons why these two notions would've been inconceivable when Numpy, Scipy, and Kubernetes were first created, but today? Today, they released Project Panama. Project Panama introduces an easy way to link into native code. There are two levels of support. You can, in a rather low-level way, manipulate memory and pass data back and forth into native code. I said "back and forth," but I probably should've said "down and up" to native code. Project Panama supports "downcalls," calls into native code from Java, and "upcalls," calls from native code into Java. You can invoke functions, allocate and free memory, read and update fields in `struct`s, etc. Let's take a look at a simple example. The code uses the new `java.lang.foreign.*` APIs to look up a symbol called `printf` (which is basically `System.out.print()`), allocate memory (sort of like `malloc`) buffer, and then pass that buffer to the `printf` function. package com.example.demo; import org.springframework.stereotype.Component; import java.lang.foreign.Arena; import java.lang.foreign.FunctionDescriptor; import java.lang.foreign.Linker; import java.lang.foreign.SymbolLookup; import java.util.Objects; import static java.lang.foreign.ValueLayout.ADDRESS; import static java.lang.foreign.ValueLayout.JAVA_INT; @Component class ManualFfi implements LanguageDemonstrationRunner { // this is package private because we'll need it later static final FunctionDescriptor PRINTF_FUNCTION_DESCRIPTOR = FunctionDescriptor.of(JAVA_INT, ADDRESS); private final SymbolLookup symbolLookup; // SymbolLookup is a Panama API, but I have an implementation I'm injecting ManualFfi(SymbolLookup symbolLookup) { this.symbolLookup = symbolLookup; } @Override public void run() throws Throwable { var symbolName = "printf"; var nativeLinker = Linker.nativeLinker(); var methodHandle = this.symbolLookup.find(symbolName) .map(symbolSegment -> nativeLinker.downcallHandle(symbolSegment, PRINTF_FUNCTION_DESCRIPTOR)) .orElse(null); try (var arena = Arena.ofConfined()) { var cString = arena.allocateFrom("hello, Panama!"); Objects.requireNonNull(methodHandle).invoke(cString); } } } Here's the definition for the `SymbolLookup` that I put together. It is a sort of composite, trying one `SymbolLookup`, and then another if the first should fail. @Bean SymbolLookup symbolLookup() { var loaderLookup = SymbolLookup.loaderLookup(); var stdlibLookup = Linker.nativeLinker().defaultLookup(); return name -> loaderLookup.find(name).or(() -> stdlibLookup.find(name)); } Run this, and you'll see it prints out `hello, Panama!`. You might be wondering why I didn't pick something more interesting as an example. It turns out that there's precious little that you can both take for granted across all operating systems _and_ perceive as having done something on your computer. IO seemed to be about all I could think of, and console IO is even easier to follow. But what about GraalVM native images? It doesn't support _every_ thing you might want to do. And, at least for the moment, it doesn't run on Apple Silicon, only x86 chips. I developed this example and set [up a GitHub Action]() to see the results in an x86 Linux environment. It's a bit of a pity for us Mac developers who are not using Intel chips, but most of us aren't deploying to Apple devices in production, we're deploying to Linux and x86, so it's not a dealbreaker. There are some other [limitations, too](). For example, GraalVM native images only support the first `SymbolLookup`, `loaderLookup`, in our composite. If that one doesn't work, then neither of them will work. GraalVM wants to know about some of the dynamic things you're going to do at runtime, including foreign function invocation. You need to tell it ahead of time. For most other things about which it needs such information, like reflection, serialization, resource loading, and more, you need to write a `.json` configuration file (or let Spring's AOT engine write them for you). This feature is so new that you have to go down a few abstraction levels and write a GraalVM `Feature` class. A `Feature` has callback methods that get invoked during GraalVM's native compilation lifecycle. You'll tell GraalVM the signature, the _shape_, of the native function that we'll eventually invoke at runtime. Here's the `Feature`. There's only one line of value. package com.example.demo; import org.graalvm.nativeimage.hosted.Feature; import org.graalvm.nativeimage.hosted.RuntimeForeignAccess; import static com.example.demo.ManualFfi.PRINTF_FUNCTION_DESCRIPTOR; public class DemoFeature implements Feature { @Override public void duringSetup(DuringSetupAccess access) { // this is the only line that's important. NB: we're sharing // the PRINTF_FUNCTION_DESCRIPTOR from our ManualFfi bean from earlier. RuntimeForeignAccess.registerForDowncall(PRINTF_FUNCTION_DESCRIPTOR); } } And then we need to wire up the feature, telling GraalVM about it, by passing in the `--features` attribute to the GraalVM native image Maven plugin configuration. We also need to unlock the foreign API support and unlock experimental stuff. (I don't know why this is experimental in GraalVM native images when it's not experimental any longer in Java 22 itself). Also, we need to tell GraalVM to allow native access for all unnamed types. So, altogether, here's the final Maven plugin configuration. org.graalvm.buildtools native-maven-plugin 0.10.1 --features=com.example.demo.DemoFeature --enable-native-access=ALL-UNNAMED -H:+ForeignAPISupport -H:+UnlockExperimentalVMOptions --enable-preview This is an awesome result. I compiled the code in this example into a GraalVM native image running on GitHub Actions runners and then executed it. The application, which - I remind you - has the Spring JDBC support, a complete and embedded SQL 99 compliant Java database called H2, and everything on the classpath - executes in 0.031 seconds (31 milliseconds, or 31 thousandths of a second), takes tens of megabytes of RAM, and invokes the native C code, from the GraalVM native image! I'm so happy, y'all. I've waited for this day for so long. But this does feel a little low-level. At the end of the day, you are using a Java API to programmatically create and maintain structures in native code. It's sort of like using SQL from JDBC. JDBC lets you manipulate SQL database records in Java, but you're not writing SQL in Java and compiling it in Java and executing it in SQL. There's an abstraction delta; you're sending strings into the SQL engine and then getting records back out as `ResultSet` objects. The same is true for the low-level API in Panama. It works, but you're not invoking native code, your looking up symbols with strings and manipulating memory. So, they released a separate but related tool called `jextract`. You can point it at a C header file, like `stdio.h`, in which the `printf` function is defined, and it'll generate Java code that mimics the call signature of the underlying C code. I didn't use it in this example because the resulting Java code ends up being tied to the underlying platform. I pointed it to `stdio.h` and got a lot of macOS specific definitions. I could hide all of that behind a runtime check for the operating system and then dynamically load a particular implementation, but, eh, this blog's already too long. If you want to see how to run `jextract`, here's the bash script I used that worked for macOS and Linux. Your mileage may vary. #!/usr/bin/env bash LINUX=https://download.java.net/java/early_access/jextract/22/3/openjdk-22-jextract+3-13_linux-x64_bin.tar.gz MACOS=https://download.java.net/java/early_access/jextract/22/3/openjdk-22-jextract+3-13_macos-x64_bin.tar.gz OS=$(uname) DL="" STDIO="" if [ "$OS" = "Darwin" ]; then DL="$MACOS" STDIO=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h elif [ "$OS" = "Linux" ]; then DL=$LINUX STDIO=/usr/include/stdio.h else echo "Are you running on Windows? This might work inside the Windows Subsystem for Linux, but I haven't tried it yet.." fi LOCAL_TGZ=tmp/jextract.tgz REMOTE_TGZ=$DL JEXTRACT_HOME=jextract-22 mkdir -p "$( dirname $LOCAL_TGZ )" wget -O $LOCAL_TGZ $REMOTE_TGZ tar -zxf "$LOCAL_TGZ" -C . export PATH=$PATH:$JEXTRACT_HOME/bin jextract --output src/main/java -t com.example.stdio $STDIO Just think about it. We have easy foreign function interop, virtual threads giving us amazing scalability, and statically linked, lightning fast, RAM efficient, self-contained GraalVM native image binaries. Tell me why you'd start a new project in Go, again? :-) ## A Brave New World Java 22 is an amazing new release. It brings with it a bevy of huge features and quality of life improvements. Just remember, it can't always be this good! Nobody can introduce paradigm-changing new features consistently every six months. It's just not possible. So, let's be thankful and enjoy it while we can, shall we? :) The last release, Java 21, was, in my estimation, maybe the single biggest release I've seen since perhaps Java 5, maybe even earlier. It might be the biggest ever! There are a ton of features there that are well worth your attention, including _data-oriented programming_ and _virtual threads_. I covered this, and a lot more, in a blog I did to support the release six months ago, [_Hello, Java 21_](). ## Virtual Threads, Structured Concurrency, and Scoped Values Virtual threads are the really important bit, though. Read the blog I just linked you to, towards the bottom. (Don't be like [the Primeagen](), who read the article but managed to sort of move on before even getting to the best part - the virtual threads! My friend... Why??) Virtual threads are a way to squeeze more out of your cloud infrastructure spend, your hardware, etc., if you're running IO-bound services. They make it so that you can take existing code written against the blocking IO APIs in `java.io`, switch to virtual threads, and handle much better scale. The effect, usually, is that your system is no longer constantly waiting for threads to be available so the average response time goes down, and, even nicer, you will see the system handle many more requests at the same time! I can't stress this enough. Virtual threads are _awesome_! And if you're using Spring Boot 3.2, you need only specify `spring.threads.virtual.enabled=true` to benefit from them! Virtual threads are part of a slate of new features, which have been more than half a decade in coming, designed to make Java the lean, mean scale machine we all knew it deserved to be. And it's working! Virtual threads was one of three features, designed to work together. Virtual threads are the only feature that has been delivered in a release form, as yet. Structured concurrency and scoped values have both yet to land. Structured concurrency gives you a more elegant programming model for building concurrent code, and scoped values give you an efficient and more versatile alternative to `ThreadLocal`, particularly useful in the context of virtual threads, where you can now realistically have _millions_ of threads. Imagine having duplicated data for each of those! These features are in preview in Java 22. I don't know that they're worth showing, just yet. Virtual threads are the magic piece, in my mind, and they are so magic precisely because you don't really need to know about them! Just set that one property, and you're off. Virtual threads give you the amazing scale of something like `async`/`await` in Python, Rust, C#, TypeScript, JavaScript, or `suspend` in Kotlin, but without the inherent verbosity of code and busy work required to use those language features. It's one of the few times where, save for maybe Go's implementation, Java is just straight-up better in the result. Go's implementation is ideal, but only because they had this baked in to the 1.0 version. Indeed, Java's implementation is more remarkable precisely because it coexists with the older platform threads model. ## Implicitly Declared Classes and Instance Main Methods This preview feature is huge quality-of-life win, even though the resulting code is smaller, and I warmly welcome it. Unfortunately doesn't really work with Spring Boot, at the moment. The basic idea is that one day you'll be able to just have a top-level main method, without all the ceremony inherent in Java today. Wouldn't this be nice as the entry point to your application? No `class` definition, no `public static void`, no unneeded `String[]` args. void main() { System.out.println("Hello, world!"); } ## Statements Before Super This is a nice quality of life feature. Basically, Java doesn't let you access `this` before invoking the super constructor in a subclass. The goal was to avoid a class of bugs related to invalid state. But it's a bit heavy handed, and forced developers to resort to `private static` auxillary methods whenever they wanted to do any sort of non-trivial computation before invoking the super method. Here's an example of the gymanastics sometimes required. I stole this example from [the JEP]() page itself: class Sub extends Super { Sub(Certificate certificate) { super(prepareByteArray(certificate)); } // Auxiliary method private static byte[] prepareByteArray(Certificate certificate) { var publicKey = certificate.getPublicKey(); if (publicKey == null) throw new IllegalArgumentException("null certificate"); return switch (publicKey) { case RSAKey rsaKey -> ///... case DSAPublicKey dsaKey -> ... //... default -> //... }; } } You can see the problem. This new JEP, a preview feature for now, would allow you to inline that method in the constructor itself, promoting readability and defeating code sprawl. ## Unnamed Variables and Patterns Unnamed variables and patterns are another quality-of-life feature. This one, however, is already delivered. When you're creating threads, or working with Java 8 streams and collectors, you're going to be creating lots of lambdas. Indeed, there are plenty of situations in Spring where you'll be working with lambdas. Just think of all the `*Template` objects, and their callback-centric methods. `JdbcClient` and `RowMapper`, eh... _spring_ to mind, too! Fun fact: Lambdas were first introduced in 2014's Java 8 release. (Yes, that was a _decade_ ago! People were doing the ice bucket challenges, the world was obsessed with selfie sticks, _Frozen_, and _Flappy Bird_.), but they had the amazing quality that the almost 20 years of Java code that came before them could participate in lambdas overnight if methods expected a single method interface implementation. Lambdas are amazing. They introduce a new unit of reuse in the Java language. And the best part is that they were designed in such a way as to sort of graft onto the existing rules of the runtime, including adapting so-called _functional interfaces_ or SAMs (single abstract method) interfaces automatically to lambdas. My only complaint with them is that it was annoying having to make things final that were referenced from within the lambda that belong to a containing scope. That's since been fixed. And it is annoying having to spell out every parameter to a lambda even if I have no intention of using it, and now, with Java 22, that too has been fixed! Here is a verbose example just to demonstrate the use of the `_` character in two places. Because I can. package com.example.demo; import org.springframework.jdbc.core.simple.JdbcClient; import org.springframework.stereotype.Component; import javax.sql.DataSource; @Component class AnonymousLambdaParameters implements LanguageDemonstrationRunner { private final JdbcClient db; AnonymousLambdaParameters(DataSource db) { this.db = JdbcClient.create(db); } record Customer(Integer id, String name) { } @Override public void run() throws Throwable { var allCustomers = this.db.sql("select * from customer ") // here! .query((rs, _) -> new Customer(rs.getInt("id"), rs.getString("name"))) .list(); System.out.println("all: " + allCustomers); } } That class uses Spring's `JdbcClient` to query the underlying database. It pages through the results, one by one, and then involves our lambda, which conforms to the type `RowMapper` to help in adapting our results into records that line up with my domain model. The `RowMapper` interface , to which our lambda conforms, has a single method `T mapRow(ResultSet rs, int rowNum) throws SQLException` that expects two parameters: the `ResultSet`, which I'll need, and the `rowNum`, which I'll almost never need. Now, thanks to Java 22, I don't need to specify it. Just plug in `_`, like in Kotlin or TypeScript. Nice! ## Gatherers Gatherers are another nice feature that is also in preview. You may know my friend [Viktor Klang]() from his amazing work on [Akka]() and for his contributions to Scala futures whilst he was at Lightbend. These days, he's a Java language architect at Oracle, and one of the things he's been working on is the new Gatherer API. The Stream API, which was also introduced in Java 8, by the way - gave Java developers a chance, along with lambdas, to greatly simplify and modernize their existing code, and to move in a more functional-programming-centric direction. It models a set of transformations on a stream of values. But, there are cracks in the abstraction. The Streams API has a number of very convenient operators that work for 99% of the scenarios, but when you find something for which a convenient operator doesn't exist, it can be frustrating because there was no easy way to plug one in. There have been countless proposals for new operator additions to the Streams API in the intervening ten years, and there were even discussions and concessions made in the original proposal for lambdas that the programming model be flexible [enough to support introducing new operators](). It's finally arrived, albeit as a preview feature. Gatherers provide a slightly more low-level abstraction that gives you the ability to plug in all sorts of new operations on Streams, without having to materialize the `Stream` as a `Collection` at any point. Here's an example I stole directly, and unabashedly, [from Viktor and the team](). package com.example.demo; import org.springframework.stereotype.Component; import java.util.Locale; import java.util.function.BiFunction; import java.util.function.Supplier; import java.util.stream.Gatherer; import java.util.stream.Stream; @Component class Gatherers implements LanguageDemonstrationRunner { private static Gatherer scan( Supplier initial, BiFunction scanner) { class State { R current = initial.get(); } return Gatherer.ofSequential(State::new, Gatherer.Integrator.ofGreedy((state, element, downstream) -> { state.current = scanner.apply(state.current, element); return downstream.push(state.current); })); } @Override public void run() { var listOfNumberStrings = Stream .of(1, 2, 3, 4, 5, 6, 7, 8, 9) .gather(scan(() -> "", (string, number) -> string + number) .andThen(java.util.stream.Gatherers.mapConcurrent(10, s -> s.toUpperCase(Locale.ROOT))) ) .toList(); System.out.println(listOfNumberStrings); } } The main thrust of that code is that there's a method here, `scan`, which returns an implementation of `Gatherer`. Each `Gatherer` expects an initializer and an integrator. It'll come with a default combiner and a default finisher, though you can override both. This implementation reads through all those number entries and builds up a string for each entry that then accumulates after every successive string. The result is that you get `1`, then `12`, then `123`, then `1234`, etc. The example above demonstrates that gatherers are also composable. We actually have two `Gatherer` in play: the one that does the scanning, and the one that maps every item to uppercase, and it does it concurrently. Still don't quite understand? I get the feeling that's going to be okay. This is a bit in the weeds for most folks, I'd imagine. Most of us don't need to write our own Gatherers. But you _can_. My friend [Gunnar Morling]() did just that the other day, in fact. The genius of the Gatherers approach is that now the community can scratch its own itch. I wonder what this implies for awesome projects like Eclipse Collections or Apache Commons Collections or Guava? Will they ship Gatherers? What other projects might? I'd love to see a lot of common sense gatherers, eh, well, _gathered_ into one place. ## Class Parsing API Yet another really nice preview feature, this new addition to the JDK is really tuned to framework and infrastructure folks. It answers questions like how do I build up a `.class` file, and how do I read a `.class` file? Right now the market is saturated with good, albeit incompatible and alway, by definition, ever so slightly out of date options like ASM (the 800 lb. gorilla in the space), ByteBuddy, CGLIB, etc. The JDK itself has three such solutions in its own codebase! These sorts of libraries are everywhere, and critical for developers who are building frameworks like Spring that generate classes at runtime to support your business logical. Think of this as a sort of reflection API, but for `.class` files - the literal bytecode on the disk. Not an object loaded into the JVM. Here's a trivial example that loads a `.class` file into a `byte[]` array and then introspects it. package com.example.demo; import org.springframework.aot.hint.RuntimeHints; import org.springframework.aot.hint.RuntimeHintsRegistrar; import org.springframework.context.annotation.ImportRuntimeHints; import org.springframework.core.io.ClassPathResource; import org.springframework.core.io.Resource; import org.springframework.stereotype.Component; import java.lang.classfile.ClassFile; import java.lang.classfile.FieldModel; import java.lang.classfile.MethodModel; @Component @ImportRuntimeHints(ClassParsing.Hints.class) class ClassParsing implements LanguageDemonstrationRunner { static class Hints implements RuntimeHintsRegistrar { @Override public void registerHints(RuntimeHints hints, ClassLoader classLoader) { hints.resources().registerResource(DEFAULT_CUSTOMER_SERVICE_CLASS); } } private final byte[] classFileBytes; private static final Resource DEFAULT_CUSTOMER_SERVICE_CLASS = new ClassPathResource( "/simpleclassfile/DefaultCustomerService.class"); ClassParsing() throws Exception { this.classFileBytes = DEFAULT_CUSTOMER_SERVICE_CLASS.getContentAsByteArray(); } @Override public void run() { // this is the important logic var classModel = ClassFile.of().parse(this.classFileBytes); for (var classElement : classModel) { switch (classElement) { case MethodModel mm -> System.out.printf("Method %s%n", mm.methodName().stringValue()); case FieldModel fm -> System.out.printf("Field %s%n", fm.fieldName().stringValue()); default -> { // ... } } } } } This example is made a bit more complicated because I am reading a resource at runtime, so I implemented a Spring AOT `RuntimeHintsRegistrar` that results in a `.json` file with information about which resource I am reading, the `DefaultCustomerService.class` file itself. Ignore all that. It's just for the GraalVM native image compilation. The interesting bit is at the bottom, where we enumerate the `ClassElement` instances and then use some pattern matching to tease out individual elements. Nice! ## String Templates Yet another preview feature, String templates bring String interpolation to Java! We've had multiline Java `String` values for a while. This new feature lets the language interpose variables available in scope in the compiled `String` value. The best part? In theory, the mechanism itself is pluggable! Don't like this syntax? Write your own. package com.example.demo; import org.springframework.stereotype.Component; @Component class StringTemplates implements LanguageDemonstrationRunner { @Override public void run() throws Throwable { var name = "josh"; System.out.println(STR.""" name: \{name.toUpperCase()} """); } } ## Conclusion There's never been a better time to be a Java and Spring developer! I say it all the time. I feel like we're being given a brand new language and runtime, and it's being done - miraculously - in such a way as to not break backwards compatibility. This is one of the most ambitious software projects I've ever seen the Java community embark on, and we are lucky to be here to reap the rewards. I'll be using Java 22 and GraalVM support Java 22 for everything from now on, and I hope you will too. Thanks for reading along, and I hope if you liked it that you'll feel free to check out our Youtube channel and my _Spring Tips_ playlist where I will for sure [be covering Java 22 and much more](). Thanks, also, to my friend and [GraalVM developer advocate extraordinaiire Alina Yurenko (@http://twitter.com/alina_yurenko/status/1587102593851052032?s=61&t=ahaeq7OhMUteRPzmYqDtKA) for helping me get some of these details right]()