AspectJ vs Jboss AOP?

Has there be any thought of providing support for AOP frameworks in
idea? Such as Jboss, aspectwerkz?

I'm not sure exactly what level of support of support might be required
non-language extension based AOPs. Maybe just allowing the AOP FWs
classloader to do its work and allowing for breakpoints on weaved in code.

0
20 comments

I use Nanning, which is non-language-extension-based, and normal Idea tools work great for me.

0
Avatar
Permanently deleted user

I will explain some of our views on this. AOP itself, being a young
extension to the OOP promised to do some things we've been doing anyway in a
more elegant and modular way. The thing itself is not mature enough to tell
its pros and cons. There are different approaches to implementing aspects,
starting from extending the language like AspectJ does, or aspect-oriented
frameworks like JBoss/Nanning/Aspectwerkz. It's clear that aspects should
be applied in a disciplined way, otherwise the program becomes
unmaintainable even much faster than by not having them. There are certain
situations when applying aspects by patching the bytecode (AspectJ) makes
sense. In other cases, more explicit ways are preferrable. As usual, it
depends. We are integrating AspectJ because this is the only toolkit that
you simply can't use without the tool support. Everything else can be used
without the IDE specially helping it. Again, we are not saying that AspectJ
is better than something else. We want to play with everything, and it's
what we do. As we try using AspectJ for IDEA, we realize that it's
usefullness is kind of limited to us. But it's our case, someone else may
use it for other purposes and may find it more useful. There are pretty
many research papers available on AspectJ and people are doing different
things with it. If AOP is here to help people create better software, we
want to provide the help, the rest is your own creativity.

Eugene


"Barry Kaplan" <bkaplan@abwg.com> wrote in message
news:bbinlv$ism$1@is.intellij.net...

Has there be any thought of providing support for AOP frameworks in
idea? Such as Jboss, aspectwerkz?

>

I'm not sure exactly what level of support of support might be required
non-language extension based AOPs. Maybe just allowing the AOP FWs
classloader to do its work and allowing for breakpoints on weaved in code.

>


0

This is a very well-reasoned outlook on the state of AOP and approach to prodviding solutions, IMO. Thanks for the post Eugene.

I think a major advantage of non-AspectJ frameworks is that they don't require an IDE maker to write a special IDE for you, and you can hire people who know standard java and there's less of a learning curve for them.

However teams may take all that into account and decide that AspectJ is still worth it - I think it's great for them that there's at least one IDE that supports their efforts. It says a lot about IntelliJ as well.

-Steve

0
Avatar
Permanently deleted user

Regarding non-AspectJ frameworks, it still would be great if an IDE would
take the interceptor info into account for usage search and navigation
features. For example, it's not that easy to find out that calls to a
certain method are intercepted and to locate the aspect actually making use
of it. But since the way of defining incerceptors (usually in XML) varies
depending on the actual framework, they should be resolved depending on the
framework. It's pretty easy (well, almost) to develop a plugin for IDEA
showing you your AOP perspective for let's say Nanning. But it's ways
harder to do it for AspectJ.

Eugene


"Steve Conover" <sgcjr@yahoo.com> wrote in message
news:10991242.1054671116037.JavaMail.jrun@is.intellij.net...

This is a very well-reasoned outlook on the state of AOP and approach to

prodviding solutions, IMO. Thanks for the post Eugene.
>

I think a major advantage of non-AspectJ frameworks is that they don't

require an IDE maker to write a special IDE for you, and you can hire people
who know standard java and there's less of a learning curve for them.
>

However teams may take all that into account and decide that AspectJ is

still worth it - I think it's great for them that there's at least one IDE
that supports their efforts. It says a lot about IntelliJ as well.
>

-Steve



0

Well now you have me thinking. I may have to take a shot at writing a plugin like this for Nanning...I figured I'd probably dive into the IDEA plugin API sooner or later...

0
Avatar
Permanently deleted user

I have to ask, since I have been looking into AspectJ myself, how have you guys been doing AOP-type stuff more elegantly and modularly?

0
Avatar
Permanently deleted user

I think he meant that AOP promised to do the things in a more elegant and
modular way.

