Last checked and updated on 13 Jun 2026
What Is New in Spring Boot 3.5
| Category | Highlights |
|---|---|
| New Features |
|
| Improvements |
|
| Breaking Changes |
|
| Deprecations |
|
What breaking changes does Spring Boot 3.5 introduce that require immediate attention before upgrading?
Spring Boot 3.5 ships several behavioral changes that will silently break applications if you upgrade without reviewing them first. The most operationally impactful ones are in task execution, actuator security, and configuration strictness.
TaskExecutor bean name change
The auto-configured TaskExecutor is no longer aliased as taskExecutor. Only applicationTaskExecutor is now registered. Any code injecting the executor by name -- including some Spring Integration and async configurations -- will fail at startup. The quickest fix is a BeanFactoryPostProcessor:
@Bean
static BeanFactoryPostProcessor taskExecutorAliasBeanFactoryPostProcessor() {
return (beanFactory) ->
beanFactory.registerAlias("applicationTaskExecutor", "taskExecutor");
}In practice, if you define a custom AsyncConfigurer, prefer the explicit approach using TaskExecutionAutoConfiguration.APPLICATION_TASK_EXECUTOR_BEAN_NAME to avoid fragile string-based lookups entirely.
Heapdump endpoint locked by default
The heapdump actuator endpoint now defaults to access=NONE. Previously, exposing it was sufficient. Now you must both expose it and set management.endpoint.heapdump.access=unrestricted. Watch out for monitoring pipelines or tooling that assumed the endpoint was available after a simple include: heapdump configuration.
Profile name validation
Profile names containing special characters (e.g. feature/my-flag or env:prod) will now throw at startup. As of 3.5.1, ., +, and @ are allowed again, and you can set spring.profiles.validate=false to disable the check entirely. Most teams using simple alphanumeric profile names will not be affected.
Boolean configuration strictness
.enabled properties no longer accept values like 1, yes, or any non-false string as truthy. Only true and false are accepted. This applies broadly to conditional configuration throughout the framework.
How does structured logging improve in Spring Boot 3.5?
Spring Boot 3.5 extends the structured logging foundation introduced in 3.4 with meaningful production-grade controls over stack trace output and contextual data.
The most practical addition is fine-grained stack trace formatting via the logging.structured.json.stacktrace.* namespace. In high-volume services, full stack traces in JSON logs can balloon log storage costs. You can now limit depth, customize the format, or suppress frames from specific packages -- all without writing custom appenders.
logging:
structured:
json:
stacktrace:
max-depth: 10
context:
include: falseECS (Elastic Common Schema) output has also been updated to use nested JSON format, improving compatibility with Elastic-stack consumers. If you are parsing ECS logs with custom tooling that expected a flat structure, you will need to update your log parsers.
Additional miscellaneous logging improvements include:
- Logback and Log4j2 now respect the console charset, fixing encoding issues in Docker/container environments
- ECS format now populates Logback and Log4j markers into the
tagsfield - A Logback
OnErrorConsoleStatusListeneris now installed automatically to surface initialization errors to the console - The
logging.structured.json.customizerproperty now accepts multiple customizer bean names - Additional
logging.structured.json.contextproperties allow context data to be excluded or relocated within the JSON payload
How does Spring Boot 3.5 improve SSL and service connection security?
Spring Boot 3.5 adds first-class client-side SSL support for the most commonly used service connections, making it straightforward to enforce TLS in production environments without custom configuration code.
SSL is now configurable for connections to Cassandra, Couchbase, Elasticsearch, Kafka, MongoDB, RabbitMQ, and Redis -- all via standard spring.ssl.bundle configuration. The Testcontainers and Docker Compose integrations have been updated in parallel: Testcontainers provides new annotations, while Docker Compose uses container labels to wire SSL bundles automatically during development.
Actuator now publishes SSL bundle health metrics. The ssl.chains metric counts certificate chains by status (valid, expired, soon-to-expire, not-yet-valid), and ssl.chain.expiry tracks seconds until expiry per chain. This matters if you operate services with certificates that rotate infrequently -- you can now set up alerting on impending expiry without custom code.
Watch out for Couchbase Capella users: the embedded Capella CA certificate is no longer trusted automatically. You must explicitly configure an SSL bundle pointing at the certificate from the com.couchbase.client:core-io dependency:
spring:
ssl:
bundle:
pem:
couchbase-bundle:
truststore:
certificate: classpath:com/couchbase/client/core/env/capella-ca.pem
couchbase:
env:
ssl:
bundle: couchbase-bundleWhat improvements has Spring Boot 3.5 made to background initialization and async task execution?
Spring Boot 3.5 makes bean background initialization available out of the box by auto-configuring a bootstrapExecutor bean, removing the need for manual setup that was previously required to parallelize application context startup.
When an applicationTaskExecutor bean is present (the default if you have not defined a custom Executor), Spring Boot now automatically registers the bootstrapExecutor bean. Spring Framework's background initialization feature will use this executor to parallelize the creation of beans that are annotated or configured for deferred startup. This can meaningfully reduce startup times for applications with many heavyweight beans such as JPA entity managers, caches, or connection pools.
For teams that have provided a custom Executor but still want the full auto-configuration stack (including @Async, virtual thread integration, and task decorators), the new spring.task.execution.mode=force property instructs Spring Boot to auto-configure an AsyncTaskExecutor alongside the custom executor:
spring:
task:
execution:
mode: forceTask decoration also reaches scheduled tasks in this release. If a TaskDecorator bean is defined (for MDC propagation, security context copying, or tracing), it is now applied not just to async execution but also to the auto-configured ThreadPoolTaskSchedulerBuilder and SimpleAsyncTaskSchedulerBuilder.
What observability and OpenTelemetry improvements are included in Spring Boot 3.5?
Spring Boot 3.5 expands OpenTelemetry integration with environment variable support, new resource attributes, configurable span export, and improved OTLP exporter customization.
The OTEL_RESOURCE_ATTRIBUTES and OTEL_SERVICE_NAME environment variables are now read automatically. This is important for Kubernetes deployments that inject OTEL configuration via the OpenTelemetry Operator or via pod environment variables -- you no longer need to mirror those values into Spring Boot properties. Note that Spring Boot properties still take precedence over environment variables if both are set.
A new service.namespace resource attribute is now populated from spring.application.group. The previously supported service.group attribute has been deprecated. Teams using Grafana or Jaeger dashboards that group traces by namespace should update their attribute mappings.
Other noteworthy changes:
- Custom
BatchSpanProcessorbeans are now supported - Span export is configurable via the new
management.tracing.opentelemetry.export.*property namespace - Customizers for
OtlpHttpSpanExporterBuilderandOtlpGrpcSpanExporterBuilderhave been added MeterProviderbeans are now auto-wired onto OTLP HTTP and gRPC log record and span exporters- If
io.micrometer:micrometer-java21is on the classpath, aVirtualThreadsMetricsbean is now auto-configured - Zipkin now defaults to
ZipkinHttpClientSender; support forURLConnectionSenderhas been removed - Histogram flavor and max-bucket configuration is now available per meter registry
Frequently Asked Questions about Spring Boot 3.5
Does upgrading to Spring Boot 3.5 require any changes to my async task executor configuration?
Yes, if your code injects the auto-configured TaskExecutor by the name taskExecutor you must update it to use applicationTaskExecutor, or register the alias manually via a BeanFactoryPostProcessor, since the taskExecutor alias is no longer provided by default.
Will my application fail to start if my Spring profiles contain special characters after upgrading to 3.5?
It depends on the characters. The initial 3.5.0 release restricts profiles to letters, digits, dashes, and underscores. However, as of 3.5.1 the dot, plus, and at-sign characters are permitted again, and you can set spring.profiles.validate to false to disable validation entirely if you need to override the restriction.
How do I re-enable the heapdump actuator endpoint in Spring Boot 3.5?
You must both include it in the exposure list and set its access level explicitly -- for example, set management.endpoints.web.exposure.include to include heapdump and set management.endpoint.heapdump.access to unrestricted in your application properties.
Does Spring Boot 3.5 change how @ConditionalOnMissingBean works with generic types?
Yes, bean conditions now consider generic type parameters when evaluating a @Bean method's return type. A condition such as @ConditionalOnMissingBean on a method returning Converter of String to Integer will only match if no Converter of exactly that parameterized type exists. To match any Converter regardless of its generic parameters, you must explicitly pass the raw class to the annotation, for example @ConditionalOnMissingBean with the type attribute set to Converter.class.
Is the Apache Pulsar client upgrade from 3.3 to 4.0 in Spring Boot 3.5 backward compatible?
The upgrade is required because Pulsar 3.3.x has reached end-of-life, and Spring Boot 3.5 now depends on the 4.0.x LTS release. Review the Apache Pulsar 4.0 release notes for any client API changes before upgrading, as 4.0 is a major version bump that may contain incompatibilities in advanced client configurations.
Can I load multiple configuration properties from a single environment variable in Spring Boot 3.5?
Yes, using the new env: import prefix in spring.config.import. Set the environment variable to multi-line content in either properties or YAML format, then add spring.config.import=env:YOUR_VARIABLE_NAME to your configuration. All key-value pairs in that variable will be imported directly into the Spring Environment.