Amber, Babylon, sun.misc.Unsafe and the rest: Java's plans for 2024 - JVM Weekly vol. 162

1. Java plans for 2024

Let’s start with a video – Nicolai Parlog, Java Developer Advocate, has released a video of the language’s development plans for the next twelve months:

TLDW: In 2024, Java will be developed by well-known projects such as Amber (for smaller productivity-enhancing features) or Valhalla (improving Java’s object model through valuable objects for better performance), but also new ones such as Babylon (extending Java with so-called Code Reflection). These projects, as well as the already well-known Leyden, Lilliput, Panama, and Loom (which has achieved most of its goals and will be phased out), aim to improve Java in areas such as code reflection, runtime, memory efficiency, native code compatibility or concurrency. Don’t expect all the activities to close in the current year – many of the above I assure you will stretch into 2025.

Which project are you most excited about? I’m torn between Leyden and Babylon which was recently featured in an interesting episode of airhacks.fm by Adam Bien. In a conversation that lasted over an hour, Paul Sandoz disclosed several details about Babylon.

We have also received the first information in the context of the future of Project Amber. Brian Goetz (in his signature mail-essay form) published Towards member patterns, which presents a comprehensive view of the future evolution of pattern matching in Java. In the article, Goetz proposes an approach for the further integration of Pattern Matching into the wider context of the Java object model. One can imagine patterns as inverse constructors and methods, where the relationship between inputs and outputs is reversed compared to traditional methods. The principle of duality leads to more consistent API design, as it encourages developers to think of methods and patterns as related pairs.

The concept of ‘deconstruction patterns’, once presented, is also reintroduced. They allow each class to declare an explicit pattern for deconstruction, providing a generalization over the existing pattern matching for Records. Additionally, the text introduces the concept of static patterns, which can be used for classes that prefer static factories over constructors. It can be seen that Goetz thinks about Pattern Matching holistically and tries to handle as many cases as possible. However, the text emphasises that they do not all have inverses, as some operations, especially those involving side effects or complex interleaved arguments, do not lend themselves to such simple inversion.

I stand by the statement that Java is the most sensibly developed programming language.

2. Also early in the year – New JEPs

We’ll stay on the subject of the future of Java, as the start of the year also means some new proposals. In addition to a few barebone updates (which we focus on a bit later), we also have absolute highlights, such as:

JEP draft: Deprecate Memory-Access Methods in sun.misc.Unsafe for Removal

We’re entering 2024 with a bump, as the aim of the above JEP is to deprecate and eventually remove memory access methods from the sun.misc.Unsafe class, which should be internal to the JDK, but has been used over the years by various projects that wanted a direct way to manage memory. The proposal comes in light of safer and more efficient alternatives: VarHandle in JDK 9 for heap memory and MemorySegment in JDK 22 for off-heap memory (one outside of JVM control).

During the initial phase, all memory access methods in sun.misc.Unsafe will be designated as deprecated, resulting in warnings during the compilation process. Subsequently, their usage will lead to compilation errors, although there will be an option to use a suitable flag to deactivate them. This will be succeeded by the step-by-step elimination of methods, starting with methods that operate on the heap and then moving to that controlling off-heap memory. This process will be carried out gradually to minimize the effect on existing libraries and applications. Notably, the JEP does not intend to completely remove the sun.misc.Unsafe class, but only specific methods used for memory access – however, plans are in place to gradually phase out the remaining operations in the future.

JEP draft: Implicitly Declared Classes and Instance Main Methods (Final)

Work focusing on making Java more accessible to beginners is coming to a close. It looks like the second preview version that we will see in JDK 22 is the final solution. This is because the final version does not introduce any changes, but only stabilises the proposed API.

JEP draft: String Templates (Final)

The same holds true for String Templates. All signs point to them being finalized in a version that aligns with what we will see during the release of JDK 22.

JEP 455: Primitive Types in Patterns, instanceof, and switch (Preview)

The above ones are just drafts, but we have lived to see the first JEP targeted to the JDK 23 release. And it’s a JEP that’s insanely interesting because it’s talking about a feature that’s strictly related to Project Valhalla.

I will start with a short reminder for those who may be a bit confused and are still trying to grasp the new terminology. Project Valhalla introduces a concept in Java called ‘Primitive Types’. This concept aims to merge the benefits of primitive types – like int or double – with the versatility of objects. The primary objective of Primitive Types is to enable the development of data types that function with the efficiency of primitive types, while also providing the features of objects, such as being utilized as generic types and in collections. The attributes and traits of these types have developed over time with each new iteration of Valhalla, and now, we finally have the first related JEP, which has been prepared for a specific JDK release.

JEP 455, which can be found here, is centered around the enhancement of pattern matching. It introduces Pattern Matching in the aforementioned instanceof and switch commands for primitive types. The goal is to standardize the handling of all data types, aligning with the maximalist approach previously detailed by Brian Goetz.

The fact that this proposal was released before receiving the final proposal regarding the primitive types is intriguing. This suggests that there is likely a lot of activity happening behind the scenes, and we should anticipate further updates shortly. This situation has significantly piqued my interest in JDK 23, as it implies that this release may include numerous additional Valhalla-related surprises.

3. Jakarta EE 11 in the end comes with support for JDK 17.

I was under the impression that the last period has been a constant competition between individual projects about who will require the latest version of Java. Not to look far, such Spring Boot 3.0 or the new release of Quarkus is a minimum of JDK 17, Helidon ups the ante, because version 4.0 already requires JDK 21 – and there was no shortage of similar announcements. The Eclipse Foundation was similarly ambitious, announcing that due to the initial support for Virtual Threads in Jakarta Concurrency 3.1, developers would have to use just JDK 21 from the release of Jakarta EE 11. The beginning of 2024, however, brought announcements of some changes.

Ivar Grimstad, Developer Advocate Jakarta EE, has in fact announced a step backwards – as the developers of the new version have decided that they are changing their decisions and will also support JDK 17 and that in order to be certified, implementations of the standard must meet the specifications on both JDK 17 and 21. This decision is based on current trends in technology adoption and user preferences. Data from New Relic and VSCode Java telemetry indicate a significant preference for Java SE 17 or lower versions, suggesting that the requirement to use Java SE 21 may be too much of a constraint. Support for both Java SE 17 and 21 ensures that migration to Jakarta EE 11 will be easier. As discussed in the GitHub Issue, support for Virtual Threads is still within the scope of the release, it is just that in the event of running on JDK 17 the Virtual Threads-related APIs will use classic threads. As specified in the documentation

When {@code true}, the thread factory can create
* virtual threads if it is capable of doing so
* and if the request is not overridden by vendor-specific
* configuration that restricts the use of virtual threads.

Let’s be honest – JDK 17 support is a logical step. Jakarta EE has never set trends but has always been an oasis of stability, so broader compatibility here is reasonable. It would be regrettable if the sole API (Jakarta Concurrency 3.1) significantly obstructed upgrades, particularly in organizations with strict rules about permissible JDK versions. Developers mustn’t be over-restricted by adherence to compatibility, but when only one API was mentioned, this seems like a reasonable compromise to me.

Amber, Babylon, sun.misc.Unsafe and the rest: Java’s plans for 2024 – JVM Weekly vol. 162