What Is New in Jedis 5.2
| Category | Key Changes |
|---|---|
| New Features | Support for Redis 7.2 commands, Redis Functions, and the ability to disable auto-flushing for pipelines. |
| Improvements | Enhanced connection pool validation, refined cluster command routing, and better error message clarity. |
| Bug Fixes | Resolved issues with cluster failover handling, connection leaks, and specific command argument parsing. |
| Deprecations | Marked several older methods and classes for removal in future versions. |
What Redis 7.2 features are now supported?
Jedis 5.2 adds full support for the new commands introduced in Redis 7.2. This includes EXPIRETIME, PEXPIRETIME, and EXPIREAT with the NX/XX/GT/LT options for more granular control over key expiration.
In practice, this means your application can now leverage the exact same expiration semantics that are available directly in the latest Redis server, ensuring consistency and unlocking new use cases for time-based data management.
How does the new Redis Functions support work?
This release introduces a dedicated API for interacting with Redis Functions. You can now execute functions, manage libraries, and more directly through the Jedis client.
The support is built around the JedisPooled and cluster clients. You can call a function using fcall() or fcallReadonly(), making it much cleaner than using the old eval() approach for complex server-side logic.
Why would I disable auto-flushing in a pipeline?
The new disableAutoFlush() method on the Pipeline object gives you manual control over when commands are sent to the server. This is a game-changer for optimizing high-throughput scenarios.
Instead of sending commands in chunks automatically, you can now build a massive pipeline locally and then flush it all at once with sync() or close(). This reduces network round-trips and can significantly improve performance for batch operations.
What connection pool improvements were made?
Connection validation in the pool has been made more robust. The pool now does a better job of checking connections before returning them to a borrower, helping to prevent the application from getting a stale or broken connection.
This is one of those behind-the-scenes fixes that really matters for production stability. It reduces the chance of runtime errors caused by underlying TCP timeouts or network hiccups that can occur between when a connection is idle in the pool and when it's next used.
FAQ
Is Jedis 5.2 backwards compatible with my existing code?
For the most part, yes. The main changes are additive. However, you should check the deprecation warnings as some older methods are now marked for removal and will require changes in a future major version.
Do I need Redis 7.2 to use Jedis 5.2?
No, Jedis 5.2 remains compatible with older Redis versions. The new commands will only work if you are connected to a Redis 7.2+ server, but all other functionality remains unchanged.
How do I use the new manual pipeline flushing?
Get your Pipeline object, call disableAutoFlush(), then add all your commands. Finally, call sync() to send the entire batch and get the responses.
What's the main benefit of using Redis Functions over Lua scripts?
Redis Functions are managed on the server side with a named library, making them easier to update and maintain than scripts identified by their SHA1 digest. The new API simply makes this management cleaner from Jedis.
Were there any fixes for cluster mode?
Yes, several fixes improve cluster reliability. One key fix addresses a race condition during failover scenarios that could sometimes cause commands to be routed to the wrong node, preventing potential MOVED slot errors.