gradle.properties defines org.gradle.jvmargs twice

While working on !8 (merged) I noticed it reverts a commit that introduces this issue (2e2b0f15)

The second declaration of org.gradle.jvmargs overwrites the first one:

org.gradle.jvmargs=--add-opens=java.base/java.io=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED
org.gradle.jvmargs=-Xmx2g

The first line was added in 04de9e00 (Add JVM args to make build work on JDK 16) in September 2021.

The second line was added in 2e2b0f15 (Make sure Gradle has enough memory at its disposal) in October 2021.

Essentially the JVM args use to make the build work were overwritten since quite some time. As I result I'm wondering whether we could just remove them. On JDK 17 I can build just fine without them. I didn't check building on JDK 16 but as this was a short term release which is already unsupported I think we can drop support for it, even if it was required to have those arguments for that version. Users should get a supported JDK anyway, i.e. 17 usually at the moment.

I'm also wondering if we (still) need the maximum heap size option -Xmx. I can run it fine without it here on both Linux and Windows. Also, inspecting the default value for OpenJDK 11 and 17 via java -XX:+PrintFlagsFinal -version | grep MaxHeapSize, it seems to be 8401190912 which is 8Gb if I'm not mistaken.

Not sure if this is determined by my main memory 32Gb. I'll check on a different machine with less memory.

OK, on my other machine the default heap size is 4Gb, with the main memory being 16Gb. I think this fits with what I read on some post on the Internet where the default max heap size is defined as 25% of main memory by default.

that would mean for 8Gb and above the max heap size is 2Gb+ anyway.

So when we specify 2Gb as max heap size, it should have an effect for systems with less than 8Gb. I don't know how common that is nowadays to have a machine with less than 8Gb of main memory. I fear it might not be too uncommon. That would be an argument in favor of keeping the -Xmx option I guess.

a quick search on Amazon for "Windows laptop" turns up quite a few new laptops one can buy with 4Gb of memory. So I guess for low budget hardware it's still common.

bottom line: I'm suggesting to remove the add-opens options and keep the Xmx option.