What Is New in Jedis 3.3
This release focuses on enhancing the cluster and sentinel support while introducing new commands and cleaning up the API. Here's a quick summary of the key changes.
| Category | Key Updates |
|---|---|
| New Features | New commands (XADD, XACK, etc.), Cluster/Sentinel API additions, URI connection improvements. |
| Improvements | Better exception handling, connection management, and method deprecations for cleanup. |
| Bug Fixes | Fixes for cluster redirection, connection leaks, and pipeline execution. |
| Deprecated | Older constructors and methods marked for removal in future versions. |
What new Redis commands were added?
Jedis 3.3 adds support for several new Redis commands, primarily around streams and hyperloglog. The main additions are XADD, XACK, XCLAIM, XDEL, XGROUP, XTRIM, and PFDEBUG.
This finally brings Jedis up to speed with the stream data type introduced in Redis 5.0. In practice, you can now build full consumer group applications natively with Jedis without needing workarounds.
How is cluster and sentinel support improved?
The cluster and sentinel APIs received significant upgrades. New methods like JedisCluster.slaves() and JedisCluster.append() were added for better cluster operation control.
For Sentinel, new methods such as sentinels(), failover(), and monitor() provide more direct management of sentinel instances. This matters because it gives developers finer-grained control over their Redis high-availability setups directly from the client.
What connection changes should I be aware of?
Connection handling got smarter. The JedisCluster constructor now accepts a GenericObjectPoolConfig for more precise connection pool tuning. The JedisSentinelPool was also updated to use a DefaultJedisClientConfig.
URI connection parsing was enhanced to handle more parameters. You can now include the database index and client name directly in the connection string, which simplifies configuration management in application code.
What was deprecated in this release?
Several older constructors and methods were marked as deprecated to clean up the API. This includes the Jedis(JedisShardInfo) constructor and various methods in the BinaryShardedJedis class.
These deprecations are a clear signal to start migrating your code. The old JedisPool constructors are being phased out in favor of the newer ones that use JedisClientConfig for better consistency.
Were there any critical bug fixes?
Yes, a few important bugs were squashed. A connection leak in JedisCluster was fixed, which resolves resource exhaustion issues during cluster redirects. Another fix addressed a problem where pipelines weren't properly retrying commands on moved redirections.
There was also a fix for the zrangeByScore method to correctly handle the ( exclusive operator. These fixes make the client more robust, especially in dynamic cluster environments where nodes can move.
FAQ
Does Jedis 3.3 require a specific Redis server version?
No, but to use the new stream commands like XADD and XACK, you need Redis server version 5.0 or higher. Other commands work with older server versions.
I use the old JedisPool constructors - will my code break?
Not immediately. The old constructors are deprecated but still functional. You should plan to migrate to the new constructors that use JedisClientConfig to avoid future breaking changes.
How do I connect to a Redis cluster with custom pool settings now?
Use the updated JedisCluster constructor that accepts a GenericObjectPoolConfig parameter. This gives you direct control over connection pool behavior for cluster connections.
What's the simplest way to start using streams with Jedis?
Start with the XADD command to add messages to a stream. The new methods follow the same pattern as other Jedis commands, making them familiar to existing users.
Were there any changes to SSL/TLS connection handling?
No major SSL-specific changes were mentioned in this release. SSL connections continue to work through the JedisClientConfig and URI configuration as in previous versions.