I still think AOP as a concept has been driven into containers, libraries, and frameworks where it can be "managed" (and hidden).
Use of something like AspectJ for ordinary development rather than bottled up and fully hidden by a container, library, or framework seems /exceedingly /rare. Moreover, use of something like AspectJ for general development (as opposed to runtime ad hoc troubleshooting) seems unworkable. Needing something like AJDT is a sign of a problem -- especially when this something exists only for 1 IDE and fails utterly for extremely large projects. [We had one large project that tried to use AspectJ, hit a brick wall of performance, etc, issues, and restarted with custom annotation processors.] In essence for the general programming public AOP has been replaced by more refined/specialized technologies, e.g. dependency injection, various annotation-based magic, etc. In cases these are implemented via AOP or byte-code weaving, but the general programming public does not *see* AOP. That seems a necessary and good thing -- as generalized, unfettered AOP is just too unworkable most especially for Java developers who are used to having explanations for any magic /in the source code/ (not present only when AJDT is used). -- Jess Holle P.S. I still do some custom AOP load-time weaving via ASM for a specialized use case -- but there again AspectJ failed in terms of both weaving performance and quality of resulting byte-code, stack traces, etc. Oliver Gierke wrote: > I just heard the comments of the posse and am quite disappointed. Not > because they seem to dislike it (as it's up to everybody to build > one's own opinion) but rather that the argumentatzion was build on a > good bunch of halfknowledge. Here are my points: > > 1) AOP is a concept. So how can one blame a concept "overkill". This > reminds me of late Pascal an C programmers not grasping object > orientation and claiming that this would be overkill. As already > stated, AOP targets crosscutting concerns that are - and here is the > point - mostly of technical nature not directly related to the > business domain problem you actually have to tackle. So AOP is a mean > to distill problem domain code from the fuzzy technical stuff that > buzzes around in average joe programmer's code. If you just take > exception handling, transaction management, caching and logging/ > tracing code out of your legacy code, how much time would you save on > trying to understand what problem this code *actually* solves. Even > more business related tasks, like notifications and so on can be > effectively solved with AOP means. It simply aims to build more > loosely coupled systems. > > 2) AOP is not widely adopted. Hey guys? Have you used an app server > these days? Almost all app current servers provide technical services > to hosted components by leveraging AOP means. So often times you use > AOP without even noticing it? Which leads me to the next point... > > 3) Accessability: As AOP is a concept, the question of accessability > is more one of the implementation. As you could have found out there > are several ones. Spring container e.g. uses a proxy based approach > that does not bother you with build time constraints or runtime JVM > option requirements. Use the container and you (as already mentioned) > probably use AOP without even knowing. There are a few other weaving > options available (complie time, runtime...). > > 4) Fuzzyness because of indirection. Well... how many levels of > indirection do we already have in the Java language? If this counted > as an argument, we'd have to complain about a lot more things. *I* am > really open to take this burden as it allows modularize my > application, make it more extensible and helps distilling the code i > have to write to solve my business problem from the one I have to > write to plumb that stuff together. > > 5) Annotations replace(?) AOP. I don't know how you got into that but > that was the point that made clear that a little more investigation > would have been good before answering the question. One more time: AOP > is a concept and leverages the notion of pointcuts to define *where* > to apply a specific behaviour. They (in the an example case) can be > formulated onto plain method signatures. That serves point 4, as the > code that gets the advice applied does not know about that fact. > Adressing that problem you typically use annotation *in conjunction* > with AOP to achieve a more declarative style of adding functionality > that is not directly related to the code to the code. @Transactional > or its derivates are the perfect example. So this is not an either/or > but rather a cooperation. > > 6) Tooling. AJDT is really a helper when it comes to make relations > between advices and their targets visible. You can debug stuff > seamlessly, see, where which advice get's applied and so on. Doesn't > the whole Java space already rely on tooling? Wouldn't any newbie > wonder when its method does not get executed because it was overriden > by someone else? Ahh, we have markers in the IDE... we have > @Override... I think you get my point. > > Phew... quite a lot point. I hope you don't get me wrong. It's totally > okay to me for you guys to build opinion different than mine, but you > shouldn't doom something a "tiny magic toy" without deeper knowledge > on it. I guess someone badly informed could argue the same way on > Scala, too: "Whoo... all that scary stuff!" :). > > One thing I entirely agree with you that AOP seems to be a Java > related thing due to the limitations of the language. But I doubt that > things are less obscure and fuzzy when implemented in other languages > means (Groovy meta class stuff and so on=. > > Regards, > Ollie > > On 23 Jul., 05:51, Alan Kent <[email protected]> wrote: > >> Jess Holle wrote: >> >>> So what is AOP good for? It's a powerful tool for building certain >>> types of library/framework capabilities. ... >>> >> Just relating a personal experience, I had read various bits on Aspect >> Oriented Programming (or aspects in general) but they always seemed to >> be vague descriptions - "they are cross cutting concerns". Err, ok, but >> like what does that really mean??? I never "got it". So just in case >> anyone else is in the same camp of not quite getting the point of >> aspects, I thought I would share an example that suddenly made it make >> sense to me. If nothing else, this post might give others the enjoyment >> of saying "gee this guy is just slow to understand isn't he!" ;-) >> >> I came across a concrete example recently in the Alfresco content >> management system. (Not really programming, but it was a concrete >> example that made sense to me.) Expressing in programming terms, in >> Alfresco you can define a class hierarchy for different document types >> (e.g. generic base class that stores an array of bytes representing the >> file contents; a subclass say for Office documents with metadata >> properties common to Word, Excel, and PowerPoint; then a subclass per >> exact file format with additional properties specified to each file type >> and maybe saying how to index the file contents appropriately). >> Inheritance makes complete sense here. Now for aspects. Within an >> Alfresco repository you might want *some* instances of documents also to >> be under version control, or record management control. This is not per >> document type - it "cuts across" different document types. Similarly >> some instances of files maybe under Record Management control (e.g. >> "this file cannot be deleted for 5 years"). So in Alfresco you can add >> an aspect (in this case "records management") on a per instance basis. >> The aspect is not part of the class hierarchy - but it does give the >> instance more properties. >> >> I am not saying this is exactly the same as AspectJ - I have never used >> AspectJ. I just found it helped me understand terms like "cross cutting >> concern" in a much more concrete way. I now at a conceptual level read >> "aspect" sort of like "Java interface", but one that can be added to >> object instances at run time irrespective of what class they belong to. >> >> Well, I hope the above helps at least one other person out there! It >> was a penny dropping moment for myself. >> >> Alan >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
