Add Documentation to Recommend Using GraalVM JDK 17 Version to 17.0.12 to Align with GFTC License Terms

[aparnajyothi-y]

Description:
This PR will update to recommend using graalvm 17 version to comply with the GraalVM free terms and conditions license(GFTC).

[fniephaus]

Hi @aparnajyothi-y, thanks for the PR. I work on the GraalVM at Oracle and contributed GraalVM support.

Instead of adding a note like this, we are using a different approach in setup-graalvm: we let java-version: '17' default to 17.0.12 and emit a job warning.

Do you think it would make sense to do the same in setup-java?

[aparnajyothi-y]

Hello @fniephaus, Thank you for the suggestion. Based on further investigation, it wouldn’t be feasible to adopt the same approach for Java 17 as in setup-graalvm at this time, because the end of GFTC support for version 17.0.12 has not yet been confirmed. As a result, we cannot be certain whether this will be the final update of Java 17 with GFTC license support, or if future versions will follow the same model.

Given this uncertainty, we’ve decided to update the documentation instead of implementing the same defaulting approach as in setup-graalvm.

We appreciate your understanding!

[noob-code55]

        - name: Setup Java JDK

uses: actions/[email protected]
with:
# The Java version to set up. Takes a whole or semver Java version. See examples of supported syntax in README file
java-version: # optional
# The path to the .java-version file. See examples of supported syntax in README file
java-version-file: # optional
# Java distribution. See the list of supported distributions in README file
distribution:
# The package type (jdk, jre, jdk+fx, jre+fx)
java-package: # optional, default is jdk
# The architecture of the package (defaults to the action runner's architecture)
architecture: # optional
# Path to where the compressed JDK is located
jdkFile: # optional
# Set this option if you want the action to check for the latest available version that satisfies the version spec
check-latest: # optional
# ID of the distributionManagement repository in the pom.xml file. Default is github
server-id: # optional, default is github
# Environment variable name for the username for authentication to the Apache Maven repository. Default is $GITHUB_ACTOR
server-username: # optional, default is GITHUB_ACTOR
# Environment variable name for password or token for authentication to the Apache Maven repository. Default is $GITHUB_TOKEN
server-password: # optional, default is GITHUB_TOKEN
# Path to where the settings.xml file will be written. Default is ~/.m2.
settings-path: # optional
# Overwrite the settings.xml file if it exists. Default is "true".
overwrite-settings: # optional, default is true
# GPG private key to import. Default is empty string.
gpg-private-key: # optional
# Environment variable name for the GPG private key passphrase. Default is $GPG_PASSPHRASE.
gpg-passphrase: # optional
# Name of the build platform to cache dependencies. It can be "maven", "gradle" or "sbt".
cache: # optional
# The path to a dependency file: pom.xml, build.gradle, build.sbt, etc. This option can be used with the cache option. If this option is omitted, the action searches for the dependency file in the entire repository. This option supports wildcards and a list of file names for caching multiple dependencies.
cache-dependency-path: # optional
# Workaround to pass job status to post job step. This variable is not intended for manual setting
job-status: # optional, default is ${{ job.status }}
# The token used to authenticate when fetching version manifests hosted on github.com, such as for the Microsoft Build of OpenJDK. When running this action on github.com, the default value is sufficient. When running on GHES, you can pass a personal access token for github.com if you are experiencing rate limiting.
token: # optional, default is ${{ github.server_url == 'https://github.com' && github.token || '' }}
# Name of Maven Toolchain ID if the default name of "${distribution}_${java-version}" is not wanted. See examples of supported syntax in Advanced Usage file
mvn-toolchain-id: # optional
# Name of Maven Toolchain Vendor if the default name of "${distribution}" is not wanted. See examples of supported syntax in Advanced Usage file
mvn-toolchain-vendor: # optional

[aparnajyothi-y]

Hello @fniephaus, a gentle reminder to check if you have any further questions or need additional clarifications on the above.

[fniephaus]

Thanks for the ping, @aparnajyothi-y!

The blog post that introduced GFTC said the following about timelines:

"For designated Long Term Support releases (GraalVM for JDK 17), Oracle will provide these free GFTC releases until one full year after the subsequent LTS release".

According to the release calendar, Oracle GraalVM for JDK 17.0.12 is the last release under GFTC. The artifacts are still available and their license are not changed retroactively. In fact, the script-friendly URLs used by setup-java can only retrieve GFTC-licensed releases of Oracle GraalVM.

The end of permissive license was also announced here.

So, I'd still recommend to let 'java-version: 17' fall back to 17.0.12 while displaying a warning that notifies users of their options (upgrading to JDK 21 is recommended).

What do you think?

[Marcono1234]

Related issue: #700

[aparnajyothi-y]

Hello @fniephaus,
Thank you for highlighting that Oracle GraalVM for JDK 17.0.12 is the final GFTC release from the blog. It's reassuring to know that the artifacts and licenses remain unchanged, and that the setup-java URLs will continue to point to GFTC-licensed releases.
We agree with your suggestion to have java-version: 17 fall back to 17.0.12, while displaying a warning to users and encouraging them to consider upgrading to JDK 21. As for making any direct changes to 17.0.12, we'll likely monitor feedback from the community moving forward to determine if any adjustments are necessary. This approach will help us make data-driven decisions based on the needs of the majority of users.

We encourage your future feedback as we continue to improve setup-java.