PPalabas APIJava field course

Extras / Lesson S.1

Supplement: Java Version Discipline

Make the project Java version boring: one local JDK pin, one Gradle toolchain, and one CI provider.

Concept

Java version management is part of the project contract. SDKMAN makes the developer shell convenient, Gradle toolchains keep the build honest, and CI pins the provider family so local and hosted proof do not drift. The lesson is not that Zulu is magic; the lesson is that the repo states exactly which Java line it expects.

Task

  1. Install or activate Azul Zulu 25.0.3 with SDKMAN.
  2. Commit `.sdkmanrc` so new shells can run `sdk env` from the repo.
  3. Keep the Gradle Java toolchain on language version 25.
  4. Configure CI with `distribution: zulu` and `java-version: 25`.
  5. Run the fast suite from a shell that has activated the repo JDK.

Run

sdk env install
sdk env
java -version
source "$HOME/.sdkman/bin/sdkman-init.sh" && sdk use java 25.0.3-zulu && ./gradlew test --no-daemon

Expected Result

  • `java -version` reports Zulu 25.0.3.
  • `./gradlew test --no-daemon` finishes with `BUILD SUCCESSFUL`.
  • Running Gradle no longer creates tracked build or `.gradle` noise.

Common Traps

  • Assuming the shell `java` and Gradle test JDK are always the same.
  • Letting CI use Temurin while local development uses Zulu.
  • Committing generated `build/` or `.gradle/` state after test runs.
  • Treating provider choice as a performance claim without benchmark evidence.

Hint Ladder

Hint 1

SDKMAN solves the human problem: activate the right JDK when entering the repo.

Hint 2

Gradle toolchains solve the build problem: fail fast if the required language version is unavailable.

Hint 3

CI should name both the Java version and the distribution so hosted proof matches local practice.

Solution

See `.sdkmanrc`, the Java Version section in `palabas-api/README.md`, and the Zulu setup-java entries in `.github/workflows/palabas-course.yml`.