Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jdt-core-dev] Re: parseCompilationUnit

We do persist some information in index files, only the amount of
information necessary to drive the search process (declarations and
references for types, methods and fields).



                                                                                                                        
                      Michael Schneider                                                                                 
                      <michaels@xxxxxxx        To:       Philippe Mulet <philippe_mulet@xxxxxxx>                        
                      >                        cc:                                                                      
                                               Subject:  Re: parseCompilationUnit                                       
                      07/05/2002 05:10                                                                                  
                      PM                                                                                                
                                                                                                                        
                                                                                                                        




It is possible to persist the AST info, so that
data for large projects can be queried.
(similar to source navigator)


Just a thought,
Mike

Philippe Mulet wrote:

> Indeed, ASTs are not directly linked to each other. However, the
referenced
> item are sharing some common representations (bindings).
> I don't think any memory efficient tool could act any differently. ASTs
are
> quite big, and when dealing with a full workspace content, having all
ASTs
> in memory would be explosive.
>
> "Dirk Baeumer" <dirk_baeumer@xxxxxxx> wrote in message
> news:ag0rel$241$1@xxxxxxxxxxxxx...
>
>>Milind,
>>
>>in refactoring we have a similar problem and we solve it in the following
>>way.
>>
>>- we create AST per compilation unit.
>>- if we want to find out if one AST node represents the same Java element
>>
> as
>
>>  another AST node then we use the bindings provided by the AST (see
class
>>  IBinding). Inside one AST, bindings are identical if they represent the
>>same
>>  Java lanaguage element. Across ASTs you have to use IBinding.getKey()
>>  to find out if two bindings represent the same element.
>>
>>So using bindings will do exactly what you are looking for. They relate
>>
> AST
>
>>nodes to other AST nodes.
>>
>>HTH
>>
>>Dirk
>>
>>"Milind " <mulay_milind@xxxxxxxxxxx> wrote in message
>>news:afvs2b$nr9$1@xxxxxxxxxxxxx...
>>
>>>Then I am back to square one. If each AST tree is going to be different,
>>>how am I going to relate each other. I don't think eclipse is the
>>>developement platform I am looking for. I am really disappointed...
>>>
>>>
>>>
>>>
>>>Olivier Thomann wrote:
>>>
>>>
>>>>On Tue, 2 Jul 2002 11:19:18 +0000 (UTC), mulay_milind@xxxxxxxxxxx
>>>>(Milind) wrote:
>>>>
>>>>>OK, then how do I create a dependency graph for my entire project. If
>>>>>
> I
>
>>>>>pass each java file to the parseCompilationUnit in a loop, will the
>>>>>sucessive AST trees, be related to each other, so that I can see the
>>>>>
>>full
>>
>>>>>dependency graph of my project...
>>>>>
>>>>No, each AST tree will be separate from the others. I wonder if in
>>>>your case you should not work on .class files rather than source
>>>>files. .class files contain only resolved names. If you look at the
>>>>APIs in org.eclipse.jdt.core.util, you will find all you need to read
>>>>..class files.
>>>>--
>>>>Olivier
>>>>
>>>
>>>
>>
>
>








Back to the top