Addressing issue * https://github.com/spring-projects/spring-boot/issues/37878
resulted in changes in this code: * https://github.com/spring-projects/spring-boot/blob/793aca60d2d6ad4ff1618bc19672038cd4755120/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/main/java/org/springframework/boot/gradle/tasks/bundling/BootArchiveSupport.java#L153
The problem with the change is that it should call the fallback code (the old API methods, like copySpec::getDirMode and copySpec::getFileMode) also via reflection, because as it is now, we are unabled to remove them (they've been deprecated for a while now in Gradle).
We intend to do the removal in Gradle 9, which is in the near future and this would completely prevent us from doing so.
Comment From: wilkinsona
This is similar to https://github.com/spring-projects/spring-boot/issues/38164. The problem's due to the use of a method reference. When the method's absent, this results in a failure at runtime even if the method isn't called. Rather than using reflection, we should be able to avoid the problem by using a lambda instead of the method reference.
Comment From: cms04
As far as I understand issue #39431, using lambdas instead of method references might not solve the problem.
But maybe that's a mistake in my thinking because the fallback.get() statement will never be reached when the method is executed with Gradle 9.0 (unlike the method call to configuration.licenseKey(licenseKey) mentioned in the other issue).
In #41606 I implemented a solution with reflection (as suggested by @jbartok). This is the most fail-safe solution in my opinion.
Comment From: wilkinsona
But maybe that's a mistake in my thinking because the fallback.get() statement will never be reached
Yes, that's the case. The supplier will never be called so the absence of the method does not matter.
Comment From: jbartok
I would think that even if the fallback lambda is never called, once you upgrade to a Gradle version's API, that no longer has the method from the fallback, you would not be able to compile your code. That's why I suggested using reflection.
Comment From: jbartok
In #41606 I implemented a solution with reflection (as suggested by @jbartok). This is the most fail-safe solution in my opinion.
LGTM
Comment From: wilkinsona
once you upgrade to a Gradle version's API, that no longer has the method from the fallback, you would not be able to compile your code
I suspect that we will have dropped support for Gradle 8.2 and earlier by the time we're compiling against the Gradle 9 API. At that point, we can remove the use of reflection entirely. Until then, I much prefer the additional compile-time checking that minimising the use of reflection provides.