Everything you might have missed in Java in 2022 – JVM Weekly #119

1. The year GraalVM became a “thing”

If someone were to tell me to pick what I think was the biggest event in 2022 for JVM, I would point to everything that happened in the GraalVM world. The past year has greatly illuminated the place GraalVM occupies in the Java ecosystem.

The unclear licensing model has been the most significant barrier to GraalVM adoption for years. While the project for the universal virtual machine (one to rule them all 💍) has always been closely linked to the JDK, in practice, the relationship between the two has never been clear. It was developed in a different way, and distributed differently, but most importantly, it was based on a completely different license than OpenJDK. Both the community edition (GraalVM Community Edition) and the corporate edition (GraalVM Enterprise Edition) were owned by Oracle.

Additionally, we now know under which “umbrella” the entire transfer will take place. The GraalVM CE is a wider ecosystem, and only the part related to Java will be migrated to the JDK. That’s why a special initiative, Project Galahad, has been set up to design and carry out the entire process. The first step will be the introduction of the JDK’s second (or rather third) JIT compiler. It is also already known that the entire GraalVM will change its release cycle to synchronize with the JDK.

In addition to organizational/licensing changes, there have been significant new features in the platform itself. In addition to ongoing work on performance and support for new runtime environments (including M1 processors), the platform has been modularized. Until now, regardless of which of the many languages supported by GraalVM was used (and probably in 90% of cases it is Java), the base image contained the files necessary to run JavaScript or LLVM, for example. On the other hand, Python or Ruby had to be directly installed. The situation was cleaned up in 2022, and now each additional module must be installed – “bare” GraalVM only supports Java (which probably makes it much easier for the team responsible for Galahad). The advantage of this solution is that it has significantly reduced the base image size, at the cost of a few additional commands for LLVM or JS programmers. All for the greater good.

GraalVM AD 2022 also has better support for external libraries. Since GraalVM creates a static image containing pre-compiled classes, it is forced to clean up those that are not achievable from the application root level. While this sounds reasonable, reflection has spread quite extensively in Java, which means that the application can refer to any arbitrarily available class on the classpath.

What if such a classpath does not exist? Luckily, we can pass GraalVM a list of classes it shouldn’t clean (Android developers probably know this mechanism from ProGuard). In the case of third-party libraries, however, this led to duplication of work when each project had to basically do it on its own. That’s why 2022 saw the emergence of the GraalVM Reachability Metadata Repository, a community hub for sharing such definitions – a bit like what happens with types in TypeScript, for example. Most importantly – GraalVM Native Build Tools can be configured to automatically pull these definitions into dependencies found in the code.

Discover more IT content selected for you

In Vived, you will find articles handpicked by devs. Download the app and read the good stuff!

2. investment in Java by BigTech giants

Most people probably know the AdoptOpenJDK project, which was created as a result of the efforts of the community fighting for a “free” implementation of the JDK when Oracle made the Oracle JDK paid for commercial use a few years ago. AdoptOpenJDK was initially developed by the community of JUGs from around the world, only to end up under the wings of the Eclipse Foundation. As a result, AdoptOpenJDK was renamed Eclipse Adoptium (JDK is a trademark belonging to Oracle), and the Adoptium Working Group was set up to take care of the project. Of course, someone has to work on and maintain this code, so the Adoptium Working Group has its corporate sponsors. And they are really big ones, and in 2022 we had several announcements related to this.

For example, RedHat (despite having its own OpenJDK for many years) in 2022 announced that it intends to focus on Temurin. This means the company’s customers can count on official support for this release, and it is one that is expected to be available in all of the company’s products. This is a slightly different model than, for example, Microsoft, which uses Temurin as a build for JDK 8, but has its own variants for later JDKs.

RedHat, however, has always been more or less associated with OpenJDK development. Much more surprising was the announcement from Google. Indeed, the company announced that it was joining the Adoptium working group as a Strategic Member. Google didn’t just limit itself to throwing piles of money at JDK, but together with Alibaba began working to accelerate the platform’s launch.

The aforementioned Microsoft, however, decided to go even wider. There are sometimes headlines after reading which I have to make sure I got it all right. At first, the news that Microsoft is becoming part of the standardization body for both Jakarta EE and MicroProfile just seemed to me… somehow unrealistic.

