Code Review Checklist Java

Standard Operating Procedure: Enterprise Java Code Review & Quality Gate Validation

Document Identifier: SOP-ENG-OPS-409
Classification: Internal Enterprise Standard

---

1. Document Control & Revision History

---

2. Executive Summary & Scope

2.1 Purpose

This Standard Operating Procedure (SOP) defines the mandatory operational constraints, verification protocols, and governance standards for conducting Java code reviews within enterprise production environments. The objective is to eliminate systemic defects, prevent security vulnerabilities, enforce architectural consistency, and maintain zero-tolerance standards for technical debt accumulation.

2.2 Operational Boundaries & Regulatory Standards

This protocol applies to all Java-based microservices, monolithic applications, libraries, and infrastructural components developed or maintained by internal engineering teams and external contractors. All reviews must adhere to:

• ISO/IEC 25010: Software product quality models (maintainability, reliability, security).
• OWASP Top 10: Application security verification standards.
• PCI-DSS / HIPAA / SOC 2 Type II: Data handling, encryption-at-rest, and logging compliance where applicable to the target system.

---

3. Prerequisites & Tool Requirements

Engineers performing code reviews must possess the following clearances, tools, and environmental access before initiating an audit:

• Certifications & Training:
  • Completion of Enterprise Secure Coding (Java) Level 2 Certification.
  • Mandatory designation as an authorized Reviewer within the Source Code Management (SCM) platform.
• Software & Tooling Access:
  • IDE/Environment: IntelliJ IDEA Ultimate Edition (or Eclipse Enterprise) configured with corporate checkstyle profiles.
  • Static Application Security Testing (SAST): Veracode, SonarQube Enterprise Edition, or Checkmarx access.
  • SCM Platform: GitHub Enterprise, GitLab Ultimate, or Bitbucket Data Center with branch protection rules enforced.
  • Build & Dependency Management: Apache Maven (3.9+) or Gradle (8.x+), integrated with OWASP Dependency-Check plugins.
• Hardware: Corporate-issued secure workstation equipped with hardware-backed TPM 2.0 and active endpoint detection and response (EDR) agents.

---

4. Roles & Responsibilities (RACI Matrix Table)

---

5. Step-by-Step Operational Procedure

Phase 1: Automated Gate Verification (Pre-Review Audit)

• Verify that all continuous integration (CI) pipelines have executed successfully on the target pull request (PR).
• Confirm that SonarQube quality gates pass with zero new Critical or Blocker smells, and zero drop in overall code coverage below the 85% threshold.
• Validate that the OWASP Dependency-Check scan reports zero unmitigated High or Critical vulnerabilities in third-party libraries.
• Ensure static analysis tools (Checkstyle, SpotBugs) report zero rule violations against the corporate baseline configuration.

Phase 2: Architectural & Design Alignment Check

• Verify that changes adhere strictly to the target architectural pattern (e.g., Domain-Driven Design, Hexagonal Architecture) without breaking layer boundaries (e.g., Presentation layer calling Database directly).
• Confirm that new dependencies introduced are approved via the Enterprise Architecture Review Board (ARB) and do not duplicate existing utility functions.
• Inspect package naming conventions, module boundaries, and ensure proper encapsulation using Java access modifiers (public, protected, private, package-private).

Phase 3: Core Java & Concurrency Inspection

• Null Safety: Verify extensive use of Optional<T> for return types where absence of value is expected, and confirm defensive null checks or @NotNull/@Nullable annotations are utilized.
• Exception Handling: Ensure checked exceptions are handled or bubbled up correctly; verify that generic catches (catch (Exception e)) are avoided in favor of specific exceptions, and that stack traces are never swallowed without logging or wrapping.
• Concurrency & Thread Safety: Validate that shared mutable state is protected via synchronized blocks, java.util.concurrent primitives, or immutable object design patterns. When using Java 21 Virtual Threads (Thread.ofVirtual()), ensure synchronization mechanisms do not rely on thread-local pinning or blocking native monitors improperly.
• Resource Management: Confirm that I/O streams, JDBC connections, sockets, and native resources are managed via try-with-resources blocks (AutoCloseable) to prevent resource leaks.

