Last checked and updated on April 16, 2026What Is New in Jedis 4.2
Jedis 4.2 introduces significant enhancements focused on new Redis commands, improved connection handling, and better integration with modern Java features. This release solidifies Jedis as a robust client for the latest Redis server capabilities.
| Category | Key Changes |
|---|---|
| New Features | Support for Redis 7.0 commands (ZMPOP, ZINTERCARD, LMPOP), ACL DRYRUN, and Function commands. |
| Improvements | Connection pool validation, URI parsing for sentinel, and Java 8 Date/Time API support for stream commands. |
| Bug Fixes | Fixes for connection leaks, sentinel authentication, and pipeline exception handling. |
| Deprecated | Legacy 'maxTotal' pool configuration parameter in favor of 'maxTotal' from commons-pool2. |
What new Redis commands are supported?
Jedis 4.2 adds full support for several Redis 7.0 commands. This keeps the client in sync with the latest server features that developers are starting to use.
You can now use ZMPOP and LMPOP for popping multiple elements from sorted sets and lists in a single operation. The ZINTERCARD command returns the cardinality of the intersection of multiple sets. For security, the ACL DRYRUN command lets you test user permissions without executing the command.
This matters because it enables more efficient data operations and better security auditing directly from your Java application without waiting for client updates.
How is connection management improved?
Connection pooling gets smarter in this release with built-in validation. The pool can now validate connections before returning them to the application, reducing the chance of handing out stale or broken connections.
Sentinel URI parsing has been enhanced to properly handle authentication credentials embedded in the connection string. This simplifies configuration management when using sentinel-based setups.
In practice, this means fewer connection-related exceptions and more reliable failover behavior in production environments, especially under heavy load.
What Java 8 integrations were added?
The update brings better integration with modern Java date and time APIs. Stream commands now support java.time.Instant instead of relying only on legacy java.util.Date.
This allows for more precise timestamp handling when working with Redis streams. You get nanosecond precision and a more modern API that aligns with current Java development practices.
If you're already using Java 8+ time classes in your application, this change makes working with stream message IDs much cleaner and more type-safe.
What critical bugs were fixed?
Several important stability issues were resolved. A connection leak was fixed in the RedisPipelineBase class that occurred during exception handling. Sentinel authentication now works correctly with the JedisSentinelPool.
Another fix addresses an issue where exceptions in pipeline execution weren't properly propagated, making debugging more difficult. These fixes improve the overall resilience of Jedis in production scenarios.
For anyone using pipelines or sentinel authentication, upgrading to 4.2 will resolve these specific pain points that could cause resource leaks or authentication failures.
FAQ
Does Jedis 4.2 require Redis 7.0?
No, Jedis 4.2 maintains backward compatibility with older Redis versions. The new Redis 7.0 commands are available if your server supports them, but you can still connect to Redis 6.x or earlier.
What should I use instead of the deprecated 'maxTotal' parameter?
Use the 'maxTotal' parameter from Apache commons-pool2 directly. The Jedis-specific alias was removed to avoid confusion and align with the underlying pooling library.
How do the new ZMPOP and LMPOP commands improve performance?
They allow popping multiple elements in a single round-trip to Redis instead of multiple calls. This reduces network latency when you need to process batches of sorted set or list elements.
Is there a breaking change in the exception handling for pipelines?
No, the exception handling fix makes the behavior more correct but doesn't change the API. Your existing pipeline code will work the same but will now properly propagate exceptions that were previously swallowed.
Does the connection validation impact performance?
The validation happens when borrowing connections from the pool and adds minimal overhead. The benefit of avoiding stale connections far outweighs this small cost in most production scenarios.