Improve support for using latest Gradle version in new projects.

[neilcsmith-net]

Support for using the latest Gradle version when initializing a project was added initially in #6333 but it's somewhat temperamental. It does not always pick up later versions, and it works by reinitializing the wrapper, potentially downloading two different Gradle versions and/or failing on some JDKs inside the init step.

This PR adds a new method to GradleDistributionManager to query the current (latest) version from the Gradle web service at https://services.gradle.org/versions/current

Support for setting a Gradle version is added in to TemplateOperation.InitOperation. If set, this is passed to the Tooling API - https://docs.gradle.org/current/javadoc/org/gradle/tooling/GradleConnector.html#useGradleVersion(java.lang.String) This downloads the required Gradle version and runs the init step with it.

The current version is queried in the wizard, replacing the previous additional wrapper step. In future this should allow the wizard to be enhanced to offer a choice of Gradle version.

With this change, the new Gradle project wizard should currently pick up the current 8.14.2 version, rather than the 8.14 version that matches the bundled Tooling API. The Tooling API is designed to be forwards compatible, so this should reduce the pressure to update it very late in the release cycle or wait on Gradle releases.

This change was also discussed on Slack and in #8461

[mbien]

With this change, the new Gradle project wizard should currently pick up the current 8.14.2 version, rather than the 8.14

can confirm. NB 26 downloads two dists and starts two daemons during new project creation. While using this PR it will download and start only the current version - awesome.

I suppose this makes first wizard use also faster - but it still feels slow even after second use for some reason (it works though!).

.. so this should reduce the pressure to update it very late in the release cycle or wait on Gradle releases.

Thanks! :) I didn't have issues doing those update PRs but the timing was usually bad for us.

[neilcsmith-net]

I suppose this makes first wizard use also faster - but it still feels slow even after second use for some reason (it works though!).

Could you test with an open Output window with all tabs closed (ctrl-f4 on the internal tabs to keep it open)? Then you should be able to see the output when the init task completes behind the wizard. With the Gradle distribution already downloaded, this is taking about 1s for me on first new project, and < 50 ms on subsequent.

The project preload step then takes an additional 10-15 seconds!

I don't think this change affects that time, as it's taking similar in NB26 for me. We could potentially cache the current version lookup, as it's polling the service each time, but at the moment that seems minimal compared to the project load stage?

.. so this should reduce the pressure to update it very late in the release cycle or wait on Gradle releases.

Thanks! :) I didn't have issues doing those update PRs but the timing was usually bad for us.

Yes, your PR was late in the cycle so missed a lot of testing, which wasn't ideal, but not overly problematic. I linked the wrong initial PR above. The latest version addition was made in #6333 because otherwise we had to either wait for the full Gradle release, or have that version of the IDE always initiating new Gradle projects with a release candidate of Gradle. That situation was a lot more problematic!

[mbien]

init task took 4s (according to the output window), until the wizard window closed ~28s. (dist was already downloaded in .gradle)

IMO: half minute until hello world is pretty bad

[mbien]

might be potentially something with the signaling again #7030
the project delete task used to take a minute before I did that ^^

[neilcsmith-net]

Not sure, it seems to be specifically spending a lot of time in https://github.com/apache/netbeans/blob/master/extide/gradle/src/org/netbeans/modules/gradle/loaders/LegacyProjectLoader.java#L658 which is actually running the model build inside https://docs.gradle.org/current/javadoc/org/gradle/tooling/BuildActionExecuter.html#run()

[lkishalmi]

Does this slowness happens with this PR or can be reproduced with NB26 as well?

For me, just testing with NB26, the first project creation took 7s, the following 2 is around 100ms (the init task), after that NB loads the project, which would take another 3-5 seconds.

[lkishalmi]

Seems to be working.

[mbien]

Does this slowness happens with this PR or can be reproduced with NB26 as well?

yes. Measured second project creation on NB 26 and it took 31s till the dialog disappeared. The two daemons were not running, the first warmup run was only there to remove noise from dist downloads.

Third project (with daemons running) took 20s.

[lkishalmi]

Strange. For the record I was testing on Ubuntu 25.04, with JDK 21. (The project were using Java 24).
Now I've tested it on another computer Ubuntu 25.04 NetBeans running on Java 24. The first project load took time 20-30s. The subsequent project creations is just 3-5 seconds. Checking on Raspberry Pi400...

[lkishalmi]

So even or Raspberry Pi400, Java 34. The first project creation, with downloading Gradle and everything it took 3 minutes and 40 seconds. However the subsequent project creations were less than 20s , usually spending ~8secs loading the project. (That's with NB26, Ubuntu 25.04, Java 24)

[neilcsmith-net]

Thanks for the reviews. I'll merge this change tomorrow if no other comment.

We should take the speed issue discussion elsewhere, as it's not affected by this change. That a Pi400 is loading a basic project twice as fast as an i7-14700 tells me there's something rather curious going on there. 😄