Standardisation of simple ABI features?


#1

One of the great things about targeting the JVM is the sophisticated OO ABI it provides, which stands in contrast to what you get in the C or C++ worlds. However, this great inheritance is slowly rotting away, as Java fails to keep up with language innovation.

The obvious fix is for the makers of Kotlin, Scala, Ceylon and perhaps other languages to get together and hammer out specifications for how to compile simple features that they all already agree on. These would become a part of the JVM ecosystem ABI.

Initial targets that hopefully shouldn’t have much mismatch between languages would be:

  • Arguments with default values/optional arguments
  • Named arguments (this is already standardised by Java but I don’t know if Kotlin uses it)
  • Companion objects/singletons
  • Nullability annotations

A standardisation effort like this would allow e.g. Scala code to call Kotin methods that have optional arguments and vice-versa, to access each others companion objects and so on.

Is there any interest in doing this?


#2

I’d vote for this in an ideal world, but in this one I imagine this would be very difficult to do primarily because of the following reasons:

  • Semantics of these features are slightly different in all languages. For example, default values for optional arguments in Scala are overridable in subclasses and, because of this, are implemented with virtual methods for each parameter, whereas in Kotlin the parameter’s default value causes a static method to be generated because it is semantically not overridable in subclasses.
  • All languages you listed already have stable releases and claim binary compatibility, so it would be very difficult for them to change anything in the ABI. For example, Scala’s companion object instance for class X is stored in a field named MODULE$ in the class X$, whereas in Kotlin the field is named INSTANCE in the class X. I don’t see how either Scala or Kotlin can change the naming of the companion object field without sacrificing binary compatibility with the old code.

#3

I guess one or the other could support both at once? It is perhaps not a high priority though. A shame about the default values.