Spring Boot is a popular Java framework that is used to build robust and scalable applications. With each new release, Spring Boot introduces new features and enhancements to improve the developer experience and make it easier to build production-ready applications. The latest release, Spring Boot 3.1, is no exception to this trend. 

In this blog post, we will dive into the exciting new features offered in Spring Boot 3.1, as documented in the official Spring Boot 3.1 Release Notes. These new features and enhancements are designed to help developers build better applications with Spring Boot. By taking advantage of these new features, developers can build applications that are more robust, scalable, and efficient. 

So, if you’re a developer looking to build applications with Spring Boot, keep reading to learn more about the exciting new features offered in Spring Boot 3.1! 

Spring Boot 3.1 Feature List: 

          1. Dependency Management for Apache HttpClient 4: 

• Spring Boot 3.0 includes dependency management for both HttpClient 4 and 5. 
• Spring Boot 3.1 removes dependency management for HttpClient 4 to encourage users to move to HttpClient 5.2. Servlet and Filter Registrations: 

• The ServletRegistrationBean and FilterRegistrationBean classes will now throw an IllegalStateException if registration fails instead of logging a warning. 
• To retain the old behaviour, you can call setIgnoreRegistrationFailure(true) on your registration bean.3. Git Commit ID Maven Plugin Version Property: 

• The property used to override the version of io.github.git-commit-id:git-commit-id-maven-plugin has been updated. 
• Replace git-commit-id-plugin.version with git-commit-id-maven-plugin.version in your pom.xml.4. Dependency Management for Testcontainers: 

• Spring Boot’s dependency management now includes Testcontainers. 

• You can override the version managed by Spring Boot Development using the testcontainers.version property.5. Hibernate 6.2: 

• Spring Boot 3.1 upgrades to Hibernate 6.2. 
• Refer to the Hibernate 6.2 migration guide to understand how it may affect your application.6. Jackson 2.15: 

• Spring Boot 3.1 upgrades to Jackson 2.15. 
• Refer to the Jackson Wiki to understand how it may affect your application. 
• One notable change in Jackson 2.15 is the introduction of processing limits.7. Mockito 5: 

• Spring Boot 3.1 upgrades to Mockito 5 (specifically 5.3). 

• Refer to the Mockito release notes to learn about the notable changes in the Mockito 5.x line. 

All the above feature has highlights of new features but from these features, some features are explained in this blog. 

1. TestContainers 

The Testcontainers library is a tool that helps manage services running inside Docker containers. It works with testing frameworks such as JUnit and Spock, allowing you to write a test class that starts up a container before any of the tests run. Testcontainers are particularly useful for writing integration tests that interact with a real backend service such as MySQL, MongoDB, Cassandra, and others. 

Integration tests with Testcontainers take it to the next level, meaning we will run the tests against the actual versions of databases and other dependencies our application needs to work with executing the actual code paths without relying on mocked objects to cut the corners of functionality. 

<dependency> 
   <groupId>org.springframework.boot</groupId> 
   <artifactId>spring-boot-testcontainers</artifactId> 
   <scope>test</scope> 
</dependency> 
<dependency> 
   <groupId>org.testcontainers</groupId> 
   <artifactId>junit-jupiter</artifactId> 
   <scope>test</scope> 
</dependency> 

Add this dependency and add @Testcontainers in SpringTestApplicationTests class and run the test case 

@SpringBootTest 
@Testcontainers 
class SpringTestApplicationTests { 
   @Container 
   GenericContainer<?> container = new GenericContainer<>("postgres:9"); 
   @Test 
   void myTest(){ 
       System.out.println(container.getContainerId()+ "  "+container.getContainerName()); 
       assert (1 == 1); 
   }
} 

This will start the docker container for Postgres with version 9 

We can define connection details to containers using “@ServiceConnection” and “@DynamicPropertySource”.

a. ConnectionService 

@SpringBootTest
@Testcontainers
class SpringTestApplicationTests {
   @Container
   @ServiceConnection
   static MongoDBContainer container = new MongoDBContainer("mongo:4.4");
}

Thanks to @ServiceConnection, the above configuration allows Mongo-related beans in the application to communicate with Mongo running inside the Testcontainers-managed Docker container. This is done by automatically defining a MongoConnectionDetails bean which is then used by the Mongo auto-configuration, overriding any connection-related configuration properties.

b. Dynamic Properties

