Accessing the Java AST from Scala

You may need to add org.eclipse.jdt.core.manipulation (or maybe
org.eclipse.ltk.core.refactoring) to your dependencies.

I had this problem too, with org.eclipse.jdt.core._
For example I could not access jdt.core.IComplilationUnit.getAllTypes
For a while I actually solved this by creating a java class with helper
methods.

The problem disappeared after adding org.eclipse.jdt.core.manipulation
to required plug-ins. I think it has to do with some missing classes on
the classpath that don't necessarily show up in the API, but that are
somehow referenced (maybe not even directly) from those types that cause
problems.

Erkki

martinvz wrote:
> I'm trying to access the abstract syntax tree classes (for Java) in Eclipse
> JDT from Scala. I have no problem accessing the classes in
> org.eclipse.jdt.core.dom themselves (such as ASTNode, CompilationUnit,
> TypeDeclaration, MethodDeclaration etc). What I can't understand, however,
> is why I can not access some of the methods on CompilationUnit. I can access
> all the methods on TypeDeclaration and MethodDeclaration all methods on
> CompilationUnit, except for rewrite(...), setPackage(), and types().
>
> The exact error message I get is:
> value types is not a member of org.eclipse.jdt.core.dom.CompilationUnit
>
> The only pattern I can see is that these three methods are last in
> alphabetical order, not counting inherited members. Has anyone else
> experienced a similar problem? I'm very new to Scala, so I'm hopefully just
> missing something...
>
> I should also mention that I'm using the Scala Eclipse plugin and that the
> methods do show up in the Outline and Hierarchy views. They don't show up
> when using code completion though.
>
>
> Martin
>

(Seems like my message didn't get through.)

I've also had problems with methods not appearing in CompilationUnit,
and I think it was types(), but I'm not entirely sure. I'd get a
compile error if I tried to use the method, even though it existed.
Unfortunately I don't have more information as I didn't fiddle with it
much.

I did what Erkki described --- create a Java class ...

This was around mid February with the latest nightly, I'll try it again
on the weekend once I have time.

Mohamed

Erkki Lindpere wrote:
> You may need to add org.eclipse.jdt.core.manipulation (or maybe
> org.eclipse.ltk.core.refactoring) to your dependencies.
>
> I had this problem too, with org.eclipse.jdt.core._
> For example I could not access jdt.core.IComplilationUnit.getAllTypes
> For a while I actually solved this by creating a java class with
> helper methods.
>
> The problem disappeared after adding org.eclipse.jdt.core.manipulation
> to required plug-ins. I think it has to do with some missing classes
> on the classpath that don't necessarily show up in the API, but that
> are somehow referenced (maybe not even directly) from those types that
> cause problems.
>
> Erkki
>
> martinvz wrote:
>> I'm trying to access the abstract syntax tree classes (for Java) in
>> Eclipse
>> JDT from Scala. I have no problem accessing the classes in
>> org.eclipse.jdt.core.dom themselves (such as ASTNode, CompilationUnit,
>> TypeDeclaration, MethodDeclaration etc). What I can't understand,
>> however,
>> is why I can not access some of the methods on CompilationUnit. I can
>> access
>> all the methods on TypeDeclaration and MethodDeclaration all methods on
>> CompilationUnit, except for rewrite(...), setPackage(), and types().
>>
>> The exact error message I get is:
>> value types is not a member of
>> org.eclipse.jdt.core.dom.CompilationUnit
>>
>> The only pattern I can see is that these three methods are last in
>> alphabetical order, not counting inherited members. Has anyone else
>> experienced a similar problem? I'm very new to Scala, so I'm
>> hopefully just
>> missing something...
>>
>> I should also mention that I'm using the Scala Eclipse plugin and
>> that the
>> methods do show up in the Outline and Hierarchy views. They don't
>> show up
>> when using code completion though.
>>
>>
>> Martin
>>

Erkki Lindpere-2 wrote:
>
> I had this problem too, with org.eclipse.jdt.core._
> For example I could not access jdt.core.IComplilationUnit.getAllTypes
>

That seems to be the same problem as I am having, although the identifier
names seem to have changed a bit. I'm using version 3.4.4.v_894_R34x (taken
from the file name of the jar file).

Erkki Lindpere-2 wrote:
>
> The problem disappeared after adding org.eclipse.jdt.core.manipulation
> to required plug-ins. I think it has to do with some missing classes on
> the classpath that don't necessarily show up in the API, but that are
> somehow referenced (maybe not even directly) from those types that cause
> problems.
>

It doesn't seem to work for me. I added it as a required plug-in, but the
compiler can still not find the mentioned methods. There are actually a few
more methods that don't show up on the content assist list. These are all
the protected methods defined on CompilationUnit that come after rewrite()
in alphabetical order. So in total, there are 9 methods from rewrite() to
types() that don't show up and that the compiler can not find either.

The problem sounds more like a bug in either the compiler or the Eclipse
plug-in to me. Does anyone know what the Scala JDT Weaving plug-in does? How
does the content assist work? Does it call on the Scala compiler? It seems
like they (content assist and the compiler) agree, but they disagree with
the Outline and Hierarchy views. I'm using the 2.7.4.final version of the
plug-in.

On Tue, May 12, 2009 at 10:15 PM, martinvz
wrote:
> The problem sounds more like a bug in either the compiler or the Eclipse
> plug-in to me. Does anyone know what the Scala JDT Weaving plug-in does? How
> does the content assist work? Does it call on the Scala compiler?

Yes it does.

> It seems like they (content assist and the compiler) agree, but they disagree
> with the Outline and Hierarchy views. I'm using the 2.7.4.final version of the
> plug-in.

I'm not quite sure what the disagreement is. The compiler is reporting
that the methods are inaccessible but the outline view is showing that
nevertheless they exist? Are you sure that's not actually correct?

Cheers,

Miles

Miles Sabin wrote:
>
> I'm not quite sure what the disagreement is. The compiler is reporting
> that the methods are inaccessible but the outline view is showing that
> nevertheless they exist? Are you sure that's not actually correct?
>

Content assist actually shows non-public methods as well, but that is not a
big problem to me. The problem is that it does not show any of the methods
(public or non-public) defined on Compilation from rewrite() and on in
alphabetical order. Even if I manually enter any of these methods (one of
the public ones of course), it doesn't compile.

Martin

On Thu, May 14, 2009 at 9:24 AM, martinvz
wrote:
> Content assist actually shows non-public methods as well, but that is not a
> big problem to me. The problem is that it does not show any of the methods
> (public or non-public) defined on Compilation from rewrite() and on in
> alphabetical order. Even if I manually enter any of these methods (one of
> the public ones of course), it doesn't compile.

That suggests to me that Erkki has it right: you're most likely
missing a required plugin ... once you've added it to your build you
should find that both auto-complete and compilation behave as
expected.

Cheers,

Miles

Miles Sabin wrote:
>
> That suggests to me that Erkki has it right: you're most likely
> missing a required plugin ... once you've added it to your build you
> should find that both auto-complete and compilation behave as
> expected.
>

I tried adding the one Erkki suggested, but it still did not compile. I
might try adding some other plugins as well some other time. I will tell you
if I get it to work.

Just for my understanding, how can adding plugins (which I guess means
adding classes to the classpath) make some existing, but inaccessible
methods on existing classes accessible? I suppose these plugins contain only
Java classes, so it doesn't have anything to do with implicits, does it? Or
is it that the plugin contains another version of the same class that should
be added before the existing plugin on the classpath? In that case I don't
understand why the methods show up in the Outline view even with the version
of the class in the plugin I have a dependency to today. However it works,
it feels very unintuitive for someone coming from Java.

On Thu, May 14, 2009 at 11:58 AM, martinvz
wrote:
> Just for my understanding, how can adding plugins (which I guess means
> adding classes to the classpath) make some existing, but inaccessible
> methods on existing classes accessible?

This is a generic JVM issue, nothing to do with Scala per-se. Consider
any case where (already compiled) class A (which is on your classpath)
mentions class B (which isn't) in the signature of one of it's
methods. Other source files (Java or Scala) will compile against the
parts of A which don't depend on B, but not against the parts of A
which do.

Cheers,

Miles