Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Java InfoQ Trends Report—December 2021

Java InfoQ Trends Report—December 2021

This item in japanese

Lire ce contenu en français

Key Takeaways

  • Java 11 has reached parity with Java 8 in terms of market share.
  • Quarkus, introduced after Micronaut and Helidon, continues to be a popular framework and has "crossed the chasm" into the Early Majority space.
  • Containers have broken through and are now the way that the majority of Java applications are deployed.
  • Microsoft furthers its commitment to Java with the release of their own downstream distribution of OpenJDK and having joined the Java Community Process. Microsoft Build of OpenJDK is a new participant in the OpenJDK downstream distribution space.
  • Spring Framework 6 and Spring Boot 3, scheduled for GA releases in 2022, will be a major overhaul of these projects to adopt modularity. Spring Native has emerged as a new tool to convert existing Spring Boot applications, written in Java or Kotlin, to GraalVM native images.
  • MicroStream has emerged as a new participant in the Java ecosystem.
  • After years of stagnation, VS Code is shaking things up in the Java IDE space.

This article provides a summary of how the InfoQ Java editorial team currently sees the adoption of technology and emerging trends within the Java space.

We focus on Java the language, as well as related languages like Kotlin and Scala, the Java Virtual Machine (JVM), and Java-based frameworks and utilities.

We discuss trends in core Java, such as the adoption of new versions of Java, and also the evolution of frameworks such as Jakarta EE, Quarkus, Micronaut, Helidon, MicroProfile and MicroStream.

This report has two main goals:

  • To assist technical leaders in making mid- to long-term technology investment decisions.
  • To help individual developers in choosing where to invest their valuable time and resources for learning and skill development.

This is our third published Java trends report. However, this topic has received ample news coverage as we have been internally tracking Java and JVM trends since 2006.

To help navigate current and future trends at InfoQ and QCon, we make use of the “crossing the chasm” mental model for technology success pioneered by Geoffrey Moore in his book of the same name. We try to identify ideas that fit what Moore referred to as the early market, where “the customer base is made up of technology enthusiasts and visionaries who are looking to get ahead of either an opportunity or a looming problem.”

As we have done for the 2020 and 2019 Java trend reports, we present the internal topic graph for 2021:

For context, here is our internal topic graph for 2020

Aside from some new technologies having been identified in the Innovators space, notable changes include: defining versions of Spring (and their related projects), Jakarta EE and Scala into different categories. We decided on this approach to avoid generalizing these technologies into one category when varying degrees of maturity and adoption exist.

Spring Framework 6 and Spring Boot 3, scheduled for GA releases in late 2022, will be going through an overhaul to adopt modularity and will require JDK 17+ and Jakarta EE 9. A preview has recently been made available with the first milestone release of Spring Framework 6.

Introduced at the beginning of 2021, Spring Native is a new tool to convert existing Spring Boot applications, written in Java or Kotlin, to GraalVM native images and is in the very early stages of development.

Scala 3, released earlier this year, was overhauled with many new features, new syntax and the much-anticipated new Dotty compiler that has been under development for a number of years.

Earlier this year, Microsoft furthered their commitment to the Java programming language when they introduced Microsoft Build of OpenJDK, their own downstream distribution of OpenJDK.

AdoptOpenJDK joined the Eclipse Foundation and was immediately renamed Adoptium. The transition to Adoptium included the creation of an Eclipse Working Group and a split of AdoptOpenJDK into multiple sub-projects under the Adoptium top level project: Eclipse AQAvit, Eclipse Temurin and Eclipse Temurin Compliance.

What follows is a lightly-edited summary of the corresponding discussion on various topics among several InfoQ Java Queue editors and Java Champions:

  • Michael Redlich, Senior Research Technician at ExxonMobil Research & Engineering and Java Queue Lead Editor at InfoQ
  • Ben Evans, Senior Principal Software Engineer at Red Hat, Java Champion and Java Queue Editor at InfoQ
  • Erik Costlow, Director of Developer Relations at Contrast Security and Java Queue Editor at InfoQ
  • Johan Janssen, Software Architect at Sanoma Learning and Java Queue Editor at InfoQ
  • Karsten Silz, Senior Full-Stack Java Developer and Java Queue Editor at InfoQ
  • Monica Beckwith, Senior Principal Engineer at Microsoft and Java Champion
  • Ana Maria Mihalceanu, Developer Advocate at Red Hat and Java Champion
  • Reza Rahman, Principal Program Manager for Java on Azure at Microsoft
  • Simon Ritter, Deputy CTO at Azul and Java Champion

