Posted by kgh on March 08, 2006 at 11:50 AM | Comments (18)
When people ask me "what do you think of AOP?", I tend
to flinch, because the term AOP has come to be used to cover a
very wide range of different uses, some of which I think are
Totally Wonderful and some of which I think are Thoroughly Bad
Ideas. Here's a brief survey of the range and of my reactions.
Quick Overview of AOP
The core concept of Aspect Oriented Programming is that there are
common issues that apply across a range of otherwise unrelated
classes. In AOP, these common issues are often referred to as "cross
cutting" concerns because they cut across the normal inheritance
class structure. The goal of AOP is to allow cross cutting concerns
to be addressed by applying some common logic (or "aspects")
to a set of classes, without having to individually modify the source
code for each class.
The idea of wrapping extra functionality around target classes will
be very familiar to Java EE developers. Java EE containers typically
add extra functionality and semantics to target classes by intercepting
incoming calls to target objects. For example, an EJB container can add
transactional semantics to a target class.
(Yes, J2EE has been using AOP all along!)
Java Language Principles
The Java language has been designed and evolved with certain
specific underlying principles in mind.
We have put great emphasis on source code readability. As far as
possible we have tried to follow the principle that "what you
get is what you see". We have worked to maintain a clear and
consistent base semantic model and to avoid language constructs that
might undermine source code readability.
People should be able to quickly read Java source code and then
reliably understand what that Java source code does. That meaning
should be independent of the particular compilers, tools, or runtime
environments that are used.
Now, we aren't ivory tower philosophers. We want a Java language
that is productive for writing
and maintaining large applications. So there will always be a trade-off
between principles and pragmatics. However, in looking at the success
and popularity of the Java language, much of it
does seem to derive from these core principles. They seem
to have worked well and to be worth maintaining and protecting.
The Good: Container Based AOP
One use of AOP is based on running objects within containers.
These objects can only be accessed via their container. The container
can intercept incoming calls and add additional semantics. An example
of this approach is the way that Java EE containers can add
transactional semantics to EJB components by intercepting incoming
calls.
In general this use of AOP seems fairly benign. The source code
within the target objects is all behaving exactly as a developer
should expect. Developers do need to be aware that they are accessing
the objects indirectly and that the container may perform extra
tasks. However the idea of operating through a level of indirection
is a fairly normal Java concept.
Now, within this general use case, there are probably a range of
good and bad uses. Uses of container intervention such as
adding transactional semantics in EJB, or adding logging,
or adding extra security checks seem very reasonable.
The Bad: Modifying Language Semantics
Some uses of AOP rely on using runtime mechanisms to modify
semantics that are specified by the Java Language Specification
(JLS). For example, side files might specify that various
modifications are to be made to target classes to invoke additional
code when various operations are performed. Some uses of AOP allow
extra code to be invoked when fields are accessed or when methods are
called.
The JLS carefully specifies the precise semantics of the Java
language. For example, it precisely specifies the behavior that
occurs when fields are accessed and it precisely specifies the rules
by which one method may call another, including the cases when the
call may proceed through other code as well as the cases when it must
proceed directly from caller to callee.
Developers should be able to rely on these semantics when they are
reading source code.
To take an extreme example, if a developer has written a statement
"a = b;" then they should be able to
rely on the value of the field "b" being
assigned to the field "a",
with no side effects. Some AOP toolkits allow arbitrary extra
code to be executed when this statement runs, so that there can be
arbitrary extra side effects as part of this assignment or even so
that an arbitrary different value may be assigned
to "a". Yikes!
Similarly, some uses of AOP permit extra code to be inserted on a
method call from one method to another, even when the JLS clearly
specifies that that method call will occur directly. This enables
arbitrary extra code to be executed, with potentially arbitrary side
effects, in situations where a Java developer should expect there
will be no side effects.
This is the kind of arbitrary intervention that I think quickly
races across the boundary line to insanity. (And I think most
serious AOP proponents would agree.) I don't want the fundamental
behavior of a chunk of source code being changed by someone magically
reaching in and changing the code's meaning from the outside. That
seems like a really bad idea!
The core problem with these approaches is that if someone relies on
techniques like these in writing their code, then other developers
will no longer be able to understand that source code, because it
has been developed to rely on side effects that are both at odds with
the Java language definition and which are magically applied from
somewhere outside the source file. You should not need to have global
knowledge of a whole environment in order to understand some local
fragments of code.
Overall, using AOP to modify the meaning of the Java language
seems like a really bad way to go.
The New: Java Language Annotations
In J2SE 5.0, the concept of annotations was added to the
Java language. In many ways, annotations were designed to meet
similar goals to AOP. The concept of annotations is that developers
may apply special markers to target method, fields, or classes in
order to designate that they should be processed specially by tools
and/or runtime libraries.
Now, annotations are not allowed to modify the behavior defined
in the Java Language Specification. Within a source file that contains
annotations, at runtime all the source code must execute exactly as
defined by the JLS. That was a deliberate choice - we don't want
annotations to become a way of defining arbitrary magic behavior within
normal Java code. However, the annotations may cause changes to the
overall behavior of the program, for example by directing a container
to apply special behavior when forwarding calls into a target class.
For me, one big benefit of annotations over classic AOP
is that annotations
are clearly visible in source code. So if you are reading an
application you can clearly see which specific annotations are
affecting the code. That readability advantage normally
seems to outweigh the AOP advantage of being able to apply new
semantics silently without modifying the affected class.
My sense is that many use cases that were initially considered for
use with AOP can now be better solved by the use of annotations.
That is part of what is happening with the extensive use of
annotations in
Java EE 5.
Conclusion
The use of container based AOP seems to provide a reasonable
mechanism for supporting AOP "cross cutting concerns" within
Java environments, without breaking developers' expectations of
how Java source code behaves. Similarly, Java language annotations
appear to provide a convenient mechanism for supporting some of
the use cases originally targeted by AOP.
However, I think AOP quickly drifts from good to evil when it
starts being used to mutate the meaning of source code or to
otherwise modify what people can and should expect from Java
source code.
So, yes, I am a fan of AOP. But of a sane, restrained AOP!
Comments are listed in date ascending order (oldest first) | Post Comment
The gist of this criticism is to completely ignore the mechanisms and value of AOP, to imply that AOP is unnecessary and that the same old failed approaches are sufficient to handle the problem of scattered and tangled logic. AOP arose out of the need to let programmers have control over these, and not to have a rigid, predefined "container" implementation. Scattering redundant annotations all over the place is far from an improvement over scattering code, especially for bugbears like consistently handling errors, ensuring consistent security policy for access to instances even fields, metering service usage, or managing feature variations in a configurable product line.
AOP gives developers power and it can be misused, just as with OOP. However, AOP finally allows an effective solution, with contained, understandable semantics with integrated tools support (e.g., the AspectJ support in Eclipse). In practice projects not using it end up trying horrid things like code generation from XML. Indeed, the emerging popularity of dynamic languages like Ruby that support arbitrary metaprogramming shows the extent that the Java community is looking for help. I think real AOP is a balanced, effective way to finally solve the problems that containers and annotations cannot. And my experience using it for enterprise projects and with the Glassbox Inspector java.net project have been real successes.
Posted by: rjbodkin on March 08, 2006 at 02:04 PM
"We want a Java language that is productive for writing and maintaining large applications. "
J2EE containers themselves must have been very easy to write and maintain. Common concerns are well taken care of there by Mr. Hamilton's colleagues.
"even when the JLS clearly specifies that that method call will occur directly"
Method A will call method B as defined by JLS. It is just that before you write them together, now you are just writing them at different places called "aspects". And you will be so happy if you do that.
Please pardon Mr. Hamilton for never really bothering looking at AspectJ himself.
Posted by: charlesz on March 08, 2006 at 03:09 PM
"This enables arbitrary extra code to be executed, with potentially arbitrary side effects, in situations where a Java developer should expect there will be no side effects."
The use of loaded terms like "arbitrary" go a long way toward making this scenario sound scary. In reality, good tool support (such as in the AspectJ development toolkit plugin to eclipse) gives an AOP developer the information he or she needs to detect when an aspect specifies additional behavior at a given location. This tool support is just as critical to AOP as OO tooling is to OOP--it makes programming in a paradigm easier to understand and manage. With good tools in hand, developers need not fear aspects, any more than they fear the "arbitrary" code executed by dynamic method dispatch.
"The JLS carefully specifies the precise semantics of the Java language. "
Sure, that's fine. But I have yet to meet a developer who keeps the JLS on her desk and frets about what exactly it says (or does not say) about what can happen at a given point in source code. And does the JLS govern vendor-specific extensions to XML configuration files? No.
When I call a method on my object and it lives in a container, "the container can intercept incoming calls and add additional semantics." With AOP, an aspect specifies additional behavior with the same effects. Either way, the upshot is the same: additional behavior attaches to my method. In the trenches, no one cares about the JLS. They care about the readability and understandability of their code from a commonsense perspective. From a commonsense perspective, and with the right tools, the two approaches are equivalent, except that the container is a lot more heavyweight and a lot less flexible.
Posted by: ndlesiecki on March 08, 2006 at 03:32 PM
Allow me to join the AOP crowd in response to this "Histoire de la Folie"...
I'm glad that you as a language person at Sun are thinking carefully about AOP. The example of advising field-set really does pose the challenge.
I like the emphasis on readability, i.e., on making it easier for the developer to understand the code. I believe the designers of AspectJ shared that concern as paramount. I like this, too: "You should not need to have global knowledge of a whole environment in order to understand some local fragments of code." But is that the whole picture?
If the user is only concerned with the method being invoked, then either container-managed interception or advice can seem weird. But what happens when you want the same thing to happen lots of times - classically, for the display to update? OO says to put in API calls everywhere and hope you get them all right, initially and whenever maintaining your code. AOP says to put them in one piece of readable source code. I personally find that easier, because I find it easier to rely on a pointcut to specify when the code should run rather than scattering the code in various methods (though pointcuts are no panacea when it comes to refactoring and maintenance). However, I can see where others might prefer the code scattered, and modern refactoring makes that a lot easier. Indeed, scattering not a sign of a bad design -- it could be said to be state of the art. OO pattern recipes typically involve interactions (and edits) between lots of classes. When looking at a given class, it can be hard to tell that it is playing a particular role in a pattern. OO by design does not capture such interaction protocols (hence the need for a pattern language), but AOP can, in some cases.
So, what about the converse?: you should not have to read all the source code to get a global view of one concern. I do agree that to move back and forth between the method/class level and the global/crosscutting level requires new IDE support (some support of some kind is required to go to the system level, even without AOP). AspectJ's support in Eclipse (AJDT) shows gutter markers on code when it is advised. You click on the marker to go to the aspect to see what it does. For debugging, thanks to Java's great support for languages like JSP, you can step through the source for a method and an AspectJ aspect without worrying about where the code is. To get a view of the entire system, AJDT has a crosscutting view, where you can see all the code affected by all the aspects, and you can drill down into any one of them. With this support, developers can work at the system level or the local level, and it is easy to go from one to the other. It's a bit like taking a helicopter rather than a car when you have a lot of ground to cover.
I wonder what you think about the other part of AOP: inter-type declarations? Being able to declare methods and fields in an aspect on other types - including interfaces - has made it much easier to modularize the implementation of patterns. For example, you can add bean support to a class just by declaring that it implements an interface declared by the aspect. Many of the core classes in a system are core precisely because they participate in many patterns (hence "pattern density" is a mark of good design). Using aspects is a way to specify pattern implementation separately instead of intermingling the essentially distinct aspects of a composite object. It's a matter of style for the developer as to whether the composite declaration is in the class (by virtue of implementing interfaces) or in an aspect. (On the question of style, it's fair to say there are bad ways to use AOP as there are bad ways to use OO; so the fair thing to do is to compare examples of good style.) However, since Java does not have multiple inheritance or default interface implementations, I would expect some objections on these grounds.
Is advising field-set a violation of language semantics? That sounds very unsafe. It certainly violates a programmers' expectations if they aren't aware that their code is being advised, but AspectJ could be (and has been) implemented as a pre-processor producing pure-Java code. There are no bytecode tricks, and, as far as I understand, the underlying JDT compiler does everything a Java compiler should.
But still, what happens when you want the assignment to just set the darn field? With AspectJ you can specify that something shouldn't happen -- e.g., that advice shouldn't run on a given set of join points -- but all the aspects have to cooperate. I'm hoping AspectJ and AOP evolve better ways to articulate concerns like "I want this code to work like it alone says" or "Advise this code if you want (doing extra things), but don't change any state." (But that's me; very few AspectJ users demand such features.)
(That's another question: does Java 5's VM-level support for bytecode weavers enable signed and sealed jars from being affected by potentially malicious weavers? I assume you can grant security privileges to trusted weavers.)
More on the safety side, AspectJ is different from all the other AOP implementations (and container-based interceptors) in one respect that aligns it even closer with the Java language: it supports compile-time, type-safe restricted views of the context available, so developers know exactly what's being affected and only need to deal with the context of interest. Ordinary Java proxies open up the entire context reflectively using Object, so once you permit proxying, there are no guarantees you won't get runtime exceptions or code modifying the objects in the wrong way. (Here's where I'd like Java to support the C++ const keyword!) (And it should go without saying that an important property of the AspectJ language is that any woven class is binary-compatible with the unwoven class.)
In any case, I agree that there should be a high bar for AOP features to get into the Java language: when they are usable and understood by most Java developers. If annotations are what make sense to developers, it's fairly easy to convert a lot of AspectJ programs to using annotations (indeed, in AspectJ you can declare annotations on another type in an aspect, so you can avoid the scattering problem there, too). Or, if Java adopted AOP with method-related and class-related join points but not field-set or handler, that wouldn't be a bad thing, either. The important thing is to listen to users who vote with their feet -- to critique but not discourage innovation, as I believe you've done. Thank you!
Posted by: wisberg on March 08, 2006 at 08:39 PM
J2EE containers have been using AOP in disguise. You need to know what a container does to understand what is happening to your objects at runtime. You need to understand what the EJB specification mandates and hope the J2EE vendors are complying with the spec. As exactly you need to understand what an Apect in aspectj can do. The difference is that is easier to look to an aspect and understand what it does, than reading so many pages of specification.
Now with aspectj and its great support to annotations many programming tasks are becoming easy to develop and evolve. In a recent project I have used aspectj to develop GUI applications, i made extensive use of the annotations support with aspectj. The code was clear easy to change and explore different ideas and prototype things quickly.
AOP can be abused.. yes it can be as any thing else can, I have come across so many horrible code, which were difficult to understand and extend.
On other note, the example you mentioned about assignment a=b is interesting one because I have used and still using it lately in an interesting way 'for me at least, and my colleagues at work', now I can track what is referencing an object in a generic way without to much code and it is applicable for any Plain Old Java Object.
I want to finish this by saying, in my opinion, AOP is a step forward for OOP. And with annotations support, working with aspectj is very exciting.
Posted by: iyad on March 08, 2006 at 09:50 PM
Graham I'm on your side. AOP is the worst kind of black magic.
Posted by: parmenion0 on March 09, 2006 at 02:45 AM
I'm not sure what "high bar" for AOP means. I think the point of them is that they empower a programmer via simplicity, so if enabling or coding them takes a lot of effort, it just kind of ruins the point of them.
I liked the idea of aspects originally, but seeing how disparately the community enables them, or how different the philosophies are, I think this is an area still under development/research, and I'll come back when it's stabilized. For Java then, I still prefer POOOP (plain ole object oriented programming, hehe).
That said, for scripting projects, you'll find @ signs all over my Python code, I shamefully only discovered the language a couple nights ago. I'm curious to see how messy it gets in my experimentation and if a set of best practices emerges that I can then infuse my Java code with.
Is there a Java.net page dedicated to AOP?
Posted by: ilazarte on March 09, 2006 at 04:23 AM
The central theme of the blog seems to be based on a notion that any language that runs on the Java platform must follow the JLS and it is okay for a J2EE container, but not for aspects, to affect program semantics. Further it seems to conveniently define AOP as the interception mechanism.
AOP's first problem is that it really isn't deserving of consideration as a programming orientation. After all this time it's usage seems to be limited to logging and similar tasks that while necessary, aren't the core of what we would consider a feature. Kicksales in his 04 java one talk gave the example of property change event notification. Is that all you've got? There should be some basic requirements for getting into the "OP" crowd. Can a program be written entirely with aspects? Are AOP proponents saying that it's advantageous to do so? (no and no). In all cases AOP decorates or enhances OOP, and therefore isn't a new programming orientation.
Posted by: tcowan on March 09, 2006 at 06:25 AM
The author has given a nice description of how not to use AOP tools such as AspectJ. A similar article could have been written describing how not to use Java, in fact numerous “anti-pattern" books have already been published in this vein. For this we could thank him: there are always those who subscribe to the "golden hammer" school of early adoption, giving a new technology a bad name and alarming potential users. However, unlike the author of this article those books do not attempt to use examples of bad practice as a way of detracting from the technology as a whole. But he does not stop there. What is more disturbing is the rather sensationalized description of the worst affects of bad AOP. But if someone is indeed injecting "arbitrary extra code", making code difficult to understand or requiring developers to have "global knowledge" then they are not practicing AOP. What they are doing is indeed a "really bad idea". Unfortunately the author of this article is confusing the reader with a description of the inappropriate exploitation of an open byte-code format and standard APIs like JVMTI that many freely available, non-AOP tools can also use.
Perhaps the most misleading aspect of this article, though, is the assertion that with the advent of Java annotations somehow AOP in unnecessary. This either suggests a complete misunderstanding of AOP or is an attempt to add confusion to the fear expressed earlier. As the author is at pains to describe annotations do not "modify the behavior defined in the Java Language Specification", but instead only describe intent of the program or invite extension and enhancement. In this way they actually complement the mechanisms that AOP implementations like AspectJ already use, such as type and pattern-based matching, by allowing the programmer to have a contract with the provider of the services they require. But the tools that the author advocates which process these annotations may "cause changes to the overall behavior of the program", perhaps by injecting the same arbitrary code as that evil AOP!
So my advice to you: steer clear of annotations; you will be inviting the devil to your door.
Posted by: bigcheeese on March 09, 2006 at 07:24 AM
Just to add something in support of what Graham is saying: AOP often is most useful and sensible in a specialized domain or as part of a known programming model, when a protocol of various responsibilities are well understood. That's because it doesn't also have to educate the programmer; it's in service of known expectations. That's what, I think, makes dependency injection with Spring something that Graham might like: it's a container-like limited form of helping the programmer avoid a bucket of boilerplate code. Of course, AspectJ is under the hood there.
The madness thing could apply to any language. Nothing in the English language prevents you from speaking syntactically correct and even semantically meaningful things that are plain crazy -- who would want to say such a thing? The purveyors of AOP (or AspectJ at least) have never held themselves out as specifying what "such a thing" is; logging, caching, security, (avoiding pattern density), etc. are all examples to show people the kinds of things *you* can do, designed primarily to show off the language. It makes as little sense to denigrate AOP for logging as to dismiss J2EE because of the Pet Store application. Users have reimplemented OO patterns in AOP and shown for some categories of patterns (those with multiple superimposed roles), AOP makes the code more modular according to generally-accepted measures of complexity. If that's not significant, what would be for an adjunct to OO? (And do annotations help at all with the complexity caused by pattern density?) JBoss was more aggressive in offering solutions, and Spring is another nice example. Java didn't become popular because of the language; it became popular because of applets and AWT and Swing and servlets and all the other API's and the VM that make it useful across multiple platforms. The language made that a whole lot easier, no small feat.
AspectJ has no such library aspects (yet) -- largely because that kind of effort doesn't happen without some financial support. But with AspectJ 5 out, that's a reasonable direction, so it's a good time for the community to step up to publish useful aspects!
Posted by: wisberg on March 09, 2006 at 01:14 PM
I agree with you on the whole. I'm a big fan of "container-based" AOP myself. AOP framework users need limitations; I personally think intercepting fields, private methods, etc., goes too far.
A couple comments though:
First, you can just as easily apply your "what you get is what you see" argument to interfaces and inheritance. I can see that my code depends on a certain interface, but many times (especially in J2EE applications), looking at an isolated code sample, I don't know what the exact implementation will be without knowledge of the bigger picture.
Second, you've focused solely on interception. Introduction, the other half of what many consider to be AOP, is just as important. I favor a mixin-like approach and would love to see the Java language extended to support it. Right now developers have two choices: inheritance and delegation/composition. They either abuse inheritance or write a lot of boilerplate delegation logic (without realizing there could be a better way!). Mixins can provide the best of both worlds.
Third, annotations: the JLS says annotations themselves don't affect the behavior of the resulting code, but to my knowledge it doesn't say anything about tools that may input annotations. Also, annotations do *not* solve the same problems as AOP. They can be used to simplify pointcuts, but you still need a tool to generate and weave in the logic. You can use a code generator like apt, but I greatly prefer cleaner, more direct approaches.
Posted by: crazybob on March 09, 2006 at 03:02 PM
I'm late into this, and much has been said already, including that using words like 'arbitrary' is more of a rhetorical tool than a technical argument. But let me try to add to some of the discussion, starting with your comment that:
Some uses of AOP rely on using runtime mechanisms to modify semantics that are specified by the Java Language Specification (JLS).
Well no. That's like saying some uses of OOP rely on using runtime mechanisms to modify semantics that are specified by the ANSI C specification. It's a meta-level shift error.
What's true is that AOP languages like AspectJ have carefully specified semantics that extend those of Java. That shouldn't be surprising - certainly no one expects that Java or C# or any other language to be the final word on programming.
But people who use these languages, i.e. AspectJ, are not modifying Java semantics, nor are they modifying the semantics of existing Java programs. They are writing new programs, that like other new programs have their own behavior. The semantics of their programs are clear and well-defined.
I think the problem you are really getting at is different. It's the problem of not knowing exactly what will happen when a given line of code executes. That's a problem -- but its not due to AOP. When I see a bit of Java Code like:
o.foo(x, y)
There's remarkably little I know for sure. Assuming the code compiles, I know that whatever class o is, it has a method named foo. But I don't know which method will run, unless I go look elsewhere to figure out the class of o, and then go look somewhere else to find out that foo is final and so on.[1] So even though I used to love printing out code and reading it, the bottom line is I would never try to reason about the execution of a big Java program without an IDE that could help me figure out things like exactly what happens when a method call runs.
In short, the fact that we don't know exactly what a given line of code does is an inherent part of modern programming languages -- its called abstraction. We don't want every line of code to say everything it does, otherwise we would drown in complexity.
What languages provide is mechanisms that enable us to define useful, clear, composable abstractions. Procedures give us that. Objects with inheritance and polymorphism give us another form of that. AOP gives us yet another form of that.
In each case the hurdle the new mechanism has to clear is to show that the abstractions it enables are intuitive, clear, useful and critically that the code written using the abstraction is easier to understand than the code written without it.
So now let's turn to another point in your message:
We have worked to maintain a clear and consistent base semantic model and to avoid language constructs that might undermine source code readability."
Needless to say the people who have developed AOP languages believe all this too. As I've said above, it's a basic goal of designing programming language abstraction mechanisms. So the real question then is are the many real examples that AOP proponents have put forth more clear in their AOP implementation than in the plain-old object implementation: Is a particular synchronization policy coded as an aspect more clear than spread around? A particular access control enforcement mechanism? Error checking...
The details of each case matter, but at this point some general points have been shown quite clearly. For example, Mira Mezini and I have shown that even for very small examples, there are cases where the AOP code is easier to understand and reason about than the non-AOP code. (Google "AOP and Modular Reasoning" to see that argument in detail.)
----
[1] I know I didn't say that precisely, its just too cumbersome to say precisely what I do and don't know, in terms of static types and dynamic types and overloading and overriding. The above is good enough for this message I think.
Posted by: gregorkiczales on March 09, 2006 at 05:26 PM
It's good to raise the debate about the role of AOP on the Java platform. It's a shame that some of the technical discussion got wrapped in sensationalism. In the interests of space, I've written a response on my own blog: Graham Hamilton on AOP.
-- Adrian Colyer.
Posted by: aspectprogrammer on March 10, 2006 at 02:50 AM
Thanks everyone for the comments.
I should have been clearer on one point:
My two main scenarios were intended to highlight the range,
from what I see as clearly good to what I see as clearly bad,
not to cover all the different uses. The current use of "AOP"
covers such a wide range of uses that I think it is difficult
to have a single binary opinion that all are good or all are bad.
With the container example I was looking for a scenario which
I hoped could be seen as obviously desirable. I hope that almost
everyone can accept using "AOP" in such scenarios!
With the example of modifying the meaning of normal Java source code,
I was using an example which I hoped most programmers would regard
as clearly undesirable. Well, I gather there are a variety of
opinions on this issue, but I'm afraid I'm still unconvinced.
I would like source code to do what it says it does and not to
have to worry that in a given environment it may be modified to
do something else. Different languages have different styles,
but the Java language has tried to have clear rules that reduce
ambiguity and uncertainty in reading source code. I think it
is good to preserve that property.
regards - Graham
Posted by: kgh on March 12, 2006 at 04:01 PM
After spending about 2 years on a custom project for a major software and hardware vendor using AspectJ 1.x I agree with some of Grahams points though I think he coudl have been somewhat clearer in distinguishing the differences between the good and bad.
One of the few problem with AOP (pre-dating annotations/attributes) was that point cuts where defined outside of the component/class and relied heavily on an actual understanding of the internal workings which meant the aspects where subject to constant change (and breakage) as the internal implementation of the components changed during the development. What contributed to this was that the component developer was not the aspect developer and there was no clear and enforceable contract between their works except for some elaborate expressions trying desparately to filter out the incorrect injection (extension/interception) points. I believe that this is one of the cases where AOP simply does have scalability and maintainability. The 'ilities' are heavily dependent on the underlying component implementation (think fields, code blocks, and methods) and thus the maintainability of the AOP solution is greatly impacted by the quality of the implementation where code blocks need to be replaced with methods to support weaving.
Now one might be lead to believe that this is not AOP's problem but it is to some degree because of its point cut expressions which (tend to) reference implementation details and not contracts (Interfaces and Annotations). A component that emits events to registered event listeners could be poorly implemented but this would not typically have any bearing on the quality of the listener registration (pointcut) or event processing code (aspect) external to the component. If you do not believe me then have a look at the code of some of the popular web containers, testing and persistence frameworks which emit events to listeners, filters and interceptors. I am glad that contracts have been defined which emit events - I would not like define pointcut expressions that (attempt) to intercept state changes or request processing stages.
Annotations provide some relief to this problem because now the component developer makes the contract (or extension/injection/interception...) points much clearer. The component developer now thinks in terms of component enhancement via containers whether they be enterprise containers or lightweight containers for smaller application development and delivery.
William
Posted by: williamlouth on March 14, 2006 at 12:10 AM
Correction:
I believe that this is one of the cases where AOP simply does have scalability and maintainability
Should be:
I believe that this is one of the cases where AOP simply does NOT have the scalability and maintainability
Posted by: williamlouth on March 14, 2006 at 12:12 AM
Hi!
I'm writing a report about Java - past, current and future trends. But I can't find so much information about Dolphin. Do you have any sources about new features and such stuff for that version?
//Mike, mjn03010 -at- student.mdh.se
del.icio.us 
Digg 
DZone 
Furl 
Reddit
java.net RSS Feeds
