What Is New in Jedis 4.0
Jedis 4.0 is a major release that introduces a new unified API, drops support for older Java versions, and adds compatibility with Redis 6's ACL and client-side caching. Here's a quick summary of the key changes.
| Category | Key Changes |
|---|---|
| New Features | Unified API, Redis 6 ACL support, Client-side caching |
| Improvements | Reduced connection overhead, Better connection pooling |
| Deprecations & Removals | Legacy Jedis class, Java 7 support, Pool classes |
| Bug Fixes | Various stability and correctness fixes |
Why did Jedis introduce a new Unified API?
The new UnifiedJedis interface combines the functionality of the old Jedis, JedisCluster, and JedisSentinel classes into a single, consistent API. This means you use the same set of commands whether you're connecting to a standalone Redis, a cluster, or a sentinel setup.
In practice, this cleans up your codebase significantly. You no longer need to maintain different client objects or handle commands differently based on your deployment mode. The new entry point is through the JedisPooled or JedisCluster classes which implement this unified interface.
What are the new security features for Redis 6?
Jedis 4.0 adds full support for Redis 6 Access Control Lists (ACL). You can now create connections authenticated with a username and password, not just a password alone. This is a requirement for connecting to Redis 6+ instances with ACLs enabled.
The client-side caching feature from Redis 6 is also supported. This lets your application cache data locally and receive invalidation messages from the Redis server, which can drastically reduce network round-trips for frequently accessed data.
How has connection management been improved?
Connection handling has been optimized to be more efficient. The internal implementation now uses a single connection for both data transmission and response reading, reducing the overhead per operation.
The classic JedisPool and related pool classes have been removed in favor of the more modern Pool<Jedis> and the new JedisPooled client. This simplifies connection pool management and aligns with the new API structure.
What was removed and what are the breaking changes?
Support for Java 7 has been completely dropped. You now need Java 8 or later to run Jedis 4.0. The entire redis.clients.jedis package has been restructured, so many old import statements will break.
The legacy Jedis class constructor is gone. You must now use connection pools or the new JedisPooled client. All deprecated methods and classes from previous versions have been removed, so a code audit is essential before upgrading.
FAQ
Is the old Jedis class completely gone?
Yes, the classic Jedis class that you instantiated directly with a host and port has been removed. You must now use the new JedisPooled client for standalone Redis or connection pools.
How do I authenticate with a username and password for Redis ACL?
Use the new user parameter in the connection configuration. For example: new JedisPooled(host, port, "username", "password");
What is the replacement for JedisPool?
The new jedis-4.0.0.jar uses a generic Pool<Jedis> interface. The specific pool implementation to use is now JedisPooled for your pooled connections.
Will my existing code work with Jedis 4.0?
Probably not without modifications. The package restructuring, removal of the old Jedis class, and deleted deprecated methods are breaking changes. You'll need to migrate to the new Unified API.
How do I use the new client-side caching feature?
You need to use the clientTracking() and related methods on the new UnifiedJedis interface. This allows the server to notify your client when cached data becomes invalid.