Blockquote I think the documentation 3 of how Kotlin code is represented in Java is really good, but maybe you can point out where it is unclear.
I think the many threads on stackoverflow on this topic, this lengthy thread, and similar criticisms I’ve read on Kotlin from java developers suggest that there is a problem here with people getting confused and that people are genuinely wondering what the big deal is around not simply supporting static. Just saying, this is a topic that comes up regularly and the tone in this thread strikes me as a bit defensive.
Blockquote I don’t think a static keyword would fit in Kotlin. Kotlin itself is build to work without statics. I can’t talk about the conversion tool from java to kotlin as I never used it, so maybe it needs to be improved but this is no reason to change the language.
I believe the opposite is the case and your argument seems to boil down to language esthetics. Kotlin’s compiler supports static just fine, so does the JVM. Kotlin is all about providing syntactic sugar and less verbose ways of doing things and making the transition from Java seamless. Static methods seem to be a strange exception. The implementation of static seems trivial, so that’s not the issue. It’s clearly more concise, easier to explain to java developers, and there seem to be lots of other keywords including “inline” that you could equally argue should not be language keywords that made it into the language.
The conversion tool does the wrong thing with static methods unless it is acceptable to you to have it refactor all your Java code to make it aware of the .Companion inner class (speaking of ugly). It seems to not be aware of the annotation that avoids this, so this might be fixable. IMHO having kotlin’s .Companion exposed to java code is not really acceptable in any published Java API (speaking of ugly).