Code Review Checklist for Java

Standard Operating Procedure: Code Review Checklist for Java

1. Document Control & Revision History

---

2. Executive Summary & Scope

2.1 Clinical Statement of Operational Boundaries

This Standard Operating Procedure (SOP) defines the mandatory, deterministic criteria for performing code reviews on enterprise Java applications. The boundaries of this SOP encompass all source code, configuration artifacts, and migration scripts targeting Java Runtime Environments (JRE) 17 LTS and 21 LTS. Adherence to this procedure is non-negotiable for all merge requests (MR) and pull requests (PR) entering production-bound branches (main, release/*).

2.2 Regulatory & Compliance Standards

Executions under this SOP ensure compliance with:

• ISO/IEC 25010: Systems and software Quality Requirements and Evaluation (SQuaRE) for maintainability, reliability, and security.
• OWASP Top 10: Mitigation of injection flaws, broken authentication, and insecure deserialization.
• PCI-DSS v4.0: Cryptographic protection of cardholder data in transit and at rest within enterprise persistence layers.

---

3. Prerequisites & Tool Requirements

Prior to initiating or reviewing any Java pull request, the reviewer and author must ensure the local and CI/CD environments are provisioned with the following toolsets and access credentials:

• Runtime Environment: Eclipse Temurin OpenJDK 17 LTS or 21 LTS configured via toolchain managers.
• Build & Dependency Management: Apache Maven 3.9+ or Gradle 8.5+ with dependency locking enabled.
• Static Application Security Testing (SAST): SonarQube Enterprise Edition / SonarLint configured with the "Sonar way" profile.
• Security Vulnerability Scanners: OWASP Dependency-Check or Snyk CLI integrated into the pipeline.
• Integrated Development Environment (IDE): IntelliJ IDEA Ultimate with plugins: Checkstyle-IDEA, SpotBugs, and SonarLint.
• Access Credentials: Read/Write access to Enterprise Git repository, artifactory (Nexus/Artifactory), and SonarQube dashboard.

---

4. Roles & Responsibilities (RACI Matrix Table)

Legend: Responsible, Accountable, Consulted, Informed.

---

5. Step-by-Step Operational Procedure

Execute the following sequential phases. Every single item containing the Markdown checkbox syntax - [ ] must be verified and checked before merge approval is granted.

Phase 1: Pre-Review Automated Gate Verification

• Verify that all CI/CD build pipelines (Maven/Gradle compile, unit tests, integration tests) pass without warnings or errors.
• Confirm that SonarQube Quality Gate returns a PASSED status with 0 New Blockers, 0 New Criticals, and $\ge$ 80% Unit Test Coverage on modified lines.
• Confirm that OWASP Dependency-Check or Snyk reports zero High or Critical CVE vulnerabilities in transitive or direct dependencies.

Phase 2: Architectural & Design Pattern Compliance

• Verify adherence to layered architecture boundaries (Controller $\rightarrow$ Service $\rightarrow$ Repository); ensure no direct database access occurs within the presentation layer.
• Ensure proper usage of Dependency Injection (DI) via constructor injection (private final fields); strictly prohibit field injection (@Autowired on fields).
• Validate that domain models are decoupled from persistence entities (DTO pattern implemented where applicable) to prevent entity leakage.
• Verify that new interfaces or classes have single responsibilities and do not violate SOLID design principles.

Phase 3: Concurrency, Multithreading & Virtual Threads (JDK 21+)

• Ensure standard platform threads are not blocked on I/O operations where Virtual Threads (Executors.newVirtualThreadPerTaskExecutor()) should be utilized.
• Verify that shared mutable state across threads is protected using appropriate synchronization mechanisms (java.util.concurrent.locks, atomic variables, or thread-safe collections) to eliminate race conditions.
• Confirm that ThreadLocal instances are explicitly cleared via .remove() within a try-finally block to prevent memory leaks in thread-pooled execution models.

Phase 4: Exception Handling & Logging Hygiene

• Verify that checked and unchecked exceptions are handled at the appropriate architectural boundary; catch blocks must not swallow exceptions silently (no empty catch blocks).
• Ensure standard custom domain exceptions extend RuntimeException and carry meaningful, structured error codes.
• Validate logging statements: Ensure no sensitive data (PII, passwords, tokens, API keys) is logged at any level (DEBUG, INFO, ERROR).
• Verify that exception stack traces are logged entirely (log.error("Context message", ex)) rather than concatenating the exception message to strings.

Phase 5: Resource Management & Memory Optimization

• Verify that all resources implementing AutoCloseable or Closeable (JDBC connections, file streams, sockets) are managed using Java try-with-resources blocks.
• Check for potential memory leaks, specifically unclosed Hibernate/JPA sessions, stagnant caches, or unmanaged event listener registrations.
• Ensure excessive object allocation within high-throughput loops is minimized (e.g., using StringBuilder instead of string concatenation within loops).

Phase 6: Security, Cryptography & Input Validation

• Verify that all external inputs (HTTP parameters, request bodies, headers) are explicitly validated using Bean Validation (javax.validation / jakarta.validation) annotations.
• Confirm that SQL queries utilize parameterized statements, criteria builders, or ORM frameworks to completely prevent SQL injection vectors.
• Verify that cryptographic operations utilize approved algorithms (AES-256 for symmetric encryption, SHA-256/SHA-3 for hashing; no MD5 or SHA-1).
• Ensure proper output encoding or sanitization is applied if rendering user-supplied content to prevent Cross-Site Scripting (XSS).

Phase 7: Unit & Integration Testing Rigor

• Verify that all business logic branches, boundary conditions, and edge cases are covered by JUnit 5 unit tests.
• Ensure mocks (Mockito) are used judiciously to isolate units of work without masking integration defects.
• Verify that integration tests utilize containerized dependencies (Testcontainers) rather than relying on shared local infrastructure.

---

6. Quality Assurance & Verification Criteria

To achieve merge authorization, the code review must meet the following deterministic thresholds:

• Defect Density Tolerance: 0 Critical or High severity defects remaining unresolved.
• Test Coverage Benchmark: Minimum 80% line coverage and 75% branch coverage on newly introduced or modified production code paths.
• Checkstyle Violations: Zero violations against the enterprise Checkstyle configuration profile.
• Approval Sign-Off: Minimum of two (2) explicit approvals: one from a designated Peer Reviewer and one from the Tech Lead (for architectural changes).

---

7. Practical Troubleshooting Scenarios

Scenario A: Uncaught Resource Leak Detected in Production-Bound Code

• Symptom: A code review reveals a database connection or file input stream managed via manual try-catch-finally blocks where the .close() method is invoked outside of the finally block or lacks null-safety checks.
• Immediate Corrective Action Protocol:
  1. Reject the pull request with status CHANGES_REQUESTED.
  2. Instruct the author to refactor the resource management block to use the try-with-resources construct (try (ResourceType r = new ResourceType()) { ... }).
  3. Re-run static analysis to confirm leak elimination via SpotBugs/SonarQube.

Scenario B: High-Throughput Service Layer Utilizing Blocking I/O on Platform Threads

• Symptom: The author implements a blocking HTTP client call or synchronous database query inside a high-concurrency request processing loop using standard thread pools, risking thread starvation.
• Immediate Corrective Action Protocol:
  1. Block the merge request referencing concurrency rule SOP-SEC-03.
  2. Require the author to migrate the execution context to asynchronous non-blocking paradigms (e.g., Spring WebFlux / reactive types) or leverage JDK 21 Virtual Threads where blocking operations are unavoidable.
  3. Require a load test verification report demonstrating thread stability under target concurrency limits prior to re-submission.