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>
* Migrate to ESM and upgrade dependencies
* fix: update import statement for JSON module in kona-installer test
---------
Co-authored-by: George Adams <georgeadams1995@gmail.com>
* 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>
* Refactor error handling for version not found cases across multiple installers
* Mock core.error in tests to suppress error logs
* fix(graalvm): improve error messages for EA version not found scenarios
* refactor(tests): update error messages for version not found scenarios
* fix(graalvm): enhance error messages for version not found scenarios
* fix(graalvm): improve error messages for version not found scenarios with updated download URL
* fix(graalvm): improve error handling for EA version not found scenarios with clearer messages
* Added Windows Arm64 Support for Windows Arm64 Runners
* microsoft test file update and tool-version test file
* Delete .DS_Store
* added test cases for windows and linux for zulu, liberica and microsoft
* adding different data files for each OS
* added changes to distribution files
* added more version support for microsoft
Bruno Borges
Priya Gupta
James Wald
Chiranjib Swain
Salman Chishti
mahabaleshwars