Mill is a fast JVM build tool that supports Java and Scala. 2-4x faster than Gradle and 4-10x faster than Maven for common workflows, Mill aims to make your project’s build process performant, maintainable, and flexible
Currently JavaModule#compile with a custom JVM relies on Zinc forking a JVM for each Java compilation, which is slow, and Zinc does not support forking JVMs for ScalaModule#compile and it would anyway be prohibitively slow (upstream discussion https://github.com/sbt/zinc/discussions/1498).
The correct solution for this is to move ZincWorkerImpl into a long-lived worker subprocess when def javaHome is overridden. This will allow us to keep the Java compilation process warm so it can benefit from the fast in-memory compiles, while also supporting Scala compilation on custom JVM versions
This will likely require an overhaul of the ZincWorkerApi.scala to dis-entangle things sufficiently that we can impose a subprocess boundary between the caller and callee. This would break binary compatibility and would need to wait for 0.13.0
Follow up from https://github.com/com-lihaoyi/mill/issues/3480
Currently
JavaModule#compile
with a custom JVM relies on Zinc forking a JVM for each Java compilation, which is slow, and Zinc does not support forking JVMs forScalaModule#compile
and it would anyway be prohibitively slow (upstream discussion https://github.com/sbt/zinc/discussions/1498).The correct solution for this is to move
ZincWorkerImpl
into a long-lived worker subprocess whendef javaHome
is overridden. This will allow us to keep the Java compilation process warm so it can benefit from the fast in-memory compiles, while also supporting Scala compilation on custom JVM versionsThis will likely require an overhaul of the
ZincWorkerApi.scala
to dis-entangle things sufficiently that we can impose a subprocess boundary between the caller and callee. This would break binary compatibility and would need to wait for 0.13.0