However, this is a fairly natural move: Microsoft has simply picked up low-hanging money. Azure will be the first cloud to provide native Java application server services. Both WebLogic and WebSphere or JBoss EAP are available right now.

Yet on the topic of cloud support for Jakarta, I continue to think that the most interesting new project of the year was Payara Cloud. The way it works is that you take your *.war compliant Jakarta Web Profile, upload it to the cloud and… you’re done. If we look at Application Servers as a runtime environment for applications (which they basically are), the “I upload a jar/war and forget about my cloud-native application” approach seems all too tempting.

Simply put, history has come full circle again.

3. JDK 11 in Android

In 2022, Android 13 was premiered, but you haven’t heard about it? No wonder. It used to be a really big event, but today the release in this case meant “merging” the whole thing into the main branch of AOSP (Android Open-Source Project) and releasing a new version for Pixels. Then, in turn, the waiting period begins for the rest of the market players to make their moves – a bit like the Linux Kernel. Also, the list of innovations is quite similar in both projects – most of the changes now take place “under the hood”.

So why am I writing about it? Well, along with “thirteen” we celebrated the transition of Android to OpenJDK 11, introducing to the platform e.g. the ability to use var, VarHandle with java.util.concurrent or many other additional APIs (like Optional.ifPresentOrElse() ❤️). It’s apparent that the results of the 2021 Google/Oracle trial have untied the developers’ hands, and they will be slow to implement Java innovations into Android.

4. Helidon Níma – the Loom-first Framework

Project Loom hasn’t really been off the tongues for most of 2022, but if I had to pick one announcement that is the most exciting in this context, it would be Helidon Níma. For it turns out that we are getting ready for the first(?) framework in which Loom will not be a tacked-on add-on, but a “First-Class Citizen.”

For now, the alpha version has been released, and we will still have to wait for the full version – as the developers have announced that work will be done on it roughly by the end of this year, when its stable release, parallel to Helidon 4.0, should be expected. For such an early stage, we’ve already received quite a bit of technical detail – the accompanying publication by Thomas Langer accompanying the release post focuses on how Níma at this stage compares to MicroProfile’s Helidon, as well as the direct competition the developers consider Netty to be. One of Níma’s goals is precisely to drive Netty completely out of the Helidon ecosystem.

5. Akka has changed its licensing model

Akka is one of the mainstays of Scala these days, and the reason why this is the language that companies are still interested in. It is one of the industry’s best implementations of the actor model, which, with the support of a mature (and well-known) platform – such as the JVM – was a very tempting combination indeed. That’s why the news that starting with version 2.7, Akka is changing its licensing model from Apache 2.0 to BSL v1.1 (Business Source License), created by MariaDB, reverberated in the industry. The license change essentially marks the closure of Akka’s development phase based on the so-called “Open Core.”

What does BSL mean for Akka in practice? Well, new versions will continue to be released under Apache 2.0, but with a considerable delay – only after three years. Until then, each new version will admittedly be made available with the sources, but it will be free-to-use only in non-production environments. If we want to have Akka in a production system and our company’s annual revenue exceeds $25 million, it will be necessary to pay license fees. Their prices start at around $2,000 USD per processor core, defined as hardware core / vCore / vCPU. If we want to modify Akka for our needs, the license will cost us $72,000 USD.

6. AWS Lambda SnapStart

Shall we remember 2022 as the year when the Java “cold start” problem was finally solved, at least on AWS? There’s a good chance of that, because at the end of the year Amazon – somewhat surprisingly – showed AWS Lambda SnapStart.

The execution of each Lambda function consists of three phases – Init, Invoke, and Shutdown. The bootstrapping of the environment in the first of these consists of preparing the entire environment for a state in which it is able to accept traffic – this is the aforementioned Cold Start. To avoid repeating this operation, SnapStart saves the Lambda’s memory state at this point and puts it “aside” for later use when our function is not hot anymore. This reduces the startup time to a minimum. The whole thing uses the brand new (and still developing) Java CRaC API, which helps in the event that a snapshot refresh is necessary – AWS Lambda provides the appropriate hooks.

If the topic has piqued your interest, I once elaborated on this issue in a pretty long text, including a better description of the aforementioned CRaC. In it, I outlined the entire path that the community had to go through before creating SnapStart.

7. Jakarta EE has finally moved forward

I would say… at last.

For a couple of years, Jakarta EE remained in a strange place. Due to the lack of copyright to the javax package, the entire community was focused on moving to a new namespace – jakarta. The last major release – 2021’s Jakarta EE 9.1 – focused on finalizing the changes associated with this transition. In 2022, meanwhile, we had the opportunity to celebrate the release of Jakarta EE 10, which can be considered the first real step forward since rebranding.

If I had to name the single biggest change in the new release, I would probably choose the appearance of a new Profile – Core. What are profiles? We used to have only one Java EE variant, which was simple but caused problems. The standard was broad, and in order to pass certification a given application server had to implement each new API, which lengthened the adoption time for new solutions. Therefore, JEE developers distinguished between two profiles – Full and Web, where the latter was intended for typical Web applications… Such from the 200X.

However, this all happened in the era before we started packaging our applications in single deployable jars. This change – and a new generation of solutions – made it necessary to further tighten the number of key APIs to only those useful in such a use-case. That’s how Jakarta EE’s independent MicroProfile was created, and now its competitor(?) – the official Jakarta EE Core Profile. Why does Jakarta EE create its own solution instead of getting along with Microprofile? TLDR: it’s related to the flexibility that MP developers crave, which Jakarta EE isn’t much able to offer them. That doesn’t mean there’s any conflict between the projects – but at the moment Core Profile will simply be able to provide a base that MicroProfile will be able to expand upon.

But that’s not all. The process of constantly slimming down corporate Java has been going on for years, and this is also the direction that the CDI standard – Context and Dependency Injection – has taken. In addition to being divided into SE versions (for standard Java, used by Helidon, among others) and EE, there are now additional variants – CDI Full and CDI Lite. The latter contains only the most essential aspects of CDI. It was designed to support the needs of popular projects such as Dagger or Guice, while omitting more advanced functionality related to the lifecycle of injected dependencies.

Overall there is a lot going on. Hopefully, 2023 will be just as successful for Jakarta EE developers. Now that most of the ecosystem – with Spring, Helidon or jOOQ at the forefront – has already rewritten itself to the Jakarta EE, the standard’s developers will finally be able to prove their worth.

8. WildFly abandons “Release Train”

Staying on the topic of Jakarta EE, the next announcement is about WildFly. At the same time, because of how strongly it goes against the trends in how software is released today, it should be of interest to a slightly wider range of people than the typical Java EE-related announcements.

Well, in an era when most projects are moving to a regular “release train,” WildFly has decided to take a kind of step back and base its new releases on defined sets of functionality. This is a kind of return to the roots when new releases of application servers were much less frequent and were just associated with big bumps in the standard, not specific dates on the calendar.

One of the big features (besides the upgrade to Jakarta EE 10) that WildFly “delivered” in 2022 is S2I – Source-to-Image (S2I). We’re talking about a toolkit that consists of new base images for java LTS versions JDK11 and JDK17, a new maven plugin, a set of cloud-based features aptly named Galeon, and a new iteration of Helm support for WildFly 2.0.

I know that the Cloud-Native server of Enterpris Java sounds like a curiosity to many, however, it is apparent that the developers of WildFly want to fight a little more in the new territory. This application server has always been regarded as the most “modern” member of Java… Jakarta EE community, also I suspect that among its users there will be some who will feel like experimenting with S2I.

9. Machine Learning has made its way into the Java standard

There was a period in 2021 when Machine Learning projects targeting Java developers were starting to appear quite rapidly. Both Oracle and LinkedIn tried to present their solutions to the community, but as loud as it was in the beginning, both Tribuo and Dagli have been relatively quiet lately. However, this does not change the fact that the ML space is too greedy a morsel to just let it go and hand it over to Python.

So the Java ecosystem is not giving up, as evidenced by the formal acceptance of work on the JSR-381 Visual Recognition (VisRec) Specification. Contrary to the rather misleading name, this is intended to be a high-level API standard for both basic machine learning (ML) as well as image classification and object recognition. JSR 381 is intended to provide a common API for ML, shared across domains. Its reference implementation is based on the DeepNetts library, but the whole thing is already supported by the Deep Java Library, developed by Amazon.

