What Is New in Jedis 2.8
Jedis 2.8 brings critical Redis 2.8 protocol support, major performance upgrades, and essential bug fixes. This release aligns the client with the latest server capabilities and improves stability for production use.
| Category | Key Changes |
|---|---|
| New Features | Support for Redis 2.8's SCAN, PFADD/PFCOUNT, and migration from old 'keyspace' events to new 'keyevent' events. |
| Performance | Connection pool handling improvements and optimized internal resource management. |
| Bug Fixes | Resolved issues with connection timeouts, SSL handshakes, and pipeline execution. |
| Deprecated | Legacy methods and constructors marked for removal in future versions. |
How does Jedis 2.8 handle Redis 2.8 commands?
This release fully integrates the new commands introduced with Redis 2.8. The most significant addition is the SCAN command, which provides a cursor-based iterator for keyspace traversal. This is a major improvement over the blocking KEYS command for production environments.
Support for the HyperLogLog data structure is also included via the PFADD and PFCOUNT commands. These allow for efficient cardinality estimation, which is useful for analytics and counting unique users.
Example: Using SCAN
ScanParams scanParams = new ScanParams().match("user:*").count(100);
String cursor = ScanParams.SCAN_POINTER_START;
do {
ScanResult<String> scanResult = jedis.scan(cursor, scanParams);
cursor = scanResult.getStringCursor();
List<String> keys = scanResult.getResult();
// process keys
} while (!cursor.equals(ScanParams.SCAN_POINTER_START));What performance improvements were made?
Performance gains in 2.8 come from smarter connection pool management. The internal logic for borrowing and returning connections to the pool was refined, reducing contention and overhead. This directly impacts applications with high concurrent request rates.
We also squashed several bugs that were causing unnecessary connection timeouts and SSL handshake failures. These fixes prevent the pool from being depleted by faulty connections, which in turn improves overall throughput and application resilience.
Are there any breaking changes to watch for?
While not a complete overhaul, Jedis 2.8 does deprecate a handful of older methods and constructors. You'll see warnings if you're using the old BinaryJedis constructor or the sharded package. These are being phased out to pave the way for a cleaner API in future major releases.
The event model for keyspace notifications has been updated to match Redis 2.8's shift from keyspace to keyevent events. If you have code that listens for these notifications, you'll need to update your event subscriptions to use the new format.
FAQ
Should I upgrade to Jedis 2.8 if I'm still on Redis 2.6?
Yes, but you won't be able to use the new commands like SCAN or PFADD. The client remains backward compatible, so the upgrade is safe and prepares you for a future server upgrade.
Does the new SCAN implementation work with JedisCluster?
Yes, the SCAN command and related classes are fully supported within a clustered Redis environment, allowing for safe keyspace iteration across nodes.
I'm getting connection timeout errors after upgrading. What gives?
Check your connection pool configuration. The improved pool management might behave differently with certain settings. The fix for SSL handshake issues might also require a review of your SSL/TLS setup.
What happened to the keyspace events I was listening for?
Redis 2.8 changed the event message format. You need to reconfigure your PubSub listeners to subscribe to the new __keyevent@*__:* channels instead of the old __keyspace@*__:* pattern.
Is it safe to ignore the deprecation warnings?
For now, yes. The deprecated methods still work in 2.8. However, they will be removed in Jedis 3.0, so you should plan to refactor that code to avoid future breakage.