{"owner":"redis","repo":"jedis","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# Jedis Coding Conventions\nJedis is a synchronous Java client for Redis, shipped as a library on Maven Central as `redis.clients:jedis`.\nIt covers standalone, cluster, sentinel, and multi-db setups — with pipelining, transactions, pub/sub, and Redis Stack modules — and targets Java 8 for source/binary compatibility.\n\n## General Principles\n- **Maintain JDK 8 compatibility.** All production and test code must compile and run on JDK 8.\n- **Keep documentation up to date.** If a change affects user-facing behavior, configuration, or the public API, update the relevant pages under [`docs/`](docs) (MkDocs).\n- **Add or update tests.** Every bug fix should include a regression test, and every new feature should include appropriate tests. Follow the conventions in [`docs/integration-testing.md`](docs/integration-testing.md) for choosing between unit and integration tests.\n- **Document breaking changes.** Any breaking change must be documented in the appropriate migration guide under [`docs/migration-guides/`](docs/migration-guides).\n- **Follow the contribution guidelines.** Ensure all changes comply with the project rules in [`.github/CONTRIBUTING.md`](.github/CONTRIBUTING.md).\n- **Request approval before adding dependencies.** Do not introduce new runtime, test, or build dependencies without explicit confirmation.\n- **Review-friendly changes.** Keep commits and pull requests focused and logically grouped. Separate feature or bug-fix changes from refactoring, formatting, and other mechanical changes whenever practical.\n\n## Development Environment\n- **Use the CI JDK version.** Build and test using the same JDK version configured in the GitHub Actions workflows. Check `.github/workflows/` (or `docs/integration-testing.md`) to determine the required version before reproducing CI failures.\n\n## Build & Test Commands\n- `make start version=8.6` + `mvn clean verify` + `make stop` — full run against\n  the Docker Redis env (`make test` does all three).\n- `mvn test` — unit tests (no Redis); `mvn -Dtest=ClassName test` for one class.\n\n## Implementation Guidelines\n### Code Style\n- Keep comments short and informative. Comment **why**, not **what**. Avoid comments that simply restate the code.\n- Remove unused imports. Do not use wildcard imports. Avoid fully qualified class names unless necessary to resolve naming conflicts.\n- **Annotate all new public API with `@since`.** Determine the version from the current build by running:\n  ```sh\n  mvn help:evaluate -Dexpression=project.version -q -DforceStdout\n  ```\n  (or by reading the top-level `<version>` in `pom.xml`), then remove the `-SNAPSHOT` suffix. For example, `8.0.0-SNAPSHOT` becomes `@since 8.0`.\n\n### Test Conventions\n- Name new unit test classes using the `*Test` convention.\n- Name new integration test classes using the `*IT` convention. Do not use the `integration` tag for new tests.\n\n## Architecture\n\nSee [`docs/redis-client-components-overview.md`](docs/redis-client-components-overview.md)\nfor a high-level walkthrough (executors, providers, builders, and command execution flows).\n\n`UnifiedJedis` is the core client. It implements the command interfaces and\ndelegates to three collaborators:\n\n- `ConnectionProvider` (`providers/`) — obtains connections: pooled, cluster,\n  sentinel, or multi-db.\n- `CommandExecutor` (`executors/`) — runs a command: simple, retry, cluster\n  routing, or failover.\n- `CommandObjects` — factory building a typed `CommandObject<T>` per command.\n\n**Modern clients** extend `UnifiedJedis` and are built through\n`AbstractClientBuilder` subclasses (`builders/`): `RedisClient`,\n`RedisClusterClient`, `RedisSentinelClient`, `MultiDbClient`. A new client\noverrides `createDefaultConnectionProvider()`, `createDefaultCommandExecutor()`,\n`createClient()`, and `validateSpecificConfiguration()` (run before `build()`).\n\n**Legacy client:** `Jedis` is the single-connection client (pooling via\n`JedisPool`), still supported. `JedisPool`, `JedisCluster`, and\n`JedisSentinelPool` are `@Deprecated` in favor of the builder-based clients.\n\n**Feature modules** expose dedicated command interfaces under\n`redis.clients.jedis.<module>`: `search`, `json`, `bloom`, `timeseries`, plus\n`csc` (client-side caching) and `mcf` (multi-db / failover).\n\n## Conventions\n\n**Adding or changing a command** — trace an existing command first, then update\nthe full matrix so all surfaces stay in sync:\n\n1. **Command interfaces** (`commands/`): `<Group>Commands` and\n   `<Group>BinaryCommands` (String vs `byte[]`), each with its `<Group>Pipeline…`\n   variant.\n2. **`CommandObjects`** — build the args and a response `Builder<T>`, e.g.\n   `new CommandObject<>(commandArguments(GET).key(key), BuilderFactory.STRING)`.\n   `ClusterCommandObjects` overrides these to enforce cluster constraints.\n3. **`UnifiedJedis`** and **`PipeliningBase`** — the execution entry points.\n4. **`Jedis`** — add it here too, for backward compatibility.\n\n**Encoding:**\n- String ↔ bytes: `SafeEncoder.encode()` — never `String.getBytes()` (breaks GBK).\n- Numeric → bytes: `Protocol.toByteArray()`.\n"},"files":{"AGENTS.md":"# Jedis Coding Conventions\nJedis is a synchronous Java client for Redis, shipped as a library on Maven Central as `redis.clients:jedis`.\nIt covers standalone, cluster, sentinel, and multi-db setups — with pipelining, transactions, pub/sub, and Redis Stack modules — and targets Java 8 for source/binary compatibility.\n\n## General Principles\n- **Maintain JDK 8 compatibility.** All production and test code must compile and run on JDK 8.\n- **Keep documentation up to date.** If a change affects user-facing behavior, configuration, or the public API, update the relevant pages under [`docs/`](docs) (MkDocs).\n- **Add or update tests.** Every bug fix should include a regression test, and every new feature should include appropriate tests. Follow the conventions in [`docs/integration-testing.md`](docs/integration-testing.md) for choosing between unit and integration tests.\n- **Document breaking changes.** Any breaking change must be documented in the appropriate migration guide under [`docs/migration-guides/`](docs/migration-guides).\n- **Follow the contribution guidelines.** Ensure all changes comply with the project rules in [`.github/CONTRIBUTING.md`](.github/CONTRIBUTING.md).\n- **Request approval before adding dependencies.** Do not introduce new runtime, test, or build dependencies without explicit confirmation.\n- **Review-friendly changes.** Keep commits and pull requests focused and logically grouped. Separate feature or bug-fix changes from refactoring, formatting, and other mechanical changes whenever practical.\n\n## Development Environment\n- **Use the CI JDK version.** Build and test using the same JDK version configured in the GitHub Actions workflows. Check `.github/workflows/` (or `docs/integration-testing.md`) to determine the required version before reproducing CI failures.\n\n## Build & Test Commands\n- `make start version=8.6` + `mvn clean verify` + `make stop` — full run against\n  the Docker Redis env (`make test` does all three).\n- `mvn test` — unit tests (no Redis); `mvn -Dtest=ClassName test` for one class.\n\n## Implementation Guidelines\n### Code Style\n- Keep comments short and informative. Comment **why**, not **what**. Avoid comments that simply restate the code.\n- Remove unused imports. Do not use wildcard imports. Avoid fully qualified class names unless necessary to resolve naming conflicts.\n- **Annotate all new public API with `@since`.** Determine the version from the current build by running:\n  ```sh\n  mvn help:evaluate -Dexpression=project.version -q -DforceStdout\n  ```\n  (or by reading the top-level `<version>` in `pom.xml`), then remove the `-SNAPSHOT` suffix. For example, `8.0.0-SNAPSHOT` becomes `@since 8.0`.\n\n### Test Conventions\n- Name new unit test classes using the `*Test` convention.\n- Name new integration test classes using the `*IT` convention. Do not use the `integration` tag for new tests.\n\n## Architecture\n\nSee [`docs/redis-client-components-overview.md`](docs/redis-client-components-overview.md)\nfor a high-level walkthrough (executors, providers, builders, and command execution flows).\n\n`UnifiedJedis` is the core client. It implements the command interfaces and\ndelegates to three collaborators:\n\n- `ConnectionProvider` (`providers/`) — obtains connections: pooled, cluster,\n  sentinel, or multi-db.\n- `CommandExecutor` (`executors/`) — runs a command: simple, retry, cluster\n  routing, or failover.\n- `CommandObjects` — factory building a typed `CommandObject<T>` per command.\n\n**Modern clients** extend `UnifiedJedis` and are built through\n`AbstractClientBuilder` subclasses (`builders/`): `RedisClient`,\n`RedisClusterClient`, `RedisSentinelClient`, `MultiDbClient`. A new client\noverrides `createDefaultConnectionProvider()`, `createDefaultCommandExecutor()`,\n`createClient()`, and `validateSpecificConfiguration()` (run before `build()`).\n\n**Legacy client:** `Jedis` is the single-connection client (pooling via\n`JedisPool`), still supported. `JedisPool`, `JedisCluster`, and\n`JedisSentinelPool` are `@Deprecated` in favor of the builder-based clients.\n\n**Feature modules** expose dedicated command interfaces under\n`redis.clients.jedis.<module>`: `search`, `json`, `bloom`, `timeseries`, plus\n`csc` (client-side caching) and `mcf` (multi-db / failover).\n\n## Conventions\n\n**Adding or changing a command** — trace an existing command first, then update\nthe full matrix so all surfaces stay in sync:\n\n1. **Command interfaces** (`commands/`): `<Group>Commands` and\n   `<Group>BinaryCommands` (String vs `byte[]`), each with its `<Group>Pipeline…`\n   variant.\n2. **`CommandObjects`** — build the args and a response `Builder<T>`, e.g.\n   `new CommandObject<>(commandArguments(GET).key(key), BuilderFactory.STRING)`.\n   `ClusterCommandObjects` overrides these to enforce cluster constraints.\n3. **`UnifiedJedis`** and **`PipeliningBase`** — the execution entry points.\n4. **`Jedis`** — add it here too, for backward compatibility.\n\n**Encoding:**\n- String ↔ bytes: `SafeEncoder.encode()` — never `String.getBytes()` (breaks GBK).\n- Numeric → bytes: `Protocol.toByteArray()`.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Jedis Coding Conventions\nJedis is a synchronous Java client for Redis, shipped as a library on Maven Central as `redis.clients:jedis`.\nIt covers standalone, cluster, sentinel, and multi-db setups — with pipelining, transactions, pub/sub, and Redis Stack modules — and targets Java 8 for source/binary compatibility.\n\n## General Principles\n- **Maintain JDK 8 compatibility.** All production and test code must compile and run on JDK 8.\n- **Keep documentation up to date.** If a change affects user-facing behavior, configuration, or the public API, update the relevant pages under [`docs/`](docs) (MkDocs).\n- **Add or update tests.** Every bug fix should include a regression test, and every new feature should include appropriate tests. Follow the conventions in [`docs/integration-testing.md`](docs/integration-testing.md) for choosing between unit and integration tests.\n- **Document breaking changes.** Any breaking change must be documented in the appropriate migration guide under [`docs/migration-guides/`](docs/migration-guides).\n- **Follow the contribution guidelines.** Ensure all changes comply with the project rules in [`.github/CONTRIBUTING.md`](.github/CONTRIBUTING.md).\n- **Request approval before adding dependencies.** Do not introduce new runtime, test, or build dependencies without explicit confirmation.\n- **Review-friendly changes.** Keep commits and pull requests focused and logically grouped. Separate feature or bug-fix changes from refactoring, formatting, and other mechanical changes whenever practical.\n\n## Development Environment\n- **Use the CI JDK version.** Build and test using the same JDK version configured in the GitHub Actions workflows. Check `.github/workflows/` (or `docs/integration-testing.md`) to determine the required version before reproducing CI failures.\n\n## Build & Test Commands\n- `make start version=8.6` + `mvn clean verify` + `make stop` — full run against\n  the Docker Redis env (`make test` does all three).\n- `mvn test` — unit tests (no Redis); `mvn -Dtest=ClassName test` for one class.\n\n## Implementation Guidelines\n### Code Style\n- Keep comments short and informative. Comment **why**, not **what**. Avoid comments that simply restate the code.\n- Remove unused imports. Do not use wildcard imports. Avoid fully qualified class names unless necessary to resolve naming conflicts.\n- **Annotate all new public API with `@since`.** Determine the version from the current build by running:\n  ```sh\n  mvn help:evaluate -Dexpression=project.version -q -DforceStdout\n  ```\n  (or by reading the top-level `<version>` in `pom.xml`), then remove the `-SNAPSHOT` suffix. For example, `8.0.0-SNAPSHOT` becomes `@since 8.0`.\n\n### Test Conventions\n- Name new unit test classes using the `*Test` convention.\n- Name new integration test classes using the `*IT` convention. Do not use the `integration` tag for new tests.\n\n## Architecture\n\nSee [`docs/redis-client-components-overview.md`](docs/redis-client-components-overview.md)\nfor a high-level walkthrough (executors, providers, builders, and command execution flows).\n\n`UnifiedJedis` is the core client. It implements the command interfaces and\ndelegates to three collaborators:\n\n- `ConnectionProvider` (`providers/`) — obtains connections: pooled, cluster,\n  sentinel, or multi-db.\n- `CommandExecutor` (`executors/`) — runs a command: simple, retry, cluster\n  routing, or failover.\n- `CommandObjects` — factory building a typed `CommandObject<T>` per command.\n\n**Modern clients** extend `UnifiedJedis` and are built through\n`AbstractClientBuilder` subclasses (`builders/`): `RedisClient`,\n`RedisClusterClient`, `RedisSentinelClient`, `MultiDbClient`. A new client\noverrides `createDefaultConnectionProvider()`, `createDefaultCommandExecutor()`,\n`createClient()`, and `validateSpecificConfiguration()` (run before `build()`).\n\n**Legacy client:** `Jedis` is the single-connection client (pooling via\n`JedisPool`), still supported. `JedisPool`, `JedisCluster`, and\n`JedisSentinelPool` are `@Deprecated` in favor of the builder-based clients.\n\n**Feature modules** expose dedicated command interfaces under\n`redis.clients.jedis.<module>`: `search`, `json`, `bloom`, `timeseries`, plus\n`csc` (client-side caching) and `mcf` (multi-db / failover).\n\n## Conventions\n\n**Adding or changing a command** — trace an existing command first, then update\nthe full matrix so all surfaces stay in sync:\n\n1. **Command interfaces** (`commands/`): `<Group>Commands` and\n   `<Group>BinaryCommands` (String vs `byte[]`), each with its `<Group>Pipeline…`\n   variant.\n2. **`CommandObjects`** — build the args and a response `Builder<T>`, e.g.\n   `new CommandObject<>(commandArguments(GET).key(key), BuilderFactory.STRING)`.\n   `ClusterCommandObjects` overrides these to enforce cluster constraints.\n3. **`UnifiedJedis`** and **`PipeliningBase`** — the execution entry points.\n4. **`Jedis`** — add it here too, for backward compatibility.\n\n**Encoding:**\n- String ↔ bytes: `SafeEncoder.encode()` — never `String.getBytes()` (breaks GBK).\n- Numeric → bytes: `Protocol.toByteArray()`.\n","category":"root","tokens":1264}]}