10. Alpaquita Linux – OS dedicated for containerized Java

In 2022 BellSoft – the developers of the Liberia JDK – decided to create a new reference Linux distribution designed directly to run Java in containers. At first glance, it sounds a bit like shooting a cannon at a fly, but there is a method in the madness. The developers have taken minimalist Alpine, which itself adds really minimal overhead (I’ve used it in practice, it’s almost unnoticeable), but modified it in a way that is supposed to provide, in the case of JVM applications, much better security and performance.

BellSoft e.g. created a modified variant of the musl memory allocator also used by Alpine, and whose support was added quite recently in JDK 16. They called the whole thing Alpaquita Linux, added LTS support, and packaged it together with the previously mentioned Liberica JDK. They’ve also published some numbers and benchmarks to back up the statement that they’ve succeeded in creating the most customized Linux distribution for containerized Java.

The most interesting releases of the year – JVM languages

Java 18

After JDK 17, which, as many of you may remember, was an LTS (Long-Time Support) release, the scope of “eighteen” is not some huge one, but there are still some things in it worth dwelling on.

Indeed, JDK 18 brought 408: Simple Web Server (building a minimalist Web Server into Java) and 413: Code Snippets in Java API Documentation (introducing the @snippet tag into JavaDoc to simplify including sample source code in API documentation).

In addition, JDK 18 is a couple of changes under the hood (416: Reimplement Core Reflection with Method Handles, 400: UTF-8 by Default and 418: Internet-Address Resolution SPI) as well as JEP 421: Deprecate Finalization for Removal – Finalizer deprecation, which was met with a mass of controversy from the community. However, it was “pushed through” to the glory of the Loom project.

Java 19

This release may seem like something small on the one hand, but don’t let the appearance of only one single stable feature fool you – for we are dealing with one of the most important new JDKs in years, I’m inclined to say even since JDK 9 with its module system. For for the first time we have the opportunity to test Preview versions of the projects that will be the future of the JVM.

With JDK 19, we finally saw the first preview of the long-awaited Loom. The community has been playing with the whole thing at its best for quite some time, and now developers fearful of development versions will also be able to play with virtual threads and painlessly check whether the whole thing lived up to all the hype the project subsequent announcements entailed. At the same time, Structured Concurrency, which is part of Loom has also gone into incubation, providing a natural complement to Virtual Threads.

Another heavyweight player, the 424: Foreign Function & Memory API and the 426: Vector API that is the effects of Project Panama, also appeared in the new JDK release. A successor to JNI is materializing in front of us, which is expected to give us new and better integration with native code and memory.

We also watched the continued development of solutions under the Project Amber umbrella, such as 427: Pattern Matching for switch and 405: Record Patterns (Preview).

In addition to updating major projects, Java developers have been tempted to support distributions running on RISC-V family processors. The platform has really been on tongues lately – this week Google announced that it wants to make it one of the backbones of Android.

More about JDK 19 can be found here.

Kotlin 1.7

Kotlin has not had it easy this year. JetBrains was forced to migrate the team working on the language from the Russian Federation, which certainly didn’t help on the broader productivity front. That’s not to say, however, that 2022 didn’t bring any new developments to the language. It released, among other things, Kotlin 1.7.

The most important news certainly seems to be the alpha version of the K2 compiler – the future of Kotlin. The developers of the language (platform?) want to be able to realistically make Kotlin a truly multiplatform solution in the near future, without the need for multiple implementations of the same functionality. The alpha version supports only the JVM for now and is still quite limited, but the first test release is a very important step for the whole project.

Of the new features side, incremental compilation via Gradle should certainly be mentioned as well. The developers boast that their internal tests showed an improvement of more than 80% for changes after they hit the cache. Kotlin has had a reputation for being quite heavy-handed over the years, so any move toward improving the Developer Experience (and that’s what any tweaks to the compilation process are, after all) are very appreciated.

As for things related to the syntax of the language, this release definitely covers further edge situations that Kotlin’s type system has to deal with. Indeed, the new release brings, among other things, definitively non-nullable types and type inference within so-called Builders. An underscore operator has also been introduced, allowing automatic inference of a generic type when the other arguments are known.

