The future and present of Enterprise Java: a first look at Jakarta EE 11 and MicroProfile 6 adoption - JVM Weekly vol. 133.

1. A rash of new candidate JEPs

Let’s start with the biggest one – JEP 447: Statements before super(). This JEP is interesting because it contains changes to the JLS – Java Language Specification. This is a formal document that describes the syntax and semantics of Java. The JLS is a guide not so much for programmers, but for compiler and tool developers to ensure consistent and accurate implementation of the language across platforms and environments.

Not every JEP includes changes to the language specification. Examples of JEPs editing the JLS include JEP 286: Local-Variable Type Inference (the new keyword ‘var’ its rules) or JEP 354: Switch Expressions, extending the switch statement to also be used as an expression, and introducing the use of so-called “Arrow labels” (e.g., case 1 ->). The JLS had to be updated to accommodate the aforementioned new switch syntax.

Returning to JEP 447: Statements before super(), the proposal is intended to loosen restrictions on Java constructors and allow for other calls even before this() or super(), as long as instance fields are not read until superclass constructs are complete, such as initializing variables.

Interestingly, the Java Virtual Machine Specification (JVMS) – the JLS equivalent for the VM – already allows this. While JLS has some limitations related to the static context (and some bugs from the past), from the VM’s point of view, there is nothing limiting constructors to function properly. The proposed changes would create a new concept called “pre-initialization context”, which is less restrictive than the existing “static context” and would allow declarations to appear before calls to this() and super().

Recently, we have also received JEP 449: Deprecate the Windows x86-32 Port. Through it, JDK developers are trying to remove the support for the 32-bit version Windows operating system. Several factors have contributed to such a step, such as the fact that Microsoft (the change was proposed by this very company, by the way) has finally stopped releasing new versions of 32-bit operating systems, and the last of them (Windows 10) will lose support in the second half of 2025. Much more interesting here, however, are the practical motives – for it turns out from the JEP that the Virtual Threads implementation is not compatible with 32-bit processors.

Probably that fact was known for a long time, and only I was taken by surprise and found out about it rather recently.

Also, soon those trying to build an application using the JDK on already abandoned systems will be greeted by the following message.

configure: error: The Windows x86-32 port is deprecated and may be removed in a future release.

Well, 32-bit processors are now a thing of the past – arm32 architecture will remain the last supported version.

And that’s all folks when it comes to JEP 446, Scoped Values (Preview).

The following excerpt (gray) is the only changes that appeared between JEP 446 – Scoped Values (Preview) and JEP 429: Scoped Values (Incubator), which appeared in JDK 20. As you can see, there isn’t much of that.

Oh, and they didn’t forget about the Vector API this time, as they did with JDK 20. It got its (already sixth) incubation in JEP 448. But that’s pretty much the only interesting news in the context of this API, long awaiting the release of the Valhalla API. This is because the long-term goal of the Vector API is to take advantage of Valhalla’s enhancements, especially Primitive Classes, with no identity. Thus, the Vector API will be incubated for many releases until the necessary Project Valhalla features become available as Preview. Then the Vector API will be adapted to its semantics and then released as Preview.

Sources

2. First information on Jakarta EE 11 and further adoption of MicroProfile

The past week has also seen a rash of announcements related to Enterprise Java (in the broader sense). So let’s start with the biggest one, which is the presentation of the first plans for Jakarta EE 11.

The Jakarta EE steering committee has outlined four main priority areas for the projects: making it easier for new community members to “enter” the project, unifying the platform around modern APIs such as CDI, and reducing internal inconsistencies that have built up over the years, introducing new specifications such as Jakarta Config and Jakarta Data, and “catching up” with modern Java. The new release aims to take advantage of the novelties that will appear in the latest LTS – Java 21. Although the developers do not declare at this stage a desire to abandon older releases, the announcement promise, for example, the use of the new capabilities provided by Project Loom. However, the steering commitee is not forgetting other recent developments of the Java platform and declared its willingness to take a closer look at the novelties of the last few years as well, such as Records.

The community aspect is very interesting. The process of getting involved in the development of the platform is supposed to be simplified, with clearer signposts and guidance for new contributors – standardization of procedures across projects and better documentation is supposed to help achieve this. The first sign may be the fact that already at this early stage the developers have provided a document (in Google Docs!), allowing one to look in detail at the ideas for the new release. You can, for example, see from behind the scenes how topics such as bringing MicroProfile and Jakarta closer together, or the gradual move away from EJB.

The target release date for Jakarta EE 11 is the first quarter of 2024, about six months after the release of Java 21.

