Automatically set recommended JVM flags in Gradle builds

[Sanne]

Description

The work on #49920 introduced a ModuleOpenBuildItem, which dynamically applies Java module configurations to the JVM launched for dev-mode or integration tests. This needs either our agent to be attached, or some JVM flags to allow us to take control of such aspects; when working on #49920 we made sure that a Maven build would automatically set such flags; when they are not, things will still work but there will be actionable warnings logged, so any Gradle user won't have problems either but they might need to add some more JVM flags to their build scripts.

It would be ideal to adapt our Gradle plugins to setup such flags automatically, so that users don't need to bother with any action at all.

Implementation ideas

See https://github.com/quarkusio/quarkus/pull/49920/commits/a3387cb21629bcd90b77403de84acf7aa64ad5e8

[quarkus-bot[bot]]

/cc @glefloch, @quarkusio/devtools

[reaver585]

Greetings @Sanne. I have no context whether this one is intended for community contributions. If it is though, I'd like to try.

[reaver585]

Question: If i understand correctly, what you are doing in a3387cb21629bcd90b77403de84acf7aa64ad5e8 is just setting

--add-opens=java.base/java.lang.invoke=ALL-UNNAMED
--add-opens=java.base/java.lang=ALL-UNNAMED
--add-exports=java.base/jdk.internal.module=ALL-UNNAMED"

Is that all we need to do in Gradle build, for the JVM that runs tests? I'm asking because when we bootstrap a Gradle Quarkus app, build.gradle already includes

test {
    systemProperty "java.util.logging.manager", "org.jboss.logmanager.LogManager"
    jvmArgs "--add-opens", "java.base/java.lang=ALL-UNNAMED"
}

be default; the end user doesn't need to add them manually. So, if i understood the objective of this issue correctly, one way we could do it is lean into this approach and simply add lines for java.lang.invoke and jdk.internal.module.

Perhaps, alternatively, we could do it in the Gradle plugin, but I'm not sure how well that would integrate with the IDEs.

Do you have a preference here, @Sanne? Thanks in advance.

[geoand]

@Sanne ^

[Sanne]

hello @reaver585 ! sorry for the delay. Yes following the example in https://github.com/quarkusio/quarkus/commit/a3387cb21629bcd90b77403de84acf7aa64ad5e8 is a good idea, but please note that https://github.com/quarkusio/quarkus/pull/49920 isn't merged yet - I should finish that first, so to confirm what exactly this patch should be doing as a follow-up. You're of course free to start experimenting based on the assumption that we'll likely just need those three properties, but I'd rather not merge a PR to address this until this is confirmed.

Essentially I'm hoping that Gradle users can have such properties set automatically without needing to set such details in the test stanza explicitly. Your example also reminds me that it would be nice to set the java.util.logging.manager system property automatically as well - although it might be best to treat that as a separate improvement.

[reaver585]

Thanks for the response @Sanne. Makes sense to me - I can prepare a PR that moves setting these properties from the build file into the plugin logic, and we can keep it open. Once #49920 is merged, I will sync my work with it. I will keep you posted.