Refactor enterprise-java image to use SDKMAN for versioning

[tw29845]

• Refactored Dockerfile to use SDKMAN! for version management of JDK, Gradle, and Maven
  • Additionally allows users to manage versions using Dotfiles or manually using sdk CLI.
• Bump OpenJDK to latest version of current LTS, 21.0.8
• Bump Gradle to latest previous major version, 8.14.3
• Bump Maven to latest version, 3.9.11
• Permanently resolves Maven download issue seen in chore: Bump actions/checkout from 4 to 5 in the github-actions group #305, chore: java: update maven to 3.9.10 #300, and chore: update maven version and download link #297 by making SDKMAN responsible for download link resolution

[Copilot]

Pull Request Overview

This PR refactors the enterprise-java Docker image to use SDKMAN for managing Java development tool versions instead of manual downloads and installations. This approach simplifies version management and resolves previous Maven download issues.

• Replaces manual JDK, Gradle, and Maven installation with SDKMAN-based management
• Updates to latest LTS versions: OpenJDK 21.0.8, Gradle 8.14.3, and Maven 3.9.11
• Eliminates hardcoded download URLs and hash verification by delegating to SDKMAN

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[tw29845]

Unsure why the pipeline building the Docker images is failing, but I don't believe it is anything to do with my changes

[tw29845]

@johnstcn Are you able to tell why the pipeline building the images fails? If it's auth issues due to me merging in a fork then I'm not sure what I can do to resolve that myself

[johnstcn]

If it's auth issues due to me merging in a fork then I'm not sure what I can do to resolve that myself

Yeah this is on us to figure out, sorry about that

For now I cherry-picked your changes into a different PR #308

[johnstcn]

@tw29845 I get this when building on linux/arm/v7:

22 3.478 'curl --fail --location --progress-bar "${SDKMAN_SERVICE}/broker/download/native/install/${SDKMAN_NATIVE_VERSION}/${SDKMAN_PLATFORM}" > "$sdkman_zip_file"': command failed with exit code 22.

https://github.com/coder/images/actions/runs/17132138297/job/48598919038?pr=308

[tw29845]

@tw29845 I get this when building on linux/arm/v7:

22 3.478 'curl --fail --location --progress-bar "${SDKMAN_SERVICE}/broker/download/native/install/${SDKMAN_NATIVE_VERSION}/${SDKMAN_PLATFORM}" > "$sdkman_zip_file"': command failed with exit code 22.

https://github.com/coder/images/actions/runs/17132138297/job/48598919038?pr=308

Are you able to tell me what the output of uname -m is? That command, along with uname -s, determines the platform and architecture within SDKMAN. There is an ARM v7 arch mentioned in the SDKMAN install script called armv7l so if that matches then it should be good.

[johnstcn]

Are you able to tell me what the output of uname -m is? That command, along with uname -s, determines the platform and architecture within SDKMAN. There is an ARM v7 arch mentioned in the SDKMAN install script called armv7l so if that matches then it should be good.

if memory serves, armv7l is correct. There's an existing script in deprecated/rust/rustup.sh that has some similar logic:

get_architecture() {
    local _ostype _cputype _bitness _arch _clibtype
    _ostype="$(uname -s)"
    _cputype="$(uname -m)"
    _clibtype="gnu"

...

case "$_cputype" in 
    ...
        armv7l | armv8l)
            _cputype=armv7
            if [ "$_ostype" = "linux-android" ]; then
                _ostype=linux-androideabi
            else
                _ostype="${_ostype}eabihf"
            fi
            ;;
esac

[tw29845]

So far as I can find, SDKMAN does not support 32-bit ARM architecture. There is a ticket asking about just that, but no replies (see here). I have hacked together a workaround for the installation of SDKMAN itself that uses the 64-bit ARM release, but even after that I get errors when verifying the installation of Maven.
As much as I think using SDKMAN for management of the SDKs would be useful to many, I unfortunately am not able to spend much more time blindly debugging the ARM images. I would welcome @johnstcn or anybody else to take a look at getting this working though. Otherwise, the PR may have to be closed.

[johnstcn]

So far as I can find, SDKMAN does not support 32-bit ARM architecture.

@matifali AFAICT the only reason I'm aware we support the armv7 architecture is for the older models of Raspberry Pi. I'd rather not drop support for this platform as it's a popular community use-case for Coder.

@tw29845 another possibility is that we add this as a new image enterprise-java-sdkman that excludes the armv7 arch.

Thoughts?

[tw29845]

AFAICT the only reason I'm aware we support the armv7 architecture is for the older models of Raspberry Pi. I'd rather not drop support for this platform as it's a popular community use-case for Coder.

That's absolutely fine, happy to see continued support for older platforms!

another possibility is that we add this as a new image enterprise-java-sdkman that excludes the armv7 arch.

I'd be happy with that, though I'm unsure of how one specific image could be configured to not being one specific architecture fitting with your current build processes. The easiest solution would be to add a new depot command to build_images.sh specific for the new enterprise-java-sdkman image

[tw29845]

@johnstcn ready for review