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
$

I think you might be confusing the CLASSPATH environment variable and the classpath used to resolve dependencies in the scalac compiler.

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@gmail.com> wrote:

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.

On Fri, Jan 30, 2009 at 1:35 PM, Antonio Cunei <scala_ml@cunei.com> wrote:

According to this test, it does work as intended:

So maybe another of the multitude of problems with the Eclipse plugin?

On Fri, Jan 30, 2009 at 1:43 PM, Alex Boisvert <boisvert@intalio.com> wrote:

I think you might be confusing the CLASSPATH environment variable and the classpath used to resolve dependencies in the scalac compiler.

e.g. make sure to use "scalac -classpath /path/to/your/java/classes"

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).

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

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
>

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

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

On Fri, Jan 30, 2009 at 3:51 PM, Miles Sabin <miles@milessabin.com> wrote:

On Fri, Jan 30, 2009 at 7:44 PM, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:
> On Fri, Jan 30, 2009 at 1:35 PM, Antonio Cunei <scala_ml@cunei.com> wrote:
>>
>> According to this test, it does work as intended:
>
> So maybe another of the multitude of problems with the Eclipse plugin?

Charming ...

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.
 

FWIW, I suspect that you probably have a misconfigured inter-project
dependency of some sort, but with the information you've provided, who
knows ...

I'll check that out.

Thanks,
Nils

That damn wavy underline represents an error in the "presentation compiler" (or autocomplete).  Whenever you see one, you can expect autocomplete to fail.  If you use case clases (which includes ~ 100% of my projects), you'll see them almost all the time.

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@gmail.com> wrote:

On Fri, Jan 30, 2009 at 3:51 PM, Miles Sabin <miles@milessabin.com> wrote:

On Fri, Jan 30, 2009 at 7:44 PM, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:
> On Fri, Jan 30, 2009 at 1:35 PM, Antonio Cunei <scala_ml@cunei.com> wrote:
>>
>> According to this test, it does work as intended:
>
> So maybe another of the multitude of problems with the Eclipse plugin?

Charming ...

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.
 

FWIW, I suspect that you probably have a misconfigured inter-project
dependency of some sort, but with the information you've provided, who
knows ...

I'll check that out.

Thanks,
Nils

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.

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.

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.

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.

I will be with you, although I don't know how much time I will have to work on the plugin.

Kind regards,
Jan

2009/2/1 Josh Suereth <joshua.suereth@gmail.com>

That damn wavy underline represents an error in the "presentation compiler" (or autocomplete).  Whenever you see one, you can expect autocomplete to fail.  If you use case clases (which includes ~ 100% of my projects), you'll see them almost all the time.

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@gmail.com> wrote:

On Fri, Jan 30, 2009 at 3:51 PM, Miles Sabin <miles@milessabin.com> wrote:

On Fri, Jan 30, 2009 at 7:44 PM, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:
> On Fri, Jan 30, 2009 at 1:35 PM, Antonio Cunei <scala_ml@cunei.com> wrote:
>>
>> According to this test, it does work as intended:
>
> So maybe another of the multitude of problems with the Eclipse plugin?

Charming ...

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.
 

FWIW, I suspect that you probably have a misconfigured inter-project
dependency of some sort, but with the information you've provided, who
knows ...

I'll check that out.

Thanks,
Nils

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!