I think I need help with some weird issue. I have a stack trace that looks like this:

Caused by: org.gradle.internal.instantiation.ClassGenerationException: Could not generate a decorated class for type MyTask
  at org.gradle.internal.instantiation.generator.AbstractClassGenerator.generateUnderLock(AbstractClassGenerator.java:245)

...

Caused by: java.lang.IllegalArgumentException: Cannot have abstract method MyTask.getServices().
  at org.gradle.internal.instantiation.generator.AbstractClassGenerator.assertNotAbstract(AbstractClassGenerator.java:386)
  at org.gradle.internal.instantiation.generator.AbstractClassGenerator.inspectType(AbstractClassGenerator.java:312)
  at org.gradle.internal.instantiation.generator.AbstractClassGenerator.generateUnderLock(AbstractClassGenerator.java:214)

This is really odd, since

MyTask

is basically

abstract class MyTask @Inject constructor() : DefaultTask() {
  @get:Internal
  abstract val services: ListProperty<String>
  
  init {
    services.convention(listOf("foobar"))
  }
  
  // ... rest of file
}

This is from Gradle 7.5; is there a reason why Gradle would have a problem with

services

, given that it has worked every other time this same pattern is used?

you can't name it

services

because that collides with an internal method

Stupid random bear traps.

The JVM includes the return type in method signatures (aka method descriptors) when linking/resolving them, only the Java language forbids you from overriding a method with the same (or contravariant) arguments and a non-covariant return type. And Kotlin is not Java, so it's allowed to generate bytecode with those two methods, but then it can indeed cause issues with method resolution (https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-5.html#jvms-5.4.3.3) or reflection (https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Class.html#getMethod(java.lang.String,java.lang.Class...); this is actually even called out here) At first glance, I'd say it could be seen as a bug in Gradle for not handling this in its internal reflection utilities, but clearly this is kind of an edge case and Gradle would be in its own right to reject it (but then maybe error out with a better error message?)