This was originally reported in SKARA-1054.

The first time you run "git skara update", the build is bootstrapped from the skara.sh script directly (as there is no ${DIR}/bin/bin/git-skara file present). On a platform where gradlew cannot download a JDK, it will simply delegate this to the official Gradle launcher, which will in turn look for JAVA_HOME first and java in the path second. This works for in my experiment if I just make sure to set JAVA_HOME to JDK 14 or later. The problems start when you try to update again. On subsequent "git skara update" calls, the skara.sh script will defer to the actual GitSkara command (implemented in Java), which will in turn run "git pull" and if deemed necessary "bash gradlew". The problem here is that the git-skara launcher shell script exports JAVA_HOME=$SKARA_DIR/bin/image. I don't know why it does this. In the case where gradlew downloads a JDK, it will override JAVA_HOME before calling the Gradle launcher, but in our case, there is no override, so the value from git-skara remains and will ruin the build. The image in $SKARA_DIR/bin/image is not intended to be used for running Gradle. It's the runtime image of the CLI tools, which is jlinked to only contain the modules needed for that.

The simplest fix would be to stop setting JAVA_HOME when launching GitSkara. I'm not sure if setting this is important for anything though. Another solution would be to actively save any current JAVA_HOME and restore it when running gradle from GitSkara.