We feel this provides more context for our recommended positioning of some of the technologies on the internal topic graph.

JDK 17

Beckwith: Java is now a more vigorous enforcement of OOP principles via JEP 403: Strongly Encapsulate JDK Internals. Vector computation via a platform-agnostic Vector API. The language additions, such as Records, and JVM improvements, such as project Valhalla, remove many verbosities and further embrace the concept of immutability, thus providing opportunities for performance optimizations.

Mihalceanu: This year pleasantly surprised Java developers with both LTS and non-LTS Java releases. The Java 17 release was the confirmation that many of those preview features are now generally and long-term available. It also added a sense of urgency for some projects that still run on Java 8 to migrate to a newer version. Java 17 is the LTS that fulfilled the lifelong dream of having helpful NullPointerExceptions.

Rahman: As always, all parts of the Java ecosystem remain lively. This speaks to the fundamental strength of Java. I think Java SE 17 has been particularly well received, especially features like Records. Runtimes like WildFly, Payara and Open Liberty are adopting Java SE 17. While some developers have adopted Java SE 11, Java SE 8 remains remarkably sticky. It is possible Java SE 17 will finally change that.

Ritter: The release of JDK 17 has been significant. This means developers now have a new long-term support (LTS) release from all the OpenJDK distributions. For those not wishing to upgrade their Java version every six months to remain as stable and secure as possible, this is an important release.

I like the way that we are seeing more small language features added to the platform more quickly than we've ever seen before. This is thanks to the six-month release cadence, which also makes both incubator modules and preview features practical.

There are also some interesting developments in how the JVM can work in a cloud environment such as the new project in OpenJDK called co-ordinated restore at checkpoint (CRaC). Features, like records, are great for developing new code.

Evans: The release of Java 17 LTS, and the ability to finally start deploying code that leverages Records and Sealed Types, as well as JFR Streaming for monitoring groups of JVMs. The path towards standardization in the Observability space - especially OpenTelemetry. Early signs of a consensus emerging around what it means for Java to be statically deployed ("Static Java"). I also think Panama will be a bigger deal than people expect.

Downstream Distributions of OpenJDK

Costlow: There are too many non-differentiated JDK distributions out there now. Microsoft has one, Eclipse has Adoptium with Temurin, Oracle has theirs and an OpenJDK build, Azul, AWS Corretto, Red Hat, Liberica, SAP Machine, etc. I'm seeing a proliferation of these, but it's hard to keep them straight. Snyk's survey seemed relatively in line with what I see in terms of usage. Given that they're all compatible, I'd like to see a "Just get me OpenJDK" randomizer in the marketplace to remove a decision for new junior Java devs.
The Eclipse branding in particular is confusing: Adoptium is a group inside Eclipse, which is also a group. Temurin is the thing you use and it is OpenJDK. Imagine learning Java on your own and reading this sentence: "Eclipse Temurin is the name of the OpenJDK distribution from Adoptium." Fewer brand names is better.

Janssen: Liberica, which is from Bellsoft, actually offers quite some interesting products which differentiate them from other JDK vendors. For instance, a full JDK which still contains JavaFX. I only know of ojdkbuild which offers a similar build. Next to that, they have more variants of the JDK and the JRE.

Azul supports non-LTS versions with minor updates for a longer period of time. Some vendors offer Docker images, etc. So there are some differences, but it's hard for end users to compare them and make a good decision about which one to select.

Java EE/Jakarta EE

Rahman: The transition from Java EE to Jakarta EE is one of the largest and most significant technology transfers in our space. That is finally on solid ground with Jakarta EE 9.x. It is very good to see how Jakarta EE 10 is now progressing towards a release early next year. It looks like many of the items in the Jakarta EE Ambassador's Contribution Guide are materializing, closing some long-standing gaps. I think this is a big relief to long term Java EE users.

I am also very happy to see Jakarta EE 9.x building momentum. Most runtimes have adopted the javax to jakarta namespace transition including Tomcat and Jetty. Spring Framework 6 is committed to adopting both Java SE 17 and Jakarta EE 9. Similarly, MicroProfile 5 is transitioning to Jakarta EE. According to the 2021 Jakarta EE Developer Survey, a substantial number of developers have already transitioned to the jakarta namespace or are planning to do so.

