Experiments can be run successfully with -XX
options on older Gradle versions
#361
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context
What is the issue?
Given a Gradle version older than 7.1, when
-XX:+UseParallelGC
is included as a JVM argument to the Gradle daemon, then user provided system properties from the command line are not available in certain parts of an Initialization script.Who is impacted?
Any projects which are on a version of Gradle older than 7.1 and are supplying the JVM argument
-XX:+UseParallelGC
to the Gradle daemon. This can be done by setting theorg.gradle.jvmargs
property ingradle.properties
.What changed between 2.2.1 and 2.3 to cause this regression?
In 2.3, it was decided to migrate all initialization script configuration to system properties. Previously, the configuration was a mix of system properties and project properties. The change was made to be consistent with the TeamCity initialization scripts, with itself, and also be compatible with the
org.gradlex.build-parameters
plugin which fails the build on unknown project properties.Is it only system properties that are unavailable?
Yes, but only when accessed via
System.getProperty(..)
. User provided system properties are still accessible viagradle.startParameter.systemPropertiesArgs.get(..)
. Environment variables accessed viaSystem.getenv(..)
and project properties accessed viagradle.startParameter.projectProperties.get(..)
are also available.Is there any other important context to understand for reviewers?
I was unable to find a Gradle Build Tool bug report for this issue. Considering that this issue is not present in Gradle 7.1, it is likely to have been fixed by this change, possibly unintentionally: gradle/gradle#16757
Investigation
I put together a reproducer project to help understand affected Gradle versions and to discover what exactly is available and where. Shown below is a summary of my findings.
System.getProperty(..)
systemPropertiesArgs.get(..)
System.getenv(..)
projectProperties.get(..)
initscript { }
settingsEvaluated { }
XX:+UseParallelGC
System.getProperty(..)
systemPropertiesArgs.get(..)
System.getenv(..)
projectProperties.get(..)
initscript { }
settingsEvaluated { }
XX:+UseParallelGC
System.getProperty(..)
systemPropertiesArgs.get(..)
System.getenv(..)
projectProperties.get(..)
initscript { }
settingsEvaluated { }
Solution
As a solution, I have chosen to replace all usages of
System.getProperty(..)
withgradle.startParameter.systemPropertiesArgs[name]
because it requires very minimal changes to the initialization scripts and no changes to the validation shell scripts. It also will not break theorg.gradlex.build-parameters
plugin.It should be noted that this works because these system properties only exist to make the initialization scripts configurable from the shell scripts via command line arguments. This would not work for reading system properties in all use cases (e.g. reading system properties from gradle.properties). This fix will work for the build validation scripts use case, but we should be cautious about where else we apply it.