Jedis is MIT-licensed Java client for Redis, maintained by Redis, that gives JVM applications direct programmatic access to Redis commands and Redis Cluster, aimed at Java developers and teams running Redis in production.

What it is

Jedis is a Java client library for Redis, distributed on Maven Central as redis.clients:jedis and developed in the redis/jedis repository under the MIT licence. It is a low-level client rather than an object-mapping framework: the README directs anyone wanting a high-level library for object mapping to redis-om-spring instead. The client speaks the Redis command surface directly, exposing data-type operations such as sadd, and it supports the Redis Cluster Specification through a dedicated client class. The project lives in the Java ecosystem, alongside the Redis server itself, and it has been the long-standing default Redis binding for JVM shops.

The concrete problem it solves is the gap between a running Redis server and Java code. Redis speaks its own wire protocol over TCP on port 6379; a Java application cannot call it without a protocol implementation, connection and pooling management, command marshalling, and, for sharded deployments, cluster topology discovery and redirect handling. Jedis replaces hand-rolled socket clients and one-off protocol layers with a maintained library that tracks new Redis releases. Per its compatibility table, the most recent library version supports Redis 7.2 through 8.10, and Jedis 5.0 and later cover Redis 6.0 to current.

Key capabilities

• Connects to a single Redis node via RedisClient.builder().hostAndPort("localhost", 6379).build(), after which commands such as jedis.sadd("planets", "Venus") are sent directly.
• Connects to a Redis Cluster using RedisClusterClient, built from a Set of cluster nodes and supporting the Redis Cluster Specification.
• Covers all Redis data types, including JSON and VectorSets documented in the Redis data-types reference.
• Version compatibility is tracked explicitly: Jedis 3.9+ targets Redis 5.0 to 6.2, Jedis 4.0+ targets Redis 5.0 to 7.2, and Jedis 5.2+ through 8.0 target Redis 7.2 to current.
• Runs on JDK 8, 11, 17, 21 and, from Jedis 8.0, JDK 25.
• Ships Javadocs on javadoc.io and code coverage reporting through codecov for the master branch.
• Publishes a cutting-edge channel at https://redis.github.io/jedis/jedis-maven/ for unreleased builds.

Who uses it and how

• Java backend teams that already run Redis for caching, session storage or queues and need a client inside a Spring Boot or plain JVM service.
• Teams operating sharded Redis where commands must route across multiple nodes; RedisClusterClient takes the node set and handles topology.
• Applications pinned to older runtimes: the compatibility table explicitly covers JDK 8 and 11, so legacy services are supported targets, not an afterthought.
• Contributors and integrators working from source, who use the project's Discord channel for the Redis community and Redis University material for onboarding.
• Developers who want object mapping rather than raw commands are pointed at redis-om-spring, which sits above this client rather than inside it.

Getting started

Add the Maven dependency redis.clients:jedis at version 8.0.1, start a server with docker run -p 6379:6379 -it redis:latest, then build a RedisClient against localhost:6379 and issue commands.

How it compares

This registry provides no list of paid products that Jedis replaces, and it names no comparable Java Redis client as an alternative, so no comparison against those axes can be drawn from the facts given. On the evidence available, Jedis stands alone in this registry as the Redis Java client entry, distinguished only by being maintained under the Redis organisation itself.

When to use it — and when not to

A self-hoster must operate a Redis server, whether via the documented docker run -p 6379:6379 redis:latest container or a managed instance; the library is a client and provides no database, no storage and no SMTP layer of its own. Teams needing object mapping, repository abstractions or Spring Data integration should not start here and should evaluate redis-om-spring instead, and anyone on a Redis version older than 7.2 will be outside the support envelope documented for current releases. Honest caveats: the README excerpt available here is truncated mid-topic on VectorSets, so feature documentation for newer data types must be read upstream, and the repository carries 125 open issues, which is normal for a client tracking a fast-moving server but still means reports can sit unresolved.

<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>8.0.1</version>
</dependency>

docker run -p 6379:6379 -it redis:latest

RedisClient jedis = RedisClient.builder().hostAndPort("localhost", 6379).build();

jedis.sadd("planets", "Venus");

Set<HostAndPort> jedisClusterNodes = new HashSet<HostAndPort>();
jedisClusterNodes.add(new HostAndPort("127.0.0.1", 7379));
jedisClusterNodes.add(new HostAndPort("127.0.0.1", 7380));
RedisClusterClient jedis = RedisClusterClient.builder().nodes(jedisClusterNodes).build();

jedis.sadd("planets", "Mars");