AOP
From APIDesign
(→Annotations + AOP) |
(→Harmony) |
||
(13 intermediate revisions not shown.) | |||
Line 1: | Line 1: | ||
- | [[wikipedia::Aspect-oriented_programming|Aspect Oriented Programming]] can be analyzed from various angles. Official explanation is available at [[wikipedia::Aspect-oriented_programming|wikipedia]]. This page offers my own thoughts. | + | [[wikipedia::Aspect-oriented_programming|Aspect Oriented Programming]] can be analyzed from various angles. Official explanation is available at [[wikipedia::Aspect-oriented_programming|wikipedia]]. This page offers my own thoughts. Read them or [[Media:Aop.mp3|download]] or listen to our podcast: [[Image:Aop.mp3]] |
== [[Bytecode]] patching == | == [[Bytecode]] patching == | ||
- | There used to be a time when people went nuts on hearing the phrase ''[[bytecode]] manipulation''. That's no longer the case. People aren't afraid to execute [[bytecode]] different to that produced by the [[Java]] compiler anymore. However, if you tell them to go directly into the .class file and manipulate the bits, the fear returns. Why is that? I believe this is due to [[AOP]]. [[AOP]] | + | There used to be a time when people went nuts on hearing the phrase ''[[bytecode]] manipulation''. That's no longer the case. People aren't afraid to execute [[bytecode]] different to that produced by the [[Java]] compiler anymore. However, if you tell them to go directly into the .class file and manipulate the bits, the fear returns. Why is that? I believe this is due to [[AOP]]. [[AOP]] makes [[bytecode]] changes normal, without requiring understanding of the class file format. In fact, [[AOP]] can be seen as a high level language for [[bytecode]] manipulation. It is not as powerful as making changes to the .class file directly, yet it is approachable to the masses and generally understandable. This perfectly illustrates the principle that good abstractions make everything more usable. The principle is true in the world of [[bytecode]] manipulation as well as in that of [[API]] design. |
== Hard too use == | == Hard too use == | ||
Line 11: | Line 11: | ||
== [[Annotations]] == | == [[Annotations]] == | ||
- | What can be simpler? Of course, [[annotation]]s (they are solution for everything, as this is [[TheYearOfAnnotations2009]]). If I want to apply the asynchronous aspect to my class, I shall be able to write just: | + | What can be simpler? Of course, [[annotation]]s (they are solution for everything these days, as this is [[TheYearOfAnnotations2009]]). If I want to apply the asynchronous aspect to my class, I shall be able to write just: |
<source lang="java"> | <source lang="java"> | ||
Line 21: | Line 21: | ||
</source> | </source> | ||
- | and the [[annotation]] shall do the rest. Why is this simpler? First of all everything remains in one place, one does not need to switch to .aspect file and use different language. Code completion works for [[annotation]]s. [[Annotation]]s can have parameters. Probably (with the help of [[AnnotationProcessor]]s) one does not need any special compiler. Using [[JavaC]] is enough. In short, this is the [[cluelessness|clueless]] solution end users want. | + | and the [[annotation]] shall do the rest. Why is this simpler? First of all everything remains in one place, one does not need to switch to .aspect file and use different language. Code completion works for [[annotation]]s. [[Annotation]]s can have parameters. Probably (with the help of [[AnnotationProcessor]]s) one does not need any special compiler. Using [[JavaC]] is enough. In short, this is the [[cluelessness|clueless]] solution end users want. Actually this is also solution taken by some projects ([[Lombok]] comes to my mind). |
- | + | This is fine enough for end users, however try to write your own [[annotation]]! Hard, quite hard. You do not need to directly manipulate with [[bytecode]], but you need to manipulate with abstract syntax trees used by compiler. That is not much simpler and definitely not [[cluelessness|clueless]]. | |
== Harmony == | == Harmony == | ||
- | Of course, there is much more people using these [[annotation]]s than writing their own. Still writing own shall be simplified. How? Via [[AOP]]! If there was an easy way to connect [[annotation]] with an aspect (for example .aspect file), one could get benefits of both worlds - end users would have all the comfort of [annotation]]s and providers could use higher level language to define what an annotation is supposed to mean. | + | Of course, there is much more people using these [[annotation]]s than writing their own. Still writing own shall be simplified. How? Via [[AOP]]! If there was an easy way to connect [[annotation]] with an aspect (for example .aspect file), one could get benefits of both worlds - end users would have all the comfort of [[annotation]]s and providers could use higher level language to define what an annotation is supposed to mean. This is well balanced path that maximizes [[cluelessness]] of all parties. As such it fully deserves [[Good Technology]] name. This is the style majority of us will code in short future. Old [[AOP]] is dead, long live [[annotation]] based [[AOP]]! |
- | + | I have seen a demonstration of [http://www.postsharp.net PostSharp] for .Net recently. It provides this kind of perfect harmony between users (via [[annotation]]s) and aspect developers. When I saw it I was amazed. This is how [[AOP]] shall look like! Does anyone knows if there actually is some framework in [[Java]] that works this way? | |
<comments/> | <comments/> | ||
+ | |||
+ | == [[AspectJ]] == | ||
+ | |||
+ | There is a pretty good explanation by ''btilford'' in the [[Talk:AOP|comments section]] showing that [[AspectJ]] can be used to define an [[annotation]] and provide an aspect that processes methods annotated by such [[annotation]]. So the only thing I am missing is integration with [[AnnotationProcessor]]s - e.g. just by running compiler, also process these [[annotation]]s. This does not seem to be possible now, but as [[Talk:AOP|Nicolas Dumoulin explains]] with [[maven]] it is very easy to setup a project to use aspects. Thus we are back where we started: [[Java]] is again ahead of any other competition. |
Current revision
Aspect Oriented Programming can be analyzed from various angles. Official explanation is available at wikipedia. This page offers my own thoughts. Read them or download or listen to our podcast:Contents |
Bytecode patching
There used to be a time when people went nuts on hearing the phrase bytecode manipulation. That's no longer the case. People aren't afraid to execute bytecode different to that produced by the Java compiler anymore. However, if you tell them to go directly into the .class file and manipulate the bits, the fear returns. Why is that? I believe this is due to AOP. AOP makes bytecode changes normal, without requiring understanding of the class file format. In fact, AOP can be seen as a high level language for bytecode manipulation. It is not as powerful as making changes to the .class file directly, yet it is approachable to the masses and generally understandable. This perfectly illustrates the principle that good abstractions make everything more usable. The principle is true in the world of bytecode manipulation as well as in that of API design.
Hard too use
If direct manipulation of bytecode is like writing something in assembly language, then AOP is like programming in C. Quite easier, but still not supporting cluelessness enough. It is fine I can write an aspect with pointcut that executes all methods in my classes asynchronously, however to do that I need to understand a lot. I need to know how to declare a pointcut, how to describe what exactly it shall match and also how my aspect gets merged into the affected object. Quite a lot of knowledge. There has to be something simpler, if this kind of programming shall be used by masses!
Annotations
What can be simpler? Of course, annotations (they are solution for everything these days, as this is TheYearOfAnnotations2009). If I want to apply the asynchronous aspect to my class, I shall be able to write just:
@Asynchronous class MyClass { public void oneMethod() { ... } public void sndMethod() { ... } }
and the annotation shall do the rest. Why is this simpler? First of all everything remains in one place, one does not need to switch to .aspect file and use different language. Code completion works for annotations. Annotations can have parameters. Probably (with the help of AnnotationProcessors) one does not need any special compiler. Using JavaC is enough. In short, this is the clueless solution end users want. Actually this is also solution taken by some projects (Lombok comes to my mind).
This is fine enough for end users, however try to write your own annotation! Hard, quite hard. You do not need to directly manipulate with bytecode, but you need to manipulate with abstract syntax trees used by compiler. That is not much simpler and definitely not clueless.
Harmony
Of course, there is much more people using these annotations than writing their own. Still writing own shall be simplified. How? Via AOP! If there was an easy way to connect annotation with an aspect (for example .aspect file), one could get benefits of both worlds - end users would have all the comfort of annotations and providers could use higher level language to define what an annotation is supposed to mean. This is well balanced path that maximizes cluelessness of all parties. As such it fully deserves Good Technology name. This is the style majority of us will code in short future. Old AOP is dead, long live annotation based AOP!
I have seen a demonstration of PostSharp for .Net recently. It provides this kind of perfect harmony between users (via annotations) and aspect developers. When I saw it I was amazed. This is how AOP shall look like! Does anyone knows if there actually is some framework in Java that works this way?
<comments/>
AspectJ
There is a pretty good explanation by btilford in the comments section showing that AspectJ can be used to define an annotation and provide an aspect that processes methods annotated by such annotation. So the only thing I am missing is integration with AnnotationProcessors - e.g. just by running compiler, also process these annotations. This does not seem to be possible now, but as Nicolas Dumoulin explains with maven it is very easy to setup a project to use aspects. Thus we are back where we started: Java is again ahead of any other competition.