[brunoborges]

Description:
The Java problem matcher turns every javac / Maven compiler diagnostic in subsequent steps into an inline annotation. This PR makes registration opt-in.

Why opt-in:

• Review noise. Annotations render inline on the PR "Files changed" tab, so routine compiler warnings (for example, deprecation warnings from static-analysis builds) clutter diffs. See "problem-matcher" should be default to false, not true #1322 and https://github.com/orgs/community/discussions/212672.
• Annotations are capped, so they are not a complete diagnostic report. These limits are still in effect on the current runner (main and latest release v2.338.2):
  • The runner uploads at most 10 annotations of each type (error, warning, notice) per step: _maxCountPerIssueType = 10, enforced in AddIssue. Diagnostics beyond the cap are still written to the log but are not annotated.
  • The Checks REST API docs state: "GitHub Actions are limited to 10 warning annotations and 10 error annotations per step."
  • The toolkit problem matcher docs also document a limit of 50 annotations per job.
• A Maven or Gradle build typically compiles in a single step, so a build with more than 10 warnings annotates only the first 10 and drops the rest from the annotation view. By default, the annotations were both noisy and incomplete.

Changes:

• problem-matcher now defaults to false in action.yml, and the runtime fallback in src/problem-matcher.ts matches.
• Setting problem-matcher: true registers the same .github/java.json matcher as before. Matcher patterns, compiler log output, and build failure behavior are unchanged.
• Invalid values such as ture still fail through the shared boolean parser.
• README (V6 highlights and inputs table) and docs/advanced-usage.md now describe the opt-in behavior with an enabling example.
• dist/setup/index.js was regenerated with npm run build.

Note for reviewers: this changes default behavior. Workflows that relied on implicit annotations must add problem-matcher: true to keep them. Omitting the input only stops this invocation from registering the matcher. It does not unregister matchers added by other steps.

Related issue:
Fixes: #1322

Check list:

• Ran npm run check locally (format, lint, build, test) and all checks pass.
  • npm run format-check: passed
  • npm run lint: passed
  • npm run build: passed (pre-push hook)
  • npm test: passed, 45 suites / 1718 tests (pre-push hook)
• Mark if documentation changes are required.
• Mark if tests were added or updated to cover the changes.

[Copilot]

🟢 Approval recommended

No active review issues block the change to opt-in Java problem matcher registration.

No open issues 🎉

What changed in this PR

Makes Java problem matcher registration opt-in, addressing #1322 by reducing unwanted inline annotations. Workflows that rely on these annotations must set problem-matcher: true; compiler output and build failure behavior remain unchanged.

Changes:

• Sets the action input default and runtime fallback to false.
• Documents opt-in behavior and clarifies that existing matchers are not unregistered.
• Updates unit tests and the generated setup bundle.

File	Description
src/​problem-matcher.ts	Disables registration by default at runtime.
README.md	Updates release highlights and the documented input default.
docs/​advanced-usage.md	Adds an enabling example and clarifies registration behavior.
dist/​setup/​index.js	Includes the updated runtime default in the shipped bundle.
action.yml	Sets the public input default to false and updates its description.
__tests__/​problem-matcher.test.ts	Covers default-disabled and explicitly enabled registration.

_{Review effort: Balanced}