Last checked and updated on 12 Jun 2026
What Is New in Jedis 2.4
Jedis 2.4 brings a host of updates focused on Redis 2.6 command support, performance tuning, and critical bug fixes. This release solidifies the client's foundation, making it more robust for production use.
| Category | Key Changes |
|---|---|
| New Features | Support for Redis 2.6 commands like BITCOUNT, BITOP, and HINCRBYFLOAT. |
| Improvements | Enhanced connection pool, pipelining performance, and SSL support. |
| Bug Fixes | Resolved issues with connection handling, timeouts, and specific command behaviors. |
| Deprecated | Marked certain older methods for future removal. |
What new Redis commands does Jedis 2.4 support?
This release adds full support for the new commands introduced in Redis 2.6. This is a big deal if you're using newer data manipulation patterns.
You now get native methods for BITCOUNT, BITOP, and HINCRBYFLOAT. Before this, you had to use the generic sendCommand method, which was clunky. Now the API is clean and type-safe for these operations.
How has performance been improved in this version?
We tightened up the connection pool and pipelining internals. The connection pool management is more efficient, reducing overhead when acquiring and returning connections.
Pipelining got some low-level optimizations that reduce latency when sending batches of commands. In practice, this means better throughput for high-volume use cases without changing your code.
What are the critical bug fixes I should know about?
Several connection-related race conditions and timeout handling issues were squashed. One fix prevents a potential resource leak when connections fail during certain operations.
Another important fix corrects the behavior of the hgetAll method to properly handle binary data. If you're storing byte arrays in hashes, this fix is essential.
Is SSL connectivity better in Jedis 2.4?
Yes, the SSL support is more robust. The underlying SSL socket implementation was improved for better handling of handshakes and session timeouts.
This matters because it makes the client more reliable in secure environments. You're less likely to run into cryptic SSL connection drops during long-running operations.
FAQ
Do I need to change my code to upgrade to Jedis 2.4?
For most applications, no. This is a drop-in replacement. The main changes are additive (new commands) and internal (performance). Just watch for deprecation warnings if you're using older API methods.
Is the Redis 2.6 command support backwards compatible?
Absolutely. The new commands only work with a Redis 2.6+ server. If you run them against an older server, you'll get the standard Redis error, just like using the redis-cli.
What's the most significant performance gain?
The connection pool improvements. In high-concurrency applications, you should see reduced contention when threads are borrowing and returning connections from the pool.
Were there any changes to exception handling?
Yes, some exceptions were made more specific. For instance, certain timeout errors now throw more descriptive exceptions, making debugging connection issues easier.
Should I use the new native methods for bit operations?
Definitely. Instead of using jedis.sendCommand("BITCOUNT", ...), switch to the new jedis.bitcount(key) method. It's cleaner and less error-prone.