search

gradle / gradle

Adaptable, fast automation for all
https://gradle.org
Apache License 2.0
16.99k stars 4.77k forks source link

The Gradle API bytecode should contain parameter names #6391

Open eskatos opened 6 years ago

eskatos commented 6 years ago

including for interface methods as per the Java 8 bytecode spec.

This is mostly for better integration with the Kotlin/Java interoperability and will allow the kotlin compiler to reuse names of method parameters from Java interfaces when doing implementation by delegation.

The most visible issue without the parameter names in the bytecode is https://github.com/gradle/kotlin-dsl/issues/464. That very issue was fixed for Gradle 4.10 by hydrating the Gradle API bytecode with parameter names at gradle/kotlin-dsl build time, but it still applies to Kotlin plugin code compiled against the current Gradle API.

With Gradle 5.0 requiring Java 8 we could simply build gradle/gradle with Java 8 and the -parameters option to javac. Another option would be to move the existing build-time bytecode post-processing to hydrate it with parameter names from gradle/kotlin-dsl to gradle/gradle.

lptr commented 6 years ago

If we do this, do we need to also update the binary compatibility check to trigger on parameter name change?

eskatos commented 6 years ago

In Kotlin, named arguments are not allowed when invoking non-Kotlin functions, yet. In practice they are only displayed as hints in the IDE. Changing parameter names on a Java interface should not be a breaking change. We could err on the safe side and update the binary compatibility check to assert on parameter name changes, once parameter names are present in the bytecode.

oehme commented 6 years ago

As discussed on Slack, this probably won't be possible in the 5.0 time frame. It would require untangling of all the code that is used in workers from all the code that is part of the public API. The former needs to remain Java 6 compatible while we want the latter to compile for Java 8.

wolfs commented 2 years ago

@eskatos To re-iterate the from from @lptr above:

If we do this, do we need to also update the binary compatibility check to trigger on parameter name change?

Does this mean changing a parameter is now a binary or source breaking change or it is not?

bamboo commented 2 years ago

Does this mean changing a parameter is now a binary or source breaking change or it is not?

A source breaking change since Java parameter names from gradle-api are used in generated Kotlin extensions.