The Jakarta EE 10 Core Profile is paving the way for Quarkus and Helidon becoming fully compatible, the MicroProfile Config API is transitioning to the new Jakarta Configuration specification and the same is happening with MicroProfile Context Propagation. It is possible the same will happen with the MicroProfile REST Client and JWT Propagation.

Redlich: With the release of Jakarta EE 9, tooling vendors can support the new jakarta package namespace, development teams can test migration of their applications to the new namespace, and runtime vendors can test and deliver options and capabilities that support migration and backwards compatibility with Jakarta EE 8.

Jakarta EE 9 may also be considered a foundation for innovation to drive new features in Jakarta EE 10 and beyond.

GraalVM/Spring Native

Mihalceanu: Building a native executable is another topic often marked as “most wanted” as the race for smaller, faster containerized applications continues.

Rahman: It is also very good to see that Spring Native is making progress.

Costlow: I like seeing the role of native apps taking shape, but disappointed by the lack of an actual specification or working group. It seems to be kind of "you get whatever GraalVM happens to do" and it behaves differently at times than a standard JDK - similar but not the same.

Janssen: Spring Native competes with all the GraalVM and other frameworks with fast startup times and low memory usage.

Silz: Once Spring Boot supports native compilation with GraalVM, fast and small native Java programs will go mainstream. This makes Java more competitive for serverless solutions and may help it in the microservices arena. I say "may" because as of today, I think that the JVM JIT still has better throughput/performance for long-running processes than GraalVM. Either way, that'll get a lot of press and make Java more competitive overall.

ARM64/Windows on ARM

Beckwith: ARM64 is now commodity hardware. As a result, the presence of Java development kits and the Java runtime environments optimized for deployment on ARM64 have gained mainstream popularity.

Silz: Java 16 supports Windows on ARM. But I think only Java 17 with ARM on macOS will blow the doors wide-open. I believe about a quarter of all Java developers use Macs. And by the end of 2022, they can only buy Macs with ARM. I expect that this will push both Windows and Linux on ARM to get better, too.

Jakarta EE and MicroProfile Alignment == Cloud Native for Java

Redlich: The MicroProfile and Jakarta EE Working Groups, two complementary initiatives under the auspices of the Eclipse Foundation, have collaborated to form a Cloud Native for Java (CN4J), an alliance to define Jakarta EE and MicroProfile positioning and alignment, both branding and technical for cloud-native technologies.

Rahman: It is a pleasant surprise to see Quarkus making well-earned headway with both Java EE and Spring developers. It is also very good to see Jakarta EE and MicroProfile alignment finally happening.


Costlow: I am extremely impressed at the work that Gluon is doing to make a single JavaFX codebase run across everywhere. Web was the missing piece from before and, frankly, client Java now seems cool again.

Adopting Modularity

Silz: I think that JPMS tries to solve three problems: class loading woes for app servers; better structuring of the JDK and all Java applications; and reducing the JVM footprint for deployment/runtime.

But at least when JPMS finally launched after multiple delays, there were good enough solutions for these problems already: OSGI for class loading; Domain-Driven Design/Clean Architecture/Modulith/ArchUnit tests for Java program structure; and ahead-of-time compilation for reduced JVM footprint.

As few unreliable data points we may have, they all show usage of Java 8 and older either being greater than or equal to that of Java 11 and later. I think this is partly because modules gave Java 9+ the reputation of being "hard to upgrade to from Java 8," as Mark Reinhold acknowledges. That's an unintended consequence of JPMS. And it means that at least half of all Java developers can't use the Java advances of the last seven years because they're stuck on Java 8.

The opportunity cost of working on modules for probably 7+ years means that many other Java improvements either fell to the wayside or only appeared in Java 10 and later. The var keyword for variables, the new switch syntax, and Java records reduce a lot of the boilerplate that Java's infamous for. If those were in Java 9 instead of Java modules, I think Java would be in a better place now because it had better developer productivity.

What Has Changed Since Last Year?

Beckwith: Many architects and developers have tamed the GC (garbage collection) pause times due to the improvements to the existing collectors. Many others have tamed the tail latencies by transitioning to low-latency, adaptive GCs for their workloads.

Evans: Java 11 has essentially reached parity with Java 8 in terms of market share. Containers have broken through and are now the way that the majority of Java apps are deployed. Quarkus continues to mature and gain ground and new fans.

