Spring Boot 4 and Spring Framework 7: The New Era of Java for Fast and Secure Microservices

Modularization: Unpacking the Suitcase

Previously, the spring-boot-autoconfigure module was a giant artifact containing configuration logic for almost everything, even if you didn't use it. This generated what's known as "classpath noise."

The Solution: Spring Boot 4 has split this massive module into smaller, focused artifacts. Now, auto-configuration is distributed across specialized modules that only load when needed.

Concrete benefits:

1. Faster startup: Less code to scan means reduced startup times.
2. Lower memory consumption: You only load what you actually need.
3. Better development experience: Your IDE will give you more precise suggestions, without showing irrelevant classes and properties.
4. Optimized native images: Native image generation with GraalVM is more efficient.

AOT Compilation and GraalVM

Spring Boot 4 is fully aligned with GraalVM 24 or higher. AOT (Ahead-of-Time) processing has been significantly optimized:

• Faster compilation times
• Reduced memory footprint at startup
• Better static analysis to eliminate dead code
• Improved compatibility with reflection hints

The new @ConfigurationPropertiesSource annotation enables even more granular modularization, making it easier to process only the configuration properties relevant to your application.

What is JSpecify?

JSpecify is a collaborative standard backed by Google, JetBrains, Meta, Oracle, and other tech giants. It provides explicit annotations to indicate whether a value can be null or not.

The Game Changer: @NullMarked

You can mark an entire package as null-safe by creating a package-info.java file:

// src/main/java/com/yourcompany/service/package-info.java
@org.jspecify.annotations.NullMarked
package com.yourcompany.service;

With this, your IDE (like IntelliJ IDEA 2025.3+ which supports it natively) will alert you while you write code if you try to use a value that could be null in a context that expects a non-null value.

Practical example:

@NullMarked
package com.example.users;

public class UserService {

    // The IDE will warn if you try to pass null
    public User createUser(@NonNull String name, @Nullable String lastName) {
        // name is never null - safe to use directly
        String fullName = name.toUpperCase();

        // lastName can be null - you must check
        if (lastName != null) {
            fullName += " " + lastName.toUpperCase();
        }

        return new User(fullName);
    }
}

This dramatically reduces the risk of a NullPointerException in production by catching problems at development time.

Goodbye to RestTemplate

RestTemplate has been officially deprecated in Spring Framework 7 and will be removed in future versions. The code was verbose, difficult to test, and didn't leverage modern Java features.

The New Era: RestClient and @HttpExchange

RestClient is the modern replacement for RestTemplate, with a fluent API and builder style. But the most revolutionary capability is creating declarative HTTP clients using @HttpExchange.

Declarative Client Example:

package com.yourcompany.clients;

import org.springframework.web.service.annotation.GetExchange;
import org.springframework.web.service.annotation.PostExchange;
import org.springframework.web.service.annotation.HttpExchange;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestBody;

@HttpExchange("/api/products")
public interface ProductClient {

    @GetExchange("/{id}")
    Product getProduct(@PathVariable("id") String id);

    @GetExchange
    List<Product> listProducts();

    @PostExchange
    Product createProduct(@RequestBody Product product);
}

Client Configuration:

@Configuration
public class ClientConfig {

    @Bean
    public ProductClient productClient(RestClient.Builder builder) {
        RestClient restClient = builder
            .baseUrl("https://api.example.com")
            .build();

        HttpServiceProxyFactory factory = HttpServiceProxyFactory
            .builderFor(RestClientAdapter.create(restClient))
            .build();

        return factory.createClient(ProductClient.class);
    }
}

Advantages:

• Zero boilerplate: You define what to call, not how to call it
• Easier to test: You can easily mock the interface
• Type-safe: Leverages Java's type system
• Native integration: No additional dependencies needed

Spring Boot 4 also introduces improvements in auto-configuration of these clients, with the clientType attribute that allows switching between RestClient (default) and WebClient (for reactive cases) without modifying client code.

Native Resilience

Resilience annotations, previously dependent on the external Spring Retry project, are now incorporated into Spring Framework 7:

• @Retryable: Applies retry logic if a method fails
• @ConcurrencyLimit: Limits concurrent calls to a method
• @EnableResilientMethods: Activates these annotations in your beans

Resilience Example:

@Service
@EnableResilientMethods
public class PaymentService {

    @Retryable(maxAttempts = 3, backoff = @Backoff(delay = 1000))
    public PaymentResponse processPayment(PaymentRequest request) {
        // If it fails, it retries up to 3 times with 1 second wait
        return paymentGateway.process(request);
    }

    @ConcurrencyLimit(maxConcurrency = 10)
    public Report generateReport() {
        // Maximum 10 concurrent calls
        return reportService.generate();
    }
}

Native API Versioning

Spring Framework 7 solves the "nightmare" of REST API versioning. Now you can use the version attribute in @RequestMapping and its variants:

Controller Example with Versioning:

@RestController
@RequestMapping("/api/orders")
public class OrderController {

    // Version 1: Simple response
    @GetMapping(version = "1", produces = MediaType.APPLICATION_JSON_VALUE)
    public List<OrderV1> getOrdersV1() {
        return orderService.getSimpleOrders();
    }

