Mocking is an essential part of unit testing, and the Mockito library makes it easy to write clean and intuitive unit tests for your Java code.
Get started with mocking and improve your application tests using our Mockito guide:
Handling concurrency in an application can be a tricky process with many potential pitfalls. A solid grasp of the fundamentals will go a long way to help minimize these issues.
Get started with understanding multi-threaded applications with our Java Concurrency guide:
Spring 5 added support for reactive programming with the Spring WebFlux module, which has been improved upon ever since. Get started with the Reactor project basics and reactive programming in Spring Boot:
Since its introduction in Java 8, the Stream API has become a staple of Java development. The basic operations like iterating, filtering, mapping sequences of elements are deceptively simple to use.
But these can also be overused and fall into some common pitfalls.
To get a better understanding on how Streams work and how to combine them with other language features, check out our guide to Java Streams:
Explore Spring Boot 3 and Spring 6 in-depth through building a full REST API with the framework:
Yes, Spring Security can be complex, from the more advanced functionality within the Core to the deep OAuth support in the framework.
I built the security material as two full courses - Core and OAuth, to get practical with these more complex scenarios. We explore when and how to use each feature and code through it on the backing project.
You can explore the course here:
Spring Data JPA is a great way to handle the complexity of JPA with the powerful simplicity of Spring Boot.
Get started with Spring Data JPA through the guided reference course:
Refactor Java code safely — and automatically — with OpenRewrite.
Refactoring big codebases by hand is slow, risky, and easy to put off. That’s where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.
Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions — one for newcomers and one for experienced users. You’ll see how recipes work, how to apply them across projects, and how to modernize code with confidence.
Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.
Distributed systems often come with complex challenges such as service-to-service communication, state management, asynchronous messaging, security, and more.
Dapr (Distributed Application Runtime) provides a set of APIs and building blocks to address these challenges, abstracting away infrastructure so we can focus on business logic.
In this tutorial, we'll focus on Dapr's pub/sub API for message brokering. Using its Spring Boot integration, we'll simplify the creation of a loosely coupled, portable, and easily testable pub/sub messaging system:
1. Overview
It is common to use Semantic Versioning when naming release versions. For example, these rules apply for a version format such as MAJOR.MINOR.REVISION:
- MAJOR: Major features and potential breaking changes
- MINOR: Backward compatible features
- REVISION: Backward compatible fixes and improvements
Together with Semantic Versioning, projects often use labels to further clarify the state of a particular release. In fact, by using these labels we give hints about the build lifecycle or where artifacts are published.
In this quick article, we’ll examine the version-naming schemes adopted by major Spring projects.
2. Spring Framework and Spring Boot
In addition to Semantic Versioning, we can see that Spring Framework and Spring Boot use these labels:
- BUILD-SNAPSHOT
- M[number]
- RC[number]
- RELEASE
BUILD-SNAPSHOT is the current development release. The Spring team builds this artifact every day and deploys it to https://repo.spring.io/ui/native/snapshot.
A Milestone release (M1, M2, M3, …) marks a significant stage in the release process. The team builds this artifact when a development iteration is completed and deploys it to https://repo.spring.io/ui/native/milestone.
A Release Candidate (RC1, RC2, RC3, …) is the last step before building the final release. To minimize code changes, only bug fixes should occur at this stage. It is also deployed to https://repo.spring.io/ui/native/milestone.
At the very end of the release process, the Spring team produces a RELEASE. Consequently, this is usually the only production-ready artifact. We can also refer to this release as GA, for General Availability.
These labels are alphabetically ordered to make sure that build and dependency managers correctly determine if a version is more recent than another. For example, Maven 2 wrongly considered 1.0-SNAPSHOT as more recent than 1.0-RELEASE. Maven 3 fixed this behavior. As a consequence, we can experience strange behaviors when our naming scheme is not optimal.
3. Umbrella Projects
Umbrella projects, like Spring Cloud and Spring Data, are projects over independent but related sub-projects. To avoid conflicts with these sub-projects, an umbrella project adopts a different naming scheme. Instead of a numbered version, each Release Train has a special name.
In alphabetical order, the London Subway Stations are the inspiration for the Spring Cloud release names — for starters, Angel, Brixton, Finchley, Greenwich, and Hoxton.
In addition to Spring labels shown above, it also defines a Service Release label (SR1, SR2…). If we find a critical bug, a Service Release can be produced.
It is important to realize that a Spring Cloud release is only compatible with a specific Spring Boot version. As a reference, the Spring Cloud Project page contains the compatibility table.
4. Conclusion
As shown above, having a clear version-naming scheme is important. While some releases like Milestones or Release Candidates may be stable, we should always use production-ready artifacts. What is your naming scheme? What advantages does it have over this one?
