Skip to content

Gradle init shall honor the configured Java Runtime#8223

Merged
ebarboni merged 1 commit intoapache:deliveryfrom
lkishalmi:gradle-init-honor-jdk
Feb 6, 2025
Merged

Gradle init shall honor the configured Java Runtime#8223
ebarboni merged 1 commit intoapache:deliveryfrom
lkishalmi:gradle-init-honor-jdk

Conversation

@lkishalmi
Copy link
Copy Markdown
Contributor

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.

@lkishalmi lkishalmi added the Gradle [ci] enable "build tools" tests label Feb 5, 2025
@lkishalmi lkishalmi added this to the NB25 milestone Feb 5, 2025
@mbien
Copy link
Copy Markdown
Member

mbien commented Feb 5, 2025

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:

Details
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).

Copy link
Copy Markdown
Member

@neilcsmith-net neilcsmith-net left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@neilcsmith-net
Copy link
Copy Markdown
Member

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
Copy link
Copy Markdown
Contributor Author

@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
Copy link
Copy Markdown
Member

mbien commented Feb 6, 2025

@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.

@ebarboni ebarboni merged commit 7593166 into apache:delivery Feb 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Gradle [ci] enable "build tools" tests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants