how to review a Java pull request with an AI agent

Have Atlas produce the diff with the bash tool, then read each changed .java file in full rather than the hunks. Atlas runs the lsp tool's findReferences on every changed method signature to catch callers the diff never touched, runs JUnit 5 via mvn test, and reports a todowrite list ordered by severity.

why read the whole Java file instead of just the diff hunks

A Java diff hides everything it did not touch: field initialization order, class annotations, the interface being implemented, and the sibling methods a change should have matched. Atlas reads the changed classes in full with the read tool so each hunk is judged against its actual surroundings.

how do I find callers broken by a changed method signature in Java

Run the lsp tool's findReferences operation on the changed method. Atlas uses it during pull request review to enumerate callers across every Maven module, including the ones the diff never touched, which is where a widened return type or a new parameter quietly breaks a consumer.

does Atlas run mvn test when reviewing a pull request

Yes. Atlas runs JUnit 5 via mvn test through the bash tool against the pull request branch. Where the output is large, the bash tool retains the full log and reports the file path, so triage happens against the whole output rather than a truncated tail.

can Atlas review a large Java pull request across multiple Maven modules

Yes. Atlas fans out work to subagents that can run in the foreground or in parallel background sessions, so a pull request spanning several Maven modules is reviewed module by module. The findings merge into one todowrite list ordered by severity.

will Atlas change my code during a Java code review

Not without approval. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, and Atlas computes a unified diff for every file edit and surfaces it for approval before writing. A review can be run entirely as reads, greps, and mvn test invocations.

what should a Java code review grep for

Grep for what the change should have updated but did not: the old constant name that survives in another package, the class that was copy-pasted and not fixed, the feature flag readers, and hard-coded strings that duplicate a renamed enum value. Atlas runs these greps as a standard review pass.

atlas Java project setup

Run atlas in a project with a pom.xml or build.gradle. Atlas reads your packages, classpath, and build configuration, and can add JUnit tests or refactor a class hierarchy, with the diff reviewed first. Tests run as JUnit 5 via mvn test and formatting through Spotless.

Review a Pull Request in Java with Atlas (2026)

Atlas reviews a Java pull request the way a careful human does: it gets the diff, then leaves the diff. The bash tool produces the changed files and the raw patch through Atlas's VCS layer, the read tool pulls each changed .java file in full rather than the hunks, and the lsp tool's findReferences operation checks whether a changed method signature broke a caller the diff never shows. Findings come back as a todowrite list ordered by severity, after JUnit 5 via mvn test has actually been run.

How does Atlas review a Java pull request?

Atlas fetches the branch and produces the diff with the bash tool. Atlas's VCS layer exposes status, diff, diffRaw, and commits over the same git data, so a 40 file Java pull request arrives as a real patch rather than a summary. Atlas then reads the changed classes in full.

The reason Atlas leaves the diff immediately is that a Java diff hides most of what a reviewer needs. A hunk showing three changed lines inside OrderService.java says nothing about the class's field initialization order, the interface it implements, or the Spring annotations above it. Atlas reads the whole file with the read tool, so the changed method is evaluated against its actual surroundings. Atlas indexes code by AST declarations using tree-sitter, not blind line windows, and searches with hybrid semantic and keyword retrieval fused by reciprocal rank fusion, so pulling in the related classes across src/main/java is a query rather than a manual hunt through the package tree.

How does Atlas catch a Java caller the pull request diff never touched?

For every changed method signature in a Java pull request, Atlas runs the lsp tool's findReferences operation to check the callers the diff never touched. 3 changes break callers silently: a method that gained a parameter, a return type moved from List to Optional, and a narrowed checked exception, each of which can live in a Maven module the PR does not include.

Java's compiler catches many of these at build time, but not all, and not before review. A default parameter added by an overload, a widened Object return type, an interface method whose new default implementation silently changes behavior for existing implementors: these compile fine and break at runtime. Atlas asks the language server directly. findReferences on the changed method returns the callers across every Maven module in the reactor build, and Atlas reads each one to judge whether the new contract still holds. That is the check that separates a real Java review from a line-by-line read of the patch.

What should Atlas grep for during a Java code review?

Atlas greps for the patterns a Java change should have updated but did not: old constant names, stale copies of a copied class, feature flags left enabled, and hard-coded strings that duplicate a renamed enum value. A pull request that renames a constant in one package and leaves 4 references elsewhere is a common Java review miss.

Grep in an Atlas Java review is targeted, not exploratory. If the pull request introduces a new constant in a Constants class, Atlas greps for the old literal to find where it survives. If it adds a null check to one branch, Atlas greps for the sibling branches that were copy-pasted from it. If it touches a feature flag, Atlas greps for every reader of that flag across src/main/java and src/test/java. Atlas surfaces these as findings, not edits: every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, and Atlas computes a unified diff for any file edit and surfaces it for approval before writing.

How does Atlas verify a Java pull request actually passes?

Atlas runs the tests with the bash tool. In a Maven project that means JUnit 5 via mvn test against the pull request branch, plus Spotless to confirm the diff is format-clean. A review that never ran mvn test is an opinion about code, not a verification of it.

Run atlas in a project with a pom.xml or build.gradle. Atlas reads your packages, classpath, and build configuration, so it drives the real build rather than a guessed command. JUnit 5 via mvn test is the substantive check: it proves the changed classes behave. Spotless is the cheap check: it proves the contributor did not leave the diff full of formatting noise that will obscure the next review. Where mvn test output is large, the Atlas bash tool retains the full log and reports the path, so triage happens against the whole output. Atlas reports its findings as a todowrite list ordered by severity, so the pull request author gets a prioritized list rather than a wall of comments.

