Spring Cleaning: A review of new tools in the Spring ecosystem – JVM Weekly vol. 135

Spring Cloud AWS 3.0

Spring Cloud AWS is a project within the larger Spring Cloud ecosystem that simplifies the integration of Spring applications with AWS services (as if you hadn’t guessed from the name), providing additional abstraction when working with AWS services. Instead of manually managing connections or credentials, Spring Cloud AWS allows you to use typical Spring mechanisms like AutoConfiguration and dependency injection. This way we don’t have to think (as much) about resource management. We also get a convenient implementation of standard framework mechanisms based on AWS services, such as, for example, SQS integrations by providing SqsTemplate. In short, we receive a unified, native-for-spring API for developers who don’t want to have to glue their own solution with the AWS SDK for Java (or more recently, also “for Kotlin“).

This does not mean, of course, that its developers are writing everything from scratch. AWS Spring Cloud uses the tools of the aforementioned AWS SDK underneath, and the biggest news coming with version 3.0 is precisely the migration to AWS SDK v2 for Java. This is because, between v1 and v2, Amazon changed its approach to asynchronicity. AWS SDK for Java v2 introduced support for non-blocking I/O and based the whole thing on Netty. In addition, the new version of the API began using so-called Fluent Interfaces, making the two editions very much backward incompatible. On the part of the Spring Cloud AWS developers, this, therefore, meant the need for overall refactoring, which they used as an opportunity to correct some decisions they were not satisfied with. This, of course, has its consequences – the whole thing is only compatible with Spring Boot 3.0+. For the greater good.

A little to celebrate (or rather – to capitalize) on the above launch, I decided to take on topics that have been lingering in my mind for some time and waiting for their day – tools that grow in the ecosystem. After all, in the world of Spring, interesting projects pop up from time to time, which do not always gather any wide audience. That’s why today I wanted to show you two that have fallen into my lap in recent months.

Discover more IT content selected for you

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

Ostara

Okay, then let’s look at the first of the promised tools. How long it has been lingering in my backlog may be proven by the fact that when I was last interested in it, it still had a different name. The tool, which in my mind was known as boost currently (less than a week ago) has changed its name to ostara. According to a GitHub discussion, this was motivated by a desire to avoid conflicts with the popular boost library from the C++ world. As this may be a kind of new beginning for the project, let’s take a look at what the assumptions behind it are.

Ostara is a tool for managing and monitoring Spring microservices, which provides real-time key metrics such as CPU and memory usage, requiring only a running microservice instance with Actuator active. As a result, we get an admin panel, displaying all the parameters exposed by this API (and, as you check for yourself, there are quite a few). Ostara is easy to integrate with production-grade applications, flexible and has quite friendly documentation.

Ostara is not the first tool created by the community, being a kind of Admin Panel for Spring Boot. After all, Spring Boot Admin has been celebrating triumphs for several years and has become a de facto standard. Why then start a new project? The creators of Ostara motivate their decision by the fact that Spring Boot Admin requires interfering with the application code by adding spring-boot-admin-starter-client. Ostara is designed to rely entirely on the Spring Actuator API, so it works completely independently of the applications it monitors.

just

That’s how we talked about what Ostara is, along the way hooking up with Spring Boot Admin, it’s time to also look at just, which looks even more interesting

A week ago, I described how much I appreciate Quarkus for its emphasis on Developer Experience and Dev Mode, with which it strongly differentiates itself from competitors. just in my eyes is an attempt to create a Spring equivalent of Quarkus’ Dev Server. The project provides such functionalities as Live Reload, a code formatter, and the creation of resulting project binaries in various formats like Docker image or GraalVM – and everything with sensible defaults. The whole thing is expected to become a kind of Swiss Army Knife, solving developers’ everyday problems.

just is a relatively young project, which was created by Maciej Walkowiak, who, by the way, is one of the main contributors to the previously mentioned Spring Cloud AWS. What the projects have in common, by the way, is not only the creator but also a certain concept behind them. As Spring Cloud AWS is an overlay over the AWS SDK for Java, just is built on the foundation of spring-boot-devtools. However, each project adds enough from itself to form its own identity entirely.

The important thing from the users’ perspective is that as stated in FAQ just is not an open-source project. At this stage, its developer has decided to give himself an option and has not released the source code. When the solution, currently remaining in alpha, becomes fully production, then a decision will be made on a licensing model or the possible creation of a paid version.

Discover more IT content selected for you

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

Spring Modulith 0.6

That’s it at the very end, to close the whole thing Ouroboros style, I wanted to point out that a new version of Spring Modulith has been released. Version 0.6 doesn’t bring huge improvements (although it does introduce min. Support for the concept of jmolecules), but the project itself is interesting enough, in my opinion, to be worth being reminded.

Indeed, Modulith’s goal is to bring Spring into the era of the majestic monolith, adopting a rather unusual strategy to do so. Instead of interfering heavily with the build process, it uses integration tests to verify architectural assumptions. These fire up ArchUnit, a library whose purpose is precisely to verify dependencies between modules. The magic of Modulith, however, is that it is able to preconfigure ArchUnit for you, thanks to its familiar runtime environment (Spring Boot 3.0 applications). This makes it easy for us to test whether some architectural spaghetti has slipped through Code Review.

And that’s all folks, but we’ll probably be returning to the topic of the most popular Java framework soon – after all, Spring I/O is just a week away, where there will certainly be no shortage of interesting announcements. Anyone going to Barcelona perhaps?

PS: Today a bit shorter, because the conference season has started and instead of following Java I’m watching what’s interesting at Google I/O – and there’s actually a lot of interesting announcements there.