Java's Plans for 2024 - Inside Java Newscast #61

Summary

The transcript covers upcoming Java language and JVM features that are expected to be worked on in 2024. It focuses on the major OpenJDK projects like Project Babylon, Project Loom, Project Leyden, Project Amber, Project Panama, Project Valhalla, and Project Lilliput. The key points are: - Project Babylon will expand Java's reflection API to allow code analysis and transformation. This enables use cases like auto-differentiation, GPU programming, and more. Babylon is still in early stages so major updates are not expected in 2024. - Project Loom brought virtual threads, structured concurrency and scoped values APIs which will likely finalize in 2024. Work remains to make synchronization non-pinning and file I/O non-capturing. Unclear if that will happen in 2024. - Project Leyden has shown 50-80% performance improvements for Spring Boot without constraints. The focus in 2024 is bringing these optimizations out of prototype stage into production use. Unlikely to see tangible changes in 2024. - Project Amber will finalize string templates, simplified main, and statements before this()/super() in 2024. Exciting new feature on the horizon is 'with' expressions for boilerplate-free record copies. Also considering expanding switch for exceptions and deconstruction assignments. - Project Valhalla will focus on JEP 401 value types and objects in 2024. Other topics like nullness markers and generic specialization unlikely to see public progress until JEP 401 stabilizes. - Project Panama will improve the Foreign Function Interface API and jextract native binding tooling. Vector API remains in incubation. - Project Lilliput aims to reduce object header sizes but alternative locking needs more work before that can happen. Unlikely to see header size reductions in 2024. The overarching message is that while many OpenJDK projects made great progress in 2023, 2024 will be focused on incremental improvements, stabilization and hardening features for production use rather than big splashy changes.

Takeaways

• Project Babylon aims to expand Java's reflection API to allow code analysis and transformation.
• Project Loom is nearing completion, with virtual threads and structured concurrency APIs finalized.
• Project Leyden is working to bring considerable performance improvements to all Java code.
• Project Amber continues driving Java's language evolution with features like string templates and `with` expressions.
• Progress is being made on value types and generics specialization in Project Valhalla.
• Project Panama focuses on improving APIs for calling native code from Java.
• Project Lilliput aims to reduce object header sizes to improve memory efficiency.
• A prototype for code reflection in Project Babylon was recently published.
• Features like pattern matching and records set the stage for upcoming work on `with` expressions.
• Improvements like fast-locking are needed before Lilliput can reduce header sizes.

Q & A

What is the goal of Project Babylon?

Project Babylon aims to expand Java's reflection API to allow code analysis and transformation. This will enable use cases like differentiating mathematical functions expressed in Java code.

What is the current status of Project Loom?

Project Loom is nearing completion, with key features like virtual threads and structured concurrency APIs already finalized in JDK versions. The remaining work is focused on smaller improvements and additions.

How does Project Leyden improve performance?

Project Leyden introduces an optional 'condenser' phase that shifts computation earlier and applies optimizations, speeding up the final program without requiring code changes.

What features is Project Amber working on?

Project Amber is driving Java's language evolution. Some current features under development are string templates, simplified `main`, statements before `this()`/`super()`, and `with` expressions.

What is the focus of Project Valhalla?

Project Valhalla is focused on value types and generics specialization. Specifically, work is progressing on JEP 401 for value classes and objects.

What does Project Panama aim to improve?

Project Panama focuses on improving APIs for calling native code from Java. Work in 2024 will focus on improving the jextract tool and tooling.

What is Project Lilliput's goal?

Project Lilliput aims to reduce object header sizes to improve memory efficiency. This requires work like the fast-locking scheme before header sizes can be reduced.

What recent progress was made on Project Babylon?

A prototype for code reflection was recently published to the Project Babylon repository, enabling initial use cases.

How do recent features relate to `with` expressions?

Features like pattern matching and records lay the groundwork for `with` expressions by enabling deconstruction of immutable objects.

What does Lilliput need to do before reducing header sizes?

Improvements like the alternative fast-locking scheme are needed in Lilliput before header sizes can be reduced.

Outlines

00:00

Introduction and Overview

The video introduces upcoming Java developments for 2024. It will cover the major OpenJDK projects and what they plan to work on this year, though not everything will be released in 2024. The predictions may not be fully accurate since the future is unpredictable. The video was recorded in the city where the host recently gave a Java User Group talk.

05:01

Project Babylon and Code Reflection

Project Babylon builds on code reflection presented at the JVM Language Summit. Code reflection allows analyzing and transforming Java code inside a method. This enables writing Java code that libraries can interpret for differentiation, GPU programming, etc. Babylon has pushed a prototype and will publish work on use cases like auto-differentiating and GPU programming in Java.

10:04

Project Loom and Concurrency

Project Loom's virtual threads and structured concurrency APIs will likely finalize in 2024. Remaining work is minor improvements like making synchronization non-pinning and file I/O non-capturing on Linux. It's uncertain if these will release in 2024 since JDK 23 fork is soon.

Project Leyden and Performance Improvements

Project Leyden improved Spring Boot startup time by 50-80% in prototypes using condensers, without constraints. The goal is to productize these benefits in 2024 but unsure if will land this year.

Project Amber and Language Evolution

Project Amber has string templates, simplified main, and statements before this()/super() in preview. These likely finalize in 2024 but not necessarily JDK 23. Excited about upcoming 'with' expressions for records. Also considering expanding switch for exceptions and deconstruction assignments.

Project Valhalla and Value Types

Progress on value types and objects to enable shallowly immutable value classes that improve efficiency. Also considering nullness markers and generic specialization. Unsure if current proposals will be final version.

Project Panama and Native Integration

Vector API is production-ready but will change post-Valhalla. Foreign function API improved. Focus is improving tooling like jextract for simpler native library integration.

Project Lilliput and Compact Objects

Lilliput merged fast-locking scheme needed to later reduce object header size. Improvements still needed so unsure if header size reductions will land in 2024.

Keywords

💡OpenJDK

OpenJDK is an open source implementation of the Java Platform, Standard Edition. It is the code base that underlies Oracle's Java SE products. Nicolai discusses the plans for OpenJDK projects in 2024, like Project Babylon, Loom, Leyden etc. He focuses on what new features or improvements these projects are working on that may get released in 2024 or later.

💡pattern matching

Pattern matching is a language feature that allows deconstructing complex data types like objects into their components and matching against patterns. Brian Goetz and the Amber project have been working on adding pattern matching to Java. Nicolai mentions how with the basics done in JDK 21, work in 2024 will focus on expanding pattern matching like adding support for primitive types.

💡Project Leyden

Project Leyden is working on improving Java startup time and reducing application footprint by introducing a new build stage called condensers. Nicolai discusses Leyden's progress in 2023 on condensers and how in 2024 it will focus on bringing those performance improvements into production.

💡Project Loom

Project Loom delivered virtual threads in Java which are now finalized. Nicolai says Loom's main work now is minor improvements and additions to the APIs. He hopes work in 2024 can make synchronization non-pinning and file I/O non-capturing.

💡Project Panama

Project Panama focuses on interoperating with non-Java APIs and code. Nicolai explains Panama's work in 2024 will be on improving the foreign function API, the vector API which is production-ready but needs rework for Valhalla, and improving jextract which generates bindings for native libraries.

💡Project Valhalla

Project Valhalla aims to improve performance and memory efficiency of certain specialized objects in Java through optimizations like flattened heap and reduced headers. Nicolai is uncertain if any specific proposal will finalize in 2024 but says work will continue on value types and objects per JEP 401.

💡records

Records are a new construct added in Java 14. Nicolai mentions how the immutability of records' final fields makes boilerplate 'wither' methods desirable, and that Amber may work on 'with' expressions in 2024 to simplify this.

💡Project Babylon

Project Babylon, led by Paul Sandoz, aims to expand Java's reflection API to allow code analysis and transformation. Nicolai discusses its recent progress and prototypes, though he doesn't expect anything in mainline JDK before 2024.

💡Project Lilliput

Project Lilliput wants to reduce object header sizes in Java for better memory efficiency. Nicolai explains in 2024 it will continue improving the fast-locking scheme needed before actual header reduction.

💡JEP 401

JEP 401 specifies value types and objects in Project Valhalla. Nicolai says most of Valhalla's focus in 2024 will be on improving value types and objects per this JEP, though unsure if it will finalize this year.

Highlights

Project Babylon was founded to expand Java's reflection API to allow code analysis and transformation

Project Loom is nearing completion, with virtual threads and structured concurrency APIs finalized or nearing finalization

Leyden made performance improvements to Spring Boot startup time by 50-80% with no constraints

Amber is working on `with` expressions to simplify creating copies of records with modified fields

Panama is focused on improving jextract to simplify working with native libraries

Lilliput is working on an alternative fast-locking scheme to allow reducing object header size

Valhalla is focused on JEP 401 for value types and value objects

Amber may expand `switch` to handle exceptions from selector expressions

Amber may add deconstruction assignments

Patterns may soon support primitive types

The vector API is production-ready but may change after Valhalla lands

FFM API improvements continue, e.g. mapping native memory to Java abstractions

Babylon may enable auto-differentiation, C# LINQ emulation, GPU programming

Leyden may convert prototypes to tangible mainline improvements in 2024

Lilliput may reduce object header size to 64 or even 32 bits after improvements

Transcripts