    // Version 2: Enriched response with metadata
    @GetMapping(version = "2", produces = MediaType.APPLICATION_JSON_VALUE)
    public OrderResponseV2 getOrdersV2() {
        return orderService.getCompleteOrders();
    }
}

Centralized Configuration:

@Configuration
public class ApiVersioningConfig implements WebMvcConfigurer {

    @Override
    public void configureContentNegotiation(ContentNegotiationConfigurer configurer) {
        // Header strategy
        configurer.apiVersioning(builder -> builder
            .strategy(VersionStrategy.HEADER)
            .headerName("API-Version")
        );

        // Or by path: /v1/orders, /v2/orders
        // Or by query parameter: /orders?version=1
    }
}

The versioning strategy is defined centrally, allowing you to change strategies (path, header, query parameter) without rewriting your controllers.

OpenTelemetry Integration

• Micrometer 2.0: Updated with performance improvements
• Native OpenTelemetry: Official starter included in Spring Boot 4
• Automatic correlation: Logs, metrics, and traces automatically correlated

The @Observed Annotation

Automatically creates metrics and traces for any method:

@Service
public class InventoryService {

    @Observed(name = "inventory.check", contextualName = "checkAvailability")
    public boolean checkAvailability(String productId) {
        // Automatically generates metrics for:
        // - Execution time
        // - Number of calls
        // - Error rate
        return inventoryRepository.hasStock(productId);
    }
}

SSL Health Monitoring

The Actuator now performs automatic SSL certificate monitoring. If a certificate is about to expire (by default, within 14-30 days), the /actuator/health endpoint explicitly reports it:

{
  "status": "UP",
  "components": {
    "ssl": {
      "status": "WARNING",
      "details": {
        "certificate": "api.example.com",
        "expiresIn": "12 days",
        "expiryDate": "2025-12-05"
      }
    }
  }
}

This is a "lifesaver" to avoid production panic when certificates expire unexpectedly.

JdbcClient: Cleaner Code

The new JdbcClient eliminates verbosity, adopting a builder pattern that's more intuitive and easier to read:

Before (JdbcTemplate):

public List<Person> findAll() {
    return jdbcTemplate.query(
        "SELECT id, name, age FROM person",
        new RowMapper<Person>() {
            @Override
            public Person mapRow(ResultSet rs, int rowNum) throws SQLException {
                Person p = new Person();
                p.setId(rs.getLong("id"));
                p.setName(rs.getString("name"));
                p.setAge(rs.getInt("age"));
                return p;
            }
        }
    );
}

Now (JdbcClient):

public List<Person> findAll() {
    return jdbcClient.sql("SELECT id, name, age FROM person")
        .query((rs, rowNum) -> new Person(
            rs.getLong("id"),
            rs.getString("name"),
            rs.getInt("age")
        ))
        .list();
}

// Or even simpler with automatic mapping
public List<Person> findAll() {
    return jdbcClient.sql("SELECT * FROM person")
        .query(Person.class)
        .list();
}

Parameterized queries:

public Optional<Person> findById(Long id) {
    return jdbcClient.sql("SELECT * FROM person WHERE id = :id")
        .param("id", id)
        .query(Person.class)
        .optional();
}

Write operations:

public int updateAge(Long id, int newAge) {
    return jdbcClient.sql("UPDATE person SET age = :age WHERE id = :id")
        .param("age", newAge)
        .param("id", id)
        .update();
}

This new approach:

• Is more concise and readable
• Leverages lambdas and method references
• Integrates better with Optional for safe null handling
• Improves support for AOT and GraalVM

More Granular Test Slices

New test slices to test specific components without loading the entire application context:

@HttpServiceClientTest
class ProductClientTest {

    @Autowired
    private ProductClient productClient;

    @Test
    void shouldGetProduct() {
        // Only loads configuration needed for HTTP clients
        Product product = productClient.getProduct("123");
        assertThat(product).isNotNull();
    }
}

Improved TestRestTemplate

Better integration with the new RestClient and support for typed responses:

@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
class IntegrationTest {

    @Autowired
    private TestRestClient restClient;

    @Test
    void shouldCreateUser() {
        User newUser = new User("John", "Doe");

        User created = restClient.post()
            .uri("/api/users")
            .body(newUser)
            .exchange()
            .expectStatus().isCreated()
            .expectBody(User.class)
            .returnResult();

        assertThat(created.getId()).isNotNull();
    }
}

Mandatory Changes

1. Jackson 3.x: Jackson update from 2.x to 3.x
2. Jakarta Namespace: Complete migration from javax.* to jakarta.*
3. Java 17 minimum: Although Java 21+ is recommended
4. Kotlin 2.2+: If you use Kotlin

Important Deprecations

• RestTemplate → RestClient or declarative clients
• Lambda-based configurations are mandatory in Spring Security
• Several configuration properties have been renamed

Migration Tools

Spring recommends using OpenRewrite to automate much of the migration:

<plugin>
    <groupId>org.openrewrite.maven</groupId>
    <artifactId>rewrite-maven-plugin</artifactId>
    <version>5.42.0</version>
    <configuration>
        <activeRecipes>
            <recipe>org.openrewrite.java.spring.boot4.UpgradeSpringBoot_4_0</recipe>
        </activeRecipes>
    </configuration>
</plugin>

This plugin can automate:

• Dependency updates
• Namespace changes javax → jakarta
• Migration of deprecated APIs
• Configuration file updates