RE: [ajdt-dev] -XnoWeave and gutters

["Mik Kersten" <beatmik@xxxxxxx>]

> -----Original Message-----
> From: ajdt-dev-bounces@xxxxxxxxxxx [mailto:ajdt-dev-bounces@xxxxxxxxxxx]
...
> On that topic I actually think that AJDT itself should not rely at all
> on what the weaver emits. I think Eclipse JDT structures (same for
> Intellij PSI structures and so on of modern IDEs) are rich enough to
> provide all information needed to do the matching. The key piece then
> becomes the reflective access to the aspects information so that their
> structure (binary or source) can be taken as input (ok that 's
> probably a huge work).
> An analogy is that somehow modern IDE don't do compilation (weaving)
> and don't query the java.lang.reflect API (weaver output) to show you
> a class hierarchy (advised by/advises), but they do that with their
> internals, handling both source and binary represented super classes
> (I actually think that the draft of AJ support that surfaced in an old
> version of IntelliJ was doing so).

That would be nice...  But we need to keep in mind that AOP tools have
considerably more work to do in resolving program structure, because this
structure is not hierarchical.  To resolve OO dependencies and provide type
hierarchy and content assist views all that JDT and other IDEs need to do is
maintain a dependency index and eagerly parse out related files on demand.
But what happens when you ask for subtypes of Object?  The IDE will hang
until it has parsed every file.  When you want to eagerly ask for the
structure of a point cut that matches *.*(..) we run into a similar problem.
For dealing with crosscutting structure in general tools need access to the
whole type system.  The weaver provides that, and can export the relevant
parts (e.g. as a structure model of crosscutting links).  

That said, it's not impossible to do what you propose and quite some time
ago we did spend time designing an eager structure model.  It would depend
on a pointcut fast-match mechanism to quickly figure out the files that need
to be parsed to get the affects / affected by links.  But such a mechanism
would be actually doing a lot of the work that a weaver is doing, and it
would probably be doing it in the same incremental way that the current
compile/weave works, sharing code and possibly execution... which brings us
to an architecture similar to what we have now.

Mik

--
http://kerstens.org/mik