Can I confirm my intuition that Compose isn t meant to offer kotlinlang #compose

Can I confirm my intuition that Compose isn't meant to offer JVM ABI compatibility, and thus that libraries which use Compose will always be version locked to that underlying Compose version and have to be recompiled when a new Compose comes out?

04/24/2023, 5:03 PM

Since 1.0, non-experimental APIs are binary compatible. Libraries do not need recompiled, although generally it's a good idea to do it occasionally to get the new output of the compiler which can be more efficient.

If you need to add new parameters you can do

@Composable fun Thing(
  foo: String = "foo",
  bar: String = "bar",
) {
  // ...
}
@Deprecated("", level = HIDDEN)
@JvmName("Thing")
@Composable fun OldThing(
  foo: String,
) {
  Thing(foo)
}

This is a general Kotlin problem for any library, though, right?

mikehearn

04/24/2023, 5:09 PM

Yeah exactly, that's why I wondered about it - seems hard to evolve Compose if every time a new parameter is added it requires boilerplate. A few years ago I suggested that the compiler could use invokedynamic to bind to methods that used default arguments but it was never implemented. Still, if the Compose team will do the work by hand anyway, then great!

04/24/2023, 5:14 PM

Yeah their hand is basically forced as tools enforce the binary compatibility.

mattinger

04/24/2023, 11:33 PM

Interesting @jw. I use the hidden level deprecation all the time. Never thought to use JvmName so that i could keep the internal api nicer.

04/24/2023, 11:37 PM

In this case it's because you wouldn't be able to call the new overload without it, at least not without also relying on its default values

#compose Join Slack