Contents

Overview of next-generation Java frameworks webp image

What constitutes a modern framework? What criteria should it fulfill to be considered as the next-gen one? I think the following aspects are essential when looking for the answer:

  • support for writing microservices,
  • integration with cloud providers,
  • startup time and memory consumption,
  • possibility to write reactive applications,
  • support for the newest versions of JDK,
  • various integrations with external systems.

In this post, I'd like to briefly describe frameworks that could be named modern ones. I will focus on open source options only.

Spring Boot

Spring Boot emerged during a natural evolution of the Spring Framework, the most popular Java framework. This fact should be not surprising since it has been on the market for a long time. The VMware company backs it.

By default, it runs on Tomcat container (other servlet containers available as well); however, we can also apply a reactive approach based on the Reactor project and run it on Netty. The Spring Boot actuator provides superb support in terms of management and monitoring, which is very useful when you think about microservices. In addition, you can find plenty of sub-projects that bring integrations with external systems.

Developers can use a rich set of cloud-specific extensions based on third-party libraries gathered under the Spring Cloud project. These cover topics like cloud providers integration, distributed configuration, service discovery, ensuring the resilience of services, and monitoring them. All of this battle-tested among plenty of projects.

The framework uses annotations extensively, with no preprocessing during the compilation phase. That means doing reflection calls and creating proxies at the runtime. As a result, we may get a bigger memory footprint and slower startup time.

Spring offers the Spring Native to provide a native deployment option with GraalVM. However, the project is in the beta phase and is not as mature as GraalVM support in other projects below.

VMware prepared an event at the end of January 2022, where Spring Framework 6 and Spring Boot 3 were presented. The baseline for the new version is Java 17, although you can use it already in the recent releases.

Micronaut

Micronaut is one of the youngest kids on the street, provided by the Object Computing company. Its development started in 2017, and currently, the Micronaut Foundation manages it.

The framework was created from the ground up to support work with microservices and serverless functions. The creators advertise it as a natively cloud-native stack, meaning various aspects of cloud deployment (service discovery, distributed tracing, fast startup, and small memory footprint) have been considered while designing the framework. Although it is cloud-focused, we can create command-line applications as well.

Thanks to the ahead-of-time compilation and resolving DI during the build phase, the memory usage and startup times are low. Such features are crucial when working with serverless functions.

Micronaut is compatible with Java, Groovy, and Kotlin. In addition, it works with Java 17, uses Reactor to provide reactive streams, and includes plenty of integrations with external systems and cloud providers. We can create services based on REST, gRPC, GraphQL, or messaging protocols. You may notice the API of Micronaut is similar to the one in Spring and Grails. That's no coincidence - it is maintained by Grails creators and takes a lot of inspiration from the two frameworks.

Quarkus

The Quarkus framework is relatively new as well. The development of the framework started in 2018. It's designed for cloud environments and is presented as a Kubernetes-native. It is extensible and formed from a bunch of well-known standards and libraries. The core of the framework is the reactive engine based on Vert.x and the SmallRye implementation of the MicroProfile specification.

The framework has been designed to support reactive, serverless, and event-driven architectures from day one. You can create command-line applications as well. Quarkus is Kubernetes-native, meaning resources are automatically generated (no manual creation of YAML configurations), and we can deploy images with a single command.

Build time processing (like configuration parsing, DI resolving, or aggressive removal of not used code) aims to provide as small application images as possible and avoid reflection calls where possible — such an approach results in less memory consumption and faster startups. It supports GraalVM. Thus, as with Micronaut, Quarkus would be the choice when considering the development of microservices and serverless functions.

If you check the Quarkus documentation, you will notice plenty of integrations available regarding cloud providers, databases (both SQL and NoSQL), messaging, and other features. In addition, it uses the Mutiny library to provide reactiveness. Web applications may expose HTTP, GraphQL, and gRPC endpoints. When writing microservices, we can coordinate activities across them with the Long-Running Actions mechanism. However, at the moment of writing, the latest released version of the framework doesn't fully support Java 17.

More on SoftwareMill Tech Blog:

Helidon

Helidon is a set of libraries for microservices. It is created and maintained by Oracle. To run it, we need at least Java 11. The latest release introduces support for Java 17. We can write code with Java and Kotlin as well. Interestingly, it comes in two flavors: Helidon SE and Helidon MP.

Helidon SE is a toolkit providing reactive streams, asynchronous and functional programming, and fluent-style APIs. It offers a reactive API for streams, messaging, and databases. You may create web endpoints based on GraphQL, gRPC, WebSockets, and HTTP server technologies. Next, we can secure them using a dedicated security add-on. And, at the end, we can spice it with a pinch of metrics, health checks, tracing, and documentation with OpenAPI.

On the other hand, Helidon MP is an implementation of MicroProfile specification. Among the features mentioned for the SE profile, you can find here support for JPA, RESTful services, security with JWT, and long-running actions based on SAGA patterns. Furthermore, this version is meant to run in the cloud; we can deploy an application on OCI or Kubernetes.

Both may be compiled into native images using GraalVM, resulting in a faster startup time and lower memory consumption. However, the SE profile consumes fewer resources than MP.

Summary

All of the presented frameworks fulfill most of the criteria I've chosen initially. All of them are actively developed, and have strong supporters. Definitely, I would name all of them as the next-gen Java frameworks.

Blog Comments powered by Disqus.