JavaOne day three: AO…P!
The next session I attended today was the AOP panel with Cedric Beust, James Gosling, Graham Hamilton, and Gregor Kiezales.
The absolute best thing about this panel is the lack of any of the JBoss fuckfaces. Of course, that omission is perfectly sensible given than JBoss does not do AOP, it does AO instead. Gavin Fleury turned surprising shades of purple a couple of nights ago trying to explain to me the huge differences between AO and AOP, and how you really shouldn’t be mixing the two concepts (apple and orange type situation). Perhaps next year we can have an AO panel alongside an AOP panel, so the JBossites get to have their say about their wonderful weird inventions.
The other thing that struck me in this panel is how, well, sane they all were. It’s truly a pleasure listening to a bunch of pragmatic intellectuals who have clearly thought long and hard about all the issues surrounding the topic. The difference between this and the AOP panel at TSSS was huge, and a great contributor I suspect was the delightful lack of the pettiness and self-aggrandising of the likes of Fleury. It really puts things in perspective, seeing professionals discuss such a topic vs a bunch of amateurs who are far more interested in name dropping, furious arm waving, and maniacal religious proclamations. It’s sad that the latter is a lot more populist and accessible to the unwashed masses though (yes, and I’m perfectly aware of the irony of me saying that, of all people).
Did I learn anything new? Not particularly. I felt more comfort with the thought of people like these guys thinking about AOP than almost any other group. There was a certain responsibility and pragmatism that was surprising to see. Graham for example clearly stated that Sun is conservative when it comes to changing Java, and I fully applaud that attitude. The overall message is that AOP has its uses, and is a perfectly valid new way of thinking about development. Is it superior, or does it radically alter WHAT we do (as opposed to HOW we do it)? I don’t think so. Hard problems are likely to remain hard, and a recurring theme in the discussion was the amount of binding and knowledge that aspects have of their targets. At the end of the day, I and many others felt uncomfortable with the level of coupling required, and that once you step aside from trivial examples, you’ll find that your aspects need to know an awful lot about what they’re aspecting, and collaborate fairly closely with the targets. That somewhat diminishes the overall benefit of AOP in many cases, and in some cases, proves that it is outright unsuitable.
Oh and bad news for all of you who think that AOP will make your life easier. You still need to be a skilled and competent designer to nail down what aspects you need, how to write them, when to apply them, and when not to. Bummer!
June 30th, 2004 at 8:30 pm
Apple and Oranges, so that’s what AO stands for!!!
June 30th, 2004 at 8:48 pm
AO is different from AOP, just like A is different from O. Ask the A-Team for competent advice regarding this topic.
June 30th, 2004 at 9:53 pm
I think Gosling should get a real job.
June 30th, 2004 at 10:23 pm
Re: I think Gosling should get a real job.
I think you should get a real job. And your mom too.
June 30th, 2004 at 11:56 pm
I read about AOP like 3 or 4 times and it really looks complicated (unless I am missing something).
Hope somebody comes with an alternative to AOP for the problem whatever this is trying to solve.
July 1st, 2004 at 12:03 am
>You still need to be a skilled and competent designer to nail down what aspects you need, how to write them, when to apply them, and when not to.
Damn you. If you don’t need to, what does programming mean?
Oh, I see…. they pulled the P away from AOP so you think AOP does not need such thing at all.
July 1st, 2004 at 12:11 am
BileOne???
I went the the TB, like Cameron suggested, and all I saw was that upper-lipless jackass Russell Beatoff wearing a sweater around his waste like some ivy-league wanna-be hanging out with a bunch of miscreants wearing “Mobile Geeks Rule” t-shirts.
And there wasn’t a single LuftHani uniform to be seen.
WTF? Was I too early? Perhaps I should head back out.
And is it me, or is that one Hostess smoking hot?
July 1st, 2004 at 1:27 am
I asked the hostess if she were hot. She didn’t seem to understand. I’ll give her the URL to the bile blog so she can respond directly.
July 1st, 2004 at 1:37 am
Not the one with the Russian accent, Cameron.
I am talking about the other one.
July 1st, 2004 at 2:08 am
Hani can you bile a litle about how most of the sessions are turning into an incoherent ramblings of JSR numbers!!
July 1st, 2004 at 3:43 pm
I too saw the panel at TSSS and I agree, the immature ruined it for the rest of the panel, and we the audience suffered for it. However, I think you are missing the boat with AOP. Nobody is claiming that it is easy and that you don’t have to have half a brain to do it.
All the AOP crowd are saying is that there is this class of problems, that can often be identified by the fact that the code for the solution is or could be in every freakin’ class in existance (or more then a few anyways). And here is this other way to implement the solution that is easier to maintain. A hard problem is still hard, but when you figure out a better solution to your hard problem it is easier to get the changes everywhere.
As to your comment about “aspects need to know an awful lot about what they’re aspecting, and collaborate fairly closely with the targets.” I say yes and no.
I think you are making the mistake of thinking that the code that says where an aspect applies is part of the aspect. In my opinion, it isn’t. Many (dare I say most) aspects should be able to be written in a general manner. Then the person using the aspect, who has more then a passing familiarity with the code the aspects are being applied to I hope, would write the binding bit.
At the same time, I am sure there will be many very specialized aspects developed (not just six like there is in AO) that need to know a lot about what they are aspecting. And a whole host of others that will be poorly written and proped up by needing more info about the code they are aspecting then should be required.
July 1st, 2004 at 6:34 pm
“And there wasn’t a single LuftHani uniform to be seen.”
That’s what I’ve been saying. Hani just isn’t here. He’s blogging away from Jordan, pretending to be here.
Sold any motorcycles lately on eBay, Hani?
July 1st, 2004 at 6:35 pm
“I went the the TB…”
BTW, I don’t think you were there either. I was dressed as a clown, and nobody, I repeat nobody, punched me.
July 5th, 2004 at 2:14 pm
re: “Aspects need to know an awful lot about what they’re aspecting” - This is absolutely true. The design question is whether you can use aspects to arrange dependencies in a way to reduce coupling and maintenance. If using aspects means you go one place to fix a problem, great. If it means having to fixup all your aspects when you modify the system, terrible. Unsurprisingly, the design principles are straight OO, but the new techniques mean some code that had to be nasty doesn’t any more. Interestingly, the whole community will revisit exactly these issues when figuring out how to use annotations. (I predict many who want to use annotations for more than point deployments might end up wanting pointcuts.) See http://aosd.net/2004/tutorials/goodaop.php for the design issues.