adding yet another parameter, even with a default, is source-compatible but is not binary-compatible
In the absence of
@JvmOverloads you mean?
That’s pretty nasty. I hadn’t actually thought about the binary compatibility of adding default arguments before … I vaguely recall the way this is compiled is rather tricky in the absence of the overloads annotation, with some bitmasking being done for efficiency, right?
I like to think that I’m more familiar with Kotlin and bytecode than most developers - even so, I can imagine myself adding a default parameter and not realising I’d broken the library ABI.
At the very least it would be helpful for there to be a page in the documentation discussing what changes are and are not binary compatible.
Now to the wider question:
- In the wake of winning the Oracle lawsuits, it seems that Android has re-committed to upgrading its support for the Java platform. Android O introduces the java.lang.invoke package, with classes that are only useful with invokedynamic like
CallSite. Whilst I don’t know what they plan to do, the fact that Java 9 is doubling down on indy-based compilation means they’ll eventually either have to add support for indy or make their “de-sugarer” even more complex. I suspect they will eventually implement this opcode.
- Yes, Kotlin is big on Android, but Kotlin can also get big in other areas: on the server and desktop. App containers don’t really exist on Android but they are common in the rest of the Java space, and “eliminate binary compatibility as a thing to think about” would be a really useful feature here. Why should Android hold back server/desktop Kotlin when a feature only affects compilation strategy?
- You are using Kotlin in IntelliJ. This is good. But IntelliJ is an app container and thus it’s in JetBrains’ own interest to ensure that Kotlin plugins that benefit from Kotlin APIs exposed by IntelliJ don’t needlessly break across IntelliJ upgrades. An indy-based compilation strategy could assist here.
Overall I think this would be a good upgrade. Eliminating the need to think about binary compatibility is the kind of mental simplification that Kotlin tends to support (e.g. hiding the differences between boxed and unboxed types as far as possible).
(btw to explain my keenness on this feature, I am developing an app container in Kotlin too)