News: Symposium Video: Bob Lee on Aspect Oriented Java Development
In this talk, given at TheServerSide Java Symposium 2003, Bob Lee discusses the state of Aspect Oriented Programming (AOP) in Java, outlining the various approaches to implementing AOP (custom compilers, dynamic proxies, byte code manipulation). He looks at its pros and cons, application strategies & patterns, and gives an overview of the JBoss AOP framework.
- Posted by: Nitin Bharti
- Posted on: March 17 2004 14:36 EST
Watch Bob Lee's Talk on Aspect Oriented Java Development
- dynaop by Bob Lee on March 17 2004 17:16 EST
- Symposium Video: Bob Lee on Aspect Oriented Java Development by graham o'regan on March 18 2004 06:52 EST
- nt by Andre Mermegas on March 18 2004 15:37 EST
- Symposium Video: Bob Lee on Aspect Oriented Java Development by Hans Schw?bli on March 18 2004 15:50 EST
- Symposium Video: Bob Lee on Aspect Oriented Java Development by Juozas Baliuka on March 18 2004 17:04 EST
Symposium Video: Bob Lee on Aspect Oriented Java Development by Hans Schw?bli on March 18 2004 06:38 EST
- Symposium Video: Bob Lee on Aspect Oriented Java Development by Bob Lee on March 18 2004 09:51 EST
Symposium Video: Bob Lee on Aspect Oriented Java Development by Bob Lee on March 18 2004 10:28 EST
Symposium Video: Bob Lee on Aspect Oriented Java Development by Bill Burke on March 19 2004 08:43 EST
- Symposium Video: Bob Lee on Aspect Oriented Java Development by Bob Lee on March 20 2004 07:54 EST
- dynaop is the most simple & clean AOP framework, IMHO by Duc Nguyen on March 21 2004 09:10 EST
- Symposium Video: Bob Lee on Aspect Oriented Java Development by Bill Burke on March 19 2004 08:43 EST
Symposium Video: Bob Lee on Aspect Oriented Java Development by Dorel Vaida on March 19 2004 01:41 EST
- Symposium Video: Bob Lee on Aspect Oriented Java Development by Hans Schw?bli on March 19 2004 01:24 EST
- Symposium Video: Bob Lee on Aspect Oriented Java Development by Hans Schw?bli on March 18 2004 06:38 EST
- best way to understand is implement it yourself by Roger Voss on March 20 2004 15:31 EST
- Symposium Video: Bob Lee on Aspect Oriented Java Development by Juozas Baliuka on March 18 2004 17:04 EST
As is often the case in this industry, the AOP landscape has changed a lot since this was taped. If you're interested in more, check out dynaop, http://dynaop.dev.java.net/.
As is often the case in this industry, the AOP landscape has changed a lot since this was taped. If you're interested in more, check out dynaop, http://dynaop.dev.java.net/.Looks like a good two days work, but I'd rather spend time learning AspectJ, AspectWerkz or Nanning.
Looks like a good two days work, but I'd rather spend time learning AspectJ, AspectWerkz or Nanning./JoeYeah, I agree that they seem to be much better than some of these two-day hacks, like JBoss AOP for example. If you're going to put effort into learning any of this stuff, you might as well go with ones that actually have some thought behind them.
Bob, could you include a link to your presentation slides as they are difficult to read from the vid, perhaps you could include the demo code too?
How is development on dynaop going, will we see a full release soon?
Am I the only one who just sees a picture on the page but no links to play the video?
I watched the video. "Crazy" Bob Lee says how absolutely fantastic all the other AOP products are: AspectJ, Aspect Workz, Nanning, jac, cglib, jboss aop, jfluid and so on. They are all "really cool stuff" in this words. But nevertheless he programmed his own AOP framework! How can he tell all other AOP products are really cool when he puts very much effort into programming his own AOP framework? Why doesn't he use the "really cool stuff" instead of making his own stuff?
He mentioned and praised so many AOP products so that I hardly remember the name of the AOP framework which he programmed! Oh, now I remember it: "JAdvise"...
I think he simply didn't like AspectJ a few years ago for no really compelling reason. That must be the reason why he programmed his own AOP framework. He doesn't tell in his video why he didn't use an existing AOP product. He says he doesn't like dynamic proxy and XML configuration based based AOP frameworks. But I think there are other AOP products, which do not use dynamic proxies and which use programmatic configuration. There is always a trade off. If I don't like the Date class in Java that doesn't mean that I will make my own OO programming language because of that!
The design and performance of his AOP framework seems to be good. But I really wonder why he puts so much effort into reinventing the wheel "his way". Nevertheless I will prefer to use AspectJ because I think it is a better AOP implementation than JAdvise or any other framework based AOP product. And I believe that AspectJ will be one of the survivers. Many of the dozens of AOP products will die in a few years (like VHS prevailed against Beta Video, stupid example, but you know what I mean).
I think it would be possible to simulate OO programming with Cobol. Maybe you would need a "helper procedure framework" to achieve this. But this would make no sense. So I think that AOP frameworks are not such a good solution like AspectJ. The best solution would be, if Java would support AOP natively. It doesn't. So the second best solution is AspectJ for me. And the third best solution are AOP frameworks in my opinion.
Do you think we have "the best" or "standard" way and we need to stop creating new frameworks ?
Do you think we have "the best" or "standard" way and we need to stop creating new frameworks ?I personally would not reinvent the wheel or invent a wheel which is inferior to an already invented wheel. But I don't stop anyone doing it.
Take log4j as an example. Its hard to produce a better logging framework. But I won't stop anyone trying it. I just doubt that it would make sense to spend time in writing another logging framework for Java.
In my eyes, the same objection applies to "yet another AOP framework". A new framework has to justify its existence in the light of already existent frameworks. If it does not provide any substantial benefit compared to the other frameworks, it was not worth creating it.
I don't state that this applies to JAdvise. But it looks like it for me.
Please trust me when I say I'm not in the business of reinventing the wheel. This video was taken almost a year ago. When I created jAdvise, there was no AspectWerkz; when I gave the speech, it was brand new. AspectJ is an excellent tool, and it has its place, but it's a little too complicated for your average corporate developer. Also, the great thing about jAdvise was that you could completely take the interceptors out without reloading the class, something you couldn't do with AspectJ.
The truth is, up until a couple months ago we did need another AOP framework. I detailed the reasons in the dynaop release announcement (http://weblogs.java.net/pub/wlg/1001). Though dynaop and AspectJ employ similar strategies, they don't compete. Each has its place. dynaop is more like a generic EJB than AspectJ. You should check out the manual, http://dynaop.dev.java.net/.
Hans, I almost forgot. You mentioned JBoss AOP. JBoss AOP started from jAdvise. This is the reason further development on jAdvise fell to the wayside--why have two projects with the same code and goals? I originally planned to focus the talk on JBoss AOP but the folks at JBoss asked me not to.
Hans, I almost forgot. You mentioned JBoss AOP. JBoss AOP started from jAdvise. This is the reason further development on jAdvise fell to the wayside--why have two projects with the same code and goals? I originally planned to focus the talk on JBoss AOP but the folks at JBoss asked me not to.Be a bit more forthcoming Bob. jAdvise fell to the wayside because you never had the gumption to continue it and I tried for months to get you to contribute to JBoss AOP to no avail. It was always "I may have time next week." Besides, JBoss AOP had a bit more loftier goals than the week of work jAdvise was. Remember, you came to me. I started with a few pieces of jAdvise, well, because, I thought I was getting you as an active contributor. Instead all I got was a bunch of empty promises and a year later, somebody like Hani accusing me of theft and plagarism.
BTW, We asked you not to focus your talk on JBoss AOP, well...because we were speaking on the same exact subject at the same exact conference.
Be a bit more forthcoming Bob.Bill, please reread my post. I said nothing bad about JBoss or any JBoss member nor did I even insinuate anything. I never have, which is why I have a hard time understanding why you continue to publicly berate me. Hans suggested that I was reinventing the wheel and specifically mentioned JBoss AOP--I pointed out that JAdvise came first. I also wanted to convey that jAdvise wasn't "abandoned" because effectively JBoss AOP picked up where it left off.
I said nothing in regard to whether I did or didn't continue to contribute. But now that you mentioned it... In part I didn't agree with the direction the design was going; I made that abundantly clear at the time. Moreso, as a developer, you write open source for free and you have to sacrifice other projects and your life to make time for it. You *really* have to believe in the project, and you *really* have to like the people your working with. Unfortunately, we didn't have that chemistry. Getting publicly humiliated by Marc regardless of the excuses afterwards doesn't exactly leave you pining to contribute to JBoss. Your response here is more of the same.
BTW, We asked you not to focus your talk on JBoss AOP, well...because we were speaking on the same exact subject at the same exact conference.BillBill, I can't believe you'd lie like that. Please, as a friend, don't publicly comment on anything that has to do with me or one of my projects again.
We've been evaluating AOP frameworks for about a year for use in our product & was hoping for Rikard Oberg to open-source his AOP framework until Bob's dynaop came out. If you're a developer and an aop person, I think all you have to do is look at dynaop's API and Bob's code. It is very simple, clean, and most importantly, provides a very original way to declare interceptors and introductions (mixins) via a beanshell script. Although dynaop lacks a couple of features that we were looking for, it was perfect for our needs. Our app in enterprise-level so I would say our needs are pretty demanding. Besides, dynaop provides the fatest interception performance of all the aop frameworks we benchmarked (spring, aspectwerks, nanning, & jboss -- which IMHO is not an aop framework).
Another interesting thing about dynaop is that by allowing the pointcuts to be specified in a beanshell script, we were able to integrate seemlessly both Spring Framework (for IOC) and DynAOP, using Spring's BeanFactory interface. We didn't feel like coupling the aop with the ioc service definitions in Spring's xml. This way, it allows us to really separate the cross-cutting concern services (i.e. IOC & AOP) at the service definition level too.
I personally would not reinvent the wheel or invent a wheel which is inferior to an already invented wheel. But I don't stop anyone doing it.You scared by competition ? You scared that a better framework would arise and you'd have to learn something new ? Not ? Than what's your problem ? I'd say the "AOP wheel" (at least that one with proven production quality) is far from being "completely" invented if I can put it that way.
I feel good when a new framework arises. "Let's see how's this compared to that ? and start digging". And that's how you create a better thing. By taking the good from here and there. And that's how good software gets done. Certainly not by saying "Oh god. AspectJ exists. It was created by the father of AOP. Let's all go have a nap and when we awake AspectJ will be better. Phew.
You scared by competition ? You scared that a better framework would arise and you'd have to learn something new ? Not ? Than what's your problem ?I choose learning and using technologies (frameworks, tools, methodologies and so on) by many considerations. One is quality. The other is price. Another consideration is whether it is mainstream or not. And yet another of the many consideration is, how I estimate its future: will this technology be a winner or a loser? If I see that something sucks, then I start to hate it and look intensively for alternatives. As long as I am satisfied with log4j, I will not search for a better logging framework. Why should I? Same applies to AspectJ. But I am still beginning with AspectJ, so I maybe start to hate it. But until now I like it.
My company expects me to be productive, to develop software. Being good and commited developers, we all want to learn thousands of things. But we need to be productive as well. So I would not bother learning a logging framework which is only 10% better than log4j. Thats just an example.
I try to mix technology decisions. I would not like to base too much decisions on one company or product line. I take Java SDK and J2EE from Sun, but not its IDE or its Application Server. Instead I use Eclipse and JBoss. I use log4j from Apache, but not Object Relational Bridge from Apache. Instead I use Hibernate. And so on. In the end I have a good mix. Its like mixing of stocks: it reduces the risk of bad investion.
And I'm like a sportsman. If I would be a professional soccer player, I would not switch to profesionally playing tennis. All the past effort in training playing soccer would be wasted then. So as a developer I choose in which direction I want to go. I ask myself: Is it worth learning it for me? I have a limited time on earth. So I must make decisions what to learn and what not. Its like a actor. He has to decide in which movies he accepts to play and which offers he rejects.
When Bob mentioned so many "really cool" AOP frameworks I really thought: "Why the hell did he programm yet another AOP framework?" He explained it here. I just want to close the circle by this statement.
One of the best ways to understand a software technology is to implement it for oneself. It gets you first hand familiarity with the issues.
Heck before I jumped into using J2EE app servers full time I'd first written my own mini app server and actually used it for production code. But these days I only use app servers that have been developed by teams of programmers and that adhere to specs. It was a very useful exercise, though, to learn some app server issues first hand - and to learn Java programming. Plus that code is still doing a bang up job saving its customers money due to improved efficiency of their operations (so it wasn't throw away). (But these days I need failover clustering and distributed caching and the app server I now use makes it super easy to build apps that make use of all that - thanks to its AOP capabilities.)
"Crazy" Bob can better explain the subject matter to his audiences because he's gotten his hands dirty in actual AOP framework implementations. Gives him more credibility to talk on the subject.
What good programmer hasn't implemented something for his/her self as a vehicle for personal learning?
One of the best ways to understand a software technology is to implement it for oneself.I agree with you. I'm just a little bit nervous because on my job I have to use a ERP framework where the framework creators reinvented the wheel many times. And their reinvented wheels are often much worse then the already invented wheels. As a developer I am totally dependent on this small framework creator company. All the information and documentation comes from them. They made our company totally dependend because they didn't use already existing sub-framworks, for example for validation, GUI, persistence and component design. So I was maybe a little bit too nervous seeing so many AOP implementations, some compiler based, most framwork based.
Bob is okay. My critique was not meant personally. It was a little bit like shooting in the bush with a shotgun and see if I have hit something...
I am totally dependent on this small framework creator company.
It can be a problem, but this problem does not exists in opensource code,
you can fork it and to reinvent wheel yourself (more work, but can reduce risk or it can solve problems specific for your application).