I'm in live mode so ignore typos and apparent lapses in consistency.
The Participants:
- James Gosling, Sun
- Cedric Beust, BEA
- Graham Hamilton, Sun
- Gregor Kiczales, University of British Columbia
- Simon Phipps, Sun, Moderator
SP - gives intros, claims ignorance and neutrality.
GK - gives overview of AOP, pretty fitting since he invented it at Park Place. Suggests that our intuitive feel for programming constructs can change over time. In this context, applications that are written using OO have clumsy mechanisms. They have good design modularity but bad code modularity. e.g. Observer Pattern in drawing programs. Enter AOP in 1997. Solves the code modularity problem. Crosscutting concern code is concentrated in Aspects that can be maintained in one place. Some design patterns are best expressed as Aspects (I'm paraphrasing) There are good and bad uses. We don't know what works great as an aspect vs what makes a terrible aspect. Hype is a big problem. Bad pedagogy. Tools need to get better. Traning. And what is the business value? Java is the #1 platform for AOP. How do we keep it there? It may not belong in 1.6. But how do wi get in there eventually.
GH - AOP is like jump/goto. Style of AOPs: when it is used to Passive monitoring is non-intrusive and a good use of AOP. AOP used by the container. The container using AOP concepts to do things like wrapping EJB calls and adding hooks. Scarier use of AOP is to use AOP to modify behavior as a maintenance method. Extreme AOP e.g. a = b * foo(); AOP would allow you to add an aspect to change the return type and behavior of foo(). Bad for understanding code. We ran to Java because we were running away from C++. C++ had lots of power, if used properly, but you have to live with what others, who may be less skilled, do. What are the right rules for safe AOP?
CB- He claims to be a conflicted AOP advocate. Likes the example that GK brought up contrasting code and design modularity issues. If you get together with some programmers to develop something and you go down a path but realize that you need to add security so you add those functions and then several months down the road you realize you need to add security to more of the code and then you realize that something like AOP might be able to help here. He is conflicted because AOP is hard. Maybe because of the technology or tools. Probably because it is built on top of Java. It seems like assembler sometimes. If AOP is as good as we think why has it not gained wide acceptance. He's hoping to get more from the community.
JG - Enthusiastic about AOP but like CB he's conflicted. Imagine a table with two axes along one nouns along the other verbs, the horizontal axis is like OO and the vertical is like procedural. Now slice it diagonally and you get new abstractions. Code complexity increases as systems evolve. AOP feels like it could solve this. Define the nouns (objects) define the verbs (procedures) and things will work out. (paraphrasing) People have given examples like security but when you peel those back and go down a level when security is added to all layers where code runs differently in different environments you have to respond to security violations in different ways. So you end up with specialized response patterns so you may get to where you don't know where the aspects come in and you won't know how to respond. Which brings complexity back into the code. He can't count the number of ways he implemented the observer pattern. You can do it globally like in AOP but sometimes you need to optimize in cases where you need selective redrawing or selective evaluation. AOP may not take the complexity away. It may be more a matter of organization.
SP - how many people heard of AOP. Lots raise hands. How many are using? A lot fewer. Maybe nothing can succeed in IT until it has failed twice.
JG - We haven't arrived at the AOP sweet spot yet. There are a few more PhD theses here. He wants it to work.
GH - AOP is like a handgun and people can shoot themselves in the foot.
JG - Jfluid profiler uses AOP type model. Lovely use of the methodology.
GK - Transparency means you write something that will work everywhere. AOP is not around transparency. You can't write a single AOP persistence aspect. It has to be highly focused.
JG - yeah but you end up with lots of points at which you need to do updates. and you need to know more about where each code point is modified
GK - no, he claims you can show that in refactoring you can show how this works. If the centrally called mechanism is involved...(He's lost me.)..... many cases do not have the problem JG has brought up.
JG - he'd love to see the code for that because he thinks the
CB - You can't judge a tech by its age. Also important is the timing. AOP may be getting close to the sweet spot. we may be reaching it because a lot of people know about it and there are a lot of people experimenting. that makes AOP unique. Plethora of frameworks is a sign of immaturity. which could be confusion. misuse of vocabulary, etc. this may cause a decline in AOP.
SP - AOP is all done in Java. How can Java remain this way?
JG - (he has to run) This is parallel to templates and generics. A few months before java was release Bill Joy and he almost came to blows over the question of templates. Joy said if it didn't have templates and polymorphism then Java was useless. So JG said which framework for doing these things? Bills answer was whatever was done in Beta or don't ship anything. So they shipped anyway. And it caused an academic food fight but it converged on something beautiful. The food fight over AOP is still here. There is still food in the air. It hasn't gone splat. It needs more people using it. See how it feels and be vocal. The non-useful feedback will be "this is great". Useful feedback will be of the form "this sucks, because..." He feels that soon well think this was right.
GH - do you think we are there with generics
JG - we're as close as we have ever been. ( he had to run to another appointment)
Cool session. I'm not blogging the Q&A....
0 Comments:
Post a Comment
<< Home