#4688·jedis

Vector sets: add plain overloads for optional params and stop accepting null while the API is @Experimental

Author: ggivoCreated Aug 18, 2026Updated Aug 18, 2026

Background

The vector-set command interfaces (@Experimental since 6.2.0) express optional VAddParams/VSimParams differently from the rest of Jedis. Repo-wide, optional params are modeled as overload pairs — a plain method plus a params-taking one — and null is never an accepted value (CommandArguments.addParams throws NPE). The vector-set family instead tolerates null via a private addOptionalParams helper, and several methods have no plain overload at all, making null the only way to call them without options. #4684 fixed the one overload that was inconsistent even within the family (String vaddFP32 with reduceDim threw NPE while its binary sibling accepted null).

None of this is documented: the interface javadocs say nothing about null being legal.

Current state — params-taking methods with no plain overload

Method VectorSetCommands VectorSetBinaryCommands pipeline interfaces
vadd(..., reduceDim, params) missing missing missing
vaddFP32(..., reduceDim, params) missing missing missing
vsimWithScores(key, vector, params) missing missing missing
vsimByElementWithScores(key, element, params) missing missing missing
vsimWithScoresAndAttribs(...) missing missing n/a (variant absent)
vsimByElementWithScoresAndAttribs(...) missing missing n/a (variant absent)

Proposal — two PRs

PR A — add the missing plain overloads (target: 8.1.0). Purely additive, no behavior change.

PR B — remove null tolerance (target: 8.1.0, while still @Experimental; decision point below). Behavior change.

  • Delete the two addOptionalParams helpers in CommandObjects;
  • Rewrite the 8 existing plain overloads that delegate with null to delegate with a default params instance.
  • Release-note line: experimental vector-set methods no longer accept null params; use the new plain overloads.

Decision point for PR B

Null tolerance has shipped since 6.2.0 with no reported issues (the #4684 report was about inconsistent null handling, not null itself). Options:

  1. Remove in 8.1.0 alongside PR A while the API is still @Experimental. (Preferred.)
  2. Keep null tolerance as undocumented leniency after PR A lands and remove it as a precondition for dropping @Experimental.

Either way, PR A should not be blocked on this decision. What is not acceptable long-term is the current state: no plain overloads and null as the required-but-undocumented idiom.

References