| AST and Java Model relation [message #257488] |
Wed, 19 November 2008 14:42  |
Eclipse User |
|
|
|
Originally posted by: aker1121.yahoo.com
Hi JDT tool group,
I have just been given an assigment to extend JDT for a customer. A truly
great job.
I have found some very good articels (and postings on this newsgroup) etc,
but I'm still a bit confused about the relation
between the AST and the Java Model. As I understand it the AST is the result
of parsing a CompilationUnit
(e.g. class), but at the same time the Java Model is involved somewhere and
I think perhaps the Model keeps all
the symbols for the entire project and holds references to several AST (per
class involved in project). But I'm not sure.
Can someone explain this to me a bit more?
Any hint or help appreciated!!
/A
|
|
|
| Re: AST and Java Model relation [message #257501 is a reply to message #257488] |
Wed, 19 November 2008 17:54  |
| Eclipse User |
|
|
|
Aker wrote:
> Hi JDT tool group,
>
> I have just been given an assigment to extend JDT for a customer. A truly
> great job.
>
> I have found some very good articels (and postings on this newsgroup) etc,
> but I'm still a bit confused about the relation
> between the AST and the Java Model. As I understand it the AST is the result
> of parsing a CompilationUnit
> (e.g. class), but at the same time the Java Model is involved somewhere and
> I think perhaps the Model keeps all
> the symbols for the entire project and holds references to several AST (per
> class involved in project). But I'm not sure.
>
> Can someone explain this to me a bit more?
The Java Model is coarser-grained: it has less information. But its
information is more readily and cheaply available. To get an AST, you
have to compile, which is slow. To get a type from the Java Model, you
just need to have it on the build path.
Generally if you are just asking about types (e.g., what methods does a
class have), the Java Model is what you want. If you are trying to
manipulate code or look inside methods, you need an AST.
Also be aware that there are a couple of different typesystems in there,
partly because of the history of the Eclipse IDE. So be wary for what
package a type is coming from and whether it has "internal,"
"compiler.lookup", etc. in the name. You'll find many reuses of given
type names and even of hierarchies, in different coexisting packages.
As I say, this is mainly just because of backwards-compatibility issues
when bringing together previously-separate projects.
|
|
|
| Re: AST and Java Model relation [message #257538 is a reply to message #257501] |
Thu, 20 November 2008 14:15 |
| Eclipse User |
|
|
|
Originally posted by: aker1121.yahoo.com
Hi and thanks for answer.
So when the AST has been created the Java Model is updated with parts of the
information from the AST, or
is the Java Model created without any info from the AST at all?
BR
A
"Walter Harley" <eclipse@cafewalter.com> skrev i meddelandet
news:gg25g0$qnq$1@build.eclipse.org...
> Aker wrote:
>> Hi JDT tool group,
>>
>> I have just been given an assigment to extend JDT for a customer. A
>> truly great job.
>>
>> I have found some very good articels (and postings on this newsgroup)
>> etc, but I'm still a bit confused about the relation
>> between the AST and the Java Model. As I understand it the AST is the
>> result of parsing a CompilationUnit
>> (e.g. class), but at the same time the Java Model is involved somewhere
>> and I think perhaps the Model keeps all
>> the symbols for the entire project and holds references to several AST
>> (per class involved in project). But I'm not sure.
>>
>> Can someone explain this to me a bit more?
>
> The Java Model is coarser-grained: it has less information. But its
> information is more readily and cheaply available. To get an AST, you
> have to compile, which is slow. To get a type from the Java Model, you
> just need to have it on the build path.
>
> Generally if you are just asking about types (e.g., what methods does a
> class have), the Java Model is what you want. If you are trying to
> manipulate code or look inside methods, you need an AST.
>
> Also be aware that there are a couple of different typesystems in there,
> partly because of the history of the Eclipse IDE. So be wary for what
> package a type is coming from and whether it has "internal,"
> "compiler.lookup", etc. in the name. You'll find many reuses of given
> type names and even of hierarchies, in different coexisting packages. As I
> say, this is mainly just because of backwards-compatibility issues when
> bringing together previously-separate projects.
|
|
|
Powered by
FUDForum. Page generated in 0.03458 seconds
Home