We are going to switch Kotlin compiler build from ...

# compiler

[max.kammerer]

We are going to switch Kotlin compiler build from -Xjvm-default=disable mode to -Xjvm-default=all. This change will keep source compatibility but could break binary one if you are using compiler internals. If you use some compiler internal interfaces could you please list them in thread. In such case we will try to also ship binary compatible stubs for DefaultImpls classes (that would gone away in all mode)

UPD: this post is not about switching default value for -Xjvm-default. The aim of it to avoid any occasional breakage for compiler extension, plugins

[max.kammerer]

Thread

[mbonnin]

Out of curiosity, how come -Xjvm-default=all doesn't break binary compatibility? If app.jar contains bytecode that references DefaultImpls in lib-1.0.jar , I'd expect shipping a newer version of the lib (lib-1.1.jar without the DefaultImpls ) and putting that in the classpath would result in a runtime crash?

[max.kammerer]

@mbonnin yes, it will cause runtime crash. -Xjvm-default option also provides modes that keep binary compatibility (there will be also additional option with @JvmDefaultWithCompatibility annotation in -Xjvm-default=all mode since 1.6.20), that could be used by libraries authors. In original message I'm wrote not about default switch in -Xjvm-default but about shipping compiler built with -Xjvm-default=all + @JvmDefaultWithCompatibility flags

[mbonnin]

Thanks for the clarification 🙏 . What is the recommendation for library authors moving forward?
Should we use @JvmDefaultWithCompatibility everywhere to be able to be used with newer versions of the compiler? That sounds like a lot of bytecode to be shipped all around? I'd rather keep the current behaviour until the next breaking version of my lib (if that's something that newer compilers can read?)

[max.kammerer]

What is the recommendation for library authors moving forward?

I assume that we speak about libraries but not about compiler extension/plugins. Than...

Should we use @JvmDefaultWithCompatibility everywhere to be able to be used with newer versions of the compiler?

...both variants (old and new one ) would work smoothly.

I'd rather keep the current behaviour until the next breaking version of my lib (if that's something that newer compilers can read?)

And yes, switching to -Xjvm-default=X will require proper library versioning

That sounds like a lot of bytecode to be shipped all around?

What do you mean?

[mbonnin]

Thanks for that link 🙏

I assume that we speak about libraries but not about compiler extension/plugins. Than...

Correct 👍

What do you mean? (

Ideally, I'd like to continue compiling my lib with with -Xjvm-default=disable (which I understand is the current 1.6 behaviour)
I understand -Xjvm-default=all-compatibility will generate both default methods and DefaultImpls but I'd better avoid this to avoid the extra bytecode (having both the default method as well as DefaultImpls).
Am I correct assuming that once the behaviour changes in the compiler, I can continue compiling my lib with `-Xjvm-default=disable`and newer versions of the compiler will still be able to use it?

[max.kammerer]

Am I correct assuming that once the behaviour changes in the compiler

We are not changing compiler behaviour yet. -Xjvm-default=disable is still default one and would be default one in several upcoming release. disable mode would be available after switching default value for this option. We will provide migration guide to -Xjvm-default=all late

[max.kammerer]

having both the default method as well as DefaultImpls

DefaultImpls will have simple stubs that would invoke default methods from interface

[ralf]

In what release do you expect this change?

[max.kammerer]

In what release do you expect this change?

@ralf If you asking about original post (switching compilation mode for Kotlin compiler build), it will be in 1.7

[ralf]

That’s helpful to know. Thanks! There were often binary incompatibilities between major compiler versions, e.g. I currently release my compiler plugin twice for 1.5.32 and 1.6.0. I had to do the same for 1.4 and 1.5 until most repositories updated to the latest Kotlin version. I guess it’ll be similar for 1.7 (it’s not a big deal in my opinion).