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

[Matt Chapman <MCHAPMAN@xxxxxxxxxx>]

In order to get the cross references / relationships view and the advice 
image decorator working properly, I ended up prototyping what the AJDT 
side of this might look like. There is now a layer on top of the ajde 
structure model which converts that IProgramElement based model into an 
IJavaElement based one, and so then the above functionality uses only this 
new model. I've refactored a bit post-M2, so the code is now mainly in the 
ajdt.core plugin, in the org.eclipse.ajdt.core.model package. After a 
build AJModel.createMap() is called do the conversion. The AJProjectModel 
class constructs a per-project
relationship map for those IJavaElements which are involved in a 
relationship.

I think the next step is to try to use this new model elsewhere in AJDT, 
such as for creating the markers, and in the visualiser. I think we still 
need the line number information for these features, so we might actually 
end up with our own nodes with contain the IJavaElement, plus the 
additional information we need. For example the cross references view 
actually shows AJNodes (package org.eclipse.ajdt.internal.builder) which 
consist of IJavaElements with a label, as we want to use a longer name to 
indicate where it comes from, rather than just the name of the element.

The issue with the code elements beneath the level of normal IJavaElements 
is indeed a tricky one. I created an 
org.eclipse.ajdt.core.javaelements.AJCodeElement class to represent these. 
These are created when we find an IProgramElement that doesn't directly 
correspond to an IJavaElement. There are not added to the JavaCore model, 
but added to our structure when needed, such as when the cross reference 
view is populated.

Once the new model is well-defined enough to be used right across AJDT, 
I'd like to consider the possibilty of getting this new model directly, 
not creating IProgramElements at all. We can then persist this new model 
in the .metadata directory instead of .ajsym files. Utimately all these 
changes should both increase performance, and reduce memory usage.

So please take a look at the mentioned classes and see what you think. As 
Andy says, I think a key point is whether we can get to a world without 
IProgramElements. 

Regards,

Matt.




Andrew Clement/UK/IBM@IBMGB 
Sent by: ajdt-dev-admin@xxxxxxxxxxx
18/12/2004 10:09
Please respond to
ajdt-dev@xxxxxxxxxxx


To
ajdt-dev@xxxxxxxxxxx
cc

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







Hi Mik, 

Yes, I think that is a good idea.  Incidentally I've just added a bit 
extra 
to the handles so they now include offset through the file (Eclipse uses 
it rather than recalculating it from the line number info). 

Can I check if you are proposing that in an AJDT world we lose the 
IProgramElement 
model of each project - and just have the relationships? Eclipse will talk 
in 
terms of IJavaElements using eager parsing to get the structure it needs 
for the outline view/package explorer? 

cheers, 
Andy. 



"Mik Kersten" <beatmik@xxxxxxx> 
Sent by: ajdt-dev-admin@xxxxxxxxxxx 
17/12/2004 21:19 

Please respond to
ajdt-dev@xxxxxxxxxxx


To
<ajdt-dev@xxxxxxxxxxx> 
cc

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









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



_______________________________________________
ajdt-dev mailing list
ajdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/ajdt-dev