Maven jvm.config instead of fork/compilerArgs

The error prone maven instructions for jdk16+^1 recommend using compilerArgs and fork. I was able to supply those same args to maven itself via .mvn/jvm.config file^2 and get a 4x improvement of build times by no longer forking the compiler.

Anecdotally, with my sample size of 1, using a maven reactor with 80 modules the build time for mvn clean compile was 11s using .mvn/jvm.config and 44s when forking the compiler.

The maven-compiler-plugin docs^3 leads me to believe that fork was designed for use cases where a different JDK was wanting to be used, rather than for configuration isolation while using the default javac. Thats not to say it can’t also work when config isolation is desired, like in this case.

Does errorprone need that level of isolation on the exports/opens configuration? Would the maintainers be open to updating the docs to include the .mvn/jvm.config option with the pros/con between the two approaches? or if the config isolation is not needed and the performance impact is impactful enough, change the recommendation to the non-forking option.

[hisener]

Filed https://issues.apache.org/jira/browse/MCOMPILER-479 and https://github.com/google/error-prone/issues/2793.

[hisener]

get a 4x improvement of build times by no longer forking the compiler.

@mattnelson Funnily enough, I applied the exact change on Tuesday, and the build times went from ~20 minutes to 8-9 minutes. However, the downside is that the Metaspace usage went up because the number of classes loaded increased significantly. Did you experience the same?

---

it’s really just about having a way to pass the JVM flags to javac, and passing -J flags to javac only works with fork enabled.

@cushon By looking at the maven-compiler-plugin code, I suspect the following description misleading:

Sets the arguments to be passed to the compiler if fork is set to true. https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerArgs

Should we file an MCOMPILER ticket? 🤔