cashapp
Eliminate redundant synthetic overloads in LicenseeExtension
This doesn't seem safe, nor desired. For one, it breaks binary compatibility if on the VERY rare chance someone has compiled their own plugin against our API. But aside from that, it exposes multiple overloads of the same functions to Kotlin when it really only should ever see one.
it breaks binary compatibility if on the VERY rare chance someone has compiled their own plugin against our API
I tested the case, it's binary compatible for code written in Java and Kotlin, which implements LicenseeExtension. BTW, it allows users to override the six functions marked as @JvmSynthetic before, if they want.
it exposes multiple overloads of the same functions to Kotlin when it really only should ever see one
it doesn't change the number of overloads for Kotlin.
METHODS:
old │ new │ diff
─────┼─────┼────────────
754 │ 746 │ -8 (+0 -8)
- app.cash.licensee.LicenseeExtension allowDependency$default(LicenseeExtension, String, String, String, Action, int, Object)
- app.cash.licensee.LicenseeExtension allowDependency$default(LicenseeExtension, Provider, Action, int, Object)
- app.cash.licensee.LicenseeExtension allowDependency$lambda$2(LicenseeExtension$AllowDependencyOptions)
- app.cash.licensee.LicenseeExtension allowDependency$lambda$3(LicenseeExtension$AllowDependencyOptions)
- app.cash.licensee.LicenseeExtension allowUrl$default(LicenseeExtension, String, Action, int, Object)
- app.cash.licensee.LicenseeExtension allowUrl$lambda$1(LicenseeExtension$AllowUrlOptions)
- app.cash.licensee.LicenseeExtension ignoreDependencies$default(LicenseeExtension, String, String, Action, int, Object)
- app.cash.licensee.LicenseeExtension ignoreDependencies$lambda$2(LicenseeExtension$IgnoreDependencyOptions)
And it will be binary incompatible if a Kotlin caller is invoking one of the functions without specifying an Action, as their code will link against the $default version of the function which has now been removed.
Kotlin should not be seeing the functions which don't have the Action.
Actually, they can see the functions without the PR or not.
And it will be binary incompatible if a Kotlin caller is invoking one of the functions without specifying an Action
I can't reproduce, is there something missing?
Your script is being recompiled–that's testing source compatibility. For binary compatibility you need to compile a class against the old API and then try to run it with the new API.
Okay I tried and it seems like we just were lucky here in that Kotlin will always link against the non-default function where possible. I originally meant to hide the other variants from being visible from Kotlin, too.
I think we want to use @JvmOverloads, though, as that will retain binary compatibility while also only presenting a single function to Kotlin.
We could switch to an abstract class. I can't remember if they work there. Nor can I remember if that's binary compatible.
It will break binary compatible if an interfere extends LicenseeExtension. I would address the convertion into a followup.