Just before New Year’s Eve, Kotlin 1.8 was also released, but this one hasn’t even gotten an official announcement yet beyond the documentation update, so I’m not counting it as part of the 2022 legacy and won’t get into it until next week’s Edition.

Groovy 4.0

The lean years have come for Groovy – news of the language resonates quite poorly with the community. I myself have to admit that despite the fact that I regularly follow the world of technology, I missed Groovy 3.0, premiere a couple of years ago, and found out about it roughly after its official release. The release of Groovy 4.0 last year also passed without an echo at most. I’m a bit unsurprised – “4.0” had mostly boring, java-compatibility-based features like Switch expressions, Sealed types, JavaShell or Records.

Although you can find a few more interesting pearls in it, most of them (such as GINQ – Groovy-Integrated Query) or intriguing Groovy Contracts are still in incubation. However, a spark of hope is that Groovy 5.0 looks quite tasty thanks to them. It is possible that in order to make a big step forward, the creators had to improve compatibility with Java first. And although I don’t believe that Groovy will ever regain the position it had a few years ago, maybe one of the more interesting JVM languages will surprise us again someday.

Clojure 1.11

The last, but definitely not the least of the language releases is a new version of the Clojure language! The days when I was up to date with Clojure are a bit gone, but as the previous new version came out back in 2018 “clojurists” had to wait a bit. The purchase of the developers of the language by Nubank in 2020 did not somehow accelerate Clojure development, but we also need to note that some tools are simply “complete”.

Clojure 1.11 provides new syntax for calling keyword arguments – functions that accept keyword arguments can now receive a map instead of key/value pairs. There is also a new namespace (in simple terms, a package) clojure.math, providing functions that wrap the methods available in java.lang.Math for “longs” and “doubles.” In addition, there is now an option to alias namespaces in a way that does not cause an error if the aliased namespace is not available. Meanwhile, quite a few new features have been added to the core language itself.

And at the end of this section a joke. What will you know a Clojure programmer by? Because he will tell you about it!

Discover more IT content selected for you

In Vived, you will find articles handpicked by devs. Download the app and read the good stuff!

The most interesting releases of the year – frameworks and libraries

Spring Framework 6.0 and Spring Boot 3.0

The end of 2022 saw the release of Spring Framework 6.0 and Spring Boot 3.0. And no matter how many changes they brought in themselves, surely the biggest revolution is the dropping of support for older versions of Java. And when I say “older” here, I mean not Java 1.6, not even Java 1.8 but even… Java 16. The new Spring requires Java 17 to function. VMWare, current steward of project, has made no compromises here and adapted the new edition of project to work exclusively with the latest LTS release available at the moment.

New Java is one thing, but Spring Framework 6.0 also brings the new Jakarta EE 9.1+. This is worth knowing, because the migration process here may prove (which will probably come as a surprise to many) more difficult than with Java. After all, let me remind you that Jakarta EE 9.1+ is the edition that got rid of the javax.* package in favor of jakarta.*, thus escaping the reach of Oracle and its trademarks.

If you’ve been following the news about the new Spring since its first announcements, I have some bad news for you – it turns out that the long-awaited support for the Java Module System (JPMS) will not be ready for the release. As the creators admit, you can expect it to appear in later versions, but the first one of the Spring Framework 6 focuses particularly on supporting Ahead-of-Time compilation and GraalVM. Modules would make this process harder, complicating the so-called “reachability analysis”. It should be remembered that, unlike new players in the framework market such as Quarkus, Helidon, or Micronaut, Spring relies very, very heavily on the Reflection API. Therefore, the process of supporting GraalVM, which does not support reflection, is much more difficult for Spring.

A longer overview of the new Spring by me can be found here.

SLF4j 2.0

I suspect that virtually everyone reading this newsletter (at least of those who have been in the industry for a few years) has had the pleasure of contributing to the slf4j project at least once. The name is being rolled out as The Simple Logging Facade for Java and that’s exactly what it is. A decade ago, log4j in its first version was a heavily complicated framework with a low-level API and it was an ideal environment for slf4 to flourish.

Since the heyday of slf4j, however, the industry has evolved a bit. First came Logback, and then came log4j2, which brought an API compatible with slf4j, but without the added overhead of abstraction. Meanwhile, there was also java.lang.system.Logger, which was the JDK developers’ second approach to the topic of logging – a much more successful one. All this adds up to the fact that slf4j’s glory years are probably behind it.

