Re: [jdt-core-dev] Analyzing class dependencies

[Jan Ploski <jpljpl@xxxxxx>]

Hello,

> As you noticed, the DOM AST isn't cheap. It provides fine grain information
> which the internal ASTs don't care about and thus are way more expensive.

Thanks for confirming that.

> We are considering improving the DOM AST support to make it faster to
> create. However the bindings you need for your purpose are somewhat
> problematic. They provide a nice world to navigate into, but have a big
> memory footprint.

I understand. In my sample project, there are 26000 simple type
references. For each reference, I must record from which type it
originates (i.e. its fully qualified name), and to which type it points.
Currently, I let my tweaked batch compiler perform all the usual steps,
but instead of generating code, I traverse each AST hunting for
TypeReference nodes.

I also saw that the compiler stores some sort of reference table with
each type on its own (referencedTypes), but these don't appear to be
what I want (they are incoming references?...). I am probably duplicating
some work already done by the compiler.

This duplication and the fact that I had to copy a bunch of JDT classes
to make it work (which I would rather extend or reuse without changes)
are my concerns.

> Are you only interesting in build information, i.e. reflecting the binaries
> processed by the compiler ?

I am foremost interested in collecting references from source files.
For an end user, those references are particularly interesting. She will
be able to select a class, see all referenced (or referencing) classes
at a glance, and for each reference jump to the place in code where it
occurs.

Best regards -
Jan Ploski