Gradle 9 compatibility fixes

[mbien]

• gradle 9 removed some deprecated API (which broke gradle project support)
• introspecting updateDaemonJvm.vendor.* causes OOME in daemon (uses 512MB by default, but 4GB were also not sufficient). Added 'vendor' to exclude set.
• init with latest supported gradle version by locking the major component (instead of using 'current')

tested hello world project loading between gradle 5 and 9.

for future reference:
I found this by increasing daemon Xmx, setting MAX_INTROSPECTION_DEPTH to a low value, e.g 8, then setting a breakpoint at

netbeans/extide/gradle/netbeans-gradle-tooling/src/main/java/org/netbeans/modules/gradle/tooling/NbProjectInfoBuilder.java

Line 590 in e54117d

LOG.warn("Too deep structure, truncating");

and attaching the debugger to the daemon.

MAX_INTROSPECTION_DEPTH is probably far too high to protect from OOMEs but it will depend on the shape of the graph.

The annoying part was to debug a daemon while extide/gradle/netbeans-gradle-tooling is trying to start daemons too, given that it is a gradle project ;)

[mbien]

would be nice if a heavy gradle user could run this against some of their projects as smoke test. (hello world worked with gradle 5-9)

[mbien]

added a second commit which works analog to #8606 but locks the major version component of the returned version. Currently set to 9. This should make it a bit safer (+ it fits that gradle 9 started to use semantic versioning). Commits meant to be squashed if we decide to do that.

[sdedic]

introspecting updateDaemonJvm.vendor.* causes OOME in daemon (uses 512MB by default, but 4GB were also not sufficient)

Can you file an issue for this + assign it (to me ?)

[sdedic]

will likely need some tweaks for compatibility with older gradle versions

Note to self:

• getFirstLevelModuleDependencies() did not exist before gradle 4.0 (roughly); NB code seems to support even 3.1 (?)
• GradleVersion did not exist before 8.0 (?)

[neilcsmith-net]

* `getFirstLevelModuleDependencies()` did not exist before gradle 4.0 (roughly); NB code seems to support even 3.1 (?)

NB can only support the versions that the Tooling API supports. I'm not sure if the current version supports 3.x. Think I saw once we upgrade to v9 that the lowest support would be 4.x.

* `GradleVersion` did not exist before 8.0 (?)

It's much older but for some reason not in the docs. We've been using since at least #5014 This usage appears to have been missed in that.

As discussed on Slack, longer term it would be good to see whether the Tooling API and models can now actually cover all of the introspection we need - make some of this someone else's problem!

[neilcsmith-net]

added a second commit which works analog to #8606 but locks the major version component of the returned version. Currently set to 9. This should make it a bit safer (+ it fits that gradle 9 started to use semantic versioning). Commits meant to be squashed if we decide to do that.

Makes sense! The change in #8606 was intended to stabilise the existing semantics, and remove the starting of two daemons / download of two distributions problem.

Is the services.gradle.org list by major version new??? I could swear that wasn't there when I did that PR. The wrapper has been enhanced to support specifying version like that in Gradle 9 so maybe it's been added since.

[neilcsmith-net]

Looks good to me with limited testing. New project working, and some old projects tested.

Added versioning API a good idea.

Thanks @mbien !

Aside : In testing old projects I'm curious why the changes in #5158 disable the Java runtime setting in certain circumstances? Seems hit and miss whether this can be changed on a broken project that needs a lower JDK.

[mbien]

just as note: this fixes the cycle (OOME) by excluding the updateDaemonJvm.vendor.* path

this had similar symptoms as #6674 (comment) but surfaced as OOME instead of stack overflow.

[sdedic]

Let me propose a different fix -- I've debugged this and (mea culpa !!!) it's caused by serializing STATIC properties reported by the metaobject. And in the JvmVendorSpec case, each instance has another set of 13 properties. Although recursive serialization of the same instance is guarded ... combinatiorial explosion is not.

[mbien]

GradleVersion did not exist before 8.0 (?)

I wondered about that too, but @lkishalmi explained to me on slack that I shouldn't worry about this since the class is in fact super old. My hypothesis is that the class moved from tooling to distribution (or the other way around) at least once, thats why its missing in javadoc.

getFirstLevelModuleDependencies() did not exist before gradle 4.0 (roughly); NB code seems to support even 3.1 (?)

the oldest gradle version where hello world project loading worked seems to be 5.0 but I could have made some mistakes while backporting the project config while testing.

going to squash

[sdedic]

The annoying part was to debug a daemon while extide/gradle/netbeans-gradle-tooling is trying to start daemons too, given that it is a gradle project ;)

FWIW, i use

tryme.args=-J-Dnetbeans.debug.gradle.info.action=true

in nbbuild/user.build.properties

The development IDE (and about everyone) happily gradles, but the debugged NetBeans creates another daemon instance. Yes, sometimes I need to kill all gradles

ps ax | grep gradle-launcher | grep -v 'grep' | sed -rn 's/ *([0-9]+).*/\1/p' | xargs kill

[mbien]

Is this PR intended to fix also org.gradle.util.VersionNumber ?

yes, this is also fixed by this PR

[MartinBalin]

Seems like I've cloned your repo, but still has old code. Sorry. Checking it

[MartinBalin]

After rebuilding from correct branch I can confirm project using Gradle 9 loads correctly.

[mbien]

since we have merges on hold atm and this would stabilize CI, I am going to merge this to delivery and sync back using #8698

RC 3 will be later this week so there would be still time to add more safeguards against introspection cycles if needed, without delaying other progress unnecessarily.