[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-core-dev] Analyzing class dependencies
|
Jan,
the latest Eclipse build (I20030422) already contains a call graph view. So
you might
want to look at this before you start implementing your own. May be you can
extend
this one.
Are you aware of the org.eclipse.jdt.core.dom package? It contains public
classes to
build an AST for a compilation unit, so there is no need to hack the
internal compiler
to achieve your goals.
The mailing lists are reserved for discussions about evolving Eclips
itself. User
questions like yours are better posted to the news group eclipse.tools.jdt.
Dirk
Jan Ploski
<jpljpl@xxxxxx>
Sent by: To
jdt-core-dev-admi jdt-core-dev@xxxxxxxxxxx
n@xxxxxxxxxxx cc
Subject
04/27/2003 05:46 [jdt-core-dev] Analyzing class
PM dependencies
Please respond to
jdt-core-dev@ecli
pse.org
Hello,
I am writing a plugin that is supposed to let you browse through package
and class dependencies of a project. You select a source package or class,
all referenced packages and classes are highlighted. It should work in
the other direction, too.
As far as I know, there are no existing plugins yet that provide such
functionality (apart from the Search feature).
Anyway, I am now pondering how to efficiently generate the dependency
graph for my plugin's use.
My first idea was to rely on JavaSearchEngine, which worked fine for
finding package references (though it takes 16 seconds for 630 classes
on my 1.6 GHz Linux PC). However, it does not work so well for finding
type references: what I get from JavaSearchEngine are source ranges that
enclose both qualified and (mostly) simple type names. I have to resolve
the simple type names myself, but doing this through the DOM API
(with resolveBindings) takes 500 msec per type. So generating the
whole graph in this way would take more than 5 minutes. Too long.
I could resolve the references lazily in response to user actions
(i.e. expanding/collapsing nodes or changing selection in my browser),
but it will still be too slow to be usable (several seconds response
time for each user action).
So I thought I could tweak the JDT compiler to achieve my goal.
After all, the entire from scratch compilation of my 630 classes
takes less than a minute, and I could skip code generation altogether.
It seems that overriding
org.eclipse.jdt.internal.compiler.Compiler.process would suffice.
More specifically, I would traverse each CompilationUnitDeclaration
with my own visitor, storing away information about every
SingleTypeReference and QualifiedTypeReference found.
The big question is, how can I do it from my plugin WITHOUT altering
jdt.internal's source code. I tried to start by copying the JavaBuilder
class source into my project, so I could alter it and implement my own
DependencyBuilder, but it references a lot of package-scope fields
and types. Is extending JavaBuilder an option? Even if I managed that,
the compiler is created by BatchImageBuilder, which itself is instantiated
by the private method buildAll. That I would not be able to override.
I am also not sure if I need all of JavaBuilder's functionality:
I am not interested in doing incremental builds at this time.
How else can I dig through to the JDT Compiler to obtain
a CompilationUnitDeclaration for each compilation unit in my project?
Can anyone suggest the path of least resistance?
Also, I may be approaching the problem from a wrong direction:
is my assumption that tweaking the compiler and making it traverse
its internal AST instead of generating code in the end phase is
the right (efficient) way to generate a class dependency graph
for an entire project?
Thanks for your support,
Jan Ploski
_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev
