What Is New in Jedis 3.7
This release focuses on enhancing connection handling, adding new Redis commands, and improving the overall API. It's a solid maintenance update that keeps the client in sync with the latest server capabilities.
| Category | Key Changes |
|---|---|
| New Features | Support for ACL users, ZPOPMIN timeout, and new GEO commands. |
| Improvements | Better Sentinel connection handling, URI parsing, and pipeline error management. |
| Bug Fixes | Fixes for SSL connections, cluster command routing, and resource leaks. |
| Deprecations | Deprecated the old `setDataSource` method in favor of `JedisPooled`. |
How does Jedis 3.7 handle connections better?
The core improvements are in Sentinel connectivity and resource management. This version introduces more robust logic for discovering and connecting to masters through Sentinels, which is critical for high-availability setups.
It also fixes a nasty issue where connections in TLS/SSL mode weren't being properly validated, which could lead to silent failures. The connection URI parsing is now more flexible, correctly handling the `rediss://` scheme for SSL connections.
What new Redis commands are supported?
Jedis 3.7 adds support for several commands introduced in newer Redis versions. The ACL SETUSER and ACL GETUSER commands are now available for managing user access control lists programmatically.
For sorted sets, the BZPOPMIN command with a timeout is now supported. The GEOADD command has been updated to accept the new NX|XX options for conditional updates, and GEOSEARCH and GEOSEARCHSTORE commands are now fully implemented for querying geospatial data.
Were there any critical bug fixes?
Yes, a few important bugs were squashed. A memory leak in the JedisCluster class was fixed, which was causing connections to accumulate over time. Another fix addressed an issue where commands weren't being correctly routed to the right cluster slot.
The pipeline behavior was improved to handle errors more gracefully. Previously, a single failed command could break the entire pipeline execution, but the error handling is now more predictable.
What's deprecated that I should know about?
The main deprecation is the `setDataSource` method. The new preferred way to work with connection pools is through the `JedisPooled` class, which provides a cleaner and more intuitive interface.
In practice, you should migrate from manually setting data sources to using `JedisPooled` for better resource management and future compatibility. The old approach will likely be removed in a future major version.
FAQ
Does Jedis 3.7 require a specific Redis server version?
No, but to use the new commands like ACL SETUSER or GEOSEARCH, you need a Redis server version that supports them (typically 6.0 or later). The client itself remains backward compatible.
I use SSL connections. What should I check after upgrading?
Verify that your `rediss://` connection URIs are working correctly. The SSL handshake validation was improved, so some previously accepted invalid configurations might now properly throw exceptions.
What's the deal with the memory leak fix in JedisCluster?
The leak was related to connection objects not being returned to the pool under certain error conditions. If you have long-running applications using JedisCluster, this fix will prevent gradual memory increase over time.
Is the pipeline error handling change backward compatible?
Mostly yes, but the behavior is now more correct. If your code relied on the old broken error handling, you might need to adjust your exception handling logic when processing pipeline responses.
Should I immediately switch to JedisPooled?
If you're starting a new project, definitely use JedisPooled. For existing code, plan to migrate eventually since the old setDataSource method is now deprecated and will be removed someday.