[bmc7505]

I was surprised to learn that in Kotlin, it is possible to disambiguate overloaded functions based only on their return type. I had no idea the JVM even supports such semantics. [1]

[1]: http://stackoverflow.com/q/42916801/1772342

[mbel]

According you your link JVM does not support this feature. It's implemented by Kotlin itself. I guess it's probably some kind of name-mangling scheme.

[masklinn]

According to the link Java/Javac does not support the feature.

The JVM does, `bar(foo: List<String>): String` can be compiled to `bar(Ljava/util/List;)Ljava/lang/String;` and `bar(foo: List<Int>): Int` to `bar(Ljava/util/list;)Ljava/lang/Integer;` or somesuch, there is no ambiguity at the bytecode level.

In fact, the documentation for Class#getMethod specifically outlines this issue[0]:

> Note that there may be more than one matching method in a class because while the Java language forbids a class to declare multiple methods with the same signature but different return types, the Java virtual machine does not.

[0] http://docs.oracle.com/javase/8/docs/api/java/lang/Class.htm...

[mbel]

The article describes Dalvik which is different from JVM, so it's not really a proof.

But you are actually right. It looks that JVM bytecode includes full function signature in function invocation: https://www.ibm.com/developerworks/library/it-haggar_bytecod... (if I'm reading examples correctly).

[masklinn]

> The article describes Dalvik which is different from JVM, so it's not really a proof.

My comment describes the actual JVM, hence having linked to official Java/JVM documentation.

[mbel]

Sorry, I misread it.

[barrkel]

It could hardly be otherwise, or the JVM would need to do overload resolution at runtime, which would not be a pleasant experience for anyone.

[mbel]

Well, it could just use function name and leave it to javac/kotlin/other JVM front end to handle overloads and generate unique names. Although that wouldn't work nice with refection and other run-time features I guess.

[masklinn]

It would also screw up interop. You'd basically have the issue everyone has when trying to call C++.

[bmc7505]

Note that the first example compiles without any further changes, producing valid JVM bytecode.