After upgrading to Boot 3.3.0 I noticed that the Gradle configuration cache throws an error. This is related to the configuration of the Boot plugin's buildInfo. With this config:

plugins.withId('org.springframework.boot') {
  springBoot {
    buildInfo {
      properties {
        excludes = ['time']
      }
    }
  }
}

I'm getting this error when running Gradle with the config cache enabled:

Configuration cache state could not be cached: field `writeLock` of `org.springframework.util.function.SingletonSupplier` bean found in field `creationTime` of `org.springframework.boot.gradle.tasks.buildinfo.BuildInfoProperties` bean found in field `properties` of task `:bootBuildInfo` of type `org.springframework.boot.gradle.tasks.buildinfo.BuildInfo`: error writing value of type 'java.util.concurrent.locks.ReentrantLock'
> Unable to make field private final java.util.concurrent.locks.ReentrantLock$Sync java.util.concurrent.locks.ReentrantLock.sync accessible: module java.base does not "opens java.util.concurrent.locks" to unnamed module @d0d7a47f

Here's a project that reproduces the problem: just run a regular build to see the error. gradle-config-cache.zip

This problem did not occur with Boot 3.2.x versions.

Comment From: WeisSeb

Seeing the same problem with Boot 3.2.6 and 3.3.0. Earlier versions do not have this issue. This seems to come down to BuildInfoProperties using the SingletonSupplier of springframework.spring-core. ~~Boot 3.2.5 comes with Spring Framework 6.1.6 where the SingletonSupplier does not have the writeLock field. Boot 3.2.6 and 3.3.0 use Spring Framework 6.1.8 where the afformentioned field exists in SingletonSupplier~~

Removing the buildInfo configuration or disabling the configuration cache is currently a workaround for us, but not really an optimal solution

EDIT: Boot 3.2.5 comes with Spring Framework 6.1.6 where SingletonSupplier.writeLock exists, however spring-boot-gradle-plugin:3.2.5 comes with springframework.spring-core:6.0.10 where SingletonSupplier.writeLock does not exist

Comment From: quaff

I think it should be handled at Gradle side.

Comment From: jkuipers

I just tested that as a workaround, you can add this line to your gradle.properties:

org.gradle.jvmargs=--add-opens java.base/java.util.concurrent.locks=ALL-UNNAMED

Comment From: wilkinsona

Thanks, @jkuipers, and apologies for the regression. This is an unanticipated side-effect of https://github.com/spring-projects/spring-boot/issues/40074. You can also work around the problem by using Gradle 8.6 or earlier.