AI Java PR Reviewer

Stop broken Java pull requests before they hit `main`.

prmerger reviews Java pull requests with real Maven or Gradle build context, checks that unit tests stay green, and comments on bug risk so teams merge with fewer regressions.

View review flow Read the docs
Build tools
Maven + Gradle
Review mode
GitHub-native
Merge verdict
Blocked until green

PR Review Snapshot

`payments-service` PR #184

Merge blocked

Build status

Compile passed `./gradlew test` failed

`OrderMapperTest` is failing after the new null-handling branch introduced in `OrderService`.

Review focus

  • Missing assertion for the empty-cart edge case in the new mapper path.
  • Refund workflow now swallows the domain exception before transaction rollback.
  • Controller response changed shape without corresponding contract coverage.
prmerger review --repo payments-service --pr 184

> gradle command: ./gradlew test
> result: FAILED in module :payments-core
> failing tests: 3
> review verdict: block merge

Comment posted:
"The new null guard changes refund behavior but the PR does not keep
coverage for the empty-cart path. Fix the failing tests and validate the
rollback behavior before merge."
Why Teams Use It

The reviewer is useful because it respects the build system you already own.

prmerger is not another generic chat bot pasted into your repo. It is tuned for Java pull requests where the merge decision should depend on real build state, passing unit tests, and targeted bug-prevention feedback.

CI gate

Build-aware merge blocking

prmerger runs the Maven or Gradle command your team already trusts and blocks the pull request when it goes red.

JUnit

Unit test truth, not guesses

The review status stays red until the existing unit suite passes again, so no one merges through a broken build by accident.

Risk review

Bug-focused review comments

Comments focus on risky branches, null handling, API contract drift, and missing failure-path validation instead of cosmetic style notes.

Code graph

Java context across modules

Changed services, repositories, controllers, DTOs, and affected tests are all considered before a verdict is posted.

Workflow

Four steps from pull request creation to a safe merge.

Step 01

Connect the repository

Choose the Java repositories you want protected and define the Maven or Gradle command that represents a clean pull request.

Step 02

Run checks on every PR

Each pull request triggers the configured build and test workflow, so the review starts from real execution state instead of static assumptions.

Step 03

Post bug-minimizing review notes

prmerger leaves concrete comments on risky code paths, suspicious edge cases, and implementation changes that deserve human attention.

Step 04

Protect `main` until green

Broken builds, failing unit tests, and unresolved critical findings keep the merge blocked until the author fixes the pull request.

What It Catches

Bug-prone Java changes before they surprise reviewers.

  • Spring Boot service changes that alter validation, transactions, or exception handling
  • Controller and DTO updates that risk serialization mismatches or contract drift
  • Repository changes that can hide null cases, n+1 queries, or unsafe filtering
  • Refactors that accidentally drop assertions, remove coverage, or weaken existing tests
Why It Lands

Designed to tighten review quality without creating process drag.

Uses your existing build truth instead of inventing a parallel CI system

Reviews Java pull requests in the same place your team already collaborates

Helps senior reviewers focus on system risk instead of chasing obvious failures

Gives teams a tighter merge policy without requiring more manual review cycles

FAQ

Straight answers for teams protecting Java pull requests.

Talk to the team

Does prmerger replace our CI?

No. It sits on top of the Maven or Gradle workflow you already trust and uses those results as the source of truth for PR status.

Can it work with Maven and Gradle monorepos?

Yes. You define the repository-specific command or module-level entrypoint that should pass before a PR can merge.

What kind of feedback does it leave on the PR?

It posts review comments about bug-prone changes, risky assumptions, and failure-path gaps, then ties the merge verdict back to build and test state.