Skip to main content

I code aspects using

AspectJ
12% (99 votes)
AspectWerkz
3% (26 votes)
Dynaop
2% (17 votes)
JBossAOP
2% (16 votes)
Other
5% (36 votes)
I don't use aspects.
76% (605 votes)
Total votes: 799

Comments

Looking for comprehensive tutorial

hmm.... my message got truncated... Anyway, AspectJ in Action from Manning is the best book on the subject. I appologize for only presenting AspectJ specific resources, but that's where the info seems to be (Probably because it is the first and most mature of the available options.) However, you can learn AOP from an AspectJ perspective and then apply the concepts to any framework you choose.

Been trying AspecWerkz

It appeals to me that, unlike it is the case with AspectJ, there is no need to extend Java syntax, so my existing tools continue to be useful.

Haven't had reason or option to use it

Most of my dev time has been working on code from work's dev center. Since they don't use AOP then it's almost impossible for me to go tell my boss to say "Hey lets use this" (of which I know very little about). I see the problem with AOP for Java is that it's not apart of the language itself. The different AOP packages out there are all hacks to the way Java works, and it seems that AOP is still trying to find its ground (some do it in a dynamic way, some basically act as precompiling). My personal view is that AOP does have its merits, just I don't have the option in my work to use it.

Looking for comprehensive tutorial

The only reason I haven't tried AOP is because I cannot find a site that gives a full rundown of AOP and how it works. Can someone point me in the right direction?

What about Spring?

I know that the popularity of Spring has been growing, especially since the publication of "Better, Faster, Lighter Java" from OReilly. However, I'd be interested to know how many people actually use its AOP features in addition to the IOC container and MVC stuff. I've been working with AspectJ for over a year now, and I've been using Spring ever since I read Rod Johnson's "Expert One-on-One J2EE Design and Development" but I haven't used the AOP features of Spring in an actual project yet.

What about Spring?

I've been using Spring's AOP for a few months now and have found it to be a great way to wrap logic in transactional groupings. It's very simple, clean, understandable, and solid. I continue to be very impressed with the Spring Framework with each new piece of it that I use.

What about Spring?

I have found Spring AOP outstanding. Like other parts of Spring - it just works. There are some features that AspectJ has that Spring doesn't. But if you are already using Spring, then you will find the AOP impl to be simple to use and non-intrusive. Particularly if you use AutoProxies. To put it another way, I have met people using Spring AOP who did not realize they were using AOP! Give it a try.

aop?

ha ha ha A vote in favour of sanity. Nice to see nodoby has been taken in by the hype.

Decorator Pattern: AOP Without the Magic?

I've never used AOP because every time it's been an option I've been able to solve the problem using the Decorator pattern anyway.

Decorator Pattern: AOP Without the Magic?

I've never used AOP because every time it's been an option I've been able to solve the problem using the Decorator pattern anyway.

Decorator Pattern: AOP Without the Magic?

This is true. I believe there is a strong alignment between the two. A couple of reasons why AOP might be better in certain situations:

  1. AOP has the ability to decorate arbitrary behavior. Whereas the decorator pattern assumes a common call structure and/or may require framework code to direct the call to the decorator.
  2. AOP behavior can be turned on or off very easily. Depending on how you implement the decorator pattern this may be somewhat more difficult.

I am sure there are other differences, but that is all I could think of.

AOP is DOA

Aspect Oriented Programming is simply a kludge. It is a feeble attempt to structure application design; (i.e. Web Services), atop a very primitive half-duplex medium: HTTP. AOP guys: it's high time to simply dump that outdated media: boldly step out of the '90's. Join the modern (full-duplex) age. You'll really like it! :-)

AOP is DOA

Woah, sorry I didn't check back sooner! Let me try to explain. To me, what is commonly called AOP, is nothing more than the old Go4 decorator pattern, rehashed once again, and with many new buzwords; but with zero additional benefit. What I mean by full-duplex, is that distributed applications simply can not follow this simplistic synchronous request / response method pattern. Essentially, when you interact with another remote object, you will really want your request to be asynchronous; i.e. returning immediately, so your application can go on to other things. Therefore, you must now provide three things to the called method:
  1. The arguments you want processed
  2. Precisely how long from now you need them to be processed
  3. A callback method, to provide the results of the invocation
I hope this makes more sense...

AOP is DOA

Let me try to explain. To me, what is commonly called AOP, is nothing more than the old Go4 decorator pattern, rehashed once again, and with many new buzwords; but with zero additional benefit.

As I said in another post, the main difference is that AOP is transparent to the code it is decorating and can decorate arbitrary method calls in a variety of ways. The GOF Decorator requires either that some interceptor be directly called or that the code that is decorated implements some common interface (Or any number of other methods, but the point is that it requires framework code.)

What I mean by full-duplex... [bla, bla, bla]

This still has absolutely nothing to do with AOP. There are a number of methods to deal with distributed code in Java, some of which use asynchronous calls and some of which don't. Regardless of which of these techniques you use you can use AOP with them, or not. The concepts, and their common implementations, are completely orthogonal.

AOP is DOA

I really didn't want to start a thread here, but your response leads me to believe I am not getting my point across. I agree the decorator pattern is useful in it's own right. That's why people use it all the time. What I'm saying is that AOP specifically, in trying to hide the underlying details of the pattern, will too likely prove of more harm than good. This is far too much like when people were saying the all-new C++ will revolutionize the way people write C code. With new language extensions, to hide all those low-level details, previously handled manually. "Let the compiler write the code you..." A good idea in concept, but disasterous in reality. I think people are just too wary to go down this road again: Wondering why is the program getting so large and slow; yet the source is so small. I think most will agree; saving keystrokes is a very poor investment. Inline decorations always inject overhead, and are deleterious to throughput. Their use must be weighed carefully; and definitely not hidden! So I'm not at all anti-decoration, just anti-AOP. Step out of the '90's, get it now? (Guess if you have to explain a punchline...) -John PS The duplex explanation was to the other reply. However, its espouses decentralization of process components in an asynchronous fashion. So if there are other interests in the code executing at hand for example; it is far better to provide a simple mechanism to observe it without affect. This I would classify as decorating in parallel.

AOP is DOA

I think you have AOP confused with SOA. None of the AOP frameworks available today have a dependency on HTTP so I don't know where you're going the full-duplex thingy. AOP has sure made my life easier. Especially when it comes to debugging.

AOP is DOA

I am not sure I get the comparison you are trying to make between web services over HTTP and AOP. As I understand it AOP, like most other programming paradigms, is simply a way to reduce the amount of effort it takes to implement a feature by reducing duplication. If I have a requirement that touches several areas of my project, but I don't want to have to write the same code in each place then I can use aspects. Simple.

None

I think I'm probably fairly representative of the many who haven't used any. I haven't really had the time to try any and I haven't had anybody present a good argument as to why I should devote some time to learning aspects.

I have used AspectWerkz

I used this after trying out many of the frameworks. I liked many of them, but AW fit my bill on the project. I could see using JBossAOP with JBoss based applications though. And I could see using AspectJ due to it's plethera of tools to support it.

Multiple

Different projects, different tools. AspectJ and DynAOP mostly.