* Use Azul metadata API

* Document arm64 -> aarch64 mapping in README.md

* Paginate through all available versions

* Fix typo: win_aarhc4

* Only query for linux_glibc packages

* Add Zulu CRaC package support to metadata migration

Fold CRaC-related work into the Zulu metadata API migration by wiring crac_supported query handling, extending Zulu package docs, and updating installer tests for jdk+crac/jre+crac behavior.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Harden Zulu metadata pagination with safety cap

- Stop paginating on a short page to avoid an extra empty request
- Guard against undefined results (not just null)
- Cap iterations at 100 pages and warn if the limit is hit to
  prevent a runaway loop if the API misbehaves

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Preserve JDK build number from Azul Metadata API

The Azul Metadata API returns java_version as a 3-element array
(e.g. [17,0,7]) and reports the build number separately in
openjdk_build_number. The migration mapped version directly from
java_version, dropping the build and breaking exact-version lookups
like 17.0.7+7 (e2e failure: "No matching version found for SemVer").

Add openjdk_build_number to IZuluVersions and append it to
java_version before converting to semver so resolved versions retain
the build (e.g. 17.0.7+7). Update the zulu test fixtures to mirror the
real API shape (3-element java_version plus openjdk_build_number) so
unit tests exercise the actual response format, and rebuild dist.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Bruno Borges <brborges@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
(cherry picked from commit d3530c1)

* Initial plan

* feat: add .mvn/extensions.xml to Maven cache key pattern

Closes #990

Maven build extensions declared in `.mvn/extensions.xml` can introduce
additional plugin dependencies (e.g. lifecycle participants, custom
packaging types). Including this file in the cache key hash ensures that
changes to extensions — which affect what plugin JARs Maven downloads —
properly invalidate the cache, preventing stale caches from missing
newly-required plugin dependencies.

Changes:
- src/cache.ts: add `**/.mvn/extensions.xml` to Maven pattern array
- __tests__/cache.test.ts: update pattern expectations; add new test
- README.md: document the new file in the Maven cache key hash list

* test: update maven cache error test name for extensions.xml

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: Bruno Borges <brborges@microsoft.com>
(cherry picked from commit 2a07c83)

The Azul Metadata API's `arch=x86` returns both 32-bit (i686) and 64-bit
(x64) packages. Because the two variants share identical java_version and
distro_version, setup-java cannot distinguish them and may resolve an
explicit `architecture: x86` request to a 64-bit JDK (and for Java 21+,
where 32-bit is dropped, x86 silently returns x64 instead of failing).

The legacy Zulu Discovery API used `arch=x86&hw_bitness=32` to target only
32-bit builds. The Metadata API exposes the equivalent via `arch=i686`,
which returns only genuine 32-bit builds with full version parity to the
old behavior. Map x86 -> i686 to restore correct 32-bit resolution.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
(cherry picked from commit 8a3e815)

* Rename jdkFile input to jdk-file with deprecated alias

Add a standardized `jdk-file` input to match the lowercase-dash naming
used by every other action input. The camelCase `jdkFile` input is kept
as a deprecated alias: it still works, but emits a deprecation warning and
may be removed in a future release. `jdk-file` takes precedence when both
are provided.

Updates docs and the local-file e2e workflow (one case intentionally keeps
using the deprecated alias for coverage) and regenerates the dist bundles.

Fixes #1077

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* docs: keep jdkFile in switching-to-v2 guide

The switching-to-v2 migration guide uses actions/setup-java@v2, which only supports the camelCase jdkFile input. Keep the new jdk-file spelling in current-version docs only.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
(cherry picked from commit 7dbccc6)

* Infer distribution from asdf .tool-versions vendor prefix

asdf-java encodes the JDK vendor as a prefix on the version string in
.tool-versions (e.g. `java temurin-17.0.3+7`). Capture that prefix and
map it to a setup-java distribution, mirroring the existing .sdkmanrc
behavior. Unknown prefixes warn and fall back to the distribution input.

Fixes #1081

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Potential fix for pull request finding

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
(cherry picked from commit 4db08ef)

