-
Notifications
You must be signed in to change notification settings - Fork 737
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Maven jvm.config instead of fork/compilerArgs #2786
Comments
Thanks for the suggestion! Using I'm trying this out on a couple of projects and so far everything looks good. Any interest in sending a PR to update the docs to suggest |
Sure, PR issued at #2788 |
see google/error-prone#2786 PiperOrigin-RevId: 418668589
see google/error-prone#2786 PiperOrigin-RevId: 418668589
see google/error-prone#2786 PiperOrigin-RevId: 418873888
see google/error-prone#2786 PiperOrigin-RevId: 418873888
@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?
@cushon By looking at the
Should we file an |
Sure, if you're willing to follow up on that, it sounds worth clarifying. I verified that I'm still seeing the behaviour where |
I was not forking the compiler before upgrading to 17, so whatever was used before was within my limits. |
The error prone maven instructions for jdk16+1 recommend using
compilerArgs
andfork
. I was able to supply those same args to maven itself via.mvn/jvm.config
file2 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 docs3 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.Footnotes
https://errorprone.info/docs/installation#jdk-16 ↩
https://maven.apache.org/configure.html#mvn-jvm-config-file ↩
https://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html ↩
The text was updated successfully, but these errors were encountered: