The community likes to hear from Java's creator, James Gosling. We heard various sound-bites from him around JavaOne, but this latest interview by eWeek is fairly detailed and asks questions on topics such as open sourcing Java, AOP, Groovy, NetBeans/Eclipse, and more.

Excerpt

Q. What's your position on aspect-oriented programming?

AOP is kind of a complicated one for me, because AOP is one of these things where the theory sounds really good. I actually mostly like the theory. The way it turns out in practice tends to be pretty dangerous. It's fraught with all kinds of problems. You know when the AOP folks talk about AOP they list you like three or four use cases for AOP and they actually mostly make sense, although they have problems in the details. But there actually aren't very many use cases outside of that. And when you find people who are using AOP, the average ones that I've talked to have been using it for things that are just like incredibly inappropriate. It's like a really, really, really bad idea to be doing what they're doing. And so I feel very conflicted because on the one hand I basically like the concept, but I don't think that the research community has really figured out how to encapsulate those in a mechanism that really works for people. It's like giving them a chainsaw without any safety instructions.

Do you like Groovy?

I think Groovy is pretty interesting. I think they're being fairly conservative. I think they could be a little more outlandish and get a little more interesting.

 remember sort of reading through their syntax list and saying, "Oh, why didn't you do this and why didn't you do that?" There were some things about the way that they did sort of the equivalence of declarations and some things about the way they did case switch statements … I sort of felt like writing them this long letter and saying, "What? Why didn't you do it this way?" You know … (laughter). So they actually had some neat stuff in there.

But I like Groovy a lot. We sort of got into political hot water when the whole JavaScript thing happened. So we've tended to try to have sort of an arm's length relationship to anything having to do with scripting. We're happy to use scripting; we do a lot of scripting ourselves …. I actually did a pretty nice scripting language; at least I think it was nice, back in the early days. And I threw it in the trash can when the whole JavaScript thing with Netscape happened. And you know, in retrospect, ugh, what a bizarre thing to have done. But, you know, it's water under the bridge.

Read the full interview: Sun's Gosling: New Java Flavors Brewing

AOP is kind of a complicated one for me, because AOP is one of these things where the theory sounds really good. I actually mostly like the theory. The way it turns out in practice tends to be pretty dangerous. It's fraught with all kinds of problems. You know when the AOP folks talk about AOP they list you like three or four use cases for AOP and they actually mostly make sense, although they have problems in the details. But there actually aren't very many use cases outside of that. And when you find people who are using AOP, the average ones that I've talked to have been using it for things that are just like incredibly inappropriate. It's like a really, really, really bad idea to be doing what they're doing. And so I feel very conflicted because on the one hand I basically like the concept, but I don't think that the research community has really figured out how to encapsulate those in a mechanism that really works for people. It's like giving them a chainsaw without any safety instructions.

Could not have been said better about my own view on AOP.

Regards,
Nikita Ivanov.

AOP is a good way to implement boring infrastructure code, but I think it is not a good idea to try solve domain specific problems with AOP. Do not oweruse AOP concepts and it will work for you.

AOP is kind of a complicated one for me, because AOP is one of these things where the theory sounds really good...


You know when the AOP folks talk about AOP they list you like three or four use cases for AOP and they actually mostly make sense, although they have problems in the details. But there actually aren't very many use cases outside of that.

And when you find people who are using AOP, the average ones that I've talked to have been using it for things that are just like incredibly inappropriate. It's like a really, really, really bad idea to be doing what they're doing.

Well this was an interview, so it isn't fair to expect more detail, but... it would be nice to see more detail. For example, it seems to me that the examples in Mastering AspectJ in AspectJ in Action are incredibly appropriate. They involve clear, stable, easy-to-understand aspects that improve design and code. And there's more than 3 or 4 of them. So it would be nice to hear more specific comments about what Gosling thinks about examples like that. Or more concrete details about what are the terrible examples he's referring to.

On the other hand, as others have pointed out, when Gosling speaks on Java, he is heard by the entire range of the Java community, from early to late adopters. And I don't think anyone would claim that aoP is ready for late adopters yet. (Although using packaged aspects ala JBoss probably is.) So I bet Gosling probably has to be extra careful to tell the late adopters to go slowly.

Q. What's your position on aspect-oriented programming?AOP is kind of a complicated one for me, because AOP is one of these things where the theory sounds really good. I actually mostly like the theory. The way it turns out in practice tends to be pretty dangerous. It's fraught with all kinds of problems. You know when the AOP folks talk about AOP they list you like three or four use cases for AOP and they actually mostly make sense, although they have problems in the details. But there actually aren't very many use cases outside of that. And when you find people who are using AOP, the average ones that I've talked to have been using it for things that are just like incredibly inappropriate. It's like a really, really, really bad idea to be doing what they're doing. And so I feel very conflicted because on the one hand I basically like the concept, but I don't think that the research community has really figured out how to encapsulate those in a mechanism that really works for people. It's like giving them a chainsaw without any safety instructions.

