Subject: Re: separation of implementation concerns
From: Therapon Skotiniotis (skotthe@ccs.neu.edu)
Date: Wed Jan 30 2002 - 09:50:18 EST
Hi,
The "best way", that hinders (and implies) issues that might not
be actually solved by reading in the class files.
I think, I made that comment when we where thinking about the
future trend in AspectJ, That is, when weaving will be possible at
bytecode level.
DJ does extract the class file through loading the bytecode, and
probably Doug is the person to give you all the gory details and
limitations. However, since AspectJ weaves in aspects at compile
time then your resulting class files will be "polluted" with all
the AspectJ renaming / source mangling !
So my question is: Do you want to get a snapshot of the Class
Graph after AspectJ weaves in ?
If yes then ok. If no then you could get all necessary information
before the code mangling, either directly from the *.java files or
(if access to the front end of the ajc compiler is possible) a
snapshot from the AST representation inside the ajc compiler.
--Theo
On Wed, Jan 30, 2002 at 09:04:42AM -0500, Karl Lieberherr wrote:
> Hi John:
>
> here is even a better way to implement your thesis project.
> The goal is to have an easy to maintain addition to AspectJ.
> We discussed the language integration issues and implementation techniques
> yesterday in COM 3362.
>
> Theo suggested that the best way to create the class graph is to get
> it from the class files. Please talk to Johan: he is our expert
> in residence how to read and modify class files. You
> need only the reading part.
>
> It is important to see that this is a very generic task
> not specific to AspectJ and some people have probably already done it.
> Maybe you can find some code for this on the web.
>
> The second point is to put the traversals into a traversal aspect file
> which has the following form:
>
> traversal aspect A {
> t = from Company to Salary;
> t1 = from Division to Department;
> ...
> }
>
> Such a file will have an extension *.trav and when we invoke your
> compiler
>
> ajc-sung *.java *.trav
>
> the following will happen:
>
> 1. Desugar the AspectJ aspects in *.java by translating
> traversal(t) to call(* t(..)) and
> crossing(e) to call(* e_t(..))
> 2. Read the *.trav files and for "t = from Company ..." produce
> a temporary implementation
> aspect Traversals {
> Company.t() {}
> }
> in file Traversals.java
> 3. ajc *.java // using standard AspectJ
> This should compile and produce *.class files.
> 4. Produce the class graph by a separate program
> cg-extract *.class > cg
> 5. Use the cg and the AP library to generate the permanent implementation
> aspect Traversal {
> Company.t() { ... }
> Division_List.t() { ... }
> }
> in Traversals.java
> 6. ajc *.java // using standard AspectJ
> This will weave it all together.
>
> Ease of maintenance:
>
> 1. If AspectJ changes we might have to update step 1. It is unlikely
> that AspectJ will change in this part.
> 2. If the class file format changes, we have to modify step 4.
> Unlikely.
>
> None of those steps requires modification of AspectJ code which
> shows proper separation of concerns for the implementation
> approach and an approach we can maintain independent of how
> the AspectJ team rearranges their code.
>
> The advantage of the above separation is also conceptually useful.
> All traversal specifications are in one place rather than scattered
> through several aspects. This will incourage traversal reuse
> and composition with join and merge.
>
> -- Karl
This archive was generated by hypermail 2b28 : Wed Jan 30 2002 - 09:50:19 EST