Why does Atlas order Java review findings by severity?

Atlas reports pull request findings as a todowrite list ordered by severity, so a NullPointerException risk in OrderService.java ranks above a naming nit in a test. A Java review that lists 20 items in file order buries the 2 that actually block the merge.

Severity ordering is what makes an Atlas review actionable. The top of the todowrite list is where a broken caller found by the lsp tool's findReferences goes, or a JUnit 5 test that fails under mvn test. Below that come the correctness risks that are real but conditional. At the bottom sit the style points that Spotless would fix mechanically anyway. Atlas fans out work to subagents that can run in the foreground or in parallel background sessions, so a large Java pull request touching several Maven modules can be reviewed module by module without any single session drowning in file content. The merged output is still one prioritized list.

Step by step

01Run atlas in a Java project with a pom.xml or build.gradle so Atlas can read your packages, classpath, and build configuration.
02Fetch the branch and produce the diff with the bash tool; Atlas's VCS layer exposes status, diff, diffRaw, and commits over the same git data.
03Read each changed .java file in full with the read tool, not just the hunks, so context outside the diff such as field initialization and annotations is visible.
04For every changed method signature, run the lsp tool's findReferences operation to check callers across the Maven modules the diff never touched.
05Grep for the patterns the change should have updated but did not: old constant names, stale copied classes, and feature flags.
06Run JUnit 5 via mvn test with the bash tool against the pull request branch and read the failures.
07Run Spotless to confirm the diff is format-clean and not carrying unrelated whitespace churn.
08Report findings as a todowrite list ordered by severity, with broken callers and failing JUnit 5 tests at the top.

Frequently asked questions

how to review a Java pull request with an AI agent: Have Atlas produce the diff with the bash tool, then read each changed .java file in full rather than the hunks. Atlas runs the lsp tool's findReferences on every changed method signature to catch callers the diff never touched, runs JUnit 5 via mvn test, and reports a todowrite list ordered by severity.
why read the whole Java file instead of just the diff hunks: A Java diff hides everything it did not touch: field initialization order, class annotations, the interface being implemented, and the sibling methods a change should have matched. Atlas reads the changed classes in full with the read tool so each hunk is judged against its actual surroundings.
how do I find callers broken by a changed method signature in Java: Run the lsp tool's findReferences operation on the changed method. Atlas uses it during pull request review to enumerate callers across every Maven module, including the ones the diff never touched, which is where a widened return type or a new parameter quietly breaks a consumer.
does Atlas run mvn test when reviewing a pull request: Yes. Atlas runs JUnit 5 via mvn test through the bash tool against the pull request branch. Where the output is large, the bash tool retains the full log and reports the file path, so triage happens against the whole output rather than a truncated tail.
can Atlas review a large Java pull request across multiple Maven modules: Yes. Atlas fans out work to subagents that can run in the foreground or in parallel background sessions, so a pull request spanning several Maven modules is reviewed module by module. The findings merge into one todowrite list ordered by severity.
will Atlas change my code during a Java code review: Not without approval. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, and Atlas computes a unified diff for every file edit and surfaces it for approval before writing. A review can be run entirely as reads, greps, and mvn test invocations.
what should a Java code review grep for: Grep for what the change should have updated but did not: the old constant name that survives in another package, the class that was copy-pasted and not fixed, the feature flag readers, and hard-coded strings that duplicate a renamed enum value. Atlas runs these greps as a standard review pass.
atlas Java project setup: Run atlas in a project with a pom.xml or build.gradle. Atlas reads your packages, classpath, and build configuration, and can add JUnit tests or refactor a class hierarchy, with the diff reviewed first. Tests run as JUnit 5 via mvn test and formatting through Spotless.

Try Atlas in your terminal

The terminal-native AI coding agent. Free core, single binary.

Install Atlas

Related guides

Review a Pull Request with Atlas (2026 Workflow)

How to review a pull request with Atlas in 2026: bash produces the raw patch, read pulls whole files, the lsp tool's findReferences checks callers the diff never shows.

Atlas for Java in 2026

Adopt Atlas, the terminal-native AI coding agent, for Java development in 2026. Enhance your workflow with intelligent code search, refactoring, and robust safety features for Maven and Gradle projects.

Self-Review Your Working Diff Before Committing in Java with Atlas (2026)

Self-review an uncommitted Java diff with Atlas in 2026. Read every changed class, grep for debug leftovers, revert from snapshots, then run JUnit 5 via mvn test.

Refactor a Legacy Java Module with Atlas (2026)

Refactor a legacy Java module with Atlas in 2026. Enumerate callers with lsp findReferences, restructure with apply_patch, and prove behavior with JUnit 5 via mvn test.

Onboard to an Unfamiliar Java Codebase with Atlas (2026)

Atlas maps an unfamiliar Java repo by meaning, not filenames: codebase_search ranks declarations, glob reveals the Maven module layout, and a read-only explore subagent fans out.

Audit a Repo With Parallel Subagents in Java Using Atlas (2026)

Sweep a large Java repo in 2026 without blowing your context window. Atlas launches explore subagents per Maven module, merges findings, and verifies with mvn test.

Diagnose a hanging or long-running command in Java with Atlas (2026)

Diagnose a hanging Maven or Java command in 2026 with Atlas: read the shell_metadata block, tell slow apart from blocked on stdin, and re-run non-interactively.

Upgrade a Java Dependency and Fix Breakage with Atlas in 2026

In 2026, Java developers use Atlas to upgrade Maven dependencies and resolve compile and test failures. Learn how Atlas automates the process, from pom.xml updates to JUnit 5 fixes.

Browse this resource hub