We have been using AOP (note the "P") since July 2002, when we started building our CMS product SiteVision. Many on our team used to work on another similar product for another company before, and it's interesting to look at some of the metrics. In half the time, with roughly half the code, we have twice as many features implemented as the other product. We're 5 developers, but since we also do installation, training, support, and sales, I'd say we have had about 6 man years of effective development time. To go from scratch to top-five CMS's in Sweden in such a short time, and with such a small number of developers, is a pretty decent thing to accomplish methinks.

Our typical time from idea-to-implementation is roughly between two days and one month, because typically we can reuse 30-80% of a new feature by using already built aspects (both advice and introductions).

We have, among many other things, implemented replication, client-side undo management, transactions, transparent partial object state versioning, security, locking, etc. as aspects, which we can reuse on any component or object model. Whenever we start on a new feature all such things are already there and "just works".

I do know that we are probably an anomaly when it comes to using AOP, both in what we use (=homegrown) and how (=throughout product), but I still think it's a good sign that AOP as such is not only viable, but can be a *key factor* in developing competitive software. I can safely say that *without it* our company would be dead by now.

Oh, and it's both performant *and* maintainable. How 'bout that!

Oh, and it's both performant *and* maintainable. How 'bout that!

Sounds terrific, except that you never know how maintainable a piece of
software is until all the original developers are gone. 8-) And I think
that's where Gosling's concern on abuse/overuse of AOP comes from.

I do understand Gosling’s mentality: he is concerned about “crowd” safety and it is certainly valid concern. It is very visible in Java design. However it is aging concern and soon will be outdated because of changing IT environment: in 94-99 it was a booming sector with tons of inexperienced, ignorant but energetic people. I see a trend now toward work in smaller teams of professional developers. Small team of smart people armed with adequate tools can do much more than huge development department ( Richard’s example is a very good one).
AOP and such is the right toolset for them. I think that concerns about “less experienced” developers (although valid) are exploited by those “less than perfect” developers for their own benefits. Kind of nowadays Luddites ( in 18xx they attacked machines ).
Tools just should be labeled: for smarties/dummies :)

I do understand Gosling’s mentality: he is concerned about “crowd” safety and it is certainly valid concern.

More and more, I'm seeing AOP as a new form of metaprogramming for Java, similar to LISP macros, without the language support. The Java language designers haven't sanctioned any language-integrated form of metaprogramming, so people have started doing their own metaprogramming outside of the language. It's really interesting to note how AOP is starting to take over tasks that were previously achieved through different styles of metaprogramming - i.e. source code generation. I wonder if the inclusion of annotations in the new Java language is going to signal a change in direction towards more language support for metaprogramming.

God bless,
-Toby Reyelts

More and more, I'm seeing AOP as a new form of metaprogramming for Java, similar to LISP macros, without the language support...

Please don't!! :)

One of the most important differences between AspectJ, and earlier things like reflection, metaobject protocols and macros, is that AspectJ is NOT like meta-programming. The same is true for AspectWerkz and others. What I mean is that when I read an aspect like, Ram's swing thread safety aspects for example, the BEST way to read it is something like:

  when I call these operations, be sure to be in another thread

The way to read it is NOT:

  go find all these calls in the source code, and wrap the call site in this code

This difference may appear minor, but its quite significant IMHO. In the early days of OOP, some people get talking about things like method tables, and generated dispatch code and the like. But now we all know that you want to think about objects in terms of what they do, not in terms of how that code is compiled. The same is true for AOP. Thinking about it that way will lead to better AOP designs, and to developing reusable aspects.

Note, I do believe that annotations are best seen as hooks for Lisp style macros. I wrote a column about that.

I found it is more easy to sell AOP as code generation for decorator design pattern. It is possible to change this way of thinking later and It is the mater of taste, some people better understand abstractions, some people want to know internals to understand new things. I think both ways of learning are good.

Please don't!! :)One of the most important differences between AspectJ, and earlier things like reflection, metaobject protocols and macros, is that AspectJ is NOT like meta-programming.

In what way? I've used both AspectJ and AspectWerkz (I use neither now, because they both had shortcomings I couldn't live with), so I'm not unaware of the general concepts of pointcuts, advice, and aspects. Perhaps my definition of meta-programming or aspects is more lose than yours? Of course, I've been writing my own Java "aspects" by hand since before AspectWerkz existed, and at least since before AspectJ was released out into the wild.

What I mean is that when I read an aspect like, Ram's swing thread safety aspects

Do you have a reference for what you're talking about here?

In the early days of OOP, some people get talking about things like method tables, and generated dispatch code and the like. But now we all know that you want to think about objects in terms of what they do, not in terms of how that code is compiled.

I still don't get you. Talking about vtables to understand implementation details of a compiler is worse than useless, because it's a very simplistic and naive model. Talking about vtables as a way to imagine polymorphic dispatch can be quite useful. You need to understand what polymorphic dispatch is before you can understand how to use it for implementation hiding and design by contract programming.

I wrote a column about that.

A nice read, thanks.

God bless,
-Toby Reyelts

more lose

Of course, that should read more loose

Please don't!! :)One of the most important differences between AspectJ, and earlier things like reflection, metaobject protocols and macros, is that AspectJ is NOT like meta-programming.

In what way? I've used both AspectJ and AspectWerkz ... so I'm not unaware of the general concepts of pointcuts, advice, and aspects.

Imagine a future in which AOP support is tightly integrated into the VM. Sometimes, in "pure interpreter mode" advice weaving happens as part of method dispatch, field access etc. and no code is changed. Othertimes, in "JIT mode" advice weaving happens when the JIT runs. But in both cases, weaving is something that you really don't see. In other words, advice weaving works like method dispatch does today.

Now, if you are someone who prefers to think about the design of a Java program, by thinking about how advice dispatch is implemented, then by all means, go ahead and think about the design of AOP programs in those same terms.

I believe that for *most* purposes, its better not to think about a class that way, and similarly I claim for *most* purposes its better not to think about aspects that way.

But there's no doubt that for many people (especially early adopters) one good way to really get your head around AOP is to really understand what the implementation does inside.

Maybe the think to say is that its BEST to be able to think both ways; SECOND BEST to be able to think only at the more abstract level; and third best to only be able to think in terms of the underlying implementation.

Is that fair?

What I mean is that when I read an aspect like, Ram's swing thread safety aspects

Do you have a reference for what you're talking about here?

AspectJ in Action, Ramivas Laddad.

As I said on Rickard on Gosling on AOP, power isn't always a bad thing.

It depends on your situation. In Rickard's case it has obviously been his secret sauce. It enables his team to run and deliver faster.

As I said on Rickard on Gosling on AOP, power isn't always a bad thing.It depends on your situation. In Rickard's case it has obviously been his secret sauce. It enables his team to run and deliver faster.

And it's not really secret, is it? ;-)

But yes, it certainly does allow us to run and deliver faster. As I said, the time from idea to finished product is rather short, and the quality is typically good since there's a minimal amount of coding to implement it. And the more you work with it, the more you learn to see where aspects can help reduce code duplication and help reduce code entanglement.

For example, we had one case the other day where we had objects representing colors, for fonts and borders and such, which had to be different depending on the users accessibility settings in the session. Basically, if accessibility is "off" you want it to look pretty, and if it is on then it should be easy to read. The options we had - not considering AOP that is - was to either wrap all calls to these objects in some utility class which understands user sessions and accessibility settings, or we could put it directly into the color representation code with some if-statements. The first case would pollute the client code, and the second would pollute the object model code with HTTP session code and similar. The final solution was an advice that intercepted the "toHexCode" method and integrated with the user settings management. By using abstract schema we avoided using regexps to map the advice to the method, and by using PicoContainer for DI we could let the advice access the HTTP session with the accessibility settings. All in all it was a small, clean solution which without AOP would have been *considerably messier*. The code was in one place, and had dependencies only to the minimal amount of components and interfaces it dependend upon.

The main drawback with this solution is that, as is often pointed out, you can't see this behaviour "just by looking at the code". And by "code" one often means the base implementation, in this case the "toHexCode" method. And it is for this precise reason why we've created a code browser which allows us to get a holistic view of all our code: regular classes, introductions, and advice. All in one place, cross-linked and integrated with JavaDoc.

And it is for this precise reason why we've created a code browser which allows us to get a holistic view of all our code: regular classes, introductions, and advice. All in one place, cross-linked and integrated with JavaDoc.

I don’t know Rickard’s CMS system but that feels awfully like a design-smell. Again, it may be appropriate for this specific system but designing a browser for your own Java code should definitely give a pause to anyone considering the technology that pretty much requires it for any but a toy project.

It was very much my (ours) experiences when we dropped AspectJ more than a year ago (for this and for other reasons).

Regards,
Nikita Ivanov.

it is awesome that really smart people are pushing the envelope in terms of what is possible, and rickard is definitely on the right track when he argues for AOP in terms of reduced complexity and reduced programmer hours per given unit of productivity, cause let's face it, at the end of the day, those are the only two arguments that really cut butter...