Project Babel, GPU kernel, Project Loom, Project Leyden, considerable performance improvements,

Project Amber, `with` expressions, Project Panama, Valhalla, Lilliput

Happy Gregorian new year, everyone, and welcome to the Inside Java Newscast, where we cover

recent (and in this case future) developments in the OpenJDK community.

I'm Nicolai Parlog, Java Developer Advocate at Oracle, and today we're gonna talk about

Java's plans for 2024.

Or, more specifically, what the big OpenJDK projects will be working on this year - of

course, there's much more development going on.

And note that "working on this year" is very different from "releasing this year", not

least because for a feature to be released in 2024, it has to be finished and merged

into the JDK main line by mid June, so more than half of 2024's completed work won't even

be released before 2025.

The last caveat is that nobody can predict the future, least of which software developers,

which is why the smart folks in OpenJDK usually don't.

Luckily for us, I'm not that smart and so I'll predict all kinds of things in this video,

which makes all errors mine.

Ready?

Then let's dive ... Oh wait, by the way I recorded this in a city

where I recently gave a talk at the local Java User Group - I'll let you guess where

I was.

Now: Let's dive right in!

During the JVM Language Summit last August, Paul Sandoz presented _code reflection_, an

expansion of the reflection API that allows access, analysis, and transformation of Java

code inside a method.

Its goal is to allow developers to write Java code that libraries can then interpret as

a mathematical function, for example to differentiate it, which is common in machine learning, or

they can transform it to a GPU kernel, to part of an SQL statement, or to anything else,

really.

I covered this in some detail in Inside Java Newscast #58.

Later in 2023 Paul's exploration led to the foundation of Project Babylon and just this

week he has pushed a prototype to the Babylon repository.

There's a link to his email announcing that and some context in the description.

Over the coming weeks, the Babylon team plans to publish work for a few use cases like auto

differentiating, a C# LINQ emulation, and GPU programming in Java.

Babylon is still in its early stages, though, so I don't expect anything tangible in the

main line in 2024.

It feels a bit mean but I think it is fair to say that Project Loom's days in the spotlight

are coming to an end.

Virtual threads are final and the structured concurrency and scoped values APIs are in

their second preview in JDK 22 and I expect them to finalize some time this year.

While we start using these features in our code, what remains to be done for the project

are various improvements, either under the hood or as additions to these APIs.

And while they're minor relative to Loom's overall scope, that doesn't mean they're not

important.

I hope specifically that there'll be progress on making synchronization non-pinning and

file I/O non-capturing, at least on Linux with io_uring.

I don't know whether that progress will be sufficient for a release in 2024, though - the

JDK 23 fork is just five months away, after all.

But maybe for the next release after that?

I'm crossing fingers - or rather, pressing thumbs, because that's what we do in Germany.

The last time we walked through the snow, I told you about Project Leyden's concept

of condeners.

A _condenser_ is an optional transformation phase that takes a code artifact (like bytecode)

as input and produces another artifact as output that can contain new code (like ahead-of-time

compiled methods), new data (like serialized heap objects), or new metadata (like pre-loaded

classes).

The condenser performs some of the computation expressed in the input artifact, thereby shifting

that computation from some later phase to the current phase; applies optimizations enabled

by that shift so the new artifact is faster, smaller, or otherwise "better"; and it possibly

imposes constraints but more on that later

In 2023, Leyden made progress researching potential condensers and at JVMLS Mark Reinhold

and John Rose presented some considerable performance improvements, where they shortened

a Spring Boot app's time to "Hello World" by 50-80%.

And the cool thing about these improvements is that they require absolutely no constraints

- they work with all of Java's features, even the most dynamic ones!

In 2024, Leyden works to bring these benefits out of their prototype state and to deliver

them to us, but it's hard to say whether we can expect anything tangible to land this

year.

Project Amber stays the powerhouse behind Java's language evolution.

It currently has three features in preview: string templates,

simplified `main` (both in their second preview), statements before `this()` and `super()` (which

is in its first preview),

I expect all three to finalize in 2024, although not necessarily in JDK 23.

One feature that isn't on that list yet and that I'm _very_ excited about are `with` expressions.

You know that anti-pattern of declaring setters for all fields?

(Yes, I called it an anti-pattern - don't @ me.)

This doesn't work when fields are final and so, in those situations, you'd want to create

methods that accept a value and return a new instance where all fields have the same value

as the current instance except for the one that was passed in.

So for a class `Name` with final fields `String first` and `String last`, you'd create a method

`withFirst(String first)` that returns a `new Name(first, this.last)` and similarly `withLast(String

last)` that returns a `new Name(this.first, last)`.

Methods like these, often called "withers", are useful but quite boilerplate-y, which

is made worse by the advent of records which always have final fields and thus almost require

withers.

To alleviate that, Brian Goetz' three year old white paper "Pattern Matching in the Java

Object Model" described `with` expressions.

They start with a record reference followed by the situational keyword `with` and a code

block.

At runtime, they take the record apart into its components and declare a mutable variable

for each that is accessible in the code block, which then gets executed.

The block can contain arbitrary code but its main function will be to assign new values

to at least one of the variables.

When it ran its course, the `with` expression will create a new instance of the record from

those variables.

So when you have a `Name` instance called `userName`, you can create a copy with the

same first but no last name, by running `var userFirstName = userName with { last = ""; };`.

So this feature has been in the pipeline for a while, but as far as I can tell, pattern

matching was simply more important.

But now that the basic building blocks for that are all final in JDK 21, I'm really hoping

for withers to be tackled next and to hear more details about them in 2024.

Speaking of pattern matching, though, you can see from the list of in-flight features

that work on it took a little breather.

But Brian Goetz, Gavin Bierman, Angelos Bimpoudis, and the other folks working on this are already

taking the next steps.

There's a JEP for a first preview of primitive types in patterns and it's already proposed

to target JDK 23.

That's JEP 455, link below the like button, and I'll tackle it in a future Newscast, so

make sure to subscribe.

And then there was a really interesting mail from Brian Goetz on the Amber mailing list

in December: It considered expanding `switch` to handle

exceptions that occur when evaluating the selector expression - that's the method calls

you can put into the parenthesis after `switch`.

And Brian also promised us deconstruction assignments a while back!

Although at this point we might be crossing over from "plans for 2024" into "Nicolai's

wishlist", so I'll stop here.

But it's clear that Amber's not slowing down and will keep shaping Java's evolution.

I still remember the old days, when I was a young whippersnapper, and thought Valhalla

is just around the corner and Brian Goetz was just too careful to admit it.

Now, three decades later (ok, it's not _that_ bad), I start to see his wisdom, though.

There have been a number of proposals that seemed good at the time but whenever one entered

the home stretch, it turned out that this is a relay race and they weren't the last

proposal after all.

Because with every new prototype, new revelations occurred and a better proposal was possible.

And I'm giving Brian and his team a lot of credit for not doing the easy thing and just

shipping something to get Valhalla over the finishing line but to work out the best possible

solution.

Is the current round of proposals it?

I wanna say yes, but maybe I'm just falling into the same trap again.

But either way, I can tell you what will be worked on - whether that'll be what ends up

in the JDK or when that happens is beyond me.

Work will be focused on JEP 401: "value classes and objects".

Instances of value classes will be shallowly immutable and lack identity which will often

make sense when modeling a domain, will categorically prevent certain kinds of bugs, and will give

the JVM much more freedom to encode simple values in ways that improve memory footprint,

locality, and garbage collection efficiency.

Beyond that there's the idea to enable nullness markers to get better heap flattening for

value objects - the issue and a conversation about that are linked in the description - and

of course generic specialization, but I doubt we'll see public progress on these as there's

little reason to work on specifics until JEP 401 is stable.

Project Panama has three irons in the fire:

The vector API is very stable for now and basically production-ready but because it

is very likely to change once Valhalla lands, it is still in incubation and sadly, I don't

expect that to change in 2024.

The foreign function and memory API, FFM for short, finalized in JDK 21 but is still being

improved.

For example, the team is currently working on a concept that allows user-friendly and

performant mapping between native memory segments and Java abstractions such as records and

interfaces.

And then there's jextract, the tool that generates FFM bindings from native library headers.

Improving it and the tooling around it will make working with native libraries much simpler

than before and is the main focus of Panama in 2024.

Every object on the heap has a header.

Project Valhalla aims to introduce optimizations that greatly reduce or even eliminate the

need for header bits for specific value type instances and Project Lilliput aims to reduce

header size for all regular objects, first to 64 and eventually to 32 bits.

I made a Newscast about Lilliput last year and project lead Roman Kennke gave a great

talk about it at JVMLS, both linked in the description.

In 2023, Lilliput merged an alternative fast-locking scheme, which is needed to later allow the

intended reduction of header size.

That scheme needs further improvements before it's ready for prime-time, though, and so

Lilliput is currently working on that and it seems to me that that'll take much of the

year, so I don't expect the header size improvements to land in 2024.

And that's it for Java's plans in 2024.

Leaving Amber and Valhalla aside, I heard most of you are looking forward to Babylon

the most.

I gotta say, from that list, my favorite is Leyden.

Let's see who gets to release an improvement first.

Talking about improvements, you may have noticed that the Inside Java Newscast changed its

look and feel in recent weeks.

I got a bit bored by the old style and wanted to shake things up a bit.

I'm super interested to hear what you think about it.

I'll see you in the comments and on screen again in two weeks.

So long ...