[ajdt-dev] one structure model to rule them all

["Mik Kersten" <beatmik@xxxxxxx>]

We finally seem to be both have more support for working directly with the
Java Model, and more need to do so.  Here's an idea for a light-weight
update to our architecture that will give us transparent access for working
with the relationship map using either the IJavaElements or
IProgramElements.

The idea is that we change the handle identifiers, used for storing entries
in the map, to be the same those used by the JavaModel, i.e.
IJavaElement.getHandleIdentifier().  That will allow us to ask for
relationships for IJavaElements, and get back a list of handles that an
adapter can turn into IJavaElements.  

Currently our identifiers are a source location including path, line, and
column number.  The Java model uses the handles that look like the
following, "=Project-l/src<pkg1{Foo.java[Foo~m1", which uniquely identify
members, are stable across builds and Eclipse invocations, but don't go
below the member signature.  So our adapter will have to extend these by
appending either line/column or offset information to reach at "code"
elements (e.g. calls, handlers).  That's doable, and these handles should
just get ignored by JavaCore as desired.  But I'm wondering what they should
correspond to in our extended Java Model, perhaps a subtype of
SourceRefElement called ICodeElement?  We should get JDT Core to add
something like that anyway, but they'll probably want to call it
IUnknownElement or IGenericRefElement to provide other projects with the
same sort of extensibility.  Another challenge will be generating the
project part of the handle because our compiler doesn't know about
workspaces.  I hope that info can be extracted from the full path and source
path information.  Then for other IDEs we can simply use the same relative
path convention.

Let me know what you think and I'll consider raising an enhancement report
and implementing the AspectJ side of this. 

Mik

--
http://kerstens.org/mik