That question is opinion-based but lets get some objective points into it:
TL; DR:
The driver choice depends on multiple things:
- Additional dependencies
- Programming model
- Scalability
- Being opinionated regarding the implementation of high-level features
- Prospect of your project, the direction in which you want to evolve
Explanation
Additional dependencies
Some projects are opinionated regarding additional dependencies and transient dependencies when adding a library.
Jedis is almost dependency-free, it requires Apache Commons Pool 2 for connection-pooling.
Redisson requires Netty, the JCache API and Project Reactor as basic dependencies. It's extensible because it integrates with a lot of other libraries (Tomcat Session store).
Programming model
That's how you interact with your Redis client. It also defines the abstraction level.
Jedis is a low-level driver exposing Redis API as Java method calls:
Jedis jedis = …;
jedis.set("key", "value");
List<String> values = jedis.mget("key", "key2", "key3");
Redisson is a high-level client that exposes its functionality through various API objects:
Redisson redisson = …
RMap map = redisson.getMap("my-map"); // implement java.util.Map
map.put("key", "value");
map.containsKey("key");
map.get("key");
Each call invokes one or more Redis calls, some of them are implemented with Lua (Redis "Scripting").
Scalability
There are multiple drivers available for Java that come with various properties that might fit your project. Scalability plays into that as well. Looking at drivers it boils down how drivers, work with their resources and which programming models they support.
Jedis uses blocking I/O and method calls are synchronous. Your program flow is required to wait until I/O is handled by the sockets. There's no asynchronous (Future, CompletableFuture) or reactive support (RxJava Observable or Reactive Streams Publisher).
Jedis client instances are not thread-safe hence they require connection-pooling (Jedis-instance per calling thread).
Redisson uses non-blocking I/O and an event-driven communication layer with netty. Method calls are synchronous, asynchronous or reactive (via Project Reactor 2.0 or 3.1). Connections are pooled, but the API itself is thread-safe and requires fewer resources. I'm not entirely sure, but maybe you can even operate on a single connection. That's the most efficient way when working with Redis.
Opinion about the client implementation
These paragraphs deal with how the clients are implemented.
Both clients have an excellent feature coverage, and you can fulfill your requirements with both libraries.
Jedis is a straightforward implementation that just writes commands to an OutputStream and parses the responses. No more than that.
If you want high-level features, then you need to implement these by using the Redis API. It gives you full control over the commands you invoke and the resulting behavior. Implementing your features might require additional efforts here.
Redisson is a high-level client that provides features through its abstractions. While you can use these objects without the need of knowing they are backed by Redis (Map, List, Set, …), each API call translates to one or more Redis calls, some to Lua script execution.
You might like or dislike the way Redisson behaves and how it implements the features, but in the end, there's not much you can do about it. Using Redissons high-level features might reduce your implementation efforts.
Outlook
That section entirely depends on where you're heading to. Jedis supports all Redis API commands, Redis Standalone, Redis Sentinel and Redis Cluster. There are no slave reads in master-slave setups, but I assume that's just a matter of time until jedis will provide these features.
With jedis, you can't go async and using advanced features of AWS ElastiCache or slave reads requires your own implementation.
Redisson has a broad coverage of various setups. It supports all the things Jedis supports and provides read strategies for Master/Slave setups, has improved support for AWS ElastiCache.
