New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Static method of object disappears after compilation #7225
Comments
Imported From: https://issues.scala-lang.org/browse/SI-7225?orig=1 |
@adriaanm said: Please experiment with variations on the following minimal example to see the error more directly. class Super {
// uncomment this and comment the last definition of get for the original report
// def get(): Any = null
}
class Foo extends Super
object Foo {
// no static forwarder generated in Foo when there's already one in Super
def get(): Foo = new Foo
// can't have two static methods with signatures that differ only in their return type
def get(): Any = null
} |
Bruno Grieder (bgrieder) said (edited on Mar 13, 2013 4:38:24 PM UTC): Actually, this is exactly the opposite: it is a Scala limitation; java does not have this limitation. For proof consider this In Scala import java.util.HashMap
class HashMapScala extends HashMap[ String, String ] {
}
object HashMapScala {
def get() : String = "dummy"
} In java import java.util.HashMap;
public class HashMapJava extends HashMap<String, String> {
private static final long serialVersionUID = 1L;
public static String get() {
return "dummy";
}
} In java, the static get() method is available in the the compiled code along with the non static get() method inherited from Hashmap. My bet is that the scala compiler only checks for method name collisions but does not check, as it should and javac does, for the methods signature: method name AND arguments. Only in the latter case you cannot have both a static and non static method generated. |
@retronym said: The method is accessible to Java via |
Bruno Grieder (bgrieder) said (edited on Mar 14, 2013 6:00:36 AM UTC): When you port Java code to Scala you may be caught in a situation where you have to port a Java Class that implements such a static method - and you can't. This is exactly what happened to us. You are then left with 2 choices if you want avoid breaking the rest of the code
Unfortunately, you cannot always refactor the rest of the code and you are just doomed. |
@adriaanm said: We're aware that Scala's approach to static methods is not ideal in the context of java interop. We've recently been discussing a new approach for code generation of methods in objects: https://groups.google.com/d/msg/scala-internals/vOps4k8CADY/-1k-08KRBzkJ I agree our interop story needs work here, so I've adjusted the priority. |
Using this very simple piece of code
the
get()
method is missing in the compiled code; a Java decompilation of theMyProperties
class yields (scala signature omitted)If
MyProperties
does not extendjava.util.Properties
however, theget()
method is generated.java.util.Properties
inherits thepublic V get(Object key)
fromjava.util.Dictionary
but that is a non static method with a different signature and this "works" in JavaA suggested workaround using
type
(author Régis Jean-Gilles) is stated below, but there does not seem to be a JVM related reason no to generate theget
method(sorry for the lack of rendered formatting)
The text was updated successfully, but these errors were encountered: