Is there any good reason why this is a limitation? why cant kotlin compiler generate overloaded equivalents so that java users don’t suffer?
I’m trying to convince my company to use kotlin for our library, bringing argument that this is transparent for java users… but things like this make it difficult.
Usually, there is a good reason why something like this is not supported, does anyone know why?
Personally I do not understand why we should use some ugly annotation just to make it usable from jvm… these things should be the default not the exception IMO…
Is there any performance gain from not using jvm overloads to implement default methods?
I suspect this is related to the fact that @JvmOverloads makes sense only if we generate implementations of methods and interfaces are abstract, so their methods don’t have implementations. Although, I think it would be nice to have an option to generate default methods in that case.
Elizarov points out that this isn’t a trivial thing to enable. I’m not familiar with the details myself but maybe there is an alternative that would satisfy your use case in the mean time.
Seems like there are some workarounds with compiler options that work with suppressing the error. And of course, you can write out the functions the same way you do in Java by writing out the multiple overloads.
Maybe a good alternative request until a full feature can be designed would be an annotation or lint rule to throw an error (or warning) when defaults are used in the target interface. That way you can safely continue working without worrying about Java compatibility and you can upgrade in the future.
EDIT:
If anyone has a list of corner cases for this feature, I’d love to hear it.
The first few corner cases I can think of are addressed with @JvmOverloads usage when within a class.
If it does not incur a performance penalty to achieve java friendly code-gen why not?
You may write libraries in kotlin and not think about someone using it from java,
just like java library contributors didn’t think about kotlin…
But kotlin does everything to be super friendly when you use java,
but not friendly when you use kotlin from java? and that should not be a default?
Because it would have many side-effects, some of them really problematic?
You focus on your specific needs and assume these needs themselves justify adding a new feature. But you don’t seem to even try to consider what side effects that change will have. What problems it will introduce, how it will affect others. You don’t consider how the change would work internally and whether it is easy to implement, hard to implement or even entirely impossible.
If Kotlin lacks some kind of interoperability with Java, this is not due to intentional decision to make Java developers life harder. Usually, this is due to limitations in Java. After all, Kotlin was created to fix some problems in Java. But it can’t fix the Java itself.
That was the point of the question to find out about side effects and reasons behind not having this. Its literally in the first sentence in my question.
