Switch to containerized Loom JDK to fix broken builds.shipilev.net downloads

[Copilot]

Plan: Switch to Containerized Loom Build

• Understand current GitHub Actions workflow configuration
• Modify .github/workflows/loom-tests.yml to use Docker container shipilev/openjdk:loom
  • Replace download/extract steps with container configuration
  • Remove manual JAVA_HOME setup (container has it pre-configured)
  • Keep existing Maven cache configuration
  • Keep existing build and test commands
  • Fix Maven cache path for container context (/github/home/.m2)
  • Install Maven in the container (not included by default)
• Validate the changes don't break the workflow syntax
• Run code review and address feedback
• Fix CI failure: container doesn't include Maven
• Run security scan with CodeQL

Changes Summary

Successfully switched the Loom Build Tests workflow from downloading tar archives from builds.shipilev.net (which are broken) to using the Docker container shipilev/openjdk:loom.

Key Changes:

1. Use container: Changed from manual JDK download to container: image: shipilev/openjdk:loom
2. Install Maven: Added step to install Maven via apt-get (not included in the container)
3. Fixed cache path: Updated Maven cache from ~/.m2 to /github/home/.m2 for container context
4. Simplified setup: Removed manual JAVA_HOME configuration (pre-configured in container)

Security Summary

✅ No security vulnerabilities found by CodeQL scan.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Shipilev loom build is broke: use the containerized version?</issue_title>
<issue_description>Starting from https://github.com/franz1981/Netty-VirtualThread-Scheduler/actions/runs/20290398644 it looks the builds of loom from https://builds.shipilev.net/openjdk-jdk-loom/ to be broken, see

It looks like https://hub.docker.com/layers/shipilev/openjdk/loom/images/sha256-c446a3ffdd0cc10d178a4cbfda40bc511e4f0098b146c16db6516e049bd43cec (docker pull shipilev/openjdk:loom) has been correctly built 2 days ago (which is right before https://github.com/franz1981/Netty-VirtualThread-Scheduler/actions/runs/20290398644 failed, which means:

1. although using the build at https://builds.shipilev.net/openjdk-jdk-loom/ is more representative of the latest commits at https://github.com/openjdk/loom/tree/fibers
2. docker pull shipilev/openjdk:loom has the advantage of allowing the github actions using it to cache it and it won't be available if the build is broken, differently from https://builds.shipilev.net/openjdk-jdk-loom/

For these reasons, I would like to modify our github actions to make use of the mentioned container instead, to run tests and verify the build (and likely there won't be any reason to modify JAVA_HOME at this point).</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Shipilev loom build is broke: use the containerized version? #55

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[franz1981]

Check the failure @copilot

[Copilot]

Check the failure @copilot

Fixed in 180f3e2. The shipilev/openjdk:loom container only includes the JDK, not Maven. Added a step to install Maven before running the build.

[franz1981]

the docker container is cached @copilot ?

[Copilot]

the docker container is cached @copilot ?

Yes, GitHub Actions automatically caches Docker container images. When using container: image: shipilev/openjdk:loom, the image layers are cached on the GitHub-hosted runner and reused across workflow runs, which speeds up job startup time significantly compared to downloading the JDK tarball each time.