AOP itself, being a young
extension to the OOP promised to do some things (which we've been doing
anyway) in a
more elegant and modular way.


Keith Lea wrote:

I have to ask, since I have been looking into AspectJ myself, how have you
guys been doing AOP-type stuff more elegantly and modularly?


0
Avatar
Permanently deleted user


"Eugene Belyaev" <beg@intellij.com> wrote in message
news:bbisek$t3d$1@is.intellij.net...

We are integrating AspectJ because this is the only toolkit that
you simply can't use without the tool support. Everything else can be

used

without the IDE specially helping it.


Eugene, what about aspect aware refactoring (something could be broken by a
simple rename when an AOP framework rely on naming pattern to designate
pointcuts) ? what about advanced navigation and visualization inside and
outside the editor?
Not to start again my aop soapbox but mainstream adoption of AOP will IMHO
depend on advanced tooling that will help visually connect all pieces of the
frameworks in developers mind and help refactor it.
The current state of the OpenApi won't allow an AOP plugin to compete with
the`necessary first class integration you are planning for AspectJ. For
example refactoring listener is not implemented sufficiently
(http://www.intellij.net/tracker/idea/viewSCR?publicId=3634)

Are you planning on opening up the enhancements you are making as part of
your AJ integration? Are you talking to other AOP framework implementers
(nanning, aspectwertz,...) to see if they would be interested? aspectwertz
for example seems pretty close to AJ and could really benefit from the same
type of integration.
In other word since like you said the AOP field is still maturing, is your
strategy not just to be the best AJ IDE but also to provide the best AOP
platforms for other vendor/projects to use?

Jacques


0
Avatar
Permanently deleted user

Eugene, what about aspect aware refactoring (something could be broken by

a

simple rename when an AOP framework rely on naming pattern to designate


This is one of the topics I personally and a lot of other people here
consider very weak in AspectJ. Defining important behavioral aspects of the
program by applying regex queries to method or field names is a very weak
and often simply a bad approach. Not even saying that you break things in a
second. Anyway, Aurora will (or at least will try to) consider aspects when
searching for usages and refactoring code.

what about advanced navigation and visualization inside and

outside the editor?


What do you mean?

In other word since like you said the AOP field is still maturing, is your
strategy not just to be the best AJ IDE but also to provide the best AOP
platforms for other vendor/projects to use?


It's hard for us to do all at once. We'll support AspectJ first. It's not
even in EAP yet, so let's continue this discussion when you will get your
hands on AOP.

Eugene


"Jacques Morel" <jacmorel@yahoo.com> wrote in message
news:bbk962$1bf$1@is.intellij.net...
>

"Eugene Belyaev" <beg@intellij.com> wrote in message
news:bbisek$t3d$1@is.intellij.net...

We are integrating AspectJ because this is the only toolkit that
you simply can't use without the tool support. Everything else can be

used

without the IDE specially helping it.

>

Eugene, what about aspect aware refactoring (something could be broken by

a

simple rename when an AOP framework rely on naming pattern to designate
pointcuts) ? what about advanced navigation and visualization inside and
outside the editor?
Not to start again my aop soapbox but mainstream adoption of AOP will IMHO
depend on advanced tooling that will help visually connect all pieces of

the

frameworks in developers mind and help refactor it.
The current state of the OpenApi won't allow an AOP plugin to compete with
the`necessary first class integration you are planning for AspectJ. For
example refactoring listener is not implemented sufficiently
(http://www.intellij.net/tracker/idea/viewSCR?publicId=3634)

>

Are you planning on opening up the enhancements you are making as part of
your AJ integration? Are you talking to other AOP framework implementers
(nanning, aspectwertz,...) to see if they would be interested? aspectwertz
for example seems pretty close to AJ and could really benefit from the

same

type of integration.
In other word since like you said the AOP field is still maturing, is your
strategy not just to be the best AJ IDE but also to provide the best AOP
platforms for other vendor/projects to use?

>

Jacques

>
>


0

As an aside, the point about the fragile naming-convention relationship between an aspect and it's pointcuts is one I hadn't considered before. That's a very valid criticism. I wonder if pointcuts wouldn't better be defined by a set of logically categorized methods rather than semantically grouped methods. For example, using the metadata tags proposed in 1.5. I wonder if aop could be integrated with these tags, and use them in pointcut definitions.

Then a "getter" method could be definitively related by the developer to all other "getter" methods in a manner less transient than a naming convention. AOP could more reliably trust it's pointcut definitions. I've always hated frameworks which relied too heavily on naming conventions.

Though I suppose these metadata tags would then need to have inheritance...

0
Avatar
Permanently deleted user

I myself eager to see how the AOP frameworks will evolve by utilizing the
metadata. Meanwhile, you might take a look at the same for C#.

Eugene

"Russell Egan" <russegan@email.com> wrote in message
news:7497636.1054730058992.JavaMail.jrun@is.intellij.net...

As an aside, the point about the fragile naming-convention relationship

between an aspect and it's pointcuts is one I hadn't considered before.
That's a very valid criticism. I wonder if pointcuts wouldn't better be
defined by a set of logically categorized methods rather than semantically
grouped methods. For example, using the metadata tags proposed in 1.5. I
wonder if aop could be integrated with these tags, and use them in pointcut
definitions.
>

Then a "getter" method could be definitively related by the developer to

all other "getter" methods in a manner less transient than a naming
convention. AOP could more reliably trust it's pointcut definitions. I've
always hated frameworks which relied too heavily on naming conventions.
>

Though I suppose these metadata tags would then need to have

inheritance...


0
Avatar
Permanently deleted user

Yep it has been suggested on multiple occasion that a richer semantic
designation needs to be used. Regexp are too brittle. NET for example use
attributes or metadata tag in the code to weave its interceptors. I too
would like to be able to designate pointcut with 1.5 meta-data. I believe
this is called attribute-based programming. Some AOP projects use this
approach like http://jac.aopsys.com/. They use things like SETTER, GETTER,
MODIFIER,... that reflect the semantic of the operation (not which advice to
weave). The pointcut designator can then be specified at a much higher
semantic level than just naming patterns.
Unfortunately it is still not ideal. You still have to make sure that all
your targets have the corresponding attributes the same way you had to make
sure they were using the naming pattern you expected. It simplify
maintainance and refactoring at least.

Jacques

"Russell Egan" <russegan@email.com> wrote in message
news:7497636.1054730058992.JavaMail.jrun@is.intellij.net...

As an aside, the point about the fragile naming-convention relationship

between an aspect and it's pointcuts is one I hadn't considered before.
That's a very valid criticism. I wonder if pointcuts wouldn't better be
defined by a set of logically categorized methods rather than semantically
grouped methods. For example, using the metadata tags proposed in 1.5. I
wonder if aop could be integrated with these tags, and use them in pointcut
definitions.
>

Then a "getter" method could be definitively related by the developer to

all other "getter" methods in a manner less transient than a naming
convention. AOP could more reliably trust it's pointcut definitions. I've
always hated frameworks which relied too heavily on naming conventions.
>

Though I suppose these metadata tags would then need to have

inheritance...


0
Avatar
Permanently deleted user


"Eugene Belyaev" <beg@intellij.com> wrote in message
news:bbkl40$4s4$1@is.intellij.net...

what about advanced navigation and visualization inside and

outside the editor?

>

What do you mean?

>
1) in regular java class editor: highlighting of code site where aspects are
woven, navigation from there to the aspects.
2) in aspect editor: from a pointcut designator: show joinpoints designated,
3) structure view for aspect: special view that isolate pointcut designator,
advice and introduction members.
4) aspect weaving view: kind of like caller hierarchy that list all
joinpoints of an aspects
5) in the project view: filter, highlight, annotate classes that are advised
6) find jointpoints