Redlich: A few Eclipse Foundation Working Groups have been established: MicroProfile, OSGi and Adoptium (formerly known as AdoptOpenJDK). The MicroProfile Working Group and the Jakarta EE Working Group have collaborated on a Cloud Native for Java (CN4J) Alliance initiative.

Microsoft furthers its commitment to Java by creating its own downstream distribution of OpenJDK, Microsoft Build of OpenJDK, and by joining the Java Community Process.

What is the Java Community Saying?

Beckwith: Pattern matching for switch statements, native image, cloud native-JVM, and JVM on accelerators, project Loom and Graal.

Mihalceanu: Upgrading. Because the Java language evolved, framework features flourished as well. In my experience, writing clean and secure code promptly depends on the practices shared by a team. Nowadays, it is possible to minimize the time spent developing or fixing code with continuous testing and fewer local configurations thanks to some framework built-in capabilities.

Rahman: Java SE 17 and Quarkus are enjoying the limelight. Kubernetes remains wildly popular. There is early enthusiasm around Spring Native. Folks in the open standard Java community are watching Jakarta EE 10 and MicroProfile/Jakarta EE alignment closely. There is something good happening pretty much for everyone in the ecosystem.

Ritter: The focus for pretty much all developers, at least when working on new development, is how to make the most effective use of the cloud, especially through a microservice architecture. Leveraging containers and technologies like Kubernetes and Spring Boot are very powerful when writing these types of applications. I hear a lot of discussion about how to use these.

Evans: Java 17, Loom, Quarkus.

What’s New and Exciting That We Didn’t Expect?

Beckwith: I had anticipated the richness of the Java ecosystem and the different JDK vendor flavors of the Java Dev Kits offerings. Still, the sheer participation and the agreement towards the accelerated release cadence were a welcome surprise.

Mihalceanu: What I love about Java is that each release adjusts both the language and the experience of developers. Enhancements such as the new date formatter for period-of-day introduced in java.time.format.DateTimeFormatter and DateTimeFormatterBuilder classes, pattern matching with switch, or the default method toList() in interface help developers to write cleaner and easier to read code.

Ritter: Looking at the Java platform, there wasn't anything we didn't expect and that's a good thing. Now that new features use JEPs to define what they are intended to do, we have a clear roadmap of the things that will be included in Java looking some years into the future. This means developers can be comfortable that there are not going to be big changes that impact backwards compatibility, at least not without plenty of time to evaluate and discuss them.

Evans: A new focus on warm start / suspend-and-resume / CRaC technologies from a number of providers, including Azul and Red Hat.

Redlich: The emergence of MicroStream, a Java persistence company. While their history goes back to 2013, the company was formally founded in 2019. Since then, they open-sourced MicroStream earlier this year with the release of MicroStream 5.0 and has collaborated with MicroStream has been integrated with Helidon and has just released version 6.0.

Silz: After years of stagnation, VS Code is shaking things up in the Java IDE space. It's something new: A cross-platform, cross-language IDE that's fast, has great plug-ins, and is loved by its users! If that sounds like "Eclipse IDE 20 years ago", you're right!

VS Code recently boosted its Java capabilities. I expect it to become the best free Java IDE. I think Eclipse recognized that threat and created a Working Group to coordinate a defense. I'm not sure how much IntelliJ will be affected.

One exciting side effect of using VS Code for Java development is that you can easily develop with non-JVM languages. I don't think you can do that in Eclipse at all, or only in a limited way. You can develop with non-JVM languages using JetBrains "All Products Pack", but then you have to launch different IDES that don't share settings, plug-ins, or keyboard shortcuts.

The Java Community

Mihalceanu: I started my Java journey while in university, learning that Java supports Object-Oriented Programming with design patterns and coding best practices. As a professional, I am happy to see that throughout the time, the language has embraced other paradigms as well: functional, reactive thus giving more implementation options without losing the readability. How to choose between each model? Occasionally profile your application, spot bottlenecks, and improve your implementation logic.

Yet, no advancement is possible without people. The Java Community is large, vibrant, and welcoming, present both physically and virtually all for one purpose: to share knowledge, improve ourselves, and succeed when facing problems.

Please note that the viewpoints of our contributors only tell part of the story. Different parts of the Java ecosystem and locales may have different experiences. Our report for 2021 should be considered as a starting point for debate, rather than a definitive statement, and an invitation to an open discussion about the direction the industry is taking.

About the Authors

Rate this Article