The resulting JAVA_HOME_..._architecture variable name is inconsistent: ARM64 or AARCH64

[vlsi]

Description:

The environment variable name is inconsistent: sometimes it is JAVA_HOME_17_AARCH64 and sometimes it is JAVA_HOME_17_ARM64.

setup-java/src/distributions/base-installer.ts

Line 172 in 9eda6b5

`JAVA_HOME_${majorVersion}_${this.architecture.toUpperCase()}`,

Task version:

'actions/setup-java@v3' (SHA:0ab4596768b603586c0de567f2430c30f5b0d2b0)

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Repro steps:
A description with steps to reproduce the issue. If your have a public example or repo to share, please provide the link.

Expected behavior:

The variable name should be consistent.
Preferably, the variable name should use the same values as the action's architecture input parameter:

setup-java/README.md

Line 36 in 9eda6b5

- `architecture`: The target architecture of the package. Possible values: `x86`, `x64`, `armv7`, `aarch64`, `ppc64le`. Default value: Derived from the runner machine.

Actual behavior:

If user omits architecture, then setup-java generates JAVA_HOME_17_ARM64 environment variable.
If user passes architecture: aarch64, then setup-java generates JAVA_HOME_17_AARCH64 variable.

[marko-zivic-93]

Hello @vlsi
Thank you for filing your issue. We will investigate it and come back to you as soon as we have some information.

[mahabaleshwars]

Hello @vlsi,
The architecture variable defaults to the runner image's architecture when not provided, and it uses the architecture variable provided by the user accordingly. We believe this is the expected behavior. Additionally, there might be confusion if a different value is printed when the user specifies the architecture variable. Could you please let us know if this is causing any issues while running the workflows?

[mahabaleshwars]

Hello @vlsi, can you confirm if the above feedback resolves the issue? If not, could you share the issues you are facing?