Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow differentiating Zulu releases with/without CRaC #636

Open
guilgaly opened this issue Jun 4, 2024 · 2 comments
Open

Allow differentiating Zulu releases with/without CRaC #636

guilgaly opened this issue Jun 4, 2024 · 2 comments
Labels
feature request New feature or request to improve the current logic

Comments

@guilgaly
Copy link

guilgaly commented Jun 4, 2024

Description:

Currently, if I specify the following options:

distribution: 'zulu'
java-version: '21'

Then actions/setup-java will download zulu21.34.19-ca-crac-jdk21.0.3-linux_x64.tar.gz. Notice that this is the build with the optional CRaC feature (-crac in the name) rather than the default build (zulu21.34.19-ca-jdk21.0.3-linux_x64.tar.gz). Not necessarily a big deal, but weird since this is an optional feature rather than the default Zulu build. This doesn't seem intentional, rather it just happens because the -crac version ends up being first in the list.

I investigated a bit, and setup-java uses the https://api.azul.com/zulu/download/community/v1.0/bundles/ API, which does not seem to offer the ability to filter out CRaC builds. Azul recommends migrating to the newer https://api.azul.com/metadata/v1/zulu/packages/ API (see the migration guide), which does have such a filter.

After a few tests with the Swagger UI for the new API, here's the queries I would probably expect (assuming Linux x64 and java-version: '21' for this example):

  • java-package: 'jdk' (or the default): https://api.azul.com/metadata/v1/zulu/packages/?java_version=21&os=linux-glibc&arch=x64&archive_type=tar.gz&java_package_type=jdk&latest=true&release_status=ga&availability_types=ca&certifications=tck&javafx_bundled=false&crac_supported=false
  • java-package: 'jdk+fx': https://api.azul.com/metadata/v1/zulu/packages/?java_version=21&os=linux-glibc&arch=x64&archive_type=tar.gz&java_package_type=jdk&latest=true&release_status=ga&availability_types=ca&certifications=tck&javafx_bundled=true&crac_supported=false
  • java-package: 'jdk+crac': https://api.azul.com/metadata/v1/zulu/packages/?java_version=21&os=linux-glibc&arch=x64&archive_type=tar.gz&java_package_type=jdk&latest=true&release_status=ga&availability_types=ca&certifications=tck&javafx_bundled=false&crac_supported=true
  • Azul doesn't seem to offer packages with both JavaFX and CRaC at the same time.

What do you think?

Justification:

  • The optional inclusion of CRaC should be treated like the optional bundling of JavaFX (i.e. an option but not the default).
  • AFAICT, this requires migrating to Azul's new API, but that's what they recommend anyway.

Note that I don't know of any specific issue with using the -crac build when it's not needed, so it would be more for the principle of intentionally selecting the type of build used rather than just getting whichever one happens to be first in the list.

Are you willing to submit a PR?

I can probably try, it doesn't seem too complicated - but no guarantee that I would have the time right away.

@guilgaly guilgaly added feature request New feature or request to improve the current logic needs triage labels Jun 4, 2024
@aparnajyothi-y
Copy link
Contributor

Hello @guilgaly, Thank you for creating this issue and we will get back to you once we have some feedback on this :)

@brent85
Copy link

brent85 commented Jun 7, 2024

Description:

Currently, if I specify the following options:

distribution: 'zulu'
java-version: '21'

Then actions/setup-java will download zulu21.34.19-ca-crac-jdk21.0.3-linux_x64.tar.gz. Notice that this is the build with the optional CRaC feature (-crac in the name) rather than the default build (zulu21.34.19-ca-jdk21.0.3-linux_x64.tar.gz). Not necessarily a big deal, but weird since this is an optional feature rather than the default Zulu build. This doesn't seem intentional, rather it just happens because the -crac version ends up being first in the list.

I investigated a bit, and setup-java uses the https://api.azul.com/zulu/download/community/v1.0/bundles/ API, which does not seem to offer the ability to filter out CRaC builds. Azul recommends migrating to the newer https://api.azul.com/metadata/v1/zulu/packages/ API (see the migration guide), which does have such a filter.

After a few tests with the Swagger UI for the new API, here's the queries I would probably expect (assuming Linux x64 and java-version: '21' for this example):

  • java-package: 'jdk' (or the default): https://api.azul.com/metadata/v1/zulu/packages/?java_version=21&os=linux-glibc&arch=x64&archive_type=tar.gz&java_package_type=jdk&latest=true&release_status=ga&availability_types=ca&certifications=tck&javafx_bundled=false&crac_supported=false
  • java-package: 'jdk+fx': https://api.azul.com/metadata/v1/zulu/packages/?java_version=21&os=linux-glibc&arch=x64&archive_type=tar.gz&java_package_type=jdk&latest=true&release_status=ga&availability_types=ca&certifications=tck&javafx_bundled=true&crac_supported=false
  • java-package: 'jdk+crac': https://api.azul.com/metadata/v1/zulu/packages/?java_version=21&os=linux-glibc&arch=x64&archive_type=tar.gz&java_package_type=jdk&latest=true&release_status=ga&availability_types=ca&certifications=tck&javafx_bundled=false&crac_supported=true
  • Azul doesn't seem to offer packages with both JavaFX and CRaC at the same time.

What do you think?

Justification:

  • The optional inclusion of CRaC should be treated like the optional bundling of JavaFX (i.e. an option but not the default).
  • AFAICT, this requires migrating to Azul's new API, but that's what they recommend anyway.

Note that I don't know of any specific issue with using the -crac build when it's not needed, so it would be more for the principle of intentionally selecting the type of build used rather than just getting whichever one happens to be first in the list.

Are you willing to submit a PR?

I can probably try, it doesn't seem too complicated - but no guarantee that I would have the time right away.

#636 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request to improve the current logic
Projects
None yet
Development

No branches or pull requests

3 participants