Avoid using system java unless explicitly specified

[lihaoyi]

This would make Mill builds more reproducible, and avoid the JVM-version confusion that e.g. @makingthematrix encountered recently in the discord channel.

The basic question is what to do if //| mill-jvm-version is not explicitly set. It seems all options have tradeoffs

1. Not providing any default and forcing the user to provide one

   • Annoying for first-time users, which have to manually set a //| mill-jvm-version even if they don't care about it
   • Even plenty of advanced users or large projects don't really care about their JVM version, so asking them to pick one is annoying when we could just pick something for them and they'll be fine
   • If Mill aims to support non-JVM toolchains like Python or JS, then they don't care about this either and would be happy for some default to be picked
   • We'd need special handling for integration and example tests, and internal uses like dist.run or dist.installLocal, where providing an explicit JVM for every test case would be super annoying. But special handling would make them diverge from normal build files (although they already diverge, e.g. not using a bootstrap script and not requiring a mill-version specified)

2. Using some hardcoded default even if there is a java environmentally installed

   • Can cause confusion since people would expect the java they installed to take effect in the absence of other explicit configuration
   • Anyone upgrading from earlier versions of Mill could have their JVM version change silently, possibly causing published artifacts to silently require newer JVMs to run and causing downstream bytecode validation errors later
   • If we keep the default version stable, it will inevitable fall out of date over time. If we keep the default version updated, it might change the user's JVM version every time they update Mill
   • There is no "generally safe" default version to use: libraries would prefer the lowest possible version to not impose requirements on downstream users, while applications would prefer the highest possible version to take advantage of JVM improvements. com-lihaoyi libraries are built with 11, Spring-Boot requires 17, etc.
   • The existence of a default version that the user has to notice is incorrect and then override adds substantial user-facing complexity over forcing them to pick a version in the first place, since in the latter case at least the user would be aware of the value and it's ability to be configured

3. Using the environmental java installation as the default,

   • Matches the "default" way most people work with JVMs, but that default way sucks
   • Someone who checks out a codebase on a different machine with some other machine with a different java installation would encounter failures.
   • While users could always resolve this issue by setting an explicit //| mill-jvm-version in their build header, most users likely won't by default, won't know that they should, and when they hit weird Java version errors they won't know that this is the solution for it. e.g. all the com-lihaoyi projects never did this, and if we as the experts aren't doing this ourselves we can't realistically expect others to do so

We are currently at (3), but of these options I think (1) is probably the best.

The increased up-front inconvenience can be mitigated by copy-pasteable instructions on installation-ide.adoc and having an explicit default be included in all the example zip downloads. The longer-term convenience of "Mill projects are easy for anyone to checkout and build" would definitely be very valuable, and can be a differentiator over other build tools where that is generally not the case

This is a breaking change, but it doesn't break binary compatibility, and we can provide a good error message to smooth the upgrade path. So it'll likely go into 1.1.0

[lefou]

Ho can a user explicitly configure to use the system-installed java (whatever version it is). Or in other words, how to restore the current behaviour?

Is it this?

//| mill-jvm-version: system

[lihaoyi]

@lefou yes I believe that's the way to do it

[lefou]

Since using system java might be the preferred way to run for some users (it's what most other (build) tools do and might be easier to integrate in existing tool chains which already handle Java versions by other means), we should have a integration test for it.