A slightly more verbose but also more flexible alternative to service connections is @DynamicPropertySource. A static @DynamicPropertySource method allows adding dynamic property values to the Spring Environment. 

@SpringBootTest
@Testcontainers
class SpringTestApplicationTests {
   @Container
   @ServiceConnection
   static MongoDBContainer container = new MongoDBContainer("mongo:4.4");
   @DynamicPropertySource
   static void registerMongoProperties(DynamicPropertyRegistry registry) {
       String uri = container.getConnectionString() + "/test";
       registry.add("spring.data.mongodb.uri", () -> uri);
   }
} 

c. Using Testcontainers at Development Time

Test the application at development time, first we start the Mongo database our app won’t be able to connect to it. If we use Docker, we first need to execute the docker run command that runs MongoDB and exposes it on the local port.

Fortunately, with Spring Boot 3.1 we can simplify that process. We don’t have to Mongo before starting the app. What we need to do – is to enable development mode with Testcontainers.

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-testcontainers</artifactId>
   <scope>test</scope>
</dependency>

Then we need to prepare the @TestConfiguration class with the definition of containers we want to start together with the app. For me, it is just a single MongoDB container as shown below: 

@TestConfiguration
public class MongoDBContainerDevMode {
   @Bean
   @ServiceConnection
   MongoDBContainer mongoDBContainer() {
       return new MongoDBContainer("mongo:5.0");
   }
} 

After that, we have to “override” the Spring Boot main class. It should have the same name as the main class with the Test suffix. Then we pass the current main method inside the SpringApplication.from(…) method. We also need to set @TestConfiguration class using the with(…) method. 

public class SpringTestApplicationTests {
   public static void main(String[] args) {
       SpringApplication.from(SpringTestApplicationTests::main)
               .with(MongoDBContainerDevMode.class)
               .run(args);
   }
}

Finally, we can start our “test” main class directly from the IDE or we can just execute the following Maven command: 

$ mvn spring-boot:test-run

Once the app starts you will see that the Mongo container is up and running and connection to it, is established 

2. Docker Compose

If you’re using Docker to containerize your application, you may have heard of Docker Compose, a tool for defining and running multi-container Docker applications. Docker Compose is a popular choice for developers as it enables them to define a set of containers and their dependencies in a single file, making it easy to manage and deploy the application.

Fortunately, Spring Boot 3.1 provides a new module called spring-boot-docker-compose that provides seamless integration with Docker Compose. This integration makes it even easier to deploy your Java Spring Boot application with Docker Compose. Maven dependency for this is given below: 

<dependencies>
   <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-docker-compose</artifactId>
       <optional>true</optional>
   </dependency>
</dependencies> 

The spring-boot-docker-compose module automatically looks for a Docker Compose configuration file in the current working directory during startup. By default, the module supports four file types: compose.yaml, compose.yml, docker-compose.yaml, and docker-compose.yml. However, if you have a non-standard file type, don’t worry – you can easily set the spring.docker.compose.file property to specify which configuration file you want to use.

When your application starts up, the services you’ve declared in your Docker Compose configuration file will be automatically started up using the docker compose up command. This means that you don’t have to worry about manually starting and stopping each service. Additionally, connection details beans for those services will be added to the application context so that the services can be used without any further configuration.

When the application stops, the services will then be shut down using the docker compose down command. 

This module also supports custom images too. You can use any custom image as long as it behaves in the same way as the standard image. Specifically, any environment variables that the standard image supports must also be used in your custom image.

You have to define a custom image in the compose.yml file.

services:
 redis:
   image: 'mycompany/mycustomredis:7.0'
   ports:
     - '6379'
   labels:
     org.springframework.boot.service-connection: redis

Spring Boot can manage the lifecycle of Docker Compose by default, but you can change it using the spring.docker.compose.lifecycle-management property. The values supported are none, start-only, and start-and-stop. You can also change the commands used to start and stop Docker Compose using the spring.docker.compose.start.command and spring.docker.compose.stop.command properties.

For more details of Spring boot docker-compose refer to spring boot 3.1 official doc

Overall, the spring-boot-docker-compose module is a powerful and user-friendly tool that simplifies the process of deploying your Spring Boot application with Docker Compose. With this module, you can focus on writing code and building your application, while the module takes care of the deployment process for you.

Conclusion

Overall, Spring Boot 3.1 brings several valuable features and improvements, making it easier for developers to build production-ready applications. Consider exploring these new features and enhancements to take advantage of the latest capabilities offered by Spring Boot.