Redisson on Spring Boot 4: Versions, Moved Classes, and Upgrade Traps

Spring Boot 4.0 shipped on 20 November 2025 and 4.1 followed on 10 June 2026. As of 30 June 2026, no Spring Boot 3.x line has free support — 3.5.x was the last one, and its OSS window closed. If you are running Redisson on Spring Boot 3, the upgrade is no longer optional maintenance; it is the difference between patched and unpatched.

The good news is that Redisson has supported Spring Boot 4 since version 4.0.0, released 16 December 2025 — twenty-six days after Boot 4 went GA — and Spring Boot 4.1 since Redisson 4.6.0 in June 2026. The awkward news is that Spring Boot 4's modularization moved the Redis auto-configuration into a different jar under different class names, and the first of the three things that can go wrong during the upgrade fails silently — nothing throws, and you end up running a configuration you deliberately turned off. The other two do throw: one waits until the application context starts, and one is a compile error you cannot miss.

This page is the version matrix and the trap list. All coordinates are verified against Maven Central as of 28 August 2026, when the current Redisson release is 4.7.0 and the current Spring Boot GA is 4.1.1.

The Version Matrix

Redisson ships one redisson-spring-boot-starter artifact, plus a family of redisson-spring-data-XX modules where the suffix tracks the Spring Data Redis line, not the Spring Boot version. Getting the pairing right is the whole job.

That repeated 7.0.x is not a typo. Spring Boot 4.1 did not move to a new Spring Framework minor — both lines track Framework 7.0.x and pick up whatever patch is current at each release, so they have converged: Boot 4.0.8 and 4.1.1 both ship Framework 7.0.9. Only the Spring Data Redis line steps, which is why the Redisson module suffix tracks Spring Data and not Spring Framework.

Every one of those modules is still published at Redisson 4.7.0. Redisson rebuilds its full compatibility range at each release — back to redisson-spring-data-16 — so staying on an older Boot line never means running an abandoned Redisson module. It only means you have to name it explicitly.

What the Starter Bundles — and What to Exclude

The starter pulls in one redisson-spring-data-XX module transitively, and which one has changed over time:

If you are on Spring Boot 4.1, the starter alone is correct and there is nothing to exclude:

<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson-spring-boot-starter</artifactId>
    <version>4.7.0</version>
</dependency>

On any other line, exclude the bundled module and add yours. For Spring Boot 4.0:

<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson-spring-boot-starter</artifactId>
    <version>4.7.0</version>
    <exclusions>
        <exclusion>
            <groupId>org.redisson</groupId>
            <artifactId>redisson-spring-data-41</artifactId>
        </exclusion>
    </exclusions>
</dependency>

<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson-spring-data-40</artifactId>
    <version>4.7.0</version>
</dependency>

And in Gradle:

implementation('org.redisson:redisson-spring-boot-starter:4.7.0') {
    exclude group: 'org.redisson', module: 'redisson-spring-data-41'
}
implementation 'org.redisson:redisson-spring-data-40:4.7.0'

What Spring Boot 4 Moved

Spring Boot 4 broke the monolithic spring-boot-autoconfigure jar into focused modules. The scale of it is easy to miss: spring-boot-autoconfigure 3.5.16 contains 1,483 classes. Version 4.1.0 contains 258, and not one of them mentions Redis. The Redis auto-configuration now lives in its own artifact, org.springframework.boot:spring-boot-data-redis, and both the package and the class names changed:

What did not change is your configuration file. DataRedisProperties still carries @ConfigurationProperties("spring.data.redis"), so every application.yml and application.properties key survives the upgrade untouched:

spring:
  data:
    redis:
      host: localhost
      port: 6379

One Redis-adjacent prefix did move, though, and it is one this article's readers are unusually likely to hit: Spring Session's keys went from spring.session.redis.* to spring.session.data.redis.* in Spring Boot 4. If you use Spring Session backed by Redis or Valkey, that is the one property rename to make.

Redisson's own property prefix, spring.redis.redisson.*, is unchanged and has been since it was introduced. The last time Redis property keys moved was Spring Boot 3.0, when Spring's own connection properties went from spring.redis.* to spring.data.redis.*. Boot 4 did not repeat that. If you are coming from 2.7 rather than 3.x, that older rename is the one to watch.

