From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

&gt; Gradle now supports running on Java 20.
I'm confused about that, I've been running Gradle with Java 20 for a long time now (the toolchains are set to lower version). The release notes suggest that that the other way around was supported — run Gradle with Java 17 but use Jdk20 toolchain for compilation.

Where exactly this incompatibility with Java 20 manifests?

Kotlin &lt; 1.9 was not Java 20 compatible, so we could not guarantee full compatibility. Gradle 8.3 uses Kotlin 1.9 which is fully compatible.

Nice to know it worked for you though!

Ah :thinking_face: It's true Kotlin 1.8 had issues, although I've been also running JDK20 with Kotlin 1.8 too. On the other hand, using JDK20 toolchain was then not possible specifically because Kotlin didn't support it :smile:

I guess maybe I didn't have any problems because I don't use .kts/`buildSrc`

```The performance benefit these persistent compiler daemons introduce can vary depending on a wide range of factors. However, Gradle's internal performance tests show up to a 30% build time improvement for builds that are dominated by compiling Java sources.```
:heart_eyes: :heart_eyes: :heart_eyes:

On the other hand, I have almost 50 `GradleWorkerMain` in memory for 2 daemons. It is normal?

```$ jps|grep GradleWorkerMain|wc -l
      43```


How many max workers do you have configured? It's expected that Gradle creates more workers than `max workers`, which only controls how many workers are _working_ simultaneously. Which is unfortunate because it makes it that more difficult to establish how much memory Gradle will use

the only configuration I have is inside `gradle.properties`
```org.gradle.caching=true
org.gradle.configuration-cache=true
org.gradle.configureondemand=true
org.gradle.jvmargs=-Xmx2048M
org.gradle.parallel=true```

Then it'll use the number of available CPU cores (or threads, I don't recall) as default. It's a good idea to limit max workers according to available memory

Memory management of workers can certainly be improved, right now Gradle has a hard-coded limit of to leave 5% (bounded to [384M, 1G]) free, assuming it can inspect OS memory. It will continue to create workers as needed up to that much memory.

Workers are also killed after a certain amount of idle time, usually a few hours.

The other big challenge I’ve found with test workers is understanding how memory is distributed and what flags affect it. IIRC you give the daemon memory with a flag but another flag will give EACH test worker a certain amount of memory rather than distributing it across all of them

The Java 20 issue might not bite you if you use the Groovy DSL, but it will definitely bite you if you use the Kotlin DSL. Glad to see this is getting fixed.