I'm getting a Platform declaration clash even with...
# getting-started
e
I'm getting a Platform declaration clash even with
@OverloadResolutionByLambdaReturnType
for these functions
Platform declaration clash: The following declarations have the same JVM signature (generateListing(Ljava/lang/Integer;Ljava/lang/String;Lkotlin/jvm/functions/Function1;)Ljava/util/Iterator;):
fun generateListing(maxAmount: Int? = ..., after: String? = ..., func: (String?) -> CommitList): Iterator<Commit> defined in lakefs
fun generateListing(maxAmount: Int? = ..., after: String? = ..., func: (String?) -> DiffList): Iterator<Diff> defined in lakefs
fun generateListing(maxAmount: Int? = ..., after: String? = ..., func: (String?) -> ObjectStatsList): Iterator<ObjectStats> defined in lakefs
fun generateListing(maxAmount: Int? = ..., after: String? = ..., func: (String?) -> RefList): Iterator<Ref> defined in lakefs
Why? Shouldn't this work?
h
The return type isn’t part of the Java function signature.
Technically Kotlin could add the return type to the Kotlin function signature (ignoring the problematic case when calling without a assignment) and could generate valid JVM byte code but you will loose Java interop so it is not implemented (and possibly never will). As a workaround use JvmName
e
OverloadResolutionByLambdaReturnType
should make
func
signature unique, given its return type (docs)
h
The function resolution of the Kotlin compiler has nothing to do with the Java signature clash, you still need JvmName to prevent the latter, see https://github.com/JetBrains/kotlin/blob/171ea3571c4c1f2f0b23e3c9448e635889392f67/libraries/stdlib/api/js/kotlin.text.kt#L339 for a sample.
👍 1
e
you were right, it worked, thanks
I really wish Kotlin would add that
h
Well, this won't be compatible with Java. It also makes calls weird if you don't care about the result.
e
well,
JvmName
could provide compatibility