Last checked and updated on April 16, 2026What Is New in Jedis 7.0
Jedis 7.0 is a major release that introduces new Redis command support, significant internal refactoring, and drops support for older Java versions. Here's a quick summary of the key changes.
| Category | Key Changes |
|---|---|
| New Features | Support for ACL commands, ZDIFF, ZINTER, ZUNION, and other new Redis commands. |
| Improvements | Refactored connection and command handling internals. Unified the cluster command execution flow. |
| Deprecations & Removals | Dropped support for Java 8 and 11. Removed deprecated classes and methods. |
| Bug Fixes | Various fixes for cluster, sentinel, and connection pool behavior. |
What new Redis commands are supported?
This release adds full support for several newer Redis commands. You can now use the ACL command family for user management directly from Jedis.
The new sorted set commands ZDIFF, ZINTER, and ZUNION are also included. These provide more flexibility when working with sorted sets compared to the older variants.
In practice, this means your application can leverage the latest Redis features without waiting for client library updates.
How has the internal architecture changed?
The core connection and command execution logic has been significantly refactored. The internal access modifiers for many classes were changed to simplify the architecture.
A major change is the unification of command execution between standalone and cluster modes. Previously, cluster commands used a different path, but now they share the same underlying flow as standalone commands.
This refactoring makes the codebase more maintainable and paves the way for future enhancements without breaking the public API.
What Java versions are now required?
Jedis 7.0 requires Java 17 or later. Support for Java 8 and Java 11 has been completely removed.
This aligns the client with the current long-term support (LTS) versions of Java. If you're still on an older JDK, you'll need to stick with Jedis 4.x.
The move to Java 17 allows the use of newer language features and APIs, which contributed to the internal refactoring improvements.
What deprecated APIs were removed?
Several classes and methods that were deprecated in previous versions have been completely removed in 7.0. This is a cleanup step to reduce the maintenance burden of the library.
If you were using any deprecated features from Jedis 4.x, your code will break when upgrading. You'll need to migrate to the newer, supported APIs first.
This matters because it keeps the client lean and focused on the recommended ways of interacting with Redis.
FAQ
Is Jedis 7.0 backwards compatible with Jedis 4.x?
No, it is not fully backwards compatible. The removal of deprecated APIs and the requirement for Java 17 means you will likely need to make code changes and update your JDK to upgrade.
How do I handle the Java version requirement change?
You need to ensure your project is running on Java 17 or a later version. Update your JDK installation and configure your build tool (Maven/Gradle) to use the correct Java version before attempting to use Jedis 7.0.
What should I do if my code uses removed deprecated methods?
First, upgrade to the latest Jedis 4.x release and address all deprecation warnings. The replacements for the deprecated methods are already available in the 4.x line, making it easier to prepare for the jump to 7.0.
Are there any new dependencies in this release?
No, the release notes do not mention adding any new external dependencies. The changes are primarily internal refactoring and support for new commands.
Why was the cluster command execution unified?
Unifying the execution path simplifies the internal code structure and reduces complexity. It makes the client more consistent and easier to maintain for future development.