- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
trait extending Java interface
Is it possible for a trait to extend a Java interface? I've tried, but get this error (in Eclipse):
"<interface> is not a member of <package>"
Where the package is the package that does in fact contain the Java interface.
The trait is simply this:
import my.pack.age.JavaInterface
trait MyTrait extends JavaInterface {
def extraMethod(ref: AnyRef)
}
results in:
"JavaInterface is not a member of my.pack.age"
And, yes, it's on the classpath.
"<interface> is not a member of <package>"
Where the package is the package that does in fact contain the Java interface.
The trait is simply this:
import my.pack.age.JavaInterface
trait MyTrait extends JavaInterface {
def extraMethod(ref: AnyRef)
}
results in:
"JavaInterface is not a member of my.pack.age"
And, yes, it's on the classpath.
Re: trait extending Java interface
e.g. make sure to use "scalac -classpath /path/to/your/java/classes"
alex
On Fri, Jan 30, 2009 at 11:08 AM, Nils Kilden-Pedersen <nilskp [at] gmail [dot] com> wrote:
Re: trait extending Java interface
I've modified the "Java Build Path" on the Scala project to include the right Eclipse java project. I assume that's enough (it seems to work for other things).
Re: trait extending Java interface
Nils Kilden-Pedersen wrote:
> Is it possible for a trait to extend a Java interface? I've tried, but get
> this error (in Eclipse):
>
> " is not a member of "
>
> Where the package is the package that does in fact contain the Java
> interface.
>
> The trait is simply this:
>
> import my.pack.age.JavaInterface
>
> trait MyTrait extends JavaInterface {
> def extraMethod(ref: AnyRef)
> }
>
> results in:
> "JavaInterface is not a member of my.pack.age"
>
> And, yes, it's on the classpath.
>
According to this test, it does work as intended:
$ cat J.java
package my.pack.age;
interface J {
int test(float f);
}
$ cat S.scala
package my.pack.age
trait S extends J {
def bar(x:Int):Float
def foo(x:Int):Float=test(x)
}
$ javac -d . J.java
$ scalac S.scala
$
Re: trait extending Java interface
So maybe another of the multitude of problems with the Eclipse plugin?
Re: trait extending Java interface
On Fri, Jan 30, 2009 at 7:44 PM, Nils Kilden-Pedersen wrote:
> On Fri, Jan 30, 2009 at 1:35 PM, Antonio Cunei wrote:
>>
>> According to this test, it does work as intended:
>
> So maybe another of the multitude of problems with the Eclipse plugin?
Charming ...
Alex's example is just fine in the 2.7.3.final plugin ...
If you're a able to put together a small reproducible test case,
please create a ticket and add the zipped project(s) as an attachment.
FWIW, I suspect that you probably have a misconfigured inter-project
dependency of some sort, but with the information you've provided, who
knows ...
Cheers,
Miles
Re: trait extending Java interface
I wasn't trying to be charming. The plugin is workable, but very immature. I have just done a clean install, and I see these little issues all the time, e.g. autocomplete does not work for protected methods in sub classes, and it doesn't seem to work reliably when extending Java classes either. Also I see those wavy warning underlines in random places, without any warnings actually being reported.
I understand that Eclipse for Java has had many years of development and it's very hard to get the same functionality for another language quickly, but please don't deny there are a lot of work left to do with the plugin.
I'll check that out.
Thanks,
Nils
Re: trait extending Java interface
You're right, the eclipse plugin is early, and it's taken a new approach to IDEs where the plugin attempts to use the same code as the compiler. The bonus is you automatically parse everything scala, the downside is that you have diverging goals (Compiler should strictly enforce the language, the IDE should losely enforce it to parse partially-formed programs). Sean mentioned once that while technically feasible, this approach might not be socially feasible.
What I want to challenge the scala eclipse users is to contribute to the plugin! Don't understand the compiler? Start trying to write plugins, start trying to do things like annotation processing. I think if enough of us get 'hip' to the design, we can start cleaning up and maintaining the plugin. Almost all IDE-related functions rely on this working (syntax-highlighting, code-completion, refactoring), so I think we need to throw some development effort. I know Miles is leading this, and he has done a lot to improve the plugin. Anyone willing to join me in trying to make the eclipse plugin nice to work with again? Perhaps we should start a team with a mailing list and promote some activity!
-Josh
On Sat, Jan 31, 2009 at 7:39 PM, Nils Kilden-Pedersen <nilskp [at] gmail [dot] com> wrote:
Re: trait extending Java interface
You can count me in. But I realize that it will take many moons before
I completely grasp the architecture of this thing.
BR,
John
On Sun, Feb 1, 2009 at 4:29 AM, Josh Suereth wrote:
> What I want to challenge the scala eclipse users is to contribute to the
> plugin! Don't understand the compiler? Start trying to write plugins,
> start trying to do things like annotation processing. I think if enough of
> us get 'hip' to the design, we can start cleaning up and maintaining the
> plugin. Almost all IDE-related functions rely on this working
> (syntax-highlighting, code-completion, refactoring), so I think we need to
> throw some development effort. I know Miles is leading this, and he has
> done a lot to improve the plugin. Anyone willing to join me in trying to
> make the eclipse plugin nice to work with again? Perhaps we should start a
> team with a mailing list and promote some activity!
Re: trait extending Java interface
Kind regards,
Jan
2009/2/1 Josh Suereth <joshua [dot] suereth [at] gmail [dot] com>
Re: trait extending Java interface
I don't think the compiler's goal differs from the IDE's here. The better the compiler does at filling in the gaps in broken code, the better error messages it can give.
scalac is certainly worse than javac in this respect though - it has a habit of reporting one error, which when fixed results in another compile error that could probably have been detected in the previous compile, for maybe 8 or so iterations.
As a non-Eclipse user, I would appreciate a toy walkthrough of using some functionality implemented by the plugin from outside the Eclipse GUI, possibly with some refactoring involved (which can be done inside the Eclipse GUI) to make it less decoupled. It would be great if Paul's autocompleting interpreter could use Eclipse's completion, or if I could get emacs' scala-mode to use Eclipse's code formatter, or if I could have svn format Scala code on checkin.
And of course, that would mean there'd be a larger group of people interested in that source, probably resulting in better cleanup. Or deseaning, whichever you want to call it.
Re: trait extending Java interface
I wrote,
> Alex's example is just fine in the 2.7.3.final plugin ...
^^^^^^
Sorry, that should have been "Toni's example ...".
Cheers,
Miles
Re: trait extending Java interface
The plugin does have issues with multiple source directories (I just
coin them miles, I'll write a ticket as soon a I can make a minimal
project)
I tend to use q4e + maven for mutli-projects and have not had the
reference issue.
On Jan 30, 2009, at 4:51 PM, Miles Sabin wrote:
> On Fri, Jan 30, 2009 at 7:44 PM, Nils Kilden-Pedersen > wrote:
>> On Fri, Jan 30, 2009 at 1:35 PM, Antonio Cunei
>> wrote:
>>>
>>> According to this test, it does work as intended:
>>
>> So maybe another of the multitude of problems with the Eclipse
>> plugin?
>
> Charming ...
>
> Alex's example is just fine in the 2.7.3.final plugin ...
>
> If you're a able to put together a small reproducible test case,
> please create a ticket and add the zipped project(s) as an attachment.
>
> FWIW, I suspect that you probably have a misconfigured inter-project
> dependency of some sort, but with the information you've provided, who
> knows ...
>
> Cheers,
>
>
> Miles
>
Re: trait extending Java interface
On Fri, Jan 30, 2009 at 10:01 PM, Josh Suereth wrote:
> The plugin does have issues with multiple source directories (I just coin
> them miles, I'll write a ticket as soon a I can make a minimal project)
Multiple source/output directories aren't currently supported at all
... that's a scalac constraint.
Cheers,
Miles