Java's Plans for 2024 - Inside Java Newscast #61
Summary
TLDRThe 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
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.
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.
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.
Mindmap
Keywords
💡OpenJDK
💡pattern matching
💡Project Leyden
💡Project Loom
💡Project Panama
💡Project Valhalla
💡records
💡Project Babylon
💡Project Lilliput
💡JEP 401
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 ...
Voir Plus de Vidéos Connexes
Copilot experiences in Microsoft Planner help transform your work management
REBUILDING A BARN FIND R32 SKYLINE | PART 7
The Disappointing Truth About Giga Mexico
Meet the new Microsoft Planner
Why Elon Musk Is Betting Big On Supercomputers To Boost Tesla And xAI
Welcome + Opening Remarks - Austin Parker, OTel Community Day Event Chair
México anuncia Nuevo Tren de pasajeros unirá estás ciudades: QRO, CDMX, GDL, SLP, GTO Y AGS
5.0 / 5 (0 votes)