That’s not the end of news related to Enterprise Java, however, as WildFly 28 has been released. The project has recently abandoned the Release Train, moving to releases related to some specific, big new features. This time it’s to match the recent changes to MicroProfile.

Particularly big changes have taken place in the context of so-called “observability,” but in order to understand them, it’s necessary to outline a bit more context. The organization dedicated to creating standards when it comes to Tracing – that is, tracking individual events within an application – is the Cloud Native Computing Foundation (CNCF for short). Several competing projects have been developed over the years, such as OpenCensus and OpenTracing. The latter came to MicroProfile as the MicroProfile OpenTracing API, and WildFly has already implemented support for it in the past.

At the beginning of the year, CNCF decided to abandon the development of OpenTracing in favor of OpenTelemetry, which is a slightly broader project. Due to that MicroProfile decided to not waste effort on its OpenTracing API as well, as of version 6.0 of the project, it too ceased to be supported. MicroProfile Telemetry Tracing was created in its place, implementing the OpenTelemetry-derived Tracing standard. Accordingly, WildFly has also made such changes, creating a new microprofile-telemetry module which replaces OpenTelemetry.

That’s not the end of the story, thou – WildFly has also decided to drop support for the MicroProfile Metrics API, a metrics standard being actively developed within MicroProfile. Instead, WildFly will use Micrometer, a facade similar in nature to SLF4J that allows working with multiple metrics systems. Key to this decision is the stabilization of OpenTelemetry Metrics – a metrics standard by OpenTelemetry, as you could probably guess – which is supported by Micrometer. These are steps that Quarkus has also made recently – so Micrometer is slowly becoming the standard when it comes to Java Metrics.

But it is well know how standard works in practice

Ending the MicroProfile topic, WildFly introduces support for MicroProfile LRA (Long Running Action), which is a side project not part of the main standard. The new WildFly also has some minor changes, but I recommend you check it out for yourself in the Release Notes.

Concluding this already lengthy section, it’s worth mentioning the new release of Open Liberty, the “cloud-based” application server being developed by IBM. The new release of OpenLiberty 23.0.0 is a big leap forward – it includes full support for Jakarta EE 10, functionality coming with JDK 20 and MicroProfile 6. The latter in particular is interesting here – unlike WildFly, IBM has also decided to support MP Metrics.

This allows them to boast full compatibility with the MicroProfile 6.0 standard – something that WildFly can’t do due to the choice of Micrometer as a metrics provider.

Sources

3. Release Radar: Micronaut & Ktor

Micronaut 3.9.0

Micronaut has released Micronaut Framework 3.9.0, introducing new features such as configurable introspection packages with @Introspected annotation, annotation-based CORS configuration. The release also includes a slew of updates to individual modules – Micronaut Kubernetes received a “major” new release (4.0), while Micronaut Security, Micronaut Maven, Micronaut Launch/CLI, and Micronaut CRaC received updates. Related to the latter is the fact that as of the new release, AWS Lambda functions created with Micronaut have AWS SnapStart enabled by default.

Micronaut Framework has also expanded support for configuration file types and now supports YAML, properties, TOML, Groovy and Hocon. In addition, the project’s documentation has been updated to show configuration snippets in the various supported formats.

Minor and major improvements have also been made to external integrations. Micronaut 3.9.0 brings several new ones – for Azure Cosmos DB, Google CloudEvents, Google Cloud Functions, or Slack. Many existing ones, such as e.g. Micronaut ElasticSearch or Micronaut Micrometer, meanwhile, have received updates.

Ktor 2.3.0

To not make this edition so completely devoid of Kotlin topic – JetBrains has released Ktor 2.3.0, introducing a number of small improvements. Among other things, Sockets got support for better Coroutines and Structure Concurrency support, while WebSockets received typing support. Also following the development of Kotlin itself, the new release sues the existing JavaScript compiler, using a new intermediate representation.

In addition, regular expressions can be now used in routing, there was a Static Content API refactoring, and support for Jetty 11 and Tomcat 10 appeared. The ability to merge several configuration files was also made available, making it easier to modularize projects. Finishing the list of changes, sanitization of sensitive headers is now available in the Logging plugin.

PS: Quarkus 3.0 has also appeared. But it’s such a big release that I don’t want to rush myself – I prefer to play with it a little first and devote a whole separate section to it next week. After all, there are a whole bunch of changes underneath.

The future and present of Enterprise Java: a first look at Jakarta EE 11 and MicroProfile 6 adoption – JVM Weekly vol. 133.

1. A rash of new candidate JEPs

Sources

2. First information on Jakarta EE 11 and further adoption of MicroProfile

Sources

3. Release Radar: Micronaut & Ktor

Micronaut 3.9.0

Ktor 2.3.0

Discover more great content!