Support for method resolution including return type

[jozefdransfield]

The Java Language does not support method overloading by return type but the JVM specification does. It would be good if this could be supported so that languages or tools that use this feature will continue to work.

JVM Spec 4.3.4 : http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.3.4

"A method signature, defined by the production MethodTypeSignature, encodes the (possibly parameterized) types of the method's formal arguments and of the exceptions it has declared in its throws clause, its (possibly parameterized) return type, and any formal type parameters in the method declaration."

Example: see Proguard http://proguard.sourceforge.net/index.html#manual/usage.html (overloadaggressively)

"Counter-indication: the resulting class files fall within the Java bytecode specification (cfr. The Java Virtual Machine Specification, Second Edition, first paragraphs of Section 4.5 and Section 4.6), even though this kind of overloading is not allowed in the Java language (cfr. The Java Language Specification, Second Edition, Section 8.3 and Section 8.4.7). "

[szegedi]

I will look into this. It might be worthwhile to take into account when selecting the overloads. As you noted, since it isn't part of the JLS spec, there's no prescribed JLS semantics for use of this information in overloaded method resolution. I'm leaning towards only using it when there's several candidates that only differ in the return type, although if you have some other semantics in mind, please let me know.