{"id":"acb2a296-6e62-4b4f-84cb-83575e77aad2","entityType":"agent","slug":"clawhub-linbingqiang-effective-java","name":"Effective Java","canonicalUrl":"https://www.xpersona.co/agent/clawhub-linbingqiang-effective-java","canonicalPath":"/agent/clawhub-linbingqiang-effective-java","generatedAt":"2026-10-11T15:12:50.609Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-11T12:07:23.995Z","emptyReason":null},"description":"Review, refactor, and explain Java code using distilled Effective Java principles for API design, immutability, generics, enums, streams, exceptions, concurr... Skill: Effective Java Owner: linbingqiang Summary: Review, refactor, and explain Java code using distilled Effective Java principles for API design, immutability, generics, enums, streams, exceptions, concurr... Tags: latest:1.0.0 Version history: v1.0.0 | 2026-04-20T06:22:55.339Z | user Initial public release Archive index: Archive v1.0.0: 5 files, 9971 bytes Files: references/item-map.md (6534b), references/review-","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.1K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s1797wcfm7pxx8rx4zamnntvc9857mgm:effective-java","sourceUrl":"https://clawhub.ai/linbingqiang/effective-java","homepage":"https://clawhub.ai/linbingqiang/skills/effective-java","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/linbingqiang/effective-java","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/linbingqiang/skills/effective-java","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":61,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Review, refactor, and explain Java code using distilled Effective Java principles for API design, immutability, generics, enums, streams, exceptions, concurr..."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T12:07:23.995Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T12:07:23.995Z","emptyReason":null},"stars":null,"forks":null,"downloads":1069,"packageName":null,"latestVersion":"1.0.0","tractionLabel":"1.1K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T12:07:23.984Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T12:07:23.995Z","lastCrawledAt":"2026-10-11T12:07:23.984Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T12:07:23.984Z","lastVerifiedAt":null,"highlights":[{"version":"1.0.0","createdAt":"2026-04-20T06:22:55.339Z","changelog":"Initial public release","fileCount":5,"zipByteSize":9971}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s1797wcfm7pxx8rx4zamnntvc9857mgm:effective-java","setupComplexity":"low","setupSteps":["Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-linbingqiang-effective-java/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-linbingqiang-effective-java/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-linbingqiang-effective-java/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-linbingqiang-effective-java/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-linbingqiang-effective-java/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-linbingqiang-effective-java/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T15:12:50.609Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-linbingqiang-effective-java/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-linbingqiang-effective-java/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-linbingqiang-effective-java/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-linbingqiang-effective-java/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-11T12:07:23.995Z","emptyReason":null},"readme":"Skill: Effective Java\n\nOwner: linbingqiang\n\nSummary: Review, refactor, and explain Java code using distilled Effective Java principles for API design, immutability, generics, enums, streams, exceptions, concurr...\n\nTags: latest:1.0.0\n\nVersion history:\n\nv1.0.0 | 2026-04-20T06:22:55.339Z | user\n\nInitial public release\n\nArchive index:\n\nArchive v1.0.0: 5 files, 9971 bytes\n\nFiles: references/item-map.md (6534b), references/review-checklist.md (6420b), skill-card.md (2099b), SKILL.md (4768b), _meta.json (133b)\n\nFile v1.0.0:SKILL.md\n\n---\nname: effective_java\ndescription: Review, refactor, and explain Java code using distilled Effective Java principles for API design, immutability, generics, enums, streams, exceptions, concurrency, and serialization.\n---\n\n# Effective Java\n\n## Core Stance\n\nUse this skill as an Effective Java design and review lens, not as a rigid style guide. Prefer APIs that are simple, type-safe, immutable where practical, composition-friendly, well-documented at boundaries, and hard to misuse.\n\nDo not reproduce book text. Paraphrase the principles, explain tradeoffs, and cite item numbers only as navigation aids when helpful.\n\n## Workflow\n\n1. Classify the task: new API design, code review, refactor, bug fix, performance pass, or teaching/explanation.\n2. Load `references/review-checklist.md` for reviews, refactors, or whenever code is provided.\n3. Load `references/item-map.md` when the user asks for item-level mapping, broad Effective Java coverage, or a learning summary.\n4. Inspect the public contract first: construction, mutability, equality, generics, exceptions, threading, serialization, and compatibility.\n5. Prioritize recommendations by semantic risk before style: correctness, API safety, encapsulation, maintainability, then performance.\n6. If editing code, make the smallest change that preserves existing behavior and public compatibility unless the user explicitly asks for an API redesign.\n\n## Default Review Order\n\n- **Correctness**: broken invariants, resource leaks, equality/hash violations, unsafe publication, races, swallowed exceptions.\n- **API design**: confusing construction, boolean traps, excessive overloads, raw types, wildcard misuse, checked exceptions that are not recoverable.\n- **Encapsulation**: exposed mutable state, public fields, inheritance without contracts, mutable static state, missing defensive copies.\n- **Type safety**: unchecked casts, heap pollution, arrays mixed with generics, int constants where enums fit.\n- **Clarity**: stream/lambda overuse, unclear method references, unnecessary cleverness, duplicated construction logic.\n- **Performance**: avoid premature tuning; flag avoidable object churn, boxing, synchronization bottlenecks, and inappropriate parallel streams only after semantics are sound.\n\n## High-Value Heuristics\n\n- Prefer named static factories when names, caching, subtype returns, or instance control improve the API; keep constructors when the simple shape is clearer.\n- Use builders for constructors with many optional parameters; validate invariants in one place before object publication.\n- Prefer dependency injection over hard-coded singletons or static utilities for resources that vary or need testing.\n- Favor immutability, minimize visibility, and make defensive copies at trust boundaries.\n- Prefer composition over inheritance unless inheritance is deliberately designed, documented, and tested.\n- Eliminate raw types; use bounded wildcards with PECS: producers `extends`, consumers `super`.\n- Use enums instead of integer or string constants; use `EnumSet` and `EnumMap` for enum-keyed collections.\n- Use lambdas and streams for clear transformations; keep complex control flow, checked exceptions, and stateful logic out of streams.\n- Validate parameters at boundaries; return empty collections or arrays instead of `null` for multi-value returns.\n- Use checked exceptions only for conditions callers can reasonably recover from; otherwise prefer unchecked exceptions with useful messages.\n- Treat concurrency as a correctness concern: prefer immutability, executors, concurrent collections, and explicit thread-safety documentation.\n- Avoid Java serialization for new designs; if forced to support it, validate invariants and consider the serialization proxy pattern.\n\n## Response Patterns\n\nFor code review, answer with prioritized findings:\n\n```text\n- [P1] Title (`Path.java:line`): explain the concrete risk.\n  Effective Java lens: item family or principle.\n  Change: concise, actionable fix.\n```\n\nFor refactoring, explain the chosen item families, apply a focused patch, then list behavior and compatibility assumptions plus validation performed.\n\nFor teaching, group principles by problem type and include small original examples rather than long quotes from the book.\n\n## Guardrails\n\n- Preserve public API compatibility unless the user explicitly asks for breaking changes.\n- Do not turn every class immutable, every constructor into a builder, or every loop into a stream; justify each recommendation by context.\n- Do not add frameworks or large abstractions when a Java language or library feature solves the problem.\n- Call out uncertainty when source context is missing, especially around concurrency guarantees, serialization compatibility, and external API contracts.\n\nFile v1.0.0:_meta.json\n\n{\n  \"ownerId\": \"kn78qwphcqsracs039f5avstah81s7r9\",\n  \"slug\": \"effective-java\",\n  \"version\": \"1.0.0\",\n  \"publishedAt\": 1776666175339\n}\n\nFile v1.0.0:references/item-map.md\n\n# Effective Java Item Map\n\nThis is a compact, paraphrased map of Effective Java, 3rd edition. Use it for item-level navigation and learning summaries; do not treat it as a substitute for the book.\n\n## Object Creation and Destruction\n\n1. Prefer static factories when naming, caching, subtyping, or instance control makes construction clearer.\n2. Use builders when constructors would require many optional or interdependent parameters.\n3. Enforce singleton properties carefully; enum singletons are often simplest.\n4. Prevent instantiation of utility classes with a private constructor.\n5. Prefer dependency injection to hard-coded resources.\n6. Avoid unnecessary objects, especially in hot paths.\n7. Remove obsolete references that prevent garbage collection.\n8. Avoid finalizers and cleaners for normal cleanup.\n9. Use try-with-resources for deterministic resource release.\n\n## Methods Common to All Objects\n\n10. Override `equals` only when logical equality is needed and can satisfy the full contract.\n11. Always override `hashCode` when overriding `equals`.\n12. Implement `toString` for useful diagnostics and logging.\n13. Prefer copying alternatives to `clone`; if cloning, respect its tricky contract.\n14. Implement `Comparable` only with a consistent, documented total ordering.\n\n## Classes and Interfaces\n\n15. Minimize accessibility of every type and member.\n16. Use accessors instead of public mutable fields.\n17. Minimize mutability; immutable objects are simpler and safer.\n18. Favor composition and forwarding over inheritance for reuse.\n19. Design and document inheritance deliberately, or prohibit it.\n20. Prefer interfaces to abstract classes for type definitions.\n21. Design interfaces carefully because default methods can create compatibility traps.\n22. Do not use interfaces only to export constants.\n23. Prefer class hierarchies to tagged classes with mode fields.\n24. Prefer static member classes over nonstatic ones when no enclosing instance is needed.\n25. Keep one top-level class per source file.\n\n## Generics\n\n26. Do not use raw types in new code.\n27. Eliminate unchecked warnings; suppress only tightly and with justification.\n28. Prefer lists to arrays when generics are involved.\n29. Favor generic types over casts at use sites.\n30. Favor generic methods for reusable type-safe operations.\n31. Use bounded wildcards to make APIs flexible.\n32. Combine generics and varargs carefully; avoid heap pollution.\n33. Use type tokens for type-safe heterogeneous containers.\n\n## Enums and Annotations\n\n34. Use enums instead of integer constants for fixed sets.\n35. Do not rely on enum ordinals for data or persistence.\n36. Use `EnumSet` instead of bit fields.\n37. Use `EnumMap` instead of ordinal indexing.\n38. Model extensible enum-like behavior with interfaces when needed.\n39. Prefer annotations to naming patterns.\n40. Consistently use `@Override`.\n41. Use marker interfaces when type relationships matter at compile time.\n\n## Lambdas and Streams\n\n42. Prefer lambdas to anonymous classes for small function objects.\n43. Prefer method references when they are clearer than lambdas.\n44. Use standard functional interfaces before inventing new ones.\n45. Use streams judiciously; clarity beats novelty.\n46. Keep stream functions side-effect-free.\n47. Return collections or arrays rather than streams when callers need normal collection behavior.\n48. Use parallel streams only with evidence that they are correct and faster.\n\n## Methods\n\n49. Check parameters for validity and fail early.\n50. Make defensive copies when accepting or returning mutable objects across trust boundaries.\n51. Design method signatures carefully: names, parameters, overloads, and return types are API.\n52. Use overloading carefully; avoid surprising compile-time dispatch.\n53. Use varargs judiciously and avoid ambiguous or unsafe calls.\n54. Return empty collections or arrays, not `null`.\n55. Return `Optional` judiciously for absent results.\n56. Write documentation comments for exposed APIs.\n\n## General Programming\n\n57. Minimize the scope of local variables.\n58. Prefer enhanced `for` loops when indexes or iterators are not needed.\n59. Know and use the standard libraries.\n60. Use `BigDecimal`, `int`, or `long` for exact monetary calculations; avoid float or double for exact answers.\n61. Prefer primitives to boxed primitives unless nullability or generics require boxing.\n62. Avoid strings for data that has a better type.\n63. Beware repeated string concatenation in performance-sensitive loops.\n64. Refer to objects by interfaces when suitable.\n65. Prefer interfaces to reflection for normal application logic.\n66. Use native methods only when justified.\n67. Optimize only after measurement identifies a real problem.\n68. Follow generally accepted naming conventions.\n\n## Exceptions\n\n69. Use exceptions only for exceptional conditions.\n70. Use checked exceptions for recoverable conditions and runtime exceptions for programming errors.\n71. Avoid unnecessary checked exceptions that make APIs painful.\n72. Prefer standard exceptions when they fit.\n73. Translate lower-level exceptions while preserving the cause.\n74. Document every exception thrown by exposed APIs.\n75. Include failure-capture information in detail messages.\n76. Strive for failure atomicity.\n77. Do not ignore exceptions.\n\n## Concurrency\n\n78. Synchronize access to shared mutable data.\n79. Avoid excessive synchronization and avoid alien method calls inside locks.\n80. Prefer executors, tasks, and streams to raw threads.\n81. Prefer concurrency utilities to `wait` and `notify`.\n82. Document thread-safety guarantees.\n83. Use lazy initialization only when it is necessary and safely implemented.\n84. Do not depend on the thread scheduler for correctness.\n\n## Serialization\n\n85. Prefer alternatives to Java serialization.\n86. Implement `Serializable` very cautiously because it creates long-lived API and security obligations.\n87. Consider a custom serialized form when the default form exposes internals or wastes space.\n88. Write `readObject` defensively.\n89. Prefer enum types for instance control when compatible with the design.\n90. Consider serialization proxies for classes with invariants.\n\n## Fast Mapping by Task\n\n- New value object: items 2, 10-14, 17, 49-50, 56.\n- Public API review: items 1-2, 15-22, 31, 49-56, 70-75, 82.\n- Collection-heavy utility: items 26-33, 45-48, 54-55, 57-59.\n- Concurrent service: items 5, 17, 78-84.\n- Enum modeling: items 34-38.\n- Legacy serialization: items 85-90.\n- Performance pass: items 6, 45-48, 59-61, 63, 67, 78-81.\n\nFile v1.0.0:references/review-checklist.md\n\n# Effective Java Review Checklist\n\nUse this checklist when reviewing or refactoring Java code. Start at the top and stop when you have enough high-value findings; avoid dumping every possible style preference.\n\n## 1. Construction and Lifecycle\n\n- Static factories: use when a name clarifies intent, instances are controlled or cached, return type can be an interface or subtype, or construction can hide complexity.\n- Constructors: keep when arguments are few, required, and obvious; avoid telescoping constructors with many optional values.\n- Builders: use for many optional parameters, cross-field validation, and readable call sites; keep the target object immutable when possible.\n- Dependency injection: inject clocks, random sources, clients, repositories, configuration, and strategies; avoid global statics for variable resources.\n- Resource cleanup: use try-with-resources for `AutoCloseable`; avoid finalizers and cleaners except as last-resort safety nets.\n- Object churn: reuse expensive immutable objects; avoid accidental boxing and regex recompilation in hot paths.\n\n## 2. Object Contracts\n\n- `equals`: check reflexive, symmetric, transitive, consistent, and non-null behavior; avoid equality across incompatible subclasses.\n- `hashCode`: update with every significant equality field; ensure equal objects have equal hashes.\n- `toString`: include useful state for diagnostics without exposing secrets or unstable implementation details.\n- `clone`: be skeptical; prefer copy constructors, static copy factories, or builders.\n- `Comparable`: ensure ordering is consistent, transitive, and documented when inconsistent with `equals`.\n\n## 3. Classes and Interfaces\n\n- Visibility: make classes, constructors, methods, fields, and nested types as private or package-private as possible.\n- Mutability: make fields `final` where practical; protect invariants; avoid leaking mutable internals.\n- Defensive copies: copy incoming mutable values and outgoing mutable state at trust boundaries.\n- Inheritance: prefer composition; if inheritable, document override hooks and self-use, or prohibit with `final` or private constructors.\n- Interfaces: define behavior contracts; avoid constant interfaces; use skeletal implementations only when they reduce repeated correct code.\n- Nested classes: make nested classes `static` unless they need the enclosing instance.\n\n## 4. Generics and Type Safety\n\n- Remove raw types and unchecked warnings at the source; do not suppress broad scopes.\n- Prefer generic methods and classes over casts at call sites.\n- Use bounded wildcards for flexibility: `? extends T` for producers, `? super T` for consumers.\n- Prefer lists to arrays for generic element types; arrays are covariant and reified, generics are invariant and erased.\n- Guard varargs with generics; use `@SafeVarargs` only when the method does not write into or expose the varargs array unsafely.\n- Prefer type-safe heterogeneous containers when a map needs keys of different value types.\n\n## 5. Enums and Annotations\n\n- Replace integer or string constants with enums when the value set is known.\n- Put behavior on enum constants when it removes switches scattered across the codebase.\n- Use `EnumSet` and `EnumMap` instead of bit fields or ordinal-indexed arrays.\n- Never persist or depend on enum ordinals; use stable names or explicit codes.\n- Use annotations instead of naming conventions for framework hooks, tests, validation, or code generation metadata.\n\n## 6. Lambdas and Streams\n\n- Prefer lambdas for small behavior blocks; prefer method references only when they are clearer than lambdas.\n- Keep stream pipelines side-effect-free, short, and readable.\n- Do not force streams onto logic with early returns, checked exceptions, mutation-heavy accumulation, or complex branching.\n- Use primitive streams to avoid boxing in numeric pipelines.\n- Avoid parallel streams unless the data source, operation cost, splitting behavior, and collector semantics are proven suitable.\n\n## 7. Methods and Defensive Programming\n\n- Validate public parameters near method entry; validate private method assumptions with assertions when useful.\n- Make method signatures explicit and small; avoid boolean parameters that hide modes when separate methods or enums are clearer.\n- Return empty collections or arrays for no results; avoid `null` multi-value returns.\n- Use `Optional` for optional return values judiciously; avoid fields, parameters, and collection elements of `Optional`.\n- Document units, ownership, mutation, thread-safety, and exceptional behavior.\n- Make defensive copies before validation when mutable inputs could be changed concurrently.\n\n## 8. Exceptions\n\n- Use exceptions for exceptional conditions, not normal loop or control flow.\n- Use checked exceptions only for recoverable conditions the caller can handle.\n- Preserve causes when translating exceptions.\n- Fail atomically where practical: a failed operation should leave objects unchanged.\n- Include useful failure-capture information in exception messages, without leaking secrets.\n- Do not ignore exceptions; if suppression is intentional, document why.\n\n## 9. Concurrency\n\n- Prefer immutable objects and thread confinement before locks.\n- Synchronize all access to shared mutable state, not just writes.\n- Use `ExecutorService`, `CompletableFuture`, concurrent collections, atomics, locks, and synchronizers instead of manually managing threads when possible.\n- Document thread-safety: immutable, thread-safe, conditionally thread-safe, not thread-safe, or thread-hostile.\n- Avoid calling overridable or foreign methods while holding locks.\n- Use lazy initialization only when needed; implement it with safe publication patterns.\n\n## 10. Serialization\n\n- Avoid Java native serialization for new APIs; prefer explicit formats.\n- If serialization is required, define serialized form deliberately and treat it as a public API.\n- Validate invariants during deserialization.\n- Use defensive copies for mutable serialized components.\n- Consider a serialization proxy for classes with invariants.\n- Be cautious with `readObject`, `readResolve`, and `serialVersionUID`; mistakes become compatibility or security issues.\n\n## Finding Template\n\n```text\n- [P1/P2/P3] Problem title (`File.java:line`): concrete impact.\n  Effective Java lens: principle or item range.\n  Fix: smallest safe change.\n  Compatibility: note if public API or serialized form changes.\n```\n\nFile v1.0.0:skill-card.md\n\n## Description:\n\nReview, refactor, and explain Java code using distilled Effective Java principles for API design, immutability, generics, enums, streams, exceptions, concurrency, and serialization.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[linbingqiang](https://clawhub.ai/user/linbingqiang)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineers use this skill to review, refactor, and explain Java code through an Effective Java lens, prioritizing correctness, API safety, encapsulation, type safety, concurrency, and maintainability.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Refactoring guidance may lead an agent to change Java source in ways that affect public API compatibility or behavior.\n\nMitigation: Review proposed patches and compatibility assumptions before applying them, especially for public APIs, concurrency guarantees, and serialization compatibility.\n\nRisk: Review recommendations may be incomplete when project context is missing.\n\nMitigation: Provide relevant source files, API contracts, tests, and thread-safety or serialization expectations so findings can be grounded in the codebase.\n\n## Reference(s):\n\n- [Effective Java Review Checklist](references/review-checklist.md)\n- [Effective Java Item Map](references/item-map.md)\n- [ClawHub Skill Page](https://clawhub.ai/linbingqiang/skills/effective-java)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Code, Guidance]\n\n**Output Format:** [Markdown with prioritized findings, explanations, and optional code patches or examples]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May include line-referenced review findings, compatibility assumptions, and validation notes.]\n\n## Skill Version(s):\n\n1.0.0 (source: server release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.","readmeExcerpt":"Skill: Effective Java Owner: linbingqiang Summary: Review, refactor, and explain Java code using distilled Effective Java principles for API design, immutability, generics, enums, streams, exceptions, concurr... Tags: latest:1.0.0 Version history: v1.0.0 | 2026-04-20T06:22:55.339Z | user Initial public release Archive index: Archive v1.0.0: 5 files, 9971 bytes Files: references/item-map.md (6534b), references/review-","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"- [P1] Title (`Path.java:line`): explain the concrete risk.\n  Effective Java lens: item family or principle.\n  Change: concise, actionable fix."},{"language":"text","snippet":"- [P1/P2/P3] Problem title (`File.java:line`): concrete impact.\n  Effective Java lens: principle or item range.\n  Fix: smallest safe change.\n  Compatibility: note if public API or serialized form changes."}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: effective_java\ndescription: Review, refactor, and explain Java code using distilled Effective Java principles for API design, immutability, generics, enums, streams, exceptions, concurrency, and serialization.\n---\n\n# Effective Java\n\n## Core Stance\n\nUse this skill as an Effective Java design and review lens, not as a rigid style guide. Prefer APIs that are simple, type-safe, immutable where practical, composition-friendly, well-documented at boundaries, and hard to misuse.\n\nDo not reproduce book text. Paraphrase the principles, explain tradeoffs, and cite item numbers only as navigation aids when helpful.\n\n## Workflow\n\n1. Classify the task: new API design, code review, refactor, bug fix, performance pass, or teaching/explanation.\n2. Load `references/review-checklist.md` for reviews, refactors, or whenever code is provided.\n3. Load `references/item-map.md` when the user asks for item-level mapping, broad Effective Java coverage, or a learning summary.\n4. Inspect the public contract first: construction, mutability, equality, generics, exceptions, threading, serialization, and compatibility.\n5. Prioritize recommendations by semantic risk before style: correctness, API safety, encapsulation, maintainability, then performance.\n6. If editing code, make the smallest change that preserves existing behavior and public compatibility unless the user explicitly asks for an API redesign.\n\n## Default Review Order\n\n- **Correctness**: broken invariants, resource leaks, equality/hash violations, unsafe publication, races, swallowed exceptions.\n- **API design**: confusing construction, boolean traps, excessive overloads, raw types, wildcard misuse, checked exceptions that are not recoverable.\n- **Encapsulation**: exposed mutable state, public fields, inheritance without contracts, mutable static state, missing defensive copies.\n- **Type safety**: unchecked casts, heap pollution, arrays mixed with generics, int constants where enums fit.\n- **Clarity**: stream/lambda overuse, unclear method references, unnecessary cleverness, duplicated construction logic.\n- **Performance**: avoid premature tuning; flag avoidable object churn, boxing, synchronization bottlenecks, and inappropriate parallel streams only after semantics are sound.\n\n## High-Value Heuristics\n\n- Prefer named static factories when names, caching, subtype returns, or instance control improve the API; keep constructors when the simple shape is clearer.\n- Use builders for constructors with many optional parameters; validate invariants in one place before object publication.\n- Prefer dependency injection over hard-coded singletons or static utilities for resources that vary or need testing.\n- Favor immutability, minimize visibility, and make defensive copies at trust boundaries.\n- Prefer composition over inheritance unless inheritance is deliberately designed, documented, and tested.\n- Eliminate raw types; use bounded wildcards with PECS: producers `extends`, consumers `super`.\n- Use enums instead of"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn78qwphcqsracs039f5avstah81s7r9\",\n  \"slug\": \"effective-java\",\n  \"version\": \"1.0.0\",\n  \"publishedAt\": 1776666175339\n}"},{"path":"references/item-map.md","content":"# Effective Java Item Map\n\nThis is a compact, paraphrased map of Effective Java, 3rd edition. Use it for item-level navigation and learning summaries; do not treat it as a substitute for the book.\n\n## Object Creation and Destruction\n\n1. Prefer static factories when naming, caching, subtyping, or instance control makes construction clearer.\n2. Use builders when constructors would require many optional or interdependent parameters.\n3. Enforce singleton properties carefully; enum singletons are often simplest.\n4. Prevent instantiation of utility classes with a private constructor.\n5. Prefer dependency injection to hard-coded resources.\n6. Avoid unnecessary objects, especially in hot paths.\n7. Remove obsolete references that prevent garbage collection.\n8. Avoid finalizers and cleaners for normal cleanup.\n9. Use try-with-resources for deterministic resource release.\n\n## Methods Common to All Objects\n\n10. Override `equals` only when logical equality is needed and can satisfy the full contract.\n11. Always override `hashCode` when overriding `equals`.\n12. Implement `toString` for useful diagnostics and logging.\n13. Prefer copying alternatives to `clone`; if cloning, respect its tricky contract.\n14. Implement `Comparable` only with a consistent, documented total ordering.\n\n## Classes and Interfaces\n\n15. Minimize accessibility of every type and member.\n16. Use accessors instead of public mutable fields.\n17. Minimize mutability; immutable objects are simpler and safer.\n18. Favor composition and forwarding over inheritance for reuse.\n19. Design and document inheritance deliberately, or prohibit it.\n20. Prefer interfaces to abstract classes for type definitions.\n21. Design interfaces carefully because default methods can create compatibility traps.\n22. Do not use interfaces only to export constants.\n23. Prefer class hierarchies to tagged classes with mode fields.\n24. Prefer static member classes over nonstatic ones when no enclosing instance is needed.\n25. Keep one top-level class per source file.\n\n## Generics\n\n26. Do not use raw types in new code.\n27. Eliminate unchecked warnings; suppress only tightly and with justification.\n28. Prefer lists to arrays when generics are involved.\n29. Favor generic types over casts at use sites.\n30. Favor generic methods for reusable type-safe operations.\n31. Use bounded wildcards to make APIs flexible.\n32. Combine generics and varargs carefully; avoid heap pollution.\n33. Use type tokens for type-safe heterogeneous containers.\n\n## Enums and Annotations\n\n34. Use enums instead of integer constants for fixed sets.\n35. Do not rely on enum ordinals for data or persistence.\n36. Use `EnumSet` instead of bit fields.\n37. Use `EnumMap` instead of ordinal indexing.\n38. Model extensible enum-like behavior with interfaces when needed.\n39. Prefer annotations to naming patterns.\n40. Consistently use `@Override`.\n41. Use marker interfaces when type relationships matter at compile time.\n\n## Lambdas and Streams\n\n42. Prefer lambdas to anonymous"},{"path":"references/review-checklist.md","content":"# Effective Java Review Checklist\n\nUse this checklist when reviewing or refactoring Java code. Start at the top and stop when you have enough high-value findings; avoid dumping every possible style preference.\n\n## 1. Construction and Lifecycle\n\n- Static factories: use when a name clarifies intent, instances are controlled or cached, return type can be an interface or subtype, or construction can hide complexity.\n- Constructors: keep when arguments are few, required, and obvious; avoid telescoping constructors with many optional values.\n- Builders: use for many optional parameters, cross-field validation, and readable call sites; keep the target object immutable when possible.\n- Dependency injection: inject clocks, random sources, clients, repositories, configuration, and strategies; avoid global statics for variable resources.\n- Resource cleanup: use try-with-resources for `AutoCloseable`; avoid finalizers and cleaners except as last-resort safety nets.\n- Object churn: reuse expensive immutable objects; avoid accidental boxing and regex recompilation in hot paths.\n\n## 2. Object Contracts\n\n- `equals`: check reflexive, symmetric, transitive, consistent, and non-null behavior; avoid equality across incompatible subclasses.\n- `hashCode`: update with every significant equality field; ensure equal objects have equal hashes.\n- `toString`: include useful state for diagnostics without exposing secrets or unstable implementation details.\n- `clone`: be skeptical; prefer copy constructors, static copy factories, or builders.\n- `Comparable`: ensure ordering is consistent, transitive, and documented when inconsistent with `equals`.\n\n## 3. Classes and Interfaces\n\n- Visibility: make classes, constructors, methods, fields, and nested types as private or package-private as possible.\n- Mutability: make fields `final` where practical; protect invariants; avoid leaking mutable internals.\n- Defensive copies: copy incoming mutable values and outgoing mutable state at trust boundaries.\n- Inheritance: prefer composition; if inheritable, document override hooks and self-use, or prohibit with `final` or private constructors.\n- Interfaces: define behavior contracts; avoid constant interfaces; use skeletal implementations only when they reduce repeated correct code.\n- Nested classes: make nested classes `static` unless they need the enclosing instance.\n\n## 4. Generics and Type Safety\n\n- Remove raw types and unchecked warnings at the source; do not suppress broad scopes.\n- Prefer generic methods and classes over casts at call sites.\n- Use bounded wildcards for flexibility: `? extends T` for producers, `? super T` for consumers.\n- Prefer lists to arrays for generic element types; arrays are covariant and reified, generics are invariant and erased.\n- Guard varargs with generics; use `@SafeVarargs` only when the method does not write into or expose the varargs array unsafely.\n- Prefer type-safe heterogeneous containers when a map needs keys of different value types.\n\n## 5. Enums"},{"path":"skill-card.md","content":"## Description:\n\nReview, refactor, and explain Java code using distilled Effective Java principles for API design, immutability, generics, enums, streams, exceptions, concurrency, and serialization.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[linbingqiang](https://clawhub.ai/user/linbingqiang)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineers use this skill to review, refactor, and explain Java code through an Effective Java lens, prioritizing correctness, API safety, encapsulation, type safety, concurrency, and maintainability.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Refactoring guidance may lead an agent to change Java source in ways that affect public API compatibility or behavior.\n\nMitigation: Review proposed patches and compatibility assumptions before applying them, especially for public APIs, concurrency guarantees, and serialization compatibility.\n\nRisk: Review recommendations may be incomplete when project context is missing.\n\nMitigation: Provide relevant source files, API contracts, tests, and thread-safety or serialization expectations so findings can be grounded in the codebase.\n\n## Reference(s):\n\n- [Effective Java Review Checklist](references/review-checklist.md)\n- [Effective Java Item Map](references/item-map.md)\n- [ClawHub Skill Page](https://clawhub.ai/linbingqiang/skills/effective-java)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Code, Guidance]\n\n**Output Format:** [Markdown with prioritized findings, explanations, and optional code patches or examples]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May include line-referenced review findings, compatibility assumptions, and validation notes.]\n\n## Skill Version(s):\n\n1.0.0 (source: server release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Review, refactor, and explain Java code using distilled Effective Java principles for API design, immutability, generics, enums, streams, exceptions, concurr... Skill: Effective Java Owner: linbingqiang Summary: Review, refactor, and explain Java code using distilled Effective Java principles for API design, immutability, generics, enums, streams, exceptions, concurr... Tags: latest:1.0.0 Version history: v1.0.0 | 2026-04-20T06:22:55.339Z | user Initial public release Archive index: Archive v1.0.0: 5 files, 9971 bytes Files: references/item-map.md (6534b), references/review-","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1835,"uniquenessScore":49,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T12:07:23.995Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T12:07:23.995Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T15:12:50.609Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}