What Is New in Spring Boot 4.1
Spring Boot 4.1 is a significant release that delivers first-class gRPC support, a comprehensive overhaul of OpenTelemetry integration, new SSRF mitigation tooling, lazy JDBC connection fetching, Redis listener auto-configuration, and dozens of smaller improvements across Jackson, observability, security, and the build toolchain.
| Category | Highlights |
|---|---|
| New Features |
|
| Improvements |
|
| Breaking Changes |
|
| Deprecations |
|
Does Spring Boot 4.1 Finally Have Native gRPC Support?
Yes -- Spring Boot 4.1 ships first-class gRPC support through three dedicated modules: spring-boot-grpc-server, spring-boot-grpc-client, and spring-boot-grpc-test, backed by Spring gRPC 1.1.0 and grpc-java 1.80.0.
You can run a stand-alone Netty-backed gRPC server, or use the Servlet integration to serve gRPC over HTTP/2 alongside your existing REST endpoints on the same port. The Servlet path is particularly useful in environments where opening a second port is operationally inconvenient -- load balancers, sidecar proxies, and Kubernetes services all become simpler to configure when everything shares one port.
Getting started is straightforward. Add the server starter and annotate your service implementations as usual:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-grpc-server</artifactId>
</dependency>Boot will auto-configure the server, wire interceptors, and pick up your service beans -- the same convention-over-configuration model you already know from REST. If you are upgrading from Spring gRPC 1.0, a dedicated migration guide covers the changes needed to move to Spring gRPC 1.1 with Boot 4.1.
What Changed for Observability and OpenTelemetry in Spring Boot 4.1?
Spring Boot 4.1 delivers the most comprehensive OpenTelemetry update since the integration was introduced, touching the SDK lifecycle, exporter configuration, sampling, limits, and environment variable interoperability.
The headline addition is management.opentelemetry.enabled=false, which switches the SDK to no-op implementations for SdkTracerProvider, SdkLoggerProvider, and SdkMeterProvider while preserving propagator configuration. This is the pattern you want in integration test environments where you need trace context to flow but do not want actual telemetry exported.
Beyond the kill-switch, 4.1 adds configuration coverage for areas that previously required custom beans:
- BatchLogRecordProcessor -- via properties under
management.opentelemetry.logging.*, mirroring the existing BatchSpanProcessor support. - Sampler -- via
management.opentelemetry.tracing.sampler. - SpanLimits and LogLimits -- via
management.opentelemetry.tracing.limits.*andmanagement.opentelemetry.logging.limits.*. - OTLP exemplars -- auto-configured when you combine OTLP metrics with Micrometer Tracing, linking traces and metrics without any extra wiring.
- SSL bundles -- now supported on all three OTLP exporters (logging, metrics, traces).
- OTel environment variables -- Boot now reads most of the standard OpenTelemetry SDK environment variables (OTEL_SERVICE_NAME, OTEL_EXPORTER_OTLP_ENDPOINT, and many more), mapping them to the corresponding Spring Boot properties. This is a major interoperability win for teams operating in environments where OTel env vars are already set at the platform level.
On the Micrometer side, auto-configured JVM metrics now pick up custom convention beans automatically -- JvmMemoryMeterConventions, JvmThreadMeterConventions, JvmClassLoadingMeterConventions, and JvmCpuMeterConventions are all wired without any extra configuration. The same applies to Kafka and RabbitMQ listener and template observation conventions. Context propagation across @Async boundaries is also now automatic for the auto-configured executor.
What New Security and HTTP Client Features Are in Spring Boot 4.1?
Spring Boot 4.1 introduces SSRF (Server-Side Request Forgery) mitigation tooling directly in the framework via a new InetAddressFilter that can be applied to both reactive and blocking HTTP clients. This lets you define a blocklist of IP ranges or hostnames that the application should never reach out to -- a meaningful hardening step for any service that fetches user-supplied URLs.
In practice, configuring it looks like declaring a bean that Boot wires into the auto-configured client. The reference documentation covers the filter API and typical blocklist patterns for private RFC 1918 ranges and link-local addresses. Most teams building internal tooling or user-facing proxy functionality should evaluate this feature before upgrading.
HTTP client cookie handling received a consistency fix: TestRestTemplate now aligns with RestTemplate behavior, and a new withCookieHandling method makes the configuration explicit. The new spring.http.clients.cookie-handling property also lets you control cookie behavior for the auto-configured client globally. This matters if you have been testing stateful flows (session cookies, CSRF tokens) and seen behavior differences between your tests and production.
On the OAuth2 side, JWT authority extraction now supports SpEL expressions via spring.security.oauth2.resourceserver.jwt.authorities-claim-expressions. This is mutually exclusive with the existing authorities-claim-name and authorities-claim-delimiter properties, and works in both Servlet and Reactive stacks. Use spring.security.oauth2.resourceserver.jwt.authority-prefix if you need a prefix other than the default SCOPE_.
What Data and Messaging Improvements Landed in Spring Boot 4.1?
Spring Boot 4.1 adds several production-relevant data access and messaging features that are worth evaluating early in any upgrade.
Lazy JDBC connection fetching is a meaningful addition for applications that run many short-lived transactions or that frequently hit cache layers before touching the database. Setting spring.datasource.connection-fetch=lazy wraps the auto-configured pooled DataSource with LazyConnectionDataSourceProxy, so a physical connection is not checked out from the pool until a JDBC statement is actually executed. This can reduce pool contention and connection hold times in mixed workloads where some request paths never reach the database.
spring.datasource.connection-fetch=lazyRedis listener auto-configuration is another gap finally closed. If your application does not define a RedisMessageListenerContainer, Boot now registers a default one so that @RedisListener annotated methods are discovered and invoked without any extra wiring. Configuration options are available under spring.data.redis.listener.*. Note that spring-boot-starter-data-redis now declares a dependency on spring-messaging, which this feature requires.
MongoDB support for Spring Batch ships with a new spring-boot-batch-data-mongo starter. Schema initialization is opt-in via spring.batch.data.mongo.schema.initialize=true, and you can supply a custom newline-delimited JSON script if the default schema does not fit your needs. This completes the picture for teams running Batch jobs without a relational database.
Spring Data JPA bootstrap modes received a behavioral refinement worth understanding before upgrading. In deferred mode, Boot now throws an exception if no suitable AsyncTaskExecutor is found -- previously this failed silently or fell back to synchronous init. In lazy mode, the bootstrap executor is no longer set because it is generally not needed. If your application explicitly relies on the old behavior in either mode, test this carefully.
What Are the Key Upgrade Considerations When Moving to Spring Boot 4.1?
Spring Boot 4.1 has a compact but impactful list of breaking changes. These are the ones most likely to surface in a production codebase:
- All Spring Boot 4.0 deprecations are removed. Run your existing build with
-Xlint:deprecation(Maven) oroptions.deprecation = true(Gradle) before attempting the upgrade. Any call to a deprecated 4.0 API will be a compile error in 4.1. - jOOQ 3.20 requires Java 21. If you use jOOQ and have not yet moved to Java 21, this is a hard blocker. Spring Boot 4.1 ships with jOOQ 3.21.5.
- Layertools jar mode is gone. Replace
java -Djarmode=layertools -jar app.jar extractwithjava -Djarmode=tools -jar app.jar extractin all Dockerfiles and CI pipelines. - Maven AOT processing is no longer skipped by
-DskipTests. Switch to-Dmaven.test.skip=trueto suppress both tests and AOT processing. - ReactorClientHttpRequestFactoryBuilder defaults changed.
proxyWithSystemProperties()is no longer applied by default. If you rely on system proxy settings for outgoing reactive HTTP calls, use thewithHttpClientDefaultsmethod to restore the previous behavior. - Spring Data JPA deferred mode is stricter. An exception is thrown if no
AsyncTaskExecutorbean is available. Review your context setup if you usespring.data.jpa.repositories.bootstrap-mode=deferred. - BuildInfo Gradle task output path changed. The generated file is now at
META-INF/build-info.properties. Use thefilenameproperty to restore the old location if your tooling depends on it. - Derby is deprecated. No new features will land for Derby and removal is on the roadmap. Migrate to H2 or HSQLDB now.
- Dynatrace V1 API deprecated. Migrate to V2 configuration before removal in a future release.
- Devtools LiveReload deprecated. No replacement is planned. Evaluate browser-sync or IDE live reload as alternatives.
Frequently Asked Questions about Spring Boot 4.1
Does Spring Boot 4.1 require any changes to existing configuration properties when upgrading from 4.0?
Most property names are unchanged. The key things to watch: if you use spring.data.jpa.repositories.bootstrap-mode=deferred you now need an AsyncTaskExecutor bean or Boot will throw; the BuildInfo Gradle task now writes to META-INF/build-info.properties by default instead of the destination root; and Dynatrace V1 API properties are deprecated and should be migrated to V2. All other configuration properties carry over from 4.0.
How do I protect my Spring Boot 4.1 application from SSRF attacks using the new InetAddressFilter?
Declare an InetAddressFilter bean that blocks the address ranges you want to forbid -- typically RFC 1918 private ranges (10.x.x.x, 172.16-31.x.x, 192.168.x.x) and the link-local range (169.254.x.x). Boot auto-wires the filter into both the reactive WebClient and the blocking RestClient when it detects the bean. The reference documentation for Spring Boot 4.1 under io.rest-client.global-configuration.inetaddress-filtering covers the API and common patterns.
How do I enable lazy JDBC connection fetching in Spring Boot 4.1?
Set spring.datasource.connection-fetch=lazy in your application properties. Boot wraps the auto-configured pooled DataSource with LazyConnectionDataSourceProxy, so a physical connection is only checked out from the pool when a JDBC statement is actually executed. The eager value restores the previous behavior if needed. This is most useful for applications with mixed workloads where many request paths hit a cache or return early without touching the database.
What is the minimum Java version for Spring Boot 4.1?
Java 21, unchanged from Spring Boot 4.0. The jOOQ 3.20 upgrade enforces this more strictly for jOOQ users since that library itself now requires Java 21.
How do I migrate from the layertools jar mode that was removed in Spring Boot 4.1?
Replace java -Djarmode=layertools -jar app.jar extract with java -Djarmode=tools -jar app.jar extract in your Dockerfiles and CI scripts. The tools mode provides the same extract and list-layers functionality plus additional capabilities. No other changes are needed.
Does Spring Boot 4.1 support OpenTelemetry environment variables like OTEL_EXPORTER_OTLP_ENDPOINT?
Yes, 4.1 adds support for reading most of the standard OpenTelemetry SDK environment variables and maps them to the corresponding Spring Boot configuration properties. This means you can configure OTel exporters, sampling, and service identity entirely through environment variables without duplicating values in application.properties. A complete mapping table is available in the reference documentation under actuator.observability.opentelemetry.environment-variables.