With Java 21 released today and Jakarta EE 11 slated for release in Q1 of 2024, the landscape for Java development is evolving rapidly, particularly in the cloud-native space. Although these two are not being developed together, they are intrinsically linked: Jakarta EE 11 will have Java 21 as its base Java SE version. This blog post will explore what these two significant releases bring to the table individually and how they can collectively enhance cloud native Java development.

So, you're a Java developer, or maybe you're aspiring to be one. Either way, you've probably faced the challenge of managing multiple versions of Java on your machine. One project requires Java 8, but another needs Java 11, yet another requires Java 17. The open-source library you're keen on contributing to needs yet another version. What do you do? You start juggling environment variables, and before you know it, your system is a tangled mess of configurations. Not fun, right?

And let's not even get started on the difference between JRE and JDK. It's easy for beginners to get confused about the distinction between the two. The JRE (Java Runtime Environment) is sufficient if you just want to run Java applications, but if you're going to be developing them, you'll need the JDK (Java Development Kit). The JDK includes everything the JRE has, plus additional tools and utilities for developers like the Java compiler, or javac.

Tired of all this complexity? Let me introduce you to SDKMan!, a version manager that streamlines the process, making it a breeze to manage multiple Java versions on your machine. Not just Java, SDKMan! can be used to manage a lot more kits and tools such as Maven. In this blog post however, we see how to use SDKMan! to effortlessly manage different versions of Java on the same machine. 

Sealed classes are a powerful feature introduced in Java 15 that allows developers to control the inheritance hierarchy of a class. In this blog, we will explore the concept of sealed classes in the context of Jakarta EE, a set of specifications for building enterprise applications in Java.

Upcoming Java 21 brings a bunch of new features, including very interesting progress in concurrency. There are two main improvements – virtual threads and structured concurrency.

In this article, we discuss incoming usage of these enhancements inJakarta EE (formerly Java EE, now an open source project maintained by the Eclipse Foundation), a set of specifications that enables the worldwide community of Java developers to work on cloud native Java enterprise applications. Jakarta Concurrency is the concrete specification describing the expected behaviour.

The support in Jakarta EE is currently under development, details may change in the final implementation.

Oracle, together with the Java Community over the last few years, have changed the release cadence of the Platform. With biannual releases, the Java of today is a remarkable departure from Java 8. With all the rapid advancement of the language comes the problem of keeping up as a developer.

Thankfully, Java Champions Marc R. Hoffmann and Cay S. Horstmann came up with the Java Almanac website. JA is a great resource that gives you both a summary and detailed overview of changes on the Java Platform from Java 1.0 to Java 22.

The changes are organised in a tabular format with details, links to the respective API and a helpful comparison page. It also has a download page with options to download from any of the JDK distros. All in all, Java Almanac is a great resource to keep abreast of the new release cadence of the Java Platform. 

Java Records, one of the major highlights of the Java 16 release, provides a concise and immutable way to define classes for modelling data. This conciseness lends itself useful in a typical Jakarta EE application that can have a number of layers that need to share data. For example the data layer might want to return a subset of a given data set to a calling client through a data projection object. The REST layer might want to have separate entities for server and client side among others. This blog post explores the adoption of Java Records in a Jakarta EE application as a data transfer and projection object.

The Lombok project is a Java library that aims at “spicing up your java.” Started back in 2009, it consists mostly of annotations that can be used on Java classes to generate helpful constructs like getters and setters. It aims at freeing you from writing quite a number of the ceremonial boilerplate code that you sometimes need to write as part of your everyday use of Java. 

YAML is a simple, human-friendly data serialization language for all programming languages. It is the main format for working with Docker. As a language agnostic format, there are many bindings for all the major programming languages. You can easily consume and return data in the YAML format in your Jakarta REST application using message body readers and writers.

Java generics is a great feature that allows you to have compile time checks for generics. However, due to historical reasons of backward compatibility, type information for generics is erased at runtime. A lot of the time this shouldn’t be of much concern. But there are a few cases where type information is needed at runtime for some kind of decision. 

One such situation is in Jakarta REST when the jakarta.ws.rs.core.Response object is used to return a generic collection of a specific type. For example the code below shows the creation and return of a Response object that has a list of HelloEntity as the return payload to the client.