but, wow, the risk...

if i went to my brass and explained that we had to create a custom code browser (plugin for Eclipse say) just to follow the logic and dependency chaining implicit with AOP, i would no doubt be shown the door pretty darn quick...

AOP will find its niche, but after hearing this tail, i have definitely decided to assume a wait and see posture.

0.02

Peter

I don’t know Rickard’s CMS system but that feels awfully like a design-smell. Again, it may be appropriate for this specific system but designing a browser for your own Java code should definitely give a pause to anyone considering the technology that pretty much requires it for any but a toy project.

Not sure I follow... the "browser" is mostly a souped up version of JavaDoc, i.e. it generates HTML which is crosslinked to JavaDoc. Are you saying JavaDoc is bad?

In practice I don't use it much but once in a while it is useful to see that the structure of everything is as I intended it to be.

I don’t know Rickard’s CMS system but that feels awfully like a design-smell. Again, it may be appropriate for this specific system but designing a browser for your own Java code should definitely give a pause to anyone considering the technology that pretty much requires it for any but a toy project.

It seems that those involved with Eclipse, or at least parts of it, are in disagreement with you.

http://www.theserverside.com/news/thread.tss?thread_id=27421

The main drawback with this solution is that, as is often pointed out, you can't see this behaviour "just by looking at the code". And by "code" one often means the base implementation, in this case the "toHexCode" method. And it is for this precise reason why we've created a code browser which allows us to get a holistic view of all our code: regular classes, introductions, and advice. All in one place, cross-linked and integrated with JavaDoc.

There is no problems with naming conventions, but it is a bad idea to interpret names or to define contracts with method name (the same is about get/set) Anotations must be a better way.

The chainsaw is safe in your hands.

You are just 5 developers and all 5 are probably hardcore, experienced, intelligent developers. Looking back, if you had a larger time with a sizeable number of junior developers, would you give them the chainsaw, even under supervision? You would probably have to watch over their shoulder all the time. The small team size probably allowed you to do this for those in your team not familiar with AOP.

I suppose it's the same argument that applies to any bleeding-edge technology. Know what you are doing, otherwise you will bleed. In case of AOP, this applies not just to the lead developer/architect but everybody else on the team.

Looking back, if you had a larger time with ..

make that "Looking back, if you had a large team with a ..

Looking back, if you had a larger time with a sizeable number of junior developers, would you give them the chainsaw, even under supervision?

You should see the massacre when the Junior Developers are on the other side of the world and there's no one to monitor them closely... Just the thought of it makes me shudder...

I was a "junior" too and I do not see any problems with "junior" developers, technology can not help, learning and good co-workers can. "Junior" will do mistakes with any technology if "senior" will not help.

Looking back, if you had a larger time with a sizeable number of junior developers, would you give them the chainsaw, even under supervision?

You should see the massacre when the Junior Developers are on the other side of the world and there's no one to monitor them closely... Just the thought of it makes me shudder...

The chainsaw is safe in your hands.You are just 5 developers and all 5 are probably hardcore, experienced, intelligent developers. Looking back, if you had a larger time with a sizeable number of junior developers, would you give them the chainsaw, even under supervision?

First of all, considering that I can do more in less time and with a fraction of the effort, there is much less need to have a large team in the first place. With the development rate I'm seeing right now I doubt we will ever have more than 8-10 people working on the core product. For consulting and similar add-on services there's no real limit, of course. But then again there's no need for our company to be providing that service. It might be better to have large consulting companies as partners providing those services.

Second, my experience so far is that with some introduction (pun intended) to the main concepts most developers can with a little training develop introductions (=domain model fragments). With a little more experience it is also possible for most developers to develop advice, especially in the domain model areas since there are definite patterns there which are repeatable.

You would probably have to watch over their shoulder all the time. The small team size probably allowed you to do this for those in your team not familiar with AOP.I suppose it's the same argument that applies to any bleeding-edge technology. Know what you are doing, otherwise you will bleed. In case of AOP, this applies not just to the lead developer/architect but everybody else on the team.

That's not necessarily true, or at least that's not my experience. Do you have any practical war stories to back your opinion?

Richard,

I really haven't made up my mind about AOP but I do remember that you once argued for EJB with the same vehemence and that makes me a little thoughtful. Even the 1.0 version! (made by aliens according to Cameron) I seem to me that you have a longing for complexity that gets you astray now and then. It is the simple solution that shows the genius, not the other way around.

Regards
Rolf Tollerud

Richard,I really haven't made up my mind about AOP but I do remember that you once argued for EJB with the same vehemence and that makes me a little thoughtful. Even the 1.0 version! (made by aliens according to Cameron) I seem to me that you have a longing for complexity that gets you astray now and then. It is the simple solution that shows the genius, not the other way around.RegardsRolf Tollerud

How easy it is to forget the context. When I argued for EJB it was because in the context of those days it was a step forward. When I argue for AOP today it is because it is, again, a step forward. If you choose to see events out of context and out of order that is your choice.

As for simple solutions, when we started down the AOP route all other options that I could think of (and yes, I tried EJB for the first iteration) led to more complex solutions. In the end AOP was the only one which led to the least amount of code and complexity, and at that time it was not because "it was cool". It was, to a large extent, because of the constraints we had: no time, no money, only a few developers, and no customers. Such constraints force you into rethinking *all* choices made thus far, and the solution we came up with, and which so far has been working quite well, was to use AOP throughout the system. If I had to do it again I would probably do the same. In five or ten years from now maybe I wouldn't. Who knows.

>We have been using AOP (note the "P") since July 2002, when we started building our CMS product SiteVision. Many on our team used to work on another similar product for another company before, and it's interesting to look at some of the metrics. In half the time, with roughly half the code, we have twice as many features implemented as the other product. We're 5 developers, but since we also do installation, training, support, and sales, I'd say we have had about 6 man years of effective development time.

I am not quite getting the point you are trying to make. If you have done something before - say program a CMS - I would argue that you have explored a lot of the wrong turns and alleys in development of CMS before. You have a good understanding of the best underlying data structures. Chances are you even have an understanding of what a CMS customer really wants. Chances are in a smaller company, you will be less influenced by wrong management decisions. Chances are you earn more and just work more/better, because you take more pride in the product ("Getting it right this time"). So <em>not</em> to get twice as many features done in <em>half</em> the time would have been, plainly, a pretty damn poor performance, even if you switched your programming language altogether, say from Delphi to Perl.
As for half the code, that certainly might come in with AOP. But there I think, half is plainly not good enough, because AOP tends to be "twice the complexity". Also, you might slice a large portion of the code by simply following better coding standards. So it seems to me your success is more or less totally unrelated to AOP.

I am not quite getting the point you are trying to make. If you have done something before - say program a CMS - I would argue that you have explored a lot of the wrong turns and alleys in development of CMS before. You have a good understanding of the best underlying data structures. Chances are you even have an understanding of what a CMS customer really wants. Chances are in a smaller company, you will be less influenced by wrong management decisions. Chances are you earn more and just work more/better, because you take more pride in the product ("Getting it right this time").

All of those things are certainly factors to consider as well, sure. The design phase was certainly easier since we already had a good grasp of what we wanted to do. In terms of implementation it certainly helps to be able to write less code though, and AOP helps with that.

As for half the code, that certainly might come in with AOP. But there I think, half is plainly not good enough, because AOP tends to be "twice the complexity".

Maybe. How do you measure "complexity"?

Also, you might slice a large portion of the code by simply following better coding standards. So it seems to me your success is more or less totally unrelated to AOP.

The factors you list are certainly important as well, but without AOP they would not have mattered because all of them on their own would not have been sufficient. The factors you list have mainly to do with design, and AOP, the way we use it, has more to do with implementation. It doesn't matter if you can get a good design if the implementation is not good enough.

All of those things are certainly factors to consider as well, sure. The design phase was certainly easier since we already had a good grasp of what we wanted to do. In terms of implementation it certainly helps to be able to write less code though, and AOP helps with that.

Ah, well but AOP probably helped you to write less code in the areas you deemed repeatable and maybe even boring :-). One might argue that in such areas any good design will save significant coding effort. So you are right to state it is a matter of design, and one might suspect, the design in your first company was inferior and had more redundancy than the one in your second company. So AOP may very well work for you, because your design - implicit or explicit - is good. Then again, good design will usually create less and more maintainable code in the first place, no matter what the coding paradigm.

On the other hand, with AOP there is pretty much nothing that stops you writing "less code", so it is fairly easy to create programs, not designs, that cross cut where it is not appropriate and not stable. If that happens - and it happens quite a lot - I would argue that it is quite hard to fix compared to a more traditional approach.

Karl,

I would argue that you have explored a lot of the wrong turns and alleys in development of CMS before. You have a good understanding of the best underlying data structures. Chances are you even have an understanding of what a CMS customer really wants.

I agree with you. Richard doesn't realize that he has become a CMS expert. If he was to rewrite everything next year, he would do a better implementation with even less lines of code! :) With or without AOP.

Regards
Rolf Tollerud

I'm not sure I can believe that Karl and Rolf are actually telling Rickard that his version of why he's successful isn't true. Unless they're intimately familiar with the product, I'd tend to believe the developer's story over a third party observer's.

Most of the time you should just ignore comments made by rolf, sometimes i think that he is just here to cause trouble.
Had to say it, feel free to mark me as noisy since im not on topic here :)