Three Traps, Only One of Them Silent

1. Your autoconfigure.exclude quietly stops working

Teams that run Redisson in some environments but not others commonly disable it by name. On Spring Boot 3 that looks like this:

spring:
  autoconfigure:
    exclude:
      - org.redisson.spring.starter.RedissonAutoConfigurationV2

Carry that file to Spring Boot 4 and it still parses. It still validates. And it excludes nothing, because the class that activates on Boot 4 is RedissonAutoConfigurationV4. Redisson starts in an environment where you deliberately turned it off, and the only symptom is connection attempts to a Redis or Valkey server that may not exist. The fix is one line:

spring:
  autoconfigure:
    exclude:
      - org.redisson.spring.starter.RedissonAutoConfigurationV4

The annotation form is no safer, and this is worth being precise about because the intuition runs the other way. @EnableAutoConfiguration(exclude = { RedissonAutoConfigurationV2.class }) still compiles on Spring Boot 4, because RedissonAutoConfigurationV2.class is physically shipped inside the starter jar on every Boot line — it simply never activates. Spring Boot will not flag it at startup either: AutoConfigurationImportSelector only rejects an exclusion that is loadable from the classpath yet absent from AutoConfiguration.imports, and V2 fails the second half — it is in the jar, but it is also listed in the imports file unconditionally, so nothing about the exclusion ever looks invalid.

So both spellings fail silently, and grep is the only defence. Before you upgrade, search the whole repository — YAML, properties files and annotations alike — for RedissonAutoConfigurationV2.

2. The transitive Spring Data module is not the one you want (NoClassDefFoundError or AbstractMethodError at runtime)

This one is louder but lands later, and it is the most common upgrade mistake. The starter bundles redisson-spring-data-41. If the version matrix above says you need a different one, your build tool will not warn you — it resolves the transitive dependency exactly as declared.

A mismatch between the resolved redisson-spring-data-XX and the Spring Data Redis on your classpath breaks in either direction, but not equally. A Boot 3.5 application that adds redisson-spring-boot-starter:4.7.0 without an exclusion pulls a Spring Data Redis 4.1 integration into a 3.5 application: the -41 module references two dozen Spring Data Redis 4.1 types that do not exist in 3.5, so it fails hard and early. The reverse — a Boot 4.1 application with a leftover explicit redisson-spring-data-40 in its POM — is quieter, and the BOM does not rescue it: it manages spring-data-redis up to 4.1 and leaves the -40 module in place. Nothing is missing at class level, so the context starts; -40 simply never implements the commands Spring Data Redis 4.1 added (delex, digest, xAckDel, xDelEx, the SetCondition overloads), and you get an AbstractMethodError the first time one is called — possibly in production, possibly never.

How it surfaces depends on your build tool, and the difference matters when you go looking for the cause. In Maven, the Boot BOM's dependencyManagement wins over any transitive version regardless of depth, so Spring Data Redis is quietly managed to the version your BOM pins — down on a 3.5 application, up on a 4.1 one — mvn compile succeeds, and the break appears when the context instantiates RedissonConnectionFactory — as NoClassDefFoundError, AbstractMethodError or IncompatibleClassChangeError. In Gradle it depends on how the BOM got into your build. Spring Initializr still generates Gradle builds with the io.spring.dependency-management plugin, on Boot 4.1 as well as Boot 3, and that plugin applies Maven-like semantics — it controls the versions of direct and transitive dependencies, so Spring Data Redis is pinned back to your Boot line exactly as in Maven. If you instead import the BOM with Gradle's native platform(…), Spring's own docs are explicit that it "treats the versions in the bom as recommendations", so the transitively requested Spring Data Redis 4.1 wins on a 3.5 application and the mismatch lands on the Spring side instead. enforcedPlatform(…) restores the forcing behaviour. Either way the build is green and the failure is at runtime — a pipeline that runs your Spring Boot tests will catch it, one that skips them will ship it.

So after any starter upgrade, confirm what you actually resolved:

mvn dependency:tree -Dincludes=org.redisson

