Update Kotlin 1.4.10 to leverage Kotlin SAM

[chao2zhang]

So that we do not need to declare a companion object implementing invoke operator

[pyricau]

Thanks!

Can we do this in a way that keeps the define maven dependency as Kotlin 1.3 so that consumers don't have to upgrade?

cc @zach-klippenstein who did this recently for Radiography.

[chao2zhang]

Good call. I do see the use case that we do not want library changes to be breaking for clients.

I am not familiar with maven publishing/dependency topics (My company used Ivy). If there are some examples that I could learn from that would be great. Otherwise, I can spend some time figuring it out.

[pyricau]

We've talked about it in this slack thread

See radiography: square/radiography#50

[chao2zhang]

There are still some limitations but I have verified that clients can keep Kotlin 1.3.72: Build scan

There is one caveat: If clients choose to keep Kotlin 1.3.72, they cannot leverage the invoke() overriding hack and have to declare an object as follows:

       object : OnHeapAnalyzedListener {
            override fun onHeapAnalyzed(heapAnalysis: HeapAnalysis) {
                TODO("Not yet implemented")
            }
        })

If they have 1.4 Kotlin IDE plugin installed, while on their build script still point to Kotlin 1.3, the IDE prompt to convert to lambda constructor would break their build.

[zach-klippenstein]

I think you'll also want to tell the compiler you're intentionally using an older stdlib version, so it doesn't complain. See https://github.com/square/radiography/pull/50/files#diff-392475fdf2bc320d17762ed97109a121R77

[chao2zhang]

I do find warnings from the console like
w: Runtime JAR files in the classpath have the version 1.3, which is older than the API version 1.4. Consider using the runtime of version 1.4, or pass '-api-version 1.3' explicitly to restrict the available APIs to the runtime of version 1.3. You can also pass '-language-version 1.3' instead, which will restrict not only the APIs to the specified version, but also the language features

Looks like we want to address those warnings.

[pyricau]

So that we do not need to declare a companion object implementing invoke operator

Question about that: what happens to existing code that was previously using that pattern? This is probably not binary compatible which is ok (LeakCanary is typically recompiled by consumers) but is it source compatible? ie if I drop in the new version of LeakCanary and recompile, will it work?

edit: it looks like yes?

edit2: unless they're using kotlin 1.3, I guess? In that case the API is now gone.

[chao2zhang]

If the client was using the syntax with LeakCanary 2.24:

        LeakCanary.config = LeakCanary.config.copy(onHeapAnalyzedListener = OnHeapAnalyzedListener {
                TODO("Not yet implemented")
        })

They need to update it to the following if using 1.3

        LeakCanary.config = LeakCanary.config.copy(onHeapAnalyzedListener = object : OnHeapAnalyzedListener {
            override fun onHeapAnalyzed(heapAnalysis: HeapAnalysis) {
                TODO("Not yet implemented")
            }
        })

If they update it to 1.4, the source code could remain unchanged.

[pyricau]

Thx!

Yeah it looks like there's no other way around, unless we create whole new separate interfaces and deprecate the old ones, which wouldn't be great either.

[pyricau]

@chao2zhang I think we should probably keep the companion object invoke operators for backward compatibility with Kotlin 1.3 users. That being said, I'm also excited about updating to 1.4. Do you think you could update the PR to bring the companion object invoke operators back?

Thanks!

[chao2zhang]

Definitely, but I would still propose to mark it as deprecated as this is a hacky workaround before Kotlin support SAM.

[pyricau]

Can we have both "fun" and the companion object? Does one rake precedence?

[chao2zhang]

We can. I verified it in a separate project depending on leak canary. It can compile successfully when in Kotlin 1.3 using the invoke hack. It also compiles successfully in Kotlin 1.4.

[pyricau]

Thanks! Sorry it took so long to merge :)