Simon: he is just here to cause trouble

What an unkind thing to say. I fact I am really curious to what the TSS forum thinks of AOP, and how much traction is has got. Why doesn't TSS have a survey facility? Maybe Richard can donate a version of Sitesurvey?

Excerts from their site,

Senselogic Sitesurvey

Revolutionary user friendliness both for those who creates surveys and for the respondents. A analysis module is integrated with advanced filtering and the results is directly available in the browser.

Regards
Rolf Tollerud

I'm not sure I can believe that Karl and Rolf are actually telling Rickard that his version of why he's successful isn't true. Unless they're intimately familiar with the product, I'd tend to believe the developer's story over a third party observer's.

I am not saying his version is true. All I say it that this reduction in code is hardly surprising considering that the whole development team has gathered domain knowledge in a previous company that broadly dealt with the same problems. AOP for me is a - sometimes very powerful tool - to cut down code size and - sometimes - increases maintainability.

Also note that a lot of complexity reduction and code size reduction that is achieved with AOP is basically done by call interception. This is a pattern that is very easily created with good upfront design in any OO programming.

We have, among many other things, implemented replication, client-side undo management, transactions, transparent partial object state versioning, security, locking, etc. as aspects, which we can reuse on any component or object model. Whenever we start on a new feature all such things are already there and "just works".

Rickard,

I sounds like a good portion of your CMS application consists of tons aspects all woven together. It looks like you guys have tried to take the notion of AOP as far as it can go. You suggest that adding a new feature can often be taken care in large part by weaving in existing aspects. If you have this stable of resuable aspects at your disposal, is configuration difficult?

I would imagine that if a large part of your application is made up of reusable aspects, the configuration to tie all this together must be complex. How do you manage this? What tools are you using? Or is it not as complex as I am imagining?

Ryan

Rickard,I sounds like a good portion of your CMS application consists of tons aspects all woven together. It looks like you guys have tried to take the notion of AOP as far as it can go. You suggest that adding a new feature can often be taken care in large part by weaving in existing aspects. If you have this stable of resuable aspects at your disposal, is configuration difficult?I would imagine that if a large part of your application is made up of reusable aspects, the configuration to tie all this together must be complex. How do you manage this? What tools are you using? Or is it not as complex as I am imagining?Ryan

There are a number of cases. Some things, like replication, is applied everywhere by default, so there's no explicit configuration to be done. In many other cases the configuration goes like this: "I want ACL's on this object, hence I add the ACL introduction to the object", which basically comes down to add "ACL" to the "interfaces" attribute in an XML file. If any particular advice should be applied to all places where ACL's are used, then those are already configured to trigger for that automatically, i.e. there's no configuration to be done for each new module which is reusing aspects (note: aspects=both advice *and* introductions).

That's pretty much it. Then you run the HTML generator on it to see if the changed configuration had the desired effect, i.e. you look at the effective configuration. This is often important since the configuration is declarative instead of explicit, which helps reduce the amount of work to be done. The HTML generator shows the explicit result of the declarative configuration.

This is the typical day to day work we do with the aspect configuration. So, no, I don't think it's that complex.

One important point is that using abstract schema brought down the complexity, and brittleness, of configuration A LOT. Since many of the dependencies and requirements of aspects are declared in type-checked Java code most errors are caught when the code is compiled. This leaves less room for error in the configuration of the system.

Rickard:

In many other cases the configuration goes like this: "I want ACL's on this object, hence I add the ACL introduction to the object", which basically comes down to add "ACL" to the "interfaces" attribute in an XML file. If any particular advice should be applied to all places where ACL's are used, then those are already configured to trigger for that automatically, i.e. there's no configuration to be done for each new module which is reusing aspects (note: aspects=both advice *and* introductions).

That's pretty much it. Then you run the HTML generator on it to see if the changed configuration had the desired effect, i.e. you look at the effective configuration. This is often important since the configuration is declarative instead of explicit, which helps reduce the amount of work to be done. The HTML generator shows the explicit result of the declarative configuration.

I don’t know is it me only who thinks that this is rather "strange" way to do the configuration? Indeed, creating configuration via introduction in XML, and then run HTML generator that generates viewable cross-referenced documentation to manually check that introductions have had a desirable effect... It could be a specific problem with Rickard’s system but even with AspectJ we found it rather killingly awkward to constantly visually (manually) check that our aspects were cross-cutting where we intended them to. And then once you add something like cflow (AspectJ) situation gets almost desparate...

Regards,
Nikita Ivanov.

Not to argue, but I haven't found using AspectJ and the excellent AJDT plugin for Eclipse to be "killingly awkward."