I am sure you have some others in mind.

Jacques


0
Avatar
Permanently deleted user

Well, I actually was asking about advanced navigation and visualization
inside the editor. I realize all those outside things, and most of them
have no need of additional open apis.

Eugene

"Jacques Morel" <jacmorel@yahoo.com> wrote in message
news:bbkud7$7er$1@is.intellij.net...
>

"Eugene Belyaev" <beg@intellij.com> wrote in message
news:bbkl40$4s4$1@is.intellij.net...

what about advanced navigation and visualization inside and

outside the editor?

>

What do you mean?

>
1) in regular java class editor: highlighting of code site where aspects

are

woven, navigation from there to the aspects.
2) in aspect editor: from a pointcut designator: show joinpoints

designated,

3) structure view for aspect: special view that isolate pointcut

designator,

advice and introduction members.
4) aspect weaving view: kind of like caller hierarchy that list all
joinpoints of an aspects
5) in the project view: filter, highlight, annotate classes that are

advised

6) find jointpoints

>

I am sure you have some others in mind.

>

Jacques

>
>


0
Avatar
Permanently deleted user

That's interesting. It could be taken either way and still be valid English. Now I'm just confused...

0
Avatar
Permanently deleted user

Do you have defined the way to highlight code that is adviced? Are you considering implementing what the emacs plugin does or more (I haven't tried the eclipse plugin myself)?
This will require more than what is available now, right?
Along that line, I believe the name of the woven aspect(s) is not enough. It would be great to have different visualization based on the type of advice: around, before, after,... Maybe an icon.
Also would it be useful to see advices on the call sites? How could IDEA show that an exception is wrapped? Things like that might be interesting to show ;)

