AOP@Work: AOP myths and realities published

Discussions

News: AOP@Work: AOP myths and realities published

  1. AOP@Work: AOP myths and realities published (65 messages)

    At last year's Java in Action conference, I presented a talk to address myths and realities of AOP. That talk has now morphed into the "AOP myths and realities" article published at IBM developerWorks. In this article, I examine the following common myths around AOP and discuss their realities:

    * AOP is good only for tracing and logging
    * AOP doesn't solve any new problems
    * Well-designed interfaces obviate AOP
    * Design patterns obviate AOP
    * Dynamic proxies obviate AOP
    * Application frameworks obviate AOP
    * Annotations obviate AOP
    * Aspects obscure program flow
    * Debugging with aspects is hard
    * Aspects can break as classes evolve
    * Aspects can't be unit tested
    * AOP implementations don't require a new language
    * AOP is just too complex
    * AOP promotes sloppy design
    * AOP adoption is all or nothing
    Like any new and exciting technology, AOP has generated its fair share of buzz, and also its fair share of myths and misunderstandings. After following AOP coverage on the Web and listening to the questions asked at conferences, I started to see some common themes (or myths) that deserve to be cleared up.

    The myths I address in this article are for the most part not malicious: many of them often stem from AOP advocates who are themselves confused about the technology. Nonetheless, these myths make it harder for developers to assess accurately whether or not to adopt AOP. Left alone, they will continue to cause incorrect perceptions and hinder the beneficial use of AOP.

    Of the 15 myths I hope to resolve, two are common enough that even developers with no interest in AOP have probably heard them; a handful deal with various technologies or practices believed to eliminate the need for AOP altogether; and the remainder are systemic, having to do with the incorporation of AOP into the bigger picture of application design and development. Once I've laid these myths gracefully to rest, I'll discuss ways that you can adopt AOP in a pragmatic, risk-managed fashion, so that you can safely try it out in your own system and learn from experience rather than hearsay.
    Have any of these myths prevented you from using AOP? Do you have or have you heard of other myths?

    Threaded Messages (65)

  2. #Myth 9: Debugging with aspects is hard#
    Reading of the article leaves impression that it is not a myth after all:
    debugging is hard or impossible with standard Java debuggers. Only newest Eclipse with AJDT allows debugging.
  3. #Myth 9: Debugging with aspects is hard#Reading of the article leaves impression that it is not a myth after all:debugging is hard or impossible with standard Java debuggers. Only newest Eclipse with AJDT allows debugging.

    Yes, debugging AspectJ is easier with AJDT, but it's not that hard with standard Java debuggers. You end up seeing extra stack frames for advice, but the sourceline mappings are accurate in the bytecodes which enables interoperability with standard debuggers.

    As Ron points out, what language support for AOP allows is for tools like AJDT to understand the structure of your crosscutting concerns, which are present in your system whether or not you are using AOP. Without support for AOP you're managing them by hand. With AOP you have to swallow the adoption curve of the new tools, but the crosscutting structure becomes explicit. For a discussion on the tool adoption issues see Part 2 of my AOP Tools comparison article from the same series:

    http://www-128.ibm.com/developerworks/library/j-aopwork2/
  4. #Myth 9: Debugging with aspects is hard#Reading of the article leaves impression that it is not a myth after all:debugging is hard or impossible with standard Java debuggers. Only newest Eclipse with AJDT allows debugging.

    Depends on the implementation. Spring AOP works with the standard debugger, like Idea.
  5. #Myth 9: Debugging with aspects is hard#Reading of the article leaves impression that it is not a myth after all:debugging is hard or impossible with standard Java debuggers. Only newest Eclipse with AJDT allows debugging.

    If you are using the @AspectJ syntax (and the old AspectWerkz) it is actually a breeze to debug it (in any IDE).

    Try it out.
  6. number of problems[ Go to top ]

    AOP technology is relatively new, immature and rapidly evolving unproven technology.

    Pretty much the only place where there is any significant adoption of AOP is in the J2EE arena. This arena is full of competing frameworks and technology and AOP is nothing more than yet another buzzword there. It is mostly used to work around the limitations of J2EE (e.g. excessive use of containers, inheritance etc.).

    On top of that the advantages of AOP are not clear at all. People attribute a lot of nice things to AOP but don't generally back this up with good case studies that demonstrate the advantages. I'm somewhat familiar with the research in this area. 99% of the articles include some silly toy example instead of a case study.

    In the eighties OO went through a similar phase. It took a long time for people to agree that OO was even a good idea (and still people reject the idea outright, e.g. the C community). Good case studies that make a case for OO are still hard to find (and there are quite a few against it as well!).

    Then there's AOP and aspectj. Aspectj is a proof of concept but frankly it is way too complicated for any widespread adoption. I'm more in favour of attribute oriented programming which is similar to AOP and now part of Java 1.5 (annotations).
  7. number of problems[ Go to top ]

    I'm more in favour of attribute oriented programming which is similar to AOP and now part of Java 1.5 (annotations).
    So, you advocate AOP :) "Complex" pointcut stuff was a workaround for language limitations and probably AOP become just another annotation processing tool.
  8. number of problems[ Go to top ]

    "Complex" pointcut stuff was a workaround for language limitations and probably AOP become just another annotation processing tool.

    I am using AOP primarily with annotations, but there are advantage to the 'pointcut stuff' - it allows you to work with legacy code and classes, and also isn't so intrusive.
  9. I am using AOP primarily with annotations, but there are advantage to the 'pointcut stuff' - it allows you to work with legacy code and classes, and also isn't so intrusive.

    Indeed, nonintrusiveness is an important consideration in using AOP (in legacy code or otherwise). Relationship between AOP and metadata is pretty complex; it took me two full-lenght articles to discuss it:
    Part 1 - Concepts and constructs of metadata-fortified AOP
    Part 2 - Multidimensional interfaces with metadata
  10. number of problems[ Go to top ]

    "Complex" pointcut stuff was a workaround for language limitations and probably AOP become just another annotation processing tool.
    I am using AOP primarily with annotations, but there are advantage to the 'pointcut stuff' - it allows you to work with legacy code and classes, and also isn't so intrusive.
    Agree, pointcuts are usefull for development time aspects, probably package level annotations are better (IMO) for infrastructure aspects, but pointcuts are not so intrusive in this case. Pointcut is very intrusive, if it forces naming conventions.
    Probably it is not so bad in some cases, but "* get*()" is a contract by naming convention example in beans framework (I prefer @Property(name = "myProperty") ).
  11. Annotation Hell...[ Go to top ]

    You can make just as much of a mess littering your code with redundant annotations as with Java calls. Putting annotations on each method where you should handle a policy is just as fragile as adding an API call or two: it's just as difficult to change (and it may actually be harder to refactor!).

    AOP shines here: using a pointcut to pick out all the places where you need to enforce security, handle errors, start and stop transactions, monitor performance, meter usage, or enforce business rules like account suspension is a big win.

    By all reports, the .NET world has seen an explosion of attributes... From what I've seen many of the standard Java annotations are leading to the same problem, with a requirement to add many redundant annotations. Where you do need to mark something with an annotation, it's a lot better to express something as a domain concept or an annotation about object relationships and then derive security, transactions, business events, etc. from those key concepts.
  12. Annotation Hell...[ Go to top ]

    Pattern maching is a good way for development time aspects or for very generic infrastructure related aspects, but contract by naming convention is more a hack than the solution. I have never saw a good contract by naming convention example and
    I prefer annotations for business rules in interface declaration:

    @Check ("$result > 0")
    int getValue();

    vs

    int getValueCheckGratherThanZero();

    (Probably constraint a.k.a business rule declaration is a good candidate for native language aspect too)
  13. Annotation Hell...[ Go to top ]

    @Check ("$result > 0")int getValue();vs
    int getValueCheckGratherThanZero();

    Absolutely. This is what I call "The tyranny of the dominant signature".
  14. Annotation Hell...[ Go to top ]

    but contract by naming convention is more a hack than the solution. I have never saw a good contract by naming convention example and I prefer annotations for business rules in interface declaration
    I agree but...
    JUnit testZZZ is reasonable naming convention IMO.
    Also it looks like most of the RoR is build upon naming conventions and people like it
  15. Annotation Hell...[ Go to top ]

    Yes, there are many reasonable naming convention, but naming convention for "aspect" is a naming convention misuse (it was a workaround for language limitations before annotations in JAVA).
  16. re: number of problems[ Go to top ]

    Can you imagine modern WWW without CSS? AOP to OOP is like CSS to HTML(or any *ML).
    OOP defines structure (business logic) while AOP apply some plumbing characteristics, while different aspects sets can be switched like Stylesheets.
    Immature?.. Maybe but AOP is definately a way to go.
  17. logging and tracing[ Go to top ]

    No AOP is only good for logging and tracing. Its a techy toy that will cause serious trouble and should be banned from any enterprise environment because of the maintainance issues it will undoubtedly create down the line.
    Show a good example where we would really use it
  18. logging and tracing[ Go to top ]

    AOP is not a toy and it is really useful. By some reasons the article seems to separate “proxy” based interceptors and AOP 'pure' :) interceptors. In reality they are just different implementations of the same AOP concept.
    AOP based techniques are very useful for transactional control and other things. EJB annotations and descriptors are nothing else but handicapped AOP in action.
    Hibernate, HiveMind, Spring – they use AOP concepts and implementations pretty successfully. However as every powerful technique it can and will be abused. It is a matter of (self)education to be able to use the tool in appropriate places.
  19. logging and tracing[ Go to top ]

    I use AOP for debugging purposes of third party tools. However I don't think it's a good idea to use it in production, even for logging.
  20. logging and tracing[ Go to top ]

    JBossCache is a good example. We use AOP to implement the following cross-cutting concerns:
    - Locking, depending on whether we use pessimistic or
      optimistic, we use a different interceptor
    - Replication. If the cache is local, the
      ReplicationInterceptor is not present
    - Invalidation. simply replace the ReplicationInterceptor with
      an InvalidationInterceptor (of course all interceptors are
      assembled by the cache at startup time, this does not have
      to be done by the user)
    - Cache loading and cache storing
    - Statistics. If disabled, the interceptor is not present
    - Transactions

    We even open the chain of interceptors up, so devs can insert their own (auditing, security etc).

    The first version of JBossCache did *not* use AOP, and it became hard to maintain code that have to cover all permutations of 'aspects', e.g.
    - transactional asynchronously replicated cache
    - non-transactional local cache
    - non-transactional synchronously replicated cache
    etc etc etc

    We already reaped the benefits of the refactoring: when we added optimistic locking, we simply replaced 1 interceptor.
    JBossCache would today be unmaintainable without AOP.
  21. There are many good examples[ Go to top ]

    I've used AOP for several functions in enterprise systems:

    - performance monitoring (see http://www.ibm.com/developerworks/java/library/j-aopwork10/ for my article that shows how this works in detail)
    - macros & user feedback in a rich client app
    - fine-grained (data-level) authorization
    - error handling (isolating, summarizing, and consistently responding to errors)
    - testing

    In each case, AOP let us write clean code that's noninvasive and separately testable. By contrast, if we had scattered and tangled the implementation of these requirements it would have been virtually impossible to be consistent and correct. I think the AOP solution is far preferable to the code generation, boilerplate templates, and heavyweight, and inflexible frameworks that people traditionally reach for to cope with these kinds of problems.
  22. logging and tracing[ Go to top ]

    No AOP is only good for logging and tracing. Its a techy toy that will cause serious trouble and should be banned from any enterprise environment because of the maintainance issues it will undoubtedly create down the line.Show a good example where we would really use it

    Wrong on all counts. We use it for
       Security
       Profiling
       Caching
       Transactions
       and soon
       Messaging
       Unified exception handling.

    As usual, the only people who seem to berate never actually used it.
  23. logging and tracing[ Go to top ]

    No AOP is only good for logging and tracing. Its a techy toy that will cause serious trouble and should be banned from any enterprise environment because of the maintainance issues it will undoubtedly create down the line.Show a good example where we would really use it
    Wrong on all counts. We use it for Security, Profiling, Caching, Transactions and soon Messaging, Unified exception handling. As usual, the only people who seem to berate never actually used it.
    Oh, I almost forgot, all those items are reused across currently six different projects and NONE affects the business logic.
  24. Reality: check![ Go to top ]

    We have been using AOP as the foundation for our CMS/portal products for three years now. It's working great, we don't even use it for logging and tracing at all, and some of the stuff we do would be impossible without AOP, not because they could not be coded, but because they would be horrendously expensive to write and maintain.

    We use it for asynchronous event handling, undo management (on the client), replication, transactions, security, caching, parameter validation, the entire object model (in a way that would be more or less impossible to do without AOP), versioning of state, automatic persistence, locking, last modified timestamps, business rules, client/server synchronization, and lots lots more.

    In other words, it is not "only good for logging and tracing", it is not a "techy toy", and it should most definitely not be "banned from any enterprise environment".

    There are other things that definitely should be banned from enterprise environments though, such as yacking about things that one knows nothing about. Now, there's something that'll cause all kinds of problems down the line.
  25. Reality: check![ Go to top ]

    We have been using AOP as the foundation for our CMS/portal products for three years now. It's working great, we don't even use it for logging and tracing at all, and some of the stuff we do would be impossible without AOP, not because they could not be coded, but because they would be horrendously expensive to write and maintain.We use it for asynchronous event handling, undo management (on the client), replication, transactions, security, caching, parameter validation, the entire object model (in a way that would be more or less impossible to do without AOP), versioning of state, automatic persistence, locking, last modified timestamps, business rules, client/server synchronization, and lots lots more.In other words, it is not "only good for logging and tracing", it is not a "techy toy", and it should most definitely not be "banned from any enterprise environment". There are other things that definitely should be banned from enterprise environments though, such as yacking about things that one knows nothing about. Now, there's something that'll cause all kinds of problems down the line.

    +1

    I think many people are making many comments about AOP without really understanding it completely. <g>
  26. Reality: check![ Go to top ]

    I think many people are making many comments about AOP without really understanding it completely.

    That is OK and welcome as long as comments are well thought and backed by reasoning.

    Lack of understanding might indicate many things and poor job of communicating technology essentials is among them.
  27. Future containers[ Go to top ]

    I attended a JBoss conference in december and where Marc Fleury said JBoss didn't want of EJB 3. They would have prefered to have 12 aspects standard specs (di, persistance, security, transactions, ...) with a microkernel so you can leverage whatever you need for a given component and you don't have to deal with the complexities of the things you don't need. Plus, this way there isn't any need to separate JEE, JSE, JME anymore. They said they partly suceeded with the adoption of JPA. I found this point fascinating and I would like it to become true in the near future. I think Spring is a good example that the aspects way light container is way better then the standard components heavy weigth container.

    Just think about it, why do we a different security model in the Web tier and Business logic tier. Why special filters in the Web tier? Or like someone said earlier, a service can be made using aspect, after a service is just exposing in a particular way some components functionalities. AOP is the best way to adress infrastructure (ie containers services) needs. I am glad to see it finally gaining some ground.

    By the way, great article that I would keep for future reference when I need to convince some coworkers.
  28. logging and tracing[ Go to top ]

    Show a good example where we would really use it

    Ok here are a few:
    • Container Managed Transactions
    • Security
    • Caching
    • Dependency Injection


    I could go on, but many of things you take for granted in a J2EE server could be (or in the case of JBoss AS are) implemented as aspects. It can also save a ton of effort if you use it properly. As for logging, AOP actually kind of suck for that, tracing is another story
  29. logging and tracing[ Go to top ]

    AOP actually kind of suck for that, tracing is another story
    Yes, it suck for "development" aspects and home made aspect can not replace debuger or profiler. It sucks for things like transaction management and as more aspect is domain specific as more it sucks. But probably there are some good AOP use cases for annotation processing (if annotations do not suck for this use case)
  30. #Myth 12: AOP implementations don't require a new language#
    #Reality: Every AOP implementation uses a new language#
    There is big difference between aspect definition 'language' or I would rather say expressions and necessity to alter Java syntax that AspectJ favors.
    When Aspect definitions are defined as expressions in annotations or external files and Aspect classes themselves use normal Java then all the goodies of IDEs – autocompletion, refactoring, syntax control, etc. can be used. With altered Java syntax for Aspects – only Eclipse ( and IDEA with experimental mode enabled ) can be used to provide those I would say necessities. Or Aspects have to be treated like text.
    So again: it is not myth - AOP does not 'requires' new language, it is rather awkward implementation choice made by AspectJ developers.
  31. When you write code & make references to code in external formats (XML files, strings), it makes it harder for an IDE to handle changes correctly. This issue causes problems in configuration files (e.g., if you rename a factory method, you probably will have to edit Spring configuration files). Ultimately, good support in an IDE requires a language extension, whether for Spring, EJB3, or AspectJ.

    The language extension route actually makes it easier to use aspects once you have experience and use AOP seriously in development. So it's a trade off: it's easier to start with annotations, but it makes for uglier code and worse IDE support ultimately.

    Of course, with AspectJ 5 you can use @AspectJ syntax if you prefer having the aspect language encoded in annotations. But it's still a language, just as are Spring or Hibernate configuration files, or the increasing number of semantic annotations on Java code. We expect our IDE's to understand languages, and increasingly that means plugins that go beyond Java support.
  32. AOP terminology non-intuitive[ Go to top ]

    Let me frame my comment by defining a few terms first, a topiccut is a some section of a topic that I'm addressing. A critpoint is a criticism location attached to some sub point of a context. A lecture is the application of a criticism given a set of critpoints. critpoints may or may not be defined by other critpoints. The use of topiccuts, critpoints, lectures involve what is defined as a 'discussion'. A taxonomy of 'discussion' needs to be defined to determine the applicability of the effectiveness of the use of critpoints, topiccuts and lectures.

    It all makes sense if you really think about it.

    In a later post, I will introduce the required query by example syntax which does not resemble the context syntax.

    I define this as the ContextJ project (ContextN and ContextMono forthcoming)...

    Now that everything has been defined, I'm a little unsure how to define my critpoints and where they may apply. I'm tired, maybe I'll just put my criticism in context directly next time...
  33. And this is new?[ Go to top ]

    Whereas polymorphism, encapsulation, inheritance, virtual inheritance, composition, delegation and contravariance were all simple intuitive concepts? For that matter so are closures, iterators, generators, unification, and monads? Last time I checked computer science and programming requires you to understand some subtle concepts. If you are going to learn new approaches, you need to learn new terminology.
  34. And this is new?[ Go to top ]

    I think you will agree with me that naming is an important aspect (intended) in this industry.

    I'm (almost) also hearing that you agree that the AOP names are not intuitive.

    My argument is simply: if the AOP names would more intuitive or ideally, intuitive, it would help promote this technology.

    What are the hurdles to adopting a new technology? One of them is surely a non-trivial learning curve. For something as mind-blowingly different as a paradigm as AOP, we (you) would hopefully want to reduce the learning curve as much as possible in early stages before it's too late.

    It's already too late in my mind but I figured I'd give my 2 cents anyway.

    Speaking from experience...
    I have tried to promote AspectJ before and I've seen that the terminology and syntax are not intuitive to most people (it didn't take hold). How can we explore its obvious power if it, with its own terminology is fighting us every step of the way? We can, but it takes longer and some of us don't feel it's worth the effort (not me, by the way).
  35. Opposite experience...[ Go to top ]

    I have the opposite experience. AOP terminologies and syntax many feel strange initially (as is the case with any interesting technology). However, in my experience, most developers understand them quite easily.

    I present AOP/AspectJ at many No Fluff Just Stuff and other conferences. I have a pretty uniform experience that most attendees understand the power, concepts, and syntax fairly well. For example, after explaining a few simple pointcuts, I ask attendees to tell me syntax for more complex pointcuts. I am happy to report near 100% correct answers. To me, this is an indication that the syntax is logical and predictable.

    The same experience is repeated with developers at client sites. Developers understand the concepts and syntax very quickly (perhaps because they are motivated by its potential to solve the problems they are facing!). Granted, many don’t understand the full power and implications of using AOP right after the first introduction, but that isn’t unexpected. As the article explains, it does take time to fully fathom AOP, much like any other technology.

    -Ramnivas
  36. And this is new?[ Go to top ]

    My argument is simply: if the AOP names would more intuitive or ideally, intuitive, it would help promote this technology.
    Yes, and get rid of that logging example in favor of something more crucial like:
    - transaction context propagation;
    - call retries;
    - method replacements: hotfixes for proprietary binary packages when source is not available and vendors are too slow to react;
  37. why stuck to tech examples only[ Go to top ]

    Caching, transactions, persistence, logging, exception handling etc. are very good examples. However, it may help the cause to use some higher level business examples ...

    I don't know, just thinking aloud here...how about:

    Audit trails, notifications on interesting conditions or structures (especially if Model Driven approaches are used for building structures and flows at runtime) in workflows, or even, authorisation/authentication, or in general overall monitoring and control of enterprise processes. How about customization and personalized view builders that could build "windows" or views into existing operations or processes that could be created without modifying the workflow itself.

    Other enterprise wide examples could possibly include areas of Disaster Recovery (e.g. distributed agents that could work in concert to monitor processes and estimate or mitigate the effects of an up coming disater situation),

    or even situations where agents could induce additional information into those parts of the process or distributed system which should know about any remote event. In this case aspects would inject or modify logical flow...say in the case of a news occurence causing a slowdown in all trading processes in an exchange.

    Eitherways, what I'm trying to get at is that some BUSINESS LOGIC related higher level examples may help to sell the point. Other than that I really would like to see somebody aligning SOA and AOP.

    Sorry about the longish post ...
  38. why stuck to tech examples only[ Go to top ]

    All good suggestions!

    I have used AOP in pretty much all the scenarios you mention. In all cases, I found that the cost of implementation is reduced significantly. Often, many useful features that would not have been implemented due to sheer implementation complexity associated with them (automatic fail over logic, for example) become suddenly very attractive when implemented using AOP.

    For the client side, I have seen Swing thread safety aspects saved the day for quite a few projects.

    Some specific projects/products for the ideas you mentioned implemented using AOP:
    Audit trail: see: http://nearinfinity.com/products.html
    Monitoring: http://www.glassbox.com/glassbox/Downloads.do (and http://www.ibm.com/developerworks/java/library/j-aopwork10)
    <plug>
    For authentication and authorization implemented using AspectJ, check out chapters from my book (free download): http://manning.com/books/laddad/chapters. Also take a look at table of content for a range of problems solved with AOP.
    </plug>

    The bottom line is a quote from the article: "...the only way to find out whether AOP is a good addition to your development practice is to try it for yourself. I suggest that you set aside one full day to experiment with AOP -- not by reading articles, books, or blogs, but by coding aspects for yourself. Doing that will let you form your own opinion of AOP, which ultimately is what really matters."
  39. And this is new?[ Go to top ]

    My argument is simply: if the AOP names would more intuitive or ideally, intuitive, it would help promote this technology.
    Yes, and get rid of that logging example in favor of something more crucial like:- transaction context propagation;- call retries;- method replacements: hotfixes for proprietary binary packages when source is not available and vendors are too slow to react;

    Absolutely agreed! Especially the method replacement is one of the prime examples where AOP is or should be applied in the professional services/solutions space. Why wait for a vendor to modify a behaviour in the next release if you can do it yourself now?
  40. And this is new?[ Go to top ]

    This kind of replacement can be done much simpler. Just dissasemble old class, rewrite, compile, put on CLASSPATH before original library. AOP is overkill for such case.
  41. And this is new?[ Go to top ]

    This kind of replacement can be done much simpler. Just dissasemble old class, rewrite, compile, put on CLASSPATH before original library. AOP is overkill for such case.

    And that's better? Decompiling and hoping that our classpath ordering is correct?

    Pass.
  42. And this is new?[ Go to top ]

    This kind of replacement can be done much simpler. Just dissasemble old class, rewrite, compile, put on CLASSPATH before original library. AOP is overkill for such case.
    And licences for proprietary stuff usually explicitly prohibit disassembling....
  43. And this is new?[ Go to top ]

    This kind of replacement can be done much simpler. Just dissasemble old class, rewrite, compile, put on CLASSPATH before original library. AOP is overkill for such case.

    And licences for proprietary stuff usually explicitly prohibit disassembling....

    Then the JVM breaks the license ;-)

    (Licenses tend to prohibit or limit "reverse engineering".)

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  44. And this is new?[ Go to top ]

    This kind of "hot fix" is a hack, and it is not any kind of AOP. Byte code transformations can be used to implement AOP tool, but it is implementation technique, there are many valid ways to implement AOP tools.
  45. And this is new?[ Go to top ]

    This kind of replacement can be done much simpler. Just dissasemble old class, rewrite, compile, put on CLASSPATH before original library. AOP is overkill for such case.

    What if there's a custom classloader?

    What if the disassembler isn't perfect?

    What if you want 99% of a class that descends from it, but only want to bypass a single method (since java can't do super.super.methodinvocation...frustration...) although I don't think AOP allows bypasses of this restriction.

    If AOP enables more fine-grained object composition at the method level (something I wish OOP languages would move toward, although that may create overly complicated languages like C++ and templates, which was an initial design goal of Java to avoid, thus the lack of operator overloads).

    In general, Aspects and Attributes are a turning away from Java's original goal of a simplified source code language. Once you get into Attributes, you basically have Domain-Specific Languages to a certain degree, which are enormously fun for the original programmer, but much harder to maintain and read the code.

    In particular, I look a the ludicrous overuse of attributes that has already occurred, and I think Java is already falling apart. Once it's in the language, it can't be removed.
  46. And this is new?[ Go to top ]

    What if there's a custom classloader?
    What if the disassembler isn't perfect?
    What if you want 99% of a class that descends from it, but only want to bypass a single method (since java can't do super.super.methodinvocation...frustration...) although I don't think AOP allows bypasses of this restriction.
    But in such environment you can't apply AOP too. You have to be sure how does it work. Things like Classloader are very basic to controll AOP deployment.
    And super.super.... is very good candidate for method replacement via CLASSPATH.
  47. And this is new?[ Go to top ]

    Things like Classloader are very basic to control AOP deployment.
    Not true. Classes can be weaved statically during build time and then deployed as usual.
    Heck, AOP can be even applied at textual(source code) level, first implementation tried that. But it it seems simpler to manipulate bytecode these days, more flexible. Although more obscure.
  48. And this is new?[ Go to top ]

    Yes, it is simpler to transform bytecode than to parse text, but it is not a problem using open source compiler like JDT these days too. All tools to implement AOP are developed, but it is not very clear how AOP can help to develop applications, stuff like tracing examples are not very realistic (it is just a simple way demonstrate tool or framework). It looks like this technique is more usefull for annotation processing (embedded constraints,queries). Probably it is very hard to count more than 10 generic and usefull aspects for application development and probably all are easy to implement without AOP languages, using annotation processing and proxies or byte code transforamtion to replace field access instructions with method call.
  49. And this is new?[ Go to top ]

    easy to implement without AOP languages, using annotation processing and proxies or byte code transforamtion to replace field access instructions with method call.
    Sorry about OT -could not resist.
    Why?WHy? WHY Do we still have that get/set stupidity?
    Compiler or JVM can easily to replace direct field access with method invocation and invoke existing accessor or mutator if they are present. Code is so much cleaner without get/set.
  50. And this is new?[ Go to top ]

    Yes, "get/set" is a workaround for language limitations.It is trivial to implement stuff like this using byte code transforamtion.

    @Property (read="getter",write="setter")
    public int myField;

    public void setter(int value){

      this.myField = value ;

    }

    public int getter(){

      return this.myField;

    }
  51. And this is new?[ Go to top ]

    Yes, "get/set" is a workaround for language limitations.It is trivial to implement stuff like this using byte code transforamtion.@Property (read="getter",write="setter")

    This is exactly that ObjectPascal (Delphi) has for a decade at least in the language :)

    property aa TypeA; [read methodToReadAA][; write methodToWriteAA;]

    I still miss the feature.
  52. And this is new?[ Go to top ]

    This kind of replacement can be done much simpler. Just dissasemble old class, rewrite, compile, put on CLASSPATH before original library. AOP is overkill for such case.

    Why not? But what about copyright/licensing issue? Do you even have the right to disassemble the class? What if the class if obfuscated?

    Given these points, I don't think AOP is overkill. It's a better way than yours to do that.

    Cheers,

    Dan
  53. And this is new?[ Go to top ]

    I am no AOP guru, but from what I've looked at:


    AOP == server-side event model


    Am I missing anything else?

    As for bad terminology, they ain't close to Sun's terrible names.
  54. AOP == server-side event model

    re server-side:
    AOP isn't just for server-side. It is just as useful in client-side programming (an even real-time programming).

    re event model:
    AOP's advice may superficially look like response to events. However, there are some important differences. First, there is no explicit firing of "events" in AOP. In other words, you won't see invocations such as notifyXYZ(). Second, the context collected by pointcuts (somewhat equivalent to information carried by an "event" object) is a lot more flexible and powerful in AOP. Pointcuts can collect just the right amount of context needed for advice logic. With normal event model, you end up passing "all that you might possibly need".

    -Ramnivas
  55. And this is new?[ Go to top ]

    AOP == server-side event model

    AOP != server-side event model

    Roughly speaking AOP is macroses on steroids.
    Macroses inject code in the place they have mentioned.
    AOP injects code in the places defined by “language structure” ( i.e AOP cannot penetrate body of methods ) by matching structural points against pointcut expressions.

    It is like mass applying a macros by pattern matching.
  56. Services and Aspects[ Go to top ]

    This may not be entirely relevant here and I hope not to start a flame war. However, I've wondered for a while that when we talk about services (in the SOA context) being something that is supposed to be usable across the board, why is it that we often don't align them as Aspects rather than as larger components accessed using a fancy new protocol? The latter is a view that is simply an extension of remoted interfaces (maybe like in Corba or RMI), but the componentization of services (or vice-versa) only reduces the SOA to yet another incarnation of the component oriented architecture which in turn in essence is an extension of the OO approach.

    If services in principle are supposed to address business requirements anywhere in the enterprise where a functionality is required to be used in a context, then why not address them as aspects ... which _are_ supposed to do that anyways. I hope we are not being biased by the current implementations of AOP in java or otherwise, and regarding Aspect Oriented approaches as a "programming tool or toy" as someone mentioned earlier.

    I believe that any and all (biz or tech) justifications for a "service" (which by definition addresses cross-cutting concerns) should apply to AOP as well.

    Again, I hope not to offend structured programming gurus stuck in a (non-structured) OO world. AOP is more functional in nature than structure oriented ... which is what services were meant to be (I hope), but landed up being otherwise.

    I guess
  57. I actually just started using it[ Go to top ]

    We have a fairly large object model, used by (right now) two very distinct applications. Due to certain realities, one project needs to listen to certain properties and the other project doesn't. I used AspectJ (AJDT in Eclipse) to instrument the model with the proper interfaces, defined the proper pointcut, and it's working beautifully.

    Took ~ 1 day to get used to the 'new' terms. Took another to get used to the syntax. Now the property change stuff is used only by the app which needs it, with absolutely zero impact on the other app.
  58. AOP adoption[ Go to top ]

    I have experimented with AOP in web containers and found it very useful but it took me lot of time and effort to look up information related to AOP use in JSP, servlets,EJB etc.

    I think more AOP and J2EE information has to be available. So to me enterprise environments mean integration of AOP with JSF,JSP,EJB.Portals etc. and related configuration and deployment. Most books only explain isolation of concerns like transactions.
  59. Lately there was a presentation about AOP at our local JUG. Everbody was interested in that stuff and wanted to play with. Many have seen presentations of AOP before.

    In the discussion after the presentation somebody asked what would be a true killer application for AOP. Nobody had any idea, but everybody agreed that logging, transactions, measuring execution time, etc. are no true killer applications.

    IMHO AOP needs a true killer application like the Internet for Java.

    I see that things have changed meanwhile. 5 years ago you only asked what would be a killer use of AOP and people would get furious at you and tell you that you had no forward thinking and were ignorant. Now people admit that they can't think of one.
  60. What's a true killer app for AOP?[ Go to top ]

    In the discussion after the presentation somebody asked what would be a true killer application for AOP. Nobody had any idea, but everybody agreed that logging, transactions, measuring execution time, etc. are no true killer applications.

    I don't think that new approaches to programming work like that. Object-Oriented development took decades to become truly mainstream. There was no 'killer application', and for some time OOP was considered primarily appropriate for GUI development (just like AOP is often considered just for logging, transactions etc.). Ideas take time to spread.
  61. I think the part about AOP that has not been well-documented, is how it can be used to make project management easier, and to allow progress to proceed on a project without necessarily having to have all the information at that point. Ramnivas refers to this as the "Architect's Dilemma." If we can simply layer in those architectural concerns later in the project cycle, without disrupting code that has already been coded and tested, this could be a huge win for using an AOP-based methodology.

    For AOSD to "cross the chasm," the focus must be on how to manage it, so that the decision makers can see how it can help make project management easier, and help produce better software faster, which I believe it can, if managed properly. However, at this time, experience in managing it is lacking. We need more 'Aspect-Oriented Programming for Managers' types of books and lectures.
  62. I think the part about AOP that has not been well-documented, is how it can be used to make project management easier, and to allow progress to proceed on a project without necessarily having to have all the information at that point. Ramnivas refers to this as the "Architect's Dilemma." If we can simply layer in those architectural concerns later in the project cycle, without disrupting code that has already been coded and tested, this could be a huge win for using an AOP-based methodology.For AOSD to "cross the chasm," the focus must be on how to manage it, so that the decision makers can see how it can help make project management easier, and help produce better software faster, which I believe it can, if managed properly. However, at this time, experience in managing it is lacking. We need more 'Aspect-Oriented Programming for Managers' types of books and lectures.

    Good post. I think a lot of people agree that technically AOP is excellent but how to manage it and how much you gain from using it in a normal applications haven't been demonstrated or documented yet. But infrastructure products like Spring or JBoss allow us to use it transparently and I think it is the first step in the massive adoption of AOP since you can test it without needing big efforts from your development team.
  63. Myth 1 not refuted[ Go to top ]

    I was wondering if anyone knew any links on the net that gave a detailed example (i.e. with pseudo code or code details) of a cross cutting business concern that for which aspect oriented programming provides an arguably good solution.
  64. Myth 1 not refuted[ Go to top ]

    I was wondering if anyone knew any links on the net that gave a detailed example (i.e. with pseudo code or code details) of a cross cutting business concern that for which aspect oriented programming provides an arguably good solution.
    Transactions and Security in Spring for 1 and JBoss is totally built using AOP. I think those kind be called "success".
  65. Myth 1 not refuted[ Go to top ]

    Replace *kind* with *can*. I would REALLY like to be able to edit my posts on TSS....
  66. I have code & slides discussing two business aspects: metering and account suspension. You can read more at http://www.newaspects.com/enterpriseAOP.ppt