Last checked and updated on 05 Jun 2026
What Is New in Jedis 7.3
Jedis 7.3 delivers key enhancements for Redis connectivity, focusing on improved protocol support and developer experience. This update introduces new commands and refines existing functionality for better stability.
| Category | Key Changes |
|---|---|
| New Features | Support for ACL DRYRUN, CLIENT NO-TOUCH, and new BITFIELD_RO variants. |
| Improvements | Enhanced CommandObject handling, Connection validation, and URI parsing. |
| Bug Fixes | Fixes for connection leaks, transaction handling, and cluster command routing. |
| Deprecations | Deprecated the 'maxRedirections' parameter in favor of 'maxAttempts'. |
What new Redis commands are supported?
Jedis 7.3 adds support for several important Redis commands. This keeps the client in sync with the latest server capabilities.
The ACL DRYRUN command lets you test user permissions without executing the actual command, which is
great for security auditing. Support for CLIENT NO-TOUCH was added to prevent resetting the
client's idle time. The release also includes the read-only variants of the bitfield command:
BITFIELD_RO and BITFIELD_RO with a key argument.
How has connection handling been improved?
Connection reliability and resource management saw significant upgrades. These changes help prevent subtle bugs that can cause application instability.
The pool now validates connections more rigorously before returning them to the application, catching broken
connections earlier. A critical fix addresses a connection leak that could occur when a Connection
object was used after being closed. For cluster operations, the handling of redirections was made more robust to
avoid potential infinite loops.
What's changed with CommandObjects?
The internal architecture for handling commands was refined for greater consistency. This matters because it creates a more predictable API for developers building complex operations.
The CommandObjects class now returns null for commands that have no reply, aligning its
behavior with the core Jedis API. The Process method was also deprecated, signaling a shift towards
the newer, more streamlined command execution patterns.
Are there any breaking changes or deprecations?
One primary deprecation notice was added to prepare developers for a future change. It's a straightforward rename for clarity.
The maxRedirections parameter used in various cluster methods is now deprecated. You should use the
more intuitively named maxAttempts parameter instead. This change aligns the terminology with what
actually happens under the hood during cluster redirections.
FAQ
How do I use the new ACL DRYRUN command?
Use it through the Jedis client
instance to simulate if a user can execute a specific command. For example:
jedis.aclDryRun("user", "get", "key").
I use connection pools - should I be concerned about the connection leak fix?
Yes, if your
application was potentially using closed connections. This fix prevents those scenarios from draining your pool,
which is crucial for long-running applications.
What's the practical difference between maxRedirections and maxAttempts?
They function the
same way; it's purely a rename for better clarity. The old parameter name is deprecated but still functional for
now.
Does the BITFIELD_RO command work with both standalone and cluster modes?
Yes, the new
read-only bitfield commands are supported across all deployment modes that Jedis connects to, just like other
commands.
Why would a CommandObject return null now?
This change creates consistency. If a Redis
command has no meaningful return value (like a successful SET), the CommandObject will return null, matching the
behavior of the standard jedis.set() method.