Regenerate the CommonJS bundle so the compiled dist/ reflects the
source changes backported from main, without the ESM migration (#1078).

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

The javac problem matcher only recognized javac's native diagnostic
format (File.java:12: warning: msg), which works for plain javac and
Gradle but not Maven. The maven-compiler-plugin reformats diagnostics
to [WARNING] /path/File.java:[12,5] msg, so Maven builds produced zero
annotations.

Add a new maven-javac matcher owner that recognizes the Maven format,
capturing severity, file, line, column, and message. Maven builds now
annotate consistently with Gradle and plain javac.

Fixes: #1085


(cherry picked from commit cf9e5e7)

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* feat: expose cache-primary-key output (#597)

Backport of the cache-primary-key output to the v5 release line.

Expose the primary cache key computed by the caching logic as a new
`cache-primary-key` action output, so workflows can compose the built-in
setup-java cache key with actions/cache or actions/cache/restore across
steps and dependent jobs.

- src/cache.ts: set the `cache-primary-key` output in restore()
- action.yml: declare the new output
- README.md: document the new output
- __tests__/cache.test.ts: assert the output is set
- dist: rebuild (CommonJS)

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Apply PR #1088 review suggestions to v5 backport

Port the review feedback from the main-line PR (#1088) into the v5 backport:
- src/cache.ts: use the STATE_CACHE_PRIMARY_KEY constant for the output name
  instead of a duplicated string literal
- action.yml / README.md: clarify that the output is also empty when caching
  is skipped (e.g. the cache service is unavailable)
- dist: rebuild

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

- Update Tencent Kona documentation to list JDK 25 as supported
- Add Kona 25 to the e2e verification matrix (ubuntu, windows, macos)
- Extend Kona test fixture with real Kona 25.0.3 release entries
- Add unit tests covering Kona 25 selection across all platforms

Signed-off-by: John Jiang <johnsjiang@tencent.com>
Co-authored-by: johnsjiang <johnsjiang@tencent.com>

…runs (#1099) (#1113)

* Preserve Maven toolchains across repeated setup-java runs (#1099)

Backport of #1111 to releases/v5.

Toolchain generation was gated behind the `overwrite-settings` input,
which is documented to control only regeneration of `settings.xml`.
Because `generateToolchainDefinition` already performs a non-destructive
merge (existing JDK, custom, and user-managed toolchains are preserved,
and only an entry with the same `type` + `provides.id` is replaced),
skipping the write when `overwrite-settings: false` caused later
setup-java executions to drop toolchain entries registered by earlier
runs.

Decouple toolchains generation from `overwrite-settings`: the toolchains
file is now always written, so consecutive runs accumulate every JDK.
`settings.xml` behavior (auth.ts) is unchanged.

- src/toolchains.ts: drop overwriteSettings from configureToolchains /
  createToolchainsSettings / writeToolchainsFileToDisk; always write.
- __tests__/toolchains.test.ts: update call sites, rewrite the
  "does not overwrite" test to assert non-destructive extension, and add
  a regression test for consecutive configureToolchains executions.
- docs/advanced-usage.md: clarify merge is non-destructive and
  independent of overwrite-settings.
- dist/setup/index.js: rebuilt.

Fixes #1099

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Potential fix for pull request finding

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

…parately (#1122)

Backports the wrapper caching fix to the v5 release line.

The Maven wrapper distribution (~/.m2/wrapper/dists) and Gradle wrapper
distribution (~/.gradle/wrapper) were cached in the same entry as the
dependency cache, keyed on the volatile dependency-file hashes (**/pom.xml,
**/*.gradle*). With no restoreKeys fallback (#269), almost every dependency
change was a full cache miss, forcing ./mvnw and ./gradlew to re-download the
build tool distribution and hitting intermittent rate-limit failures.

Each wrapper distribution now lives in its own additional cache entry keyed
only on the rarely-changing wrapper properties file
(**/.mvn/wrapper/maven-wrapper.properties, **/gradle-wrapper.properties), so
it survives dependency changes. Optional-cache saves swallow ValidationError
and ReserveCacheError so a project without a wrapper never fails the post step.

Fixes: #1095


Copilot-Session: ea015caa-980a-4e0a-af20-3fc9f39c77fd

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>