But what does slf4j 2.0 bring? Some changes have been made to the API (some builders have been heavily remodeled and the Fluent Logging API has been added), but certainly the biggest revolution has happened under the hood. With the new version, slf4j got rid of support for JDKs smaller than JDK 8 – so they’re not as “ambitious” as the developers of, for example, Spring, but also because of its strong roots in the past, it’s a fairly reasonable step. However, also those using newer JDK 9+ will gain a lot from the migration – unlike Spring, slf4j lived to see support for JPMS modules, which will make it easier to use in modularized projects.

Hibernate 6.0

Hibernate 6.0 is an edition that is the first Hibernate “major” since 2011. This does not mean, of course, that the library’s development has stood still – each of the regularly released 5.x minors has brought a lot of new features. Recently, however, there has been more talk about side projects, such as Hibernate Reactive.

The new Hibernate is all about new annotations, which abandoned their XML roots and received a lot of changes e.g. better type safety. Also, a big step forward is the Semantic Query Model (SQM), a new entity query parser that supports both JPQL and the Criteria API. The new parser will be much more flexible, so we are providing a better translation of entity queries in SQL. In addition, there are performance improvements by changing from reading columns by name to reading by item within ResultSet and updating the parser used by Hibernate with ANTLR.

A very big change is also the migration of Hibernate to Jakarta EE and the abandonment of the old Java EE-related APIs. It’s the main reason why that a major version of the framework is being bumped up, as there is a need to migrate from the javax.persistence namespace to jakarta.persistence.

Ktor 2.0

Ktor is a JetBrains-created reference framework to develop web applications in Kotlin. In the new edition 2.0 many APIs (e.g. Plugins) have been rebuilt basically from scratch. Additionally, in line with the recent spirit of Kotlin Multiplatform Ktor started to support the Native platform, among others. From my perspective, however, the most interesting new feature is (at last!) support for Retries.

AWS SDK for Kotlin with Coroutine support

If you’re using AWS and Kotlin, I highly recommend you try the Kotlin version of AWS SDK. After all, the “native” version for the JetBrains language, released earlier this year, supports coroutines, which is crucial since the AWS SDK basically consists of I/O operations alone. It’s nice of AWS to opt for a special Kotlin edition – while the compatibility of this language with Java is sufficient, it’s good that after 2022 we won’t have to resort to it too often – after all, stable Coroutines are feature already a good few years old.

Vaadin 23

What is Vaadin, many of you will ask? Back in the days when it seemed to everyone that generating frontend from Java was a sensational idea, Vaadin was created to allow the minimization of frontend familiarity for those who wanted to create a full web application. Times are a little different now, and we’ve learned a bit that a dedicated frontend engineer is a good idea after all, but that doesn’t make Vaadin give up.

The new release drops support for Java older than 11, and introduces changes to Vaadin’s design system. Vaadin, however, is not only the core itself but also the entire platform, with two major supporting Frameworks.

The first is Flow, which is used to generate JavaScript code 100% from within Java, and the new version brings e.g. full support for npm and Vite – an increasingly popular tool for building front-end applications.

The other is Hille, a new web framework for Java developers that combines the Spring Boot backend with TypeScript, giving us a full-stack application template. Formerly known as Vaadin Fusion, Hilla is said to offer many capabilities to simplify the development of business applications, such as unified project configuration for Java and TypeScript. It also has a rich set of UI components. It looks quite interesting, although today people looking for a FullStack solution will probably opt for JHipster sooner.

Helidon 3.0

Helidon is a kind of reference implementation for MicroProfile and “micro” Jakarta EE from Oracle itself. The new edition requires a minimum of JDK 17 to function. Oracle is going like a storm in the process of pushing users to the latest LTS – they have adopted the method of the stick (minimum supported releases) and carrot (significant new features).

The support for MicroProfile 5.0 and selected aspects of Jakarta EE 9.1 can certainly be considered such a “significant novelty”. In some ways I find it amusing that with this boost also the framework from Oracle gets rid of the trademarked javax. package in favor of jakarta…. the developers boast that this is the first corporate product to make this change.

If you are still here – thank you for your perseverance 🎉. And I hope 2023 will be as interesting as 2022 🤩