From bd4d94e4510dd5d6855afe60b4510c04b21af578 Mon Sep 17 00:00:00 2001 From: Julian lechner Date: Thu, 8 Oct 2026 10:34:01 +0200 Subject: [PATCH] docs(rules): keep Java composition guidance in modern-java only Co-Authored-By: Claude Opus 5.5 --- shared/rules/java/references/architecture-and-apis.md | 2 +- shared/rules/java/references/modern-java.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/shared/rules/java/references/architecture-and-apis.md b/shared/rules/java/references/architecture-and-apis.md index 8321090..ca725d8 100644 --- a/shared/rules/java/references/architecture-and-apis.md +++ b/shared/rules/java/references/architecture-and-apis.md @@ -7,5 +7,5 @@ Apply these rules when designing public APIs, service boundaries, or application * Authorize the specific resource and operation where data is accessed or changed. Preserve ownership and tenant scope across alternate paths and background work. * Bound payloads, page sizes, query complexity, and operation cost. Use pagination or streaming for potentially large results. * Keep domain decisions separate from transport, persistence, and framework wiring. Make dependencies explicit; use dependency injection for real lifecycle or substitution needs. -* Prefer composition and small contracts at real boundaries. Avoid service locators, broad base classes, reflection, and wrappers without a concrete purpose. +* Use small contracts at real boundaries. Avoid service locators. * Preserve existing API and serialization behavior unless the task requires a change. Treat changes to nullability, ordering, exception types, and collection mutability as compatibility changes. diff --git a/shared/rules/java/references/modern-java.md b/shared/rules/java/references/modern-java.md index dbeac51..f953428 100644 --- a/shared/rules/java/references/modern-java.md +++ b/shared/rules/java/references/modern-java.md @@ -6,7 +6,7 @@ Apply these rules when editing Java syntax, class structure, and everyday code o * Prefer direct control flow and descriptive domain names. Use streams when they clarify a transformation; loops are often clearer for stateful work or error handling. * Use local `var` only when the initializer makes the type obvious. Keep public contracts explicitly typed. * Use records for transparent immutable carriers and sealed types for genuinely closed variants when the target release supports them. Do not force them onto mutable entities or framework-managed types. -* Prefer composition and focused classes over inheritance, reflection, global mutable state, or speculative interfaces. +* Prefer composition and focused classes over inheritance, broad base classes, reflection, wrappers, global mutable state, or speculative interfaces. * Make ownership, mutation, and side effects visible. Use `final` where it clarifies invariants; do not add it mechanically to every local variable. * Prefer supported `java.time` APIs and standard library facilities over obsolete APIs or custom helpers when they fit the contract. * Remove dead code. Add comments only for non-obvious decisions or public contracts that code cannot express clearly.