Gradle init shall honor the configured Java Runtime

[lkishalmi]

Well, the issue is that running the IDE with Java 24, new Gradle project were initialized using unsupported JDK version, that results not updating the wrapper to the latest version.

That could result some unexpected behavior. Now the Java Runtime configured at Tools > Options > Java > Gradle will be used for the init and wrapper operations as well.

[mbien]

code looks good - thanks for filling the catch blocks. However I am not sure if this would work.

when testing on JDK 24 it picked 8.10 and gave up on the upgrade step (which would have been 8.12.1 and in future a JDK 24 compatible version). So this indicates that it still won't work in future?

edit: also first run I got this exception but only once - is likely a separate issue:

java.util.ConcurrentModificationException
	at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1230)
	at org.netbeans.modules.gradle.java.spi.support.JavaToolchainSupport.platformByHome(JavaToolchainSupport.java:70)
	at org.netbeans.modules.gradle.java.classpath.BootClassPathImpl.createPath(BootClassPathImpl.java:59)
	at org.netbeans.modules.gradle.java.classpath.AbstractGradleClassPathImpl.getResources(AbstractGradleClassPathImpl.java:108)
	at org.netbeans.api.java.classpath.ClassPath.entries(ClassPath.java:363)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.findDependencies(RepositoryUpdater.java:1891)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.access$2400(RepositoryUpdater.java:135)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$RootsWork.getDone(RepositoryUpdater.java:4965)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$InitialRootsWork.getDone(RepositoryUpdater.java:5842)
[catch] at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doTheWork(RepositoryUpdater.java:3452)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task._run(RepositoryUpdater.java:6197)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task.access$3400(RepositoryUpdater.java:5855)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2.lambda$call$0(RepositoryUpdater.java:6116)
	at org.openide.util.lookup.Lookups.executeWith(Lookups.java:288)
	at org.netbeans.modules.parsing.impl.RunWhenScanFinishedSupport.performScan(RunWhenScanFinishedSupport.java:83)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2.call(RepositoryUpdater.java:6116)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2.call(RepositoryUpdater.java:6112)
	at org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:153)
	at org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:335)
	at org.netbeans.modules.parsing.nb.DataObjectEnvFactory.runPriorityIO(DataObjectEnvFactory.java:118)
	at org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:67)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task.run(RepositoryUpdater.java:6112)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
	at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1403)
	at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
	at org.openide.util.lookup.Lookups.executeWith(Lookups.java:287)
	at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2018)

edit2: neil explained to me that I likely misunderstood the PR here. This is about having the option to downgrade the gradle RT as workaround (not about what we talked on slack of upgrading to latest in one go).

[neilcsmith-net]

Seems good to me, and a good fix for NB 25.

[neilcsmith-net]

In addition (as discussed on Slack), as a future step it would be good to remove the whole wrapper update phase and just pass the right Gradle version to the Tooling API and run the init step in that.

This, while a bad idea without caching and configuration, seems to work and leave the right wrapper in place -

public Set<FileObject> execute() {
    GradleConnector gconn = GradleConnector.newConnector();
    try {
         gconn.useGradleVersion(GradleDistributionManager.get().availableDistributions(true).get(0).getVersion());
     } catch (Exception ex) {
         Exceptions.printStackTrace(ex);
     }
     JavaRuntimeManager.JavaRuntime defaultRuntime = GradleExperimentalSettings.getDefault().getDefaultJavaRuntime();

[lkishalmi]

@mbien I think the tests needs to be updated to provide a JavaPlatformManager instance in the default lookup, where we can point a Gradle Supported JDK for Gradle Execution.

[mbien]

@mbien I think the tests needs to be updated to provide a JavaPlatformManager instance in the default lookup, where we can point a Gradle Supported JDK for Gradle Execution.

nothing against it in principle. Just so you know that we don't do such thing anywhere so far. For sake of simplicity the JDK is defined by the matrix and everything uses the same JDK within that instance of the job. Also how would tests run locally? Would it need two JDK paths?

#7871 is also not blocked by this, since gradle supports JDK 21 (and 23) and it can only test on 17 atm.

Long ago we had something like that for the build itself to influence the JDK used for the daemon f61c2c9#diff-7829468e86c1cc5d5133195b5cb48e1ff6c75e3e9203777f6b2e379d9e4882b3R114 which is gone now.