Get the public API surface right before writing implementation code.
Build the internals.
Phase 1 (API Design):
#93 (packages) ──┐
#81 (interfaces) ├──→ #82 (value objects)
├──→ #83 (Where DSL)
├──→ #84 (record builders) ← depends on #83
├──→ #85 (auth)
├──→ #86 (exceptions)
└──→ #87 (client builder) ← depends on #82, #85
Phase 2 (Implementation):
#88 (HTTP transport) ← depends on #85, #86
#89 (ChromaClient) ← depends on #81-#88
#90 (record ops) ← depends on #83, #84, #88, #89
#91 (tests) ← depends on #89, #90
#92 (remove swagger) ← depends on #88, #89
Phase 3 (Go parity) — depends on Phase 2:
#96-#97 (Client APIs) ← depends on #89
#98-#100 (Collection APIs) ← depends on #90
#101-#103 (Config & DSL) ← depends on #82, #83, #87
#104 (ResultRow) ← depends on #90
#105 (Search API) ← depends on #90, #104
#106-#109 (EF ecosystem) ← independent
#110 (ID generators) ← depends on #84
#111 (Local client) ← depends on #89
Overview
Complete redesign of the Java client for Chroma's v2 API, modeled after the Go client with Java-idiomatic patterns (builders, strong typing, AutoCloseable).
This replaces PR #80 which explored the right patterns but accumulated too much technical debt across iterations.
Phase 1: API Design (shape the contract)
Get the public API surface right before writing implementation code.
Phase 2: Implementation
Build the internals.
Phase 3: API Parity with Go Client
Gaps identified by cross-referencing the Go client API surface.
Client API additions
Collection API additions
Configuration & DSL
Result types
Search API
Embedding & Reranking ecosystem
Utilities
Advanced
Phase 4: Future
ChromaClient.cloud())Dependency Graph
Superseded Issues
These older issues are addressed by the v2 redesign: