Java Code Review

Review Java source code systematically for correctness, security, performance, and maintainability.

Input Handling

Determine the input type and gather code accordingly:

1. Direct code -- Code provided in the conversation. Review as-is.
2. File path(s) -- Read the specified .java files.
3. Directory path -- Find all .java files recursively. For large codebases (>50 files), ask the user which packages or files to focus on.
4. Diff/patch content -- Review only the changed lines plus sufficient surrounding context. Focus findings on the changed code.

Review Process

Execute these phases in order. For each finding, assign a severity.

Phase 1: Correctness and Bug Detection

Examine code for:

• Null safety -- Nullable parameters without checks, Optional misuse, potential NullPointerException paths
• Resource leaks -- Unclosed streams, connections, or locks. Verify try-with-resources usage for all AutoCloseable types
• Error handling -- Empty catch blocks, catching overly broad exceptions (Exception, Throwable), swallowed exceptions, missing finally blocks
• Concurrency -- Race conditions, unsynchronized shared mutable state, incorrect use of volatile, double-checked locking without volatile, ConcurrentModificationException risks
• Logic errors -- Off-by-one, incorrect operator precedence, unreachable code, broken equals/hashCode contracts
• API misuse -- Incorrect use of Collections, Streams, Date/Time API, String comparison with == instead of .equals()

Phase 2: Security Review

Read references/security-checklist.md before this phase.

Check for:

• Injection -- SQL injection (string concatenation in queries), command injection, LDAP injection, XPath injection, log injection
• Authentication and authorization -- Hardcoded credentials, missing access checks, insecure token handling
• Data exposure -- Sensitive data in logs, exceptions, or error messages. Unmasked PII
• Cryptography -- Weak algorithms (MD5, SHA-1 for security), hardcoded keys, insecure random (Math.random for security purposes)
• Deserialization -- Untrusted ObjectInputStream usage, missing type validation
• Input validation -- Missing or insufficient validation of external input, path traversal risks

Phase 3: Performance Analysis

Read references/performance-patterns.md before this phase.

Check for:

• Algorithmic complexity -- O(n^2) or worse in hot paths, unnecessary nested iterations
• Memory -- Excessive object creation in loops, large collections held longer than needed, missing initial capacity for known-size collections
• String handling -- String concatenation in loops (use StringBuilder), unnecessary String.format in hot paths
• I/O -- Unbuffered streams, N+1 query patterns, missing connection pooling, synchronous I/O where async is appropriate
• Collections -- Wrong collection type for the access pattern, unnecessary copying, missing pre-sizing
• JVM considerations -- Excessive autoboxing, finalizer usage, classloader leaks

Phase 4: Code Quality and Maintainability

Check for:

• Design -- God classes, excessive coupling, Liskov substitution violations, missing encapsulation
• Naming -- Unclear variable/method names, naming convention violations (Java conventions: camelCase methods, PascalCase classes, UPPER_SNAKE constants)
• Complexity -- Methods exceeding ~30 lines, cyclomatic complexity >10, deeply nested conditionals (>3 levels)
• Duplication -- Repeated logic that should be extracted
• Documentation -- Missing Javadoc on public API, outdated comments that contradict code
• Testing gaps -- Untested public methods, missing edge case tests, no assertions in test methods, test methods that cannot fail
• AI-generated code smells -- Hallucinated or non-existent API calls, overly verbose boilerplate that could use standard library methods, unnecessary wrapper classes or abstractions that add indirection without value, generic variable names (data, result, temp, info) that obscure intent, contradictory or parroted comments that restate the code without adding insight, TODO/FIXME/placeholder blocks left unimplemented, inconsistent patterns within the same file (e.g., mixing builder and constructor styles, mixing streams and loops for identical tasks), dead code or unreachable branches that suggest generation artifacts

Phase 5: Dependency and License Review

If build files are available (pom.xml, build.gradle, build.gradle.kts), or if import statements reference third-party libraries, check for:

• License compatibility -- Copyleft licenses (GPL, AGPL, LGPL) in proprietary or permissively licensed projects. Flag any dependency whose license is incompatible with the project's declared license
• License presence -- Dependencies with no discernible license (treat as all-rights-reserved). Unlicensed code cannot be safely used
• Copyleft obligations -- LGPL dependencies linked statically (must be dynamic), GPL dependencies in non-GPL projects, AGPL dependencies in network services without source disclosure
• Transitive risk -- A permissively licensed library that itself depends on a copyleft library. The copyleft obligation propagates
• Deprecated or unmaintained libraries -- Dependencies with known end-of-life status, no updates in 2+ years, or archived repositories
• Duplicate functionality -- Multiple libraries solving the same problem (e.g., both Guava and Apache Commons for the same utilities), increasing attack surface and license exposure unnecessarily

Severity Levels

Assign one severity to each finding:

Output Format

Structure the review as follows:

Summary

Provide a 2-3 sentence overview: what the code does, overall quality assessment, and the most important finding.

Findings

List each finding with this structure:

[S{n}] {Category}: {Brief title}

• Location: File and line number (or method name if line unknown)
• Issue: What is wrong and why it matters
• Suggestion: Concrete fix, with a code snippet when helpful

Order findings by severity (S1 first), then by location within each severity.

Positive Observations

Note 1-3 things the code does well. Good patterns, clean design, or thorough error handling deserve acknowledgment.

Summary Table

End with a count table:

Guidelines

• Be specific. Reference exact line numbers, method names, and variable names.
• Provide concrete fix suggestions, not vague advice.
• When suggesting a fix, show a brief code snippet demonstrating the improvement.
• Do not flag style preferences that have no correctness or readability impact (e.g., brace placement style) unless the code mixes styles inconsistently.
• For diffs, focus review on changed lines. Only flag pre-existing issues if they interact with the changes.
• If the code is too large for a single review, divide it into logical sections and review each, providing a consolidated summary.
• When uncertain about intent, state the assumption explicitly rather than making a silent judgment.