This message was deleted.

This is the corresponding PR: https://github.com/gradle/gradle/pull/22232 Maybe you should ask there 🙂

Oh, thank you, I missed that the upgrade guide specifically mentioned the need for plugins to be recompiled.

BTW, if you need to support multiple Gradle versions, this is possible since Gradle 7: https://docs.gradle.org/current/userguide/implementing_gradle_plugins.html#plugin-with-variants

Out of curiosity (I'm not related to the development of the aforementioned plugin), and to follow on the idea to provide different variants, how would you approach the need to target versions 7 and 8 in that specific situation, where we have source compatibility (only the return type got changed) ? Any way for compiling against an arbitrary Gradle API, as

gradleApi()

only provides the current API?

There is nothing built-in yet, but the Nokee guys publish those jars

Nice to know, thank you 🙂

Hi @Fiouz, you are correct this changes a stable API during a major version upgrade. Thank you, @Vampire, for pointing out the note in the upgrade guide. You will have to recompile plugins that are statically calling this method. We have a problem with applying the standard lifecycle in the case of wanting to narrow or otherwise change method return types while keeping method names constant. If we

@Deprecated

the method, then we have to provide a replacement - but it wouldn’t be a permanent replacement, since we want the API to keep the same method name. If we did this, anyone wanting to keep their builds free of deprecation warnings would have to migrate to the new method. Then, once we

@Deprecated

that new method, they would have to migrate back. This would stretch out the migration cycle and introduce a lot of churn on both our side and the author’s side. We have identified many other APIs where similar improvements could be made, for instance

SourceSetOutput

, where

FileCollection

return types really ought to be `ConfigurableFileCollection`s, and are thinking about better ways to ease the pain of transition for plugin authors for 9.0 and later major versions. We hoped that this particular change would be small enough that it wouldn’t affect most authors, but realized the potential consequences. We have other potential work in this area of the API that could require it, which is why we went ahead, along with issuing a warning in the upgrade notes.

Any way for compiling against an arbitrary Gradle API, as gradleApi() only provides the current API?

We are also discussing potential ways to make this easier. Sorry for the trouble this may cause, but we hope it’s ultimately worth it as we continue to evolve our API to be more consistent and useful.

IIRC the bytecode can contain overloads with same argument list but different return types, you just can't write such a thing in Java; so maybe an annotation on the methods and some post-processing of the compiled bytecode could add back those signatures to keep binary compatibility? (and if the method in bytecode is properly marked as a synthetized method –or whatever the name– then compiling against the new API would "link" to the new method so it's forward-compatible with Gradle 9 or 10 that would remove the bytecode manipulation)

Such a "trick" would be great if possible, simplifying upgrades for users and plugin providers.

This is pretty much exactly what has been suggested and we’re researching if it could work.

if you write in Kotlin, it will compile this just fine

fun foo(): SomeType

@JvmName("foo")
fun legacyFoo(): SomeOtherType

@Tom Tresansky, would you have any news on the research to implement backward compatibility (is there any GitHub issue we can follow)? Gradle 8.0-rc-2 still exhibits the same symptom (

NoSuchMethodError

for APIs that were not marked as deprecated/incubating); is there any flag I can enable to turn on an experimental compatibility layer? Or should we just assume that affected plugins will just break with Gradle 8, until authors release a compatible variant/version? (that would delay adoption of Gradle 8)

Nothing specific to share yet. This is still very much in the discussion phase.