Phase 4: Security & Data Sanitization Audit

• Injection Prevention: Verify that all SQL operations utilize parameterized queries or safe JPA/Hibernate Criteria APIs; confirm zero string concatenation within query statements.
• Data Sanitization: Check that all untrusted inputs crossing system boundaries are validated against strict allow-lists and sanitized prior to processing or rendering.
• Cryptographic Standards: Ensure deprecated algorithms (MD5, SHA-1, DES) are absent; verify that AES-256 or stronger encryption is applied to sensitive fields, and passwords leverage robust hashing schemes (Argon2id or bcrypt).
• Information Exposure: Confirm that production logging statements do not emit Personally Identifiable Information (PII), Protected Health Information (PHI), credentials, or raw stack traces to external client outputs.

Phase 5: Performance, Memory & Scalability Verification

• Memory Footprint: Inspect object creation patterns inside high-throughput loops to minimize garbage collection (GC) pressure (e.g., avoiding excessive string concatenation via + within loops; using StringBuilder).
• Collections & Algorithms: Verify that appropriate data structures are selected based on time/space complexity (e.g., ConcurrentHashMap vs. HashMap, explicit initial capacities for collections to prevent rehashing overhead).
• Database Performance: Ensure JPA/Hibernate queries do not introduce N+1 select anomalies; confirm @BatchSize or explicit JOIN FETCH directives are applied where fetching associations.

Phase 6: Test Coverage & Verification Integrity

• Verify that unit tests (JUnit 5, Mockito) cover new business logic pathways, edge conditions, and null/exception scenarios.
• Confirm that integration tests validate end-to-end functionality using containerized dependencies via Testcontainers where database or message broker interactions occur.
• Ensure test assertions are rigorous, asserting specific state changes rather than merely verifying code execution.

---

6. Quality Assurance & Verification Criteria

To secure final approval and merge permission into the main integration branch, the code review must meet the following hard gates:

• Tolerance Thresholds:
  • Code Smells: 0 Critical, 0 Major (Minor smells must be resolved or documented with an approved ticket).
  • Test Coverage: Minimum 85% line coverage and 80% branch coverage on newly introduced or modified code lines.
  • Security Vulnerabilities: Zero open SAST or dependency vulnerabilities.
• Sign-off Requirements:
  • Minimum of two (2) explicit approvals from authorized Senior/Principal Engineers.
  • Explicit sign-off from SecOps if the change touches authentication, authorization, cryptography, or external boundary integrations.
  • Resolution of all inline review comment threads.

---

7. Practical Troubleshooting Scenarios

Scenario A: The N+1 Query Performance Degradation

• Symptom: SonarQube or manual audit identifies an unoptimized collection iteration issuing repeated single queries inside an ORM loop, causing performance degradation under load.
• Immediate Corrective Action Protocol:
  1. Block PR merge immediately by requesting changes in the SCM platform.
  2. Direct the author to refactor the JPA repository query to use a JOIN FETCH query annotation or apply @EntityGraph to fetch child entities in a single batch statement.
  3. Require the author to attach a local execution plan or performance test log demonstrating query count reduction from $N+1$ to $1$.

Scenario B: Unsafe Deserialization Vulnerability Detected

• Symptom: Security scanner flags usage of native Java serialization (ObjectInputStream) or unconstrained Jackson/Gson object mapping utilizing polymorphic type typing (enableDefaultTyping).
• Immediate Corrective Action Protocol:
  1. Reject the pull request with a Security Block tag.
  2. Mandate the removal of native Java deserialization or insecure polymorphic type configurations.
  3. Require replacement with a safe data interchange format (e.g., standard DTO mapping via MapStruct) or explicit, whitelisted JSON deserialization bounds.
  4. Require a secondary security review sign-off before re-submitting the PR for approval.