WIP: Fix build functionality post auto-migration

[ajaychandran]

Follow up to #5428.

[lihaoyi]

@ajaychandran if the heuristics to guess the java version from the compiler flags don't work well in practice, maybe we should just go with mill-java-version: system then. Trying to look at the user JAVA_HOME and expecting the user to set it to the right place is probably too error prone for new Mill users to do reliably

[ajaychandran]

@ajaychandran if the heuristics to guess the java version from the compiler flags don't work well in practice, maybe we should just go with mill-java-version: system then. Trying to look at the user JAVA_HOME and expecting the user to set it to the right place is probably too error prone for new Mill users to do reliably

We auto-detect the JVM version from the system JDK in ModuleConfig.JavaHomeModule.system and set a concrete version for jvmId. The user is not required to set a version anywhere.
Only the environment needs to be set up with the correct JAVA_HOME. This should already be true on a development system.

Using mill-java-version: system will also work. The loss of build reproducibility is acceptable I suppose.

[lihaoyi]

Got it. If we want to auto-detect the JVM version, how about just shelling out to java -version? That should give us a version to use and would be simpler than the logic you currently have in lazy val system

[ajaychandran]

On second thoughts, I will make the switch to the mill-java-version: system option.
This will minimize changes to any CI workflows and is semantically more accurate.