Anyway what is the timeframe to have the first cut of aspect annotation in the editor?

Jacques

0
Avatar
Permanently deleted user


Eugene Belyaev wrote:

We are integrating AspectJ because this is the only toolkit that
you simply can't use without the tool support. Everything else can be used
without the IDE specially helping it.


Is this true in 818? When I tried to aspectwerkz I could not because of
the idea boostraper/loader. Has this issue been resolved? Will I be able
to start a jboss-aop in the debugger using -Duser.system.classloader=xxx?

0
Avatar
Permanently deleted user

If you're looking only for annotation, it's already there in 818. :)
Of course, 819 might have enhancements, but 818 is decent enough already.

Do this:
- create an aspect file (a file with the aj extension)
- write an aspect, define a pointcut and an advice and then go to a class
you think should be affected by the advice.

Here's an aspect I'm working on integrating in the build process (I'm using
ant) right now, for instance.

public aspect LoggingEnforcement{

pointcut systemOutUsage() : call(* print*(..)) &&
!within(com.creditwave.service.LogService) && !within(java.lang.Throwable+);
pointcut systemErrUsage() : call(* print*(..)) &&
!within(com.creditwave.service.LogService) && !within(java.lang.Throwable+);

declare warning : systemErrUsage() : "Wrongful usage of
System.err.print*(..)";
declare warning : systemOutUsage() : "Wrongful usage of
System.out.print*(..)";
}

Before and after advices get highlighted as well, I can hardly wait to get
my hands on 819 and play with the searches and all the other stuff. :)

Have fun,
Andrei

"Jacques Morel" <jacmorel@yahoo.com> wrote in message
news:18462140.1054755221964.JavaMail.jrun@is.intellij.net...

Do you have defined the way to highlight code that is adviced? Are you

considering implementing what the emacs plugin does or more (I haven't tried
the eclipse plugin myself)?

This will require more than what is available now, right?
Along that line, I believe the name of the woven aspect(s) is not enough.

It would be great to have different visualization based on the type of
advice: around, before, after,... Maybe an icon.

Also would it be useful to see advices on the call sites? How could IDEA

show that an exception is wrapped? Things like that might be interesting to
show ;)
>

Anyway what is the timeframe to have the first cut of aspect annotation in

the editor?
>

Jacques



0
Avatar
Permanently deleted user

I could not make it work. I got lots of NPE right away.
The editor was basically too unstable to use ;-[
I will wait for 820

Jacques

0
Avatar
Permanently deleted user

Yes, the only difference when running with IDEA launcher now is the
additional jar at the end of classpath, so I guess there won't be any
problems in running aspectwerkz now (though I personally did not try it)
Also, we are planning to make the use of the launcher optional providing a
choice in run configuration.

Is this true in 818? When I tried to aspectwerkz I could not because of
the idea boostraper/loader. Has this issue been resolved?



0

Please sign in to leave a comment.