When I have a scala singleton object that extends a trait, I cannot use the object in Java code as this type. Trying to assign the singleton object (i.e. MyClass$.MODULE$, or returned by a ref() method as demonstrated) to a variable of that type results in an assignment error in Eclipse. Casting is not possible either.
However, the byte-code is generated correctly by the Eclipse compiler and the created program runs just fine.
When I add another singleton object to the .scala file containing the object in question, the errors become unchecked-conversion warnings.
For more details please see the attached example of the problem, which contains demo code and the exact Eclipse error messages.
However, the byte-code is generated correctly by the Eclipse compiler and the created program runs just fine.
When I add another singleton object to the .scala file containing the object in question, the errors become unchecked-conversion warnings.
For more details please see the attached example of the problem, which contains demo code and the exact Eclipse error messages.
Leave a comment
on 2015-05-10 11:34 *
By Iulian Dragos
One thing you can try is to put them in some package. The empty (or default, in Java terminology) has very strange semantics. At any rate, this is a problem in the Eclipse Java compiler, so there's little chance we can fix it.
Of course in the original problem, the files were in a package. Only the minimal example I created is in the default package, but also shows the same symptoms when I put all classes in a package.
Are you sure that this is a problem in the Eclipse Java compiler? If I put the generated .class files from the above example in to a jar that I put on the build path, the identical code shows no errors at all. To me this feels like the Scala plugin is generating a wrong in-memory version of the generated bytecode, or AST, or something like that. The generated .class files seem to be absolutely fine.
Are you sure that this is a problem in the Eclipse Java compiler? If I put the generated .class files from the above example in to a jar that I put on the build path, the identical code shows no errors at all. To me this feels like the Scala plugin is generating a wrong in-memory version of the generated bytecode, or AST, or something like that. The generated .class files seem to be absolutely fine.
No news and we don't have plans to work on this.
That's unfortunate. I would have expected that bugs, especially where Scala IDE compiles(?) something different than the scala compiler, would at least be worth looking at.
I noticed that I have not explained my real-life usecase: I'm using Play templates from a java application, trying to handle them generically by assigning them to a variable of the Interface they implement, e.g. Template1[MyModel]. This triggers the above issue, as described in the minimal example.
(Since it can reproduced without anything Play-related, it's definitely not the fault of the Play2 plugin. )
I noticed that I have not explained my real-life usecase: I'm using Play templates from a java application, trying to handle them generically by assigning them to a variable of the Interface they implement, e.g. Template1[MyModel]. This triggers the above issue, as described in the minimal example.
(Since it can reproduced without anything Play-related, it's definitely not the fault of the Play2 plugin. )
on 2016-04-19 12:20 *
By Simon Schäfer
I don't know where exactly the problem is. I guess we don't translate Scala code correctly to what the Java compiler can understand. But it is only a bug in the typechecker, it doesn't affect the bytecode and therefore the code can be executed. It is annoying to see these false compilation errors but we simply have more important issues to resolve right now.
No file chosen
You have an empty file field. Please select or remove it.
| Name | Size | ||
|---|---|---|---|
| BugDemo.java | 1.55 KB | Added by oxc on 2015-05-09 - Upload new version | |
| Implementor.scala | 537 Bytes | Added by oxc on 2015-05-09 - Upload new version |