One more detail if you are staying on Boot 3.5 for now: Redisson 4.7.0 builds against Netty 4.2.16, while Spring Boot 3.5.16 pins Netty 4.1.135, and the Boot BOM's dependency management wins — so Redisson runs on Netty 4.1. In practice that is fine. The only Netty 4.2 APIs Redisson 4.7.0 touches — MultiThreadIoEventLoopGroup, IoHandlerFactory and the io.netty.channel.uring classes — are all reached only through the opt-in io_uring transport; the default NIO path and the epoll and kqueue paths construct NioEventLoopGroup, EpollEventLoopGroup and KQueueEventLoopGroup, which resolve entirely against 4.1. If you have set TransportMode.IO_URING, either override netty.version to 4.2.x or stay on epoll. Spring Boot 4.0 and 4.1 both pin Netty 4.2, so the question disappears on upgrade.

3. Custom connection-details beans break at compile time

This one fails earliest of the three — before you ever start the application. If you wrote a custom bean to supply connection details — fetching a Redis endpoint from a secrets manager or a service registry, say — it implements a Spring interface that moved:

// Spring Boot 3
import org.springframework.boot.autoconfigure.data.redis.RedisConnectionDetails;

// Spring Boot 4
import org.springframework.boot.data.redis.autoconfigure.DataRedisConnectionDetails;

Update the import, rename the type, and make sure spring-boot-data-redis is on the classpath — the starter brings it in transitively via spring-boot-starter-data-redis, so in practice you only touch the import. Redisson's RedissonAutoConfigurationV4 consumes DataRedisConnectionDetails directly, so a correctly migrated bean keeps working exactly as before.

If You Use the Hibernate Second-Level Cache

Redisson's Hibernate modules track the Hibernate version, and Spring Boot 4 moved that too. Pick from what your Boot line actually ships:

Note the trap in the naming: redisson-hibernate-7 is built against Hibernate 7.1, which only Boot 4.0.0 itself ships. Every Boot 4 release after that wants -72, so despite the "7" the -7 module is the wrong choice for almost every Boot 4 application. Redisson documents each module as a bounded range rather than a floor — -7 is "for Hibernate v7.0.x - 7.1.x", -72 is "for Hibernate v7.2.x - 7.3.x" — and the published range lags the build: at Redisson 4.7.0 the -72 module is actually compiled against Hibernate 7.4.4, which is Boot 4.1's own 7.4.x line, so on Boot 4.1 you are on the module's build target to within a patch even though the documented ceiling still reads 7.3.x. On Boot 4.0.1 and later you are inside the documented range but two minors below the build target. Either way the hibernate-core dependency is optional, so nothing is forced on you — smoke-test your second-level cache rather than assuming. Full setup in our guide to the Hibernate second-level cache with Valkey or Redis.

The Upgrade Checklist

Do this in two commits, not one. Move to Redisson 4.7.0 first, with the exclusion for the Boot line you are on today (steps 1–3), and confirm the build is green. Then change the Boot version and do the renames (step 4 onward). The V2-to-V4 rename is only correct once you are actually on Boot 4 — do it early and you break a working exclusion on the old line instead of fixing it on the new one.

1. Confirm your Java version. Spring Boot 4 keeps the Java 17 floor — it does not require 21 or 25, though it supports both. Redisson itself compiles to Java 8 bytecode, so it is never the constraint.
2. Move to redisson-spring-boot-starter:4.7.0 (or later).
3. Unless you are on Boot 4.1, exclude the bundled redisson-spring-data-41 from the starter and add the redisson-spring-data-XX for your line from the version matrix. On Boot 4.1 the starter is already correct and there is nothing to exclude.
4. Grep the repository for RedissonAutoConfigurationV2 in YAML, properties files and annotations — but rename it to V4 only in the same commit that moves you to Boot 4. On Boot 3.5 the V2 name is still the live one.
5. In the same commit that moves you to Boot 4.1, remove the exclusion and the explicit redisson-spring-data-XX you added in step 3 — on Boot 4.1 the starter's bundled redisson-spring-data-41 is already the right one. If you are landing on Boot 4.0 rather than 4.1, change the explicit module to redisson-spring-data-40 instead.
6. Grep for org.springframework.boot.autoconfigure.data.redis imports and repoint them at org.springframework.boot.data.redis.autoconfigure, inserting Data before Redis in the type names (RedisProperties → DataRedisProperties, PropertiesRedisConnectionDetails → PropertiesDataRedisConnectionDetails).
7. Swap redisson-hibernate-6 for redisson-hibernate-72 if you use the second-level cache. (Boot 4.0.0 exactly is the one exception — see the Hibernate table — but there is no reason to land on 4.0.0 rather than the current 4.0.x.)
8. Leave spring.data.redis.* and spring.redis.redisson.* alone — neither moved.
9. If you use Spring Session on Redis or Valkey, rename spring.session.redis.* to spring.session.data.redis.*. This is the one Redis-adjacent prefix Boot 4 did move.
10. Run mvn dependency:tree -Dincludes=org.redisson and check the resolved module.

Your Redisson application code — RLock, RMap, RTopic, the Spring Cache manager, @Cacheable — is untouched by any of this. The Redisson API did not change across the Boot 4 boundary. Everything above is dependency wiring and package names.

Frequently Asked Questions

Does Redisson support Spring Boot 4?

Yes. Spring Boot 4.0 support shipped in Redisson 4.0.0 on 16 December 2025, and Spring Boot 4.1 support in Redisson 4.6.0 on 15 June 2026. The current release, 4.7.0, is built against Spring Boot 4.1.0.

Do I need a different Redisson starter for Spring Boot 4?

No. There is one redisson-spring-boot-starter artifact. It contains separate auto-configuration classes for Boot 4, Boot 2.7–3.5, and Boot 2.6 and earlier, and activates whichever matches the classpath. You only change the bundled redisson-spring-data-XX module.

Which redisson-spring-data module do I need?

Match the suffix to your Spring Data Redis line, which follows your Spring Boot line: -41 for Boot 4.1, -40 for Boot 4.0, -35 for Boot 3.5, -27 for Boot 2.7. The starter bundles -41 by default as of Redisson 4.6.0, so every other line needs an exclusion plus an explicit dependency.

Do my application.yml Redis properties change on Spring Boot 4?

Mostly. Your spring.data.redis.* keys are unchanged in Spring Boot 4, and Redisson's spring.redis.redisson.* prefix is unchanged too. The one exception nearby is Spring Session, whose keys moved from spring.session.redis.* to spring.session.data.redis.*. The last time Spring's core Redis keys moved was Boot 3.0, when they went from spring.redis.* to spring.data.redis.*.

Why did my Redisson autoconfigure exclusion stop working after upgrading?

Because the active auto-configuration class changed from RedissonAutoConfigurationV2 to RedissonAutoConfigurationV4. Neither spelling warns you: a string exclusion naming V2 parses and matches nothing, and @EnableAutoConfiguration(exclude = RedissonAutoConfigurationV2.class) still compiles, because that class ships in the jar on every Boot line. Rename both to V4.

Is Spring Boot 3 still supported?

Not on the free support line. Spring Boot 3.5.x — the last 3.x generation — reached the end of its OSS support window on 30 June 2026. Commercial support for 3.5.x runs to 2032. Spring Boot 4.0.x has OSS support to 31 December 2026 and 4.1.x to 31 July 2027.

Does Spring Boot 4 require Java 21?

No. Spring Boot 4.0 and 4.1 both keep a Java 17 baseline while supporting newer releases. Spring Boot 4 is based on Jakarta EE 11 and requires a Servlet 6.1 baseline, which is the change more likely to affect a web application than the Java version.

Getting Help With the Upgrade

Redisson gives a Spring application a great deal more than a connection factory — distributed locks, near caching, and a full set of Java-native distributed objects that Spring Data Redis does not provide. If you are already doing an upgrade, it is a reasonable moment to look at what else is available: see the feature comparison for the Community and PRO breakdown, or start a PRO trial.

Similar articles

• Spring Boot Caching With Valkey or Redis: A Complete @Cacheable Guide
• Spring Data Redis to Redisson: When to Add It and When to Migrate
• Feature Comparison: Redisson vs Spring Data Redis
• Hibernate Second-Level Cache with Valkey or Redis
• Scalable Session Management for Java Microservices With Valkey or Redis