AspectJ: Variable existence?

[Conrad Eaglehill]

Hi,

I'm learning AspectJ and running through some example programs, and in
writing aspects, I find that one aspect may relate to another.

For example, I'm creating an application that has a main App class, a
MenuBarAspect aspect, and then a FileMenuAspect aspect, EditMenuAspect
aspect, etc., corresponding to the Menus at the top of the
application. MenuBarAspect defines a JMenuBar variable App.menuBar,
FileMenu defines a JMenu variable App.file, and so on. It compiles and
runs fine. If I remove, say, HelpMenuAspect from the configuration, my
app runs fine, just without a Help menu above, which is perfect.

But if I remove MenuBarAspect from the configuration, it won't compile
because FileMenuAspect, EditMenuAspect, etc., all call the JMenuBar
method add contained within. (so an example line looks like
app.menuBar.add(app.file = new JMenu("File");, but the variable
App.menuBar no longer exists as the aspect that contained the variable
is no longer in the build).

Basically, a solution I envision would be an if statement that
ascertains either the existence of menuBar OR MenuBarAspect in the
build. Then, if I remove MenuBarAspect, the *MenuAspect aspects would
do nothing since they'd fail the if test. Java, as far as I know, has
no such method to do so. A friend mentioned a concept called
refleciton, but I've not really worked with it, though I'm open to it
as a solution. Is there in AspectJ such a way to solve this?

Thanks in advance for the conceptual help,

Conrad Eaglehill

 

[Sebastian Scheid]

Hi,

I'm learning AspectJ and running through some example programs, and in
writing aspects, I find that one aspect may relate to another.

For example, I'm creating an application that has a main App class, a
MenuBarAspect aspect, and then a FileMenuAspect aspect, EditMenuAspect
aspect, etc., corresponding to the Menus at the top of the
application. MenuBarAspect defines a JMenuBar variable App.menuBar,
FileMenu defines a JMenu variable App.file, and so on. It compiles and
runs fine. If I remove, say, HelpMenuAspect from the configuration, my
app runs fine, just without a Help menu above, which is perfect.

I'm quite sure that this is not an aspect AOP is designed for. You want to
configure your app's menu or perhaps more of your gui. That is not a
crosscutting concern! Probably you can do it with AspectJ but I cannot see
any advantage.
Perhaps you should search for another solution to build your gui generically
(properties, XML or whatever).

But if I remove MenuBarAspect from the configuration, it won't compile
because FileMenuAspect, EditMenuAspect, etc., all call the JMenuBar
method add contained within. (so an example line looks like
app.menuBar.add(app.file = new JMenu("File");, but the variable
App.menuBar no longer exists as the aspect that contained the variable
is no longer in the build).

Of course, you cannot compile any more. What did you expect?

Basically, a solution I envision would be an if statement that
ascertains either the existence of menuBar OR MenuBarAspect in the
build. Then, if I remove MenuBarAspect, the *MenuAspect aspects would
do nothing since they'd fail the if test. Java, as far as I know, has
no such method to do so. A friend mentioned a concept called
refleciton, but I've not really worked with it, though I'm open to it
as a solution. Is there in AspectJ such a way to solve this?

Try ant targets for your different menu configs. Every target which adds at
least one menu has to depend on the target which enables the menuBar.

Thanks in advance for the conceptual help,

You really should think your AOP solution for this problem over!

Sebastian

 

[Conrad Eaglehill]

I'm quite sure that this is not an aspect AOP is designed for. You want to
configure your app's menu or perhaps more of your gui.

Perhaps you misunderstand. I'm using a gui simply as an example from
which to practice AspectJ. I'm not turning in a gui to a boss or a
professor, or to sell. Just to learn.

That is not a
crosscutting concern! Probably you can do it with AspectJ but I cannot see
any advantage.

Well, that's where we part ways. I do see an advantage, and posted a
question to further my pursuit of knowledge. If you don't see an
advantage (or, more likely, can't answer my question), why'd you
reply?

Perhaps you should search for another solution to build your gui generically
(properties, XML or whatever).

You'd be right if I were learning how to build an app. However, I'm
learning how to use AspectJ, which may have come about from a need to
handle crosscutting concerns, but is also quite adept using a software
engineering concept called feature-oriented programming. In this
context, each aspect is a feature as well.

Of course, you cannot compile any more. What did you expect?

Well, Sebastian, I obviously expected it to not compile, since I also
explained *why* it wouldn't in the text you quoted. I'm explaining my
process, step-by-step, so my question, and my intent, will be clear.
I'm not sure where I've earned the derisive tone.

You really should think your AOP solution for this problem over!

Again, this idea that AspectJ is designed for one purpose is, to be
polite, quaint. It's akin to telling a poet who's learning German to
rethink his choice, because French is a language much better suited to
such a pursuit. A language is a language. If one finds a different use
for any language, so much the better for all of us.

Sebastian

Conrad Eaglehill

 

[Sebastian Scheid]

"Sebastian Scheid" <[email protected]> wrote in message

Perhaps you misunderstand. I'm using a gui simply as an example from
which to practice AspectJ. I'm not turning in a gui to a boss or a
professor, or to sell. Just to learn.



Well, that's where we part ways. I do see an advantage, and posted a
question to further my pursuit of knowledge. If you don't see an
advantage (or, more likely, can't answer my question), why'd you
reply?


You'd be right if I were learning how to build an app. However, I'm
learning how to use AspectJ, which may have come about from a need to
handle crosscutting concerns, but is also quite adept using a software
engineering concept called feature-oriented programming. In this
context, each aspect is a feature as well.


Well, Sebastian, I obviously expected it to not compile, since I also
explained *why* it wouldn't in the text you quoted. I'm explaining my
process, step-by-step, so my question, and my intent, will be clear.
I'm not sure where I've earned the derisive tone.


Again, this idea that AspectJ is designed for one purpose is, to be
polite, quaint. It's akin to telling a poet who's learning German to
rethink his choice, because French is a language much better suited to
such a pursuit. A language is a language. If one finds a different use
for any language, so much the better for all of us.


Conrad Eaglehill

Sorry because of my tone.
There are many beginners, learning new techniques like OO or AOP, who have a
wrong understanding how these techniques are meant to be used. So I wanted
to tell you that AOP was originally designed to be used in other scenarios.
That's why I answered.
But now I know that you are aware of the things you are doing there. So we
can continue with the problem of the existance of a variable.

AFAIK AspectJ does not offer a special way to check the existence of a
variable. So Java's reflection mechanism is a good idea:

public class A {
public void test() {

}
}
______________________________

public aspect TestAspect1 {

// introduce member "flag"
public Boolean A.flag = Boolean.FALSE; // comment this line to see the
effect

// Test pointcut
pointcut pc1(A a) : call(* A.test())
&& target(a);

// modify the intoduced member
before(A a) : pc1(a) {
System.out.println("OK");
a.flag = Boolean.TRUE; // comment this line, too
}
}
______________________________


import java.lang.reflect.*;

public aspect TestAspect2 {

declare precedence: TestAspect2, TestAspect1;

// pointcut captures call to A.test() only if A has the Boolean member
"flag"
pointcut pc2(A a) : call(* A.test())
&& target(a)
&& if(check(A.class, "flag", Boolean.class)); // see method below

before(A a): pc2(a) {
// a.flag is not possible if TestAspect1 has not introduced field flag
// This is quite uncomfortable. But I don't know a better solution. The aj
compiler doesn't accept a.flag even if the advice body is never entered
Boolean flag = (Boolean) getField(a, "flag"); // see method below
System.out.println("OK2 flag = " + flag);
}

after(A a): pc2(a) {
Boolean flag = (Boolean) getField(a, "flag");
System.out.println("OK2 flag = " + flag);
}

// methods that use reflection to check and access a member variable

/** Checks if class c has a member variable called memberName of type
memberType */
private static boolean check(Class c, String memberName, Class memberType)
{
try {
Field f = c.getField(memberName);
return f.getType().equals(memberType);
} catch (SecurityException e) {
e.printStackTrace();
} catch (NoSuchFieldException e) {
}
return false;
}

/** Returns the object the variable memberName in object o references to.
Method check() has to be called before */
private static Object getField(Object o, String memberName) {
try {
Field f = o.getClass().getField(memberName);
return f.get(o);
} catch (SecurityException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (NoSuchFieldException e) {
}
return null;
}

}
___________________________________________________

It's a pity that the aj compiler doesn't recognize that the before and after
advice in TestAspect2 is only entered if variable flag is available. So you
have to handle reflection to access the fields.

As I mentioned before, ant could help here if you separate your aspects
clearly so that some aspects are excluded from build if an aspect they
depend on is also not built. Then you can use "a.flag" again and can avoid
reflection.

I hope this post is more helpful for you and makes you not angry again
Sebastian

 

[Conrad Eaglehill]

Sorry because of my tone.
There are many beginners, learning new techniques like OO or AOP, who have a
wrong understanding how these techniques are meant to be used. So I wanted
to tell you that AOP was originally designed to be used in other scenarios.
That's why I answered.

Okay, that's certainly understandable. Thank you for clarifying; no
harm done.

But now I know that you are aware of the things you are doing there. So we
can continue with the problem of the existance of a variable.

AFAIK AspectJ does not offer a special way to check the existence of a
variable. So Java's reflection mechanism is a good idea:

--Example code snipped...--

Thank you for the example code--I'd never used reflection before, so
now I can begin to learn and apply it.

It's a pity that the aj compiler doesn't recognize that the before and after
advice in TestAspect2 is only entered if variable flag is available. So you
have to handle reflection to access the fields.

As I mentioned before, ant could help here if you separate your aspects
clearly so that some aspects are excluded from build if an aspect they
depend on is also not built. Then you can use "a.flag" again and can avoid
reflection.

I'll try both techniques and see which works best for me. I think you
may be right with the suggestion to use ant. I guess I was hoping to
an AO way to handle it. But now I have another tool in my belt with
reflection.

I hope this post is more helpful for you and makes you not angry again
Sebastian

I'm not angry, but perhaps my tone last time was sharp. Anyway,
thank you again for the quick reply. Now I'm off to apply what you've
shown me!

--Conrad Eaglehill