State of Java in 2022

Java has been a core language in Nitor’s projects since Nitor’s inception. We do work with many other languages as well, but Java has a special place in the hearts of many Nitoreans. Since this turned into a lengthy article, I decided to pepper the text with some photos from my years working with Java.

A brief history of Java

Sun Microsystems published Java in 1995. Before that they had been calling their new object-oriented programming language Oak, but had run into intellectual property rights issues with the name, so the name had to be changed.

Contrary to what many may think, “Java” does not refer only to the programming language itself: Java also covers the virtual machine (JVM) where the applications are executed, as well as the class libraries that can be used when programming for the JVM. The virtual machine means that when you create applications in Java programming language, they can be executed in any environment provided that the JVM has been ported there first, so the applications themselves do not need to be recompiled. The powerful class libraries make it easier for developers to implement projects which in other programming languages would have to rely on third party libraries (and there are a ton of those for Java too).

Technically, the Java virtual machine does not actually know anything about the Java programming language [1], much like an Intel or AMD CPU would not know anything about the C++ language, working with binary machine code instead. JVM works with bytecode into which Java language is compiled. Since Java became popular, other language developers have found the JVM a good platform for their languages as well. Currently there exists a myriad of different JVM languages, i.e. programming languages that compile into JVM bytecode and can then be executed in any JVM platform. Some of the most well known ones are Clojure, which is a LISP variant, and Kotlin, which is Google’s preferred language for Android development. Many existing languages such as Python, JavaScript, and Ruby, can also be compiled into JVM bytecode.

I studied computer science at TKK (Aalto university) around the time when Java 5 came out. I remember an incident where the teacher complained my code wasn’t working and I got to point out: "it does, just update your Java”.

Java was originally closed-source, but Sun made it open source in 2006 and called the source OpenJDK, although the final closed-source binary components weren’t replaced, removed or made open source too until 2011 with the release of JDK 7.

OpenJDK source code is compiled and released as binaries by many different actors. These OpenJDK binaries include but are not limited to Oracle OpenJDK, Azul Zulu, Microsoft Build of OpenJDK, JetBrains Runtime, etc. Why so many choices for a binary, then? For one, the binaries may differ by their licenses, and they may or may not come with commercial support. Obviously, distributions may also be compiled for different operating systems and machine architectures. For example, who would be better to create a Windows-optimized binary than Microsoft itself? Some binaries may be optimized for large or small amounts of RAM, others for low latency. Often a specific OpenJDK binary may also include optimizations or changes that are later submitted to the main project and will then actually become official parts of OpenJDK.

To ensure that all the binaries are compatible with the Java specifications a comprehensive set of tests and documents known as Technology Compatibility Kit (TCK) is maintained by Oracle, who acquired Sun in 2010 and thus holds the most important strings in the community. Gaining access to the test suite is not trivial, though: one needs to agree to the OpenJDK Community TCK License Agreement, sign the Oracle Contributor Agreement, and submit a formal request to Oracle. TCK conformance is important, however, as it allows for developing against the standard rather than vendor-specific implementations, and it also enables the same applications to be executed with confidence on any conformant platform. That being said, there also exists at least the AdoptOpenJDK implementation which is not officially TCK compliant.

Me kayaking on Nitor Summer day in 2021. The weather was perfect and I got into a similar flow like I often do when programming.

OpenJDK development process

When JDK 9 was released in 2017, it had been three years since JDK 8, which was released three years after JDK 7. Java had been evolving slowly, with two to five years between each release. The community wanted a faster release cadence, so a decision was made to release a new version every six months: every March and September. Instead of waiting for features to be complete, they would be postponed for half a year if they were not ready by the deadline of the next version. The faster release cycle allows, for example, feedback from the community, as beta versions of new language features can be published as Preview Features, and beta versions of new libraries can be published as so-called Incubator Modules.

Oracle submitted that with this many releases it would be too cumbersome to offer full support for all of them, so it was decided that every three years the binary releases would be named Long Term Support (LTS) releases, similarly to what the Linux distribution Ubuntu was doing. Later the LTS cadence was shortened to every two years, so as of February 2022 the current LTS versions of the new release cycle are Java 11 (released in September 2018, supported until September 2023) and Java 17 (released in September 2021, supported until September 2026). The next LTS version will be Java 21 in September 2023.

OpenJDK development is driven using JEPs: JDK Enhancement Proposals. Anyone can submit a JEP, and it goes to the end of a long list, the JEP 0, to be considered. JEP 1 then outlines the actual process where a JEP passes through multiple states, reviews and considerations. The OpenJDK Lead decides which JEPs are accepted for inclusion in the JDK Roadmap, consulting experts of certain areas of the JVM in their decision making.

There are also Projects, which are collaborative efforts around some theme to produce a deliverable, which may be code, documentation, or something else. Take, for example, projects Amber and Loom. Amber is working on productivity-oriented language features, has delivered several JEPs, and is working on more. Project Loom, on the other hand, is working on enabling Java processes to have potentially millions of threads, at which point the current system of mapping each Java thread into an operating system thread would no longer be feasible. The new lightweight threads would be called fibers.

Nitoreans ice climbing on our winter day. Sometimes fixing a devious bug is an uphill struggle -- but not as literally as here.

Java: latest developments

Let’s take a look at some of the new features introduced into Java between the previous two LTS versions, 11 and 17. In the name of keeping this post brief I will not provide complete examples for all of these, but I will provide links to the JEPs that have them.

First, in JDK 14 (March 2020) Switch Expressions were released. Switch statements have been both verbose and prone to errors and I, for one, have not been a big fan of using them in the past. Switch Expressions turns switch statements into expressions that can return values and where there is no danger of accidentally “falling through” from one case block to the next: case SATURDAY, SUNDAY -> "weekend";.

JDK 14 also released a small but important quality of life improvement for developers: Helpful NullPointerExceptions. Previously the JVM would only have told the line number where a NullPointerException (NPE) would have taken place, but what if that line had multiple possibilities where the NPE might have occurred? This improvement highlights the particular accessor where the NPE took place.

Moving on to JDK 15 (September 2020), Text Blocks were added as a feature. Triple quotes ("""...""") were borrowed from Python, providing a clean way of defining String variables that have line breaks in them.

In March 2021, with JDK 16, Records were released. Java has historically been criticized for having a lot of boilerplate code, such as accessors like getValue() to access a value within an object. Records are a new type of immutable data transfer objects where you only define a constructor, and the platform handles the fields, accessors, and other such boilerplate in the background: public record Person(String name, LocalDate birthday) {} and that’s it. Further checks and methods can still be added, if required. If you have ever used the Lombok library in your applications, records should make it unnecessary.

There have also been many more interesting improvements, such as Pattern Matching for instanceof and Sealed Classes which are already at your disposal. JDK 18, due out in March 2022, will be a more “quiet” release, but you should know at least about UTF-8 becoming the default, and about the Simple Web Server that has already been available in one form or another in many other languages, and that promises to make prototyping, ad-hoc coding, and testing easier.

Java is sturdy and has nice views, like the Stirling Castle in Scotland that Nitor visited in 2018.

Conclusions

By now you should have a decent understanding on how the Java system is developed, where it is now, and what is happening. Java was discussed extensively in the FOSDEM ‘22 online event in February 2022, so if any of this sparked your interest, head to the Friends of OpenJDK devroom and watch a few presentations. And if you are now thinking “Hey, I cannot just take an hour in the middle of the day to watch some presentations?!”, then please consider applying to Nitor where our flexible learning budget actually allows you to do exactly that.