ubuntu-latest uses wrong JDK version

[tresf]

Description:
When [25] is selected, [17] is used.

This issue seems to be specific to steps that use the sudo command.

Logs:
https://github.com/qzind/tray/actions/runs/23968390243/job/69912859804

Task version:
v5

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Repro steps:
https://github.com/qzind/tray/blob/669af6f31f3b6417c32299ea70376afe414825a1/.github/workflows/build.yaml

Expected behavior:
Java 25 is used

Actual behavior:
Java 17 is used

[tresf]

Hmm... on closer inspection, the compilation works just fine using jdk25 then fails later in the unit tests after installing sudo apt-get install firefox chromium. Something about this additional testing step may be modifying the environment...

[tresf]

I believe this issue is caused by steps using the sudo command.

[tresf]

I believe this issue is caused by steps using the sudo command.

Yeah, it's fixed by passing JAVA_HOME to the sudo command. Not sure if this is a bug?

Edit: No, it's not. What the heck lol.

[tresf]

Hmm... forcing JAVA_HOME to the sudo command doesn't help either. I'm scratching my head...

[v-chiranjib-swain]

Hi @tresf , Thank you for raising this. We will investigate it and get back to you as soon as we have some feedback.

[v-mahabaleshwars]

Hi @tresf,

This is not a bug in setup-java. The action correctly sets JAVA_HOME and PATH for JDK 25 via core.exportVariable and core.addPath, which is the standard GitHub Actions mechanism.

The issue is that sudo on Ubuntu resets the environment (due to env_reset/secure_path in sudoers), causing commands to fall back to the runner image's default JDK 17. This is expected OS-level behaviour, not something setup-java controls.

We'd suggest ensuring JAVA_HOME and PATH are correctly propagated to the sudo context in your workflow steps.

[tresf]

As can be seem from the trial and error above, JAVA_HOME didn't seem to fix this, so any advice is appreciated.

The term "expected behavior" I believe to be a bit misleading here, since the readme makes no mention of the behavior being "expected to fail" as sudo.

I'm curious, does macOS and Windows behave the same way where a version other than the one requested may be used under similar circumstances?