What is the advantage of "companion object" vs static keyword

That’s not true. Package level functions are available to Java Code. Every file that contains package-level declarations will produce a class, under which the declarations are accessible as static members, so, it’s exactly what you need. By default, a file called Strings.kt will produce a file-class called StringsKt, but you can even rename that for more intuitive calling from java code, by putting a @file:JvmName("StringUtils") annotation at the very top of the file. From the Java POV, this will produce a class called StringUtils, which has all the package-level functions of the file accessible as static methods, it’s exactly what you want when calling from Java.

I’m all for great interoperability, but I think the omission of statics from the language was a good design choice and not worth compromising when there are perfectly fine alternatives if you need those statics to call from Java.

PS.:
Quick word about the inline and @InlineOnly thing: @InlineOnly is an internal annotation marking functions that should never be called directly without inlining. This might seem to be the same as regular inline at first, but regular inlined functions can still be called from Java Code, where they obviously can’t be inlined so they are called as regular functions. @InlineOnly tells the compiler “This is a function that can only be called from Kotlin, don’t make it available as a regular callable function to other bytecode.” Code outside the internal Kotlin libraries can’t use that annotation, it’s basically just to hide all those Kotlin utilities from Java code.

4 Likes