Last checked and updated on April 20, 2026What Is New in Jedis 6.0
Jedis 6.0 is a major release that modernizes the client, focusing on new Redis commands and a cleaner, more intuitive API. It drops support for older Java versions and introduces several breaking changes to pave the way for future development.
| Category | Key Changes |
|---|---|
| New Features | Support for Redis 6 ACLs, Redis Graph, and new commands (ZPOPMIN, ZPOPMAX, etc.) |
| API Improvements | Unified connection interface, deprecated method removal, new response classes |
| Requirements | Java 8+ required; Java 6 and 7 support dropped |
| Deprecations | Legacy 'client' methods, old constructors, and ShardedJedis |
How did Jedis improve Redis 6 support?
The client now fully supports Redis 6 access control lists (ACL). You can authenticate with a username and password instead of just a password, bringing it in line with the latest Redis security features.
This matters because it allows you to use the more granular permission systems available in modern Redis deployments. In practice, you'll use the auth method with both parameters.
jedis.auth("username", "password"); // New way for Redis 6
jedis.auth("password"); // Still works for older configsWhat new Redis commands were added?
Jedis 6.0 adds support for a batch of newer Redis commands. This includes the blocking sorted set commands ZPOPMIN and ZPOPMAX, and the hyperloglog PFDEBUG command.
More significantly, it introduces initial support for the Redis Graph module with the graph.query command. This is a big deal for developers building applications on top of RedisGraph, as they can now use Jedis as their client.
How was the Jedis API cleaned up?
The API was streamlined by removing a lot of deprecated cruft. Methods that were marked deprecated in older versions, like many in the Client class, have been completely removed.
They also introduced new response classes (AccessControlUser, StreamEntryID) to provide stronger typing instead of relying on raw Lists and Strings. This makes the code safer and easier to work with.
What are the breaking changes for Java developers?
The biggest break is the requirement for Java 8 or later. If you're stuck on Java 6 or 7, you cannot upgrade to Jedis 6.0 and will need to stay on a 5.x release.
Several class and method signatures have changed. For example, the BinaryClient class was removed, and the Protocol class is no longer public. You'll need to audit your code for these changes before upgrading.
FAQ
Is Jedis 6.0 backwards compatible with my existing code?
No, it is not fully backwards compatible. This is a major release with breaking changes, including removed deprecated methods and new Java version requirements. You will likely need to make some code changes to upgrade.
Can I still use ShardedJedis?
Yes, but it's officially deprecated. The release notes recommend moving to Redis Cluster for sharding instead of using the standalone ShardedJedis functionality.
How do I authenticate with a Redis 6 ACL user?
Use the auth method with both a username and password: jedis.auth("myuser", "mypass");. The old single-parameter method still works for traditional password-only setup.
Why was support for Java 6 and 7 dropped?
Dropping support for these older Java versions allows the Jedis developers to use modern Java features and APIs, simplifying the codebase and enabling future improvements that wouldn't be possible otherwise.
What should I do if I used the BinaryClient class?
The BinaryClient class was removed. You should migrate your code to use the standard Jedis client class or other available interfaces for binary data operations.