Jedis 8.1.0 Release Notes

This guide helps you upgrade from Jedis 8.0.0.

Unreleased

Jedis 8.1.0 has not been released yet. These notes track changes on master since 8.0.0 and are updated as changes merge; remove this notice when 8.1.0 ships.

Note

If your change alters user-visible behavior, add an entry here in the same PR.

Highlights

Smart Client Handoffs (#4668)

Jedis now reacts to server maintenance push notifications with relaxed timeouts and pre-handoffs. The feature requires RESP3 and is configured with MaintenanceNotificationsConfig via RedisClient.builder().maintenanceNotifications(...). It is enabled by default (Mode.AUTO) on RESP3 connections; pass MaintenanceNotificationsConfig.DISABLED to opt out. See the Smart Client Handoffs guide.

Behavior Changes

Changes that may affect existing applications even though they are not breaking API changes.

Key pre-processor applied to all key arguments (#4675)

The source key of ZRANGESTORE/GEOSEARCHSTORE and the script KEYS passed to eval(script, keyCount, ...) / evalsha(sha1, keyCount, ...) were previously not treated as keys: a configured CommandKeyArgumentPreProcessor (e.g. key prefixing) did not transform them, and the store commands' source key was invisible to cluster key routing. They are now handled like every other key argument: the pre-processor applies to them, and on cluster a cross-slot ZRANGESTORE/GEOSEARCHSTORE fails client-side with JedisClusterOperationException instead of the server's CROSSSLOT error.

Action required: remove any manual prefixing workaround for these arguments (they would now be prefixed twice), and update catch blocks that matched the server CROSSSLOT JedisDataException for these commands.

Pub/sub push messages are no longer delivered as command replies outside a subscription (#4701)

On RESP3, a pub/sub push frame that arrived while no pub/sub read loop was running — for example a message the server delivered after the UNSUBSCRIBE confirmation, as can happen behind the Redis Enterprise proxy — was returned as the next command's reply. This desynced the reply stream and typically surfaced as ClassCastException: java.util.ArrayList cannot be cast to [B.

Such stray pub/sub pushes are now logged at debug level and dropped instead of being delivered to the application, and the following command receives its own reply. Behavior during an active subscribe/psubscribe/ssubscribe loop is unchanged. Custom PushConsumers registered on a connection now also observe pub/sub-typed pushes received outside a subscription, which the built-in consumer previously propagated before they could see them; the public PUBSUB_CONSUMER constant is unchanged and still propagates unconditionally.

Action required: none for typical applications. Code that relied on reading raw pub/sub frames from a connection without going through the JedisPubSub/ JedisShardedPubSub loops (e.g. hand-rolled sendCommand(SUBSCRIBE) + getUnflushedObject()) will no longer receive those frames; use the pub/sub APIs or register a custom PushConsumer that propagates them.