Not to argue, but I haven't found using AspectJ and the excellent AJDT plugin for Eclipse to be "killingly awkward."

Hi Nicholas,
Ok, may be I still have bad aftertaste in my mouth so lets remove "killingly" and leave it just at "awkward". It doesn’t change much – in my view it is still awkward. But the point though was that I do agree with Gosling’s comment, paraphrasing – theory is great, implementations are not.

Regards,
Nikita.

I agree with Rickard on this, I wrote a blog entry about it:

http://surfrat.blogspot.com/2004/07/aspect-arguments.html

This is very trivial if you will try to think about AOP as design pattern. It has as many use cases as Decorator design pattern has. It has some "exotic" features too, but if you do not use exotic stuff then you will not have more problems with AOP than with OOP.

It's hard to tell who's talking. The problem with any corporation is that it's actually a collection of people, and IBM is a huge collection of people. I mean IBM's ten times the size of Sun, with ten times as many people arguing. Never ever mistake a corporation for a coherent entity.

This guy is full of wisdom!

Finally it seems That Sun not openSource java
and its best decision for not allowing community to be forked.
does it?

Concerning AOP its like with Exceptions. One can abuse it or use it correctly. There are good, bad and ugly practices.

I think AOP is a good thing. But it requires good tool support (IDEs supporting coding with AOP). I know only AspectJ.

Yes, using AOP requires that you understand how to use it.

Yes, understanding how to use a new paradigm is harder than working in an old paradigm because you don't have years of good (paradigmatic) examples to learn from.

But letting a bunch of junior developers (or even average developers) loose on OOP 10 years ago was also easily a recipe for disaster (there are a number of books about the disasters that Cobol programmers told to "do OO" accomplished with this newfangled C++). Or look at Java AWT's extremely long inheritance hierarchies for an examples of people who aren't dealing well with a new-ish technology - even experienced developers could make mistakes in how to use OO then that no experienced developer would make now.

So Gosling's argument isn't an argument against AOP, just a reminder that being too close to the cutting edge is not a smart thing for most mainstream development.

Sean

The way it turns out in practice tends to be pretty dangerous. It's fraught with all kinds of problems. You know when the AOP folks talk about AOP they list you like three or four use cases for AOP and they actually mostly make sense, although they have problems in the details. But there actually aren't very many use cases outside of that.

I tend to disagree. I've found a wide variety of use cases in various problem domains for AOP. I've just been working on a presentation about how my company applied AspectJ to a J2EE project. The challenge for me was to pare down the list of uses we've found to a manageable length.

 And when you find people who are using AOP, the average ones that I've talked to have been using it for things that are just like incredibly inappropriate.

I wish I had something concrete to disagree with here. In most of the cases where I've applied AOP, I've seen a concrete reduction in code complexity without a loss of comprehensibility. I'm not sure what he means by inappropriate.

It's like giving them a chainsaw without any safety instructions.

Well, I don't think anyone disagrees that any technology can be misused. I'm sure we've all seen Java misused. :-)

That being said, I really like the chainsaw analogy. Why? Because as a developer I imagine myself as a lumberjack who's been cutting certain trees (crosscutting concerns) with a handsaw. A chainsaw presents a huge opportunity for me to get ahead of the competition. Yes, it entails some risks--but real lumberjacks use real chainsaws despite their risks.

As for the instruction manual--I think that the AOP community (as a whole) has strongly encouraged developers to pursue an incremental approach to adoption. Furthermore, there are training courses, books, articles, and presentations available on AOP to help new users get started with low-risk experiments.

So yes, I agree that new technologies are difficult and risky, but I don't think there's anything inherently dangerous about AOP.

I wish I had something concrete to disagree with here. In most of the cases where I've applied AOP, I've seen a concrete reduction in code complexity without a loss of comprehensibility.

It's like giving them a chainsaw without any safety instructions.

I wish I had something concrete to disagree with here. In most of the cases where I've applied AOP, I've seen a concrete reduction in code complexity without a loss of comprehensibility. I'm not sure what he means by inappropriate.

I frankly think it is quite interesting that we are down to discussing "reduction in code". The initial promise of AOP was that it was to be used to implement "cross cutting concerns" and that they would be implemented and maintained by staff that was not coupled to the developers of whatever these concerns cut through.

I frankly think it is quite interesting that we are down to discussing "reduction in code". The initial promise of AOP was that it was to be used to implement "cross cutting concerns" and that they would be implemented and maintained by staff that was not coupled to the developers of whatever these concerns cut through.

It is interesting, "reduction in code" is caused by "cross cutting concerns".
The goal is not to reduce code. And you say true about OO design too, classic OOP desing patterns ( Interceptor and Decorator ) can do the same, AOP language or framework just generates it at compile or at run time. You do not need to see something very clever or magic in AOP, it is code generation.

In most of the cases where I've applied AOP, I've seen a concrete reduction in code complexity without a loss of comprehensibility. I'm not sure what he means by inappropriate.

I frankly think it is quite interesting that we are down to discussing "reduction in code". The initial promise of AOP was that it was to be used to implement "crosscutting concerns" and that they would be implemented and maintained by staff that was not coupled to the developers of whatever these concerns cut through.

I don't really agree...

The goal of AOP has always been to support the modularization of crosscutting concerns. In turn, modularity of any kind (procedural, oo, ao etc.) has many benefits:

 - reduction in code size
 - (un)pluggability
 - better correspondence between design and code
 - better designs and code (more clear, coherent...)
 - fewer bugs
 - enhanced ability to align organization structure, expertise, and coding responsibilities

and so on.

So I see no change in claims here. The original message focused on one of the longstanding AOP claims, you are focusing on another.

I don't really agree...The goal of AOP has always been to support the modularization of crosscutting concerns.

Gregor, quite frankly, one of the main selling points and promises of AOP has always been that the coder of whatever an Aspect is acting upon need not be aware of the Aspect and that the author of the aspect need not be aware of the internals of the code it is working on - I like to call that "grey box re-use".

If we are just after the code reduction there are much more obvious ways like CLISP :-). And that AOP in the end derives its power from what with CLISP a lot of people have called "unclear", "complex" and "dangerous".

I prefer to understand things I use, knowlege is not a bad thing. "Pointer" was
too abstract concept for me before I renamed it to "address" for myself too.
People are not equal and use different ways to understand things.

I don't really agree...The goal of AOP has always been to support the modularization of crosscutting concerns.

Gregor, quite frankly, one of the main selling points and promises of AOP has always been that the coder of whatever an Aspect is acting upon need not be aware of the Aspect and that the author of the aspect need not be aware of the internals of the code it is working on - I like to call that "grey box re-use".If we are just after the code reduction...

I didn't say were just after code reduction. I said were after modularity and ALL of its benefits. What you describe as

coder of whatever an Aspect is acting upon need not be aware of the Aspect and that the author of the aspect need not be aware of the internals of the code it is working on

is also a modularity benefit, having to do with the power of interface abstraction. AOP's new mechanisms for defining interfaces is what gives you this property.

My main point really is just that its fine to cite code reduction as a benefit of AOP, and as ONE OF the original goals, since its subsumed by the main goal of improved modularity.

Me too. But I would step back and say "programming" as a whole is like a chainsaw. And way too many who are not "qualified" to use a traditional saw have gone down to their local hardware store and bought them a chainsaw thinking now they can cut down trees the size of redwoods. When in reality, those who can and are trained and ... could do it better, safer and faster with less people and cost . And most of all be able to wield those special saws when the occassion arises.

Me too. But I would step back and say "programming" as a whole is like a chainsaw. And way too many who are not "qualified" to use a traditional saw have gone down to their local hardware store and bought them a chainsaw thinking now they can cut down trees the size of redwoods. When in reality, those who can and are trained and ... could do it better, safer and faster with less people and cost . And most of all be able to wield those special saws when the occassion arises.

It's like giving them a chainsaw without any safety instructions.

If AOP is equivalent to a chainsaw, than programming without it is like an attempt to cut down a tree with a jigsaw. Jigsaw's are great at cutting sharp curves, but it's not usefull for every problem. The same can be said about the chainsaw. Knowing when to use which comes with experience (or guidance).



I've used chainsaws without reading the instructions, and I've never cut off my arm. Some things just make sense.



Don't be afraid of using the chainsaw just because it makes loud noises and has sharp edges. It really is a useful tool.

Don't be afraid of using the chainsaw just because it makes loud noises

Chainsaws make noise? I quit using one cause it took me so long to cut wood. :)

"Vroom. Vrooom. What's that noise? What's that noise?" I loved that joke.

Some people shouldn't use any power tools. The problem is them, not the tool.

I've been waiting for AOP to get a little less bleeding edge. I don't yet have an opinion but I guess I should have a proper look.

Is there any real-world implementation of an AOP program? (i.e. petstore like?)

I'm not interested in "textbook problem created for the answer" examples.

TIA

You mean like this? http://www.theserverside.com/news/thread.tss?thread_id=27447#130697

I wasn't asking for someone's story.

I was asking whether there was an AOP download sample real world application that demonstrates AOP solving real world problems.

I should probably search on source forge rather then asking :)

You didn't say download.

Maybe if you ask Rickard nicely maybe he will show that it is more than just a story. But I understand your point.

I think JBoss actually uses AO(P). I've only downloaded but not looked. Can anyone confirm?