Cedric has written an interesting post on AOP and annotations.
I think things are going to get a little hairy here.
The main problem is that we can start chasing out tail:
xml -> annotations -> aop to put in the annotations -> xml to define how aop puts in the annotations -> repeat
I think there is going to be some art when it comes to knowing WHEN to use annotations.
I don’t think that it makes sense to annotate on major cross cutting concerns. The obvious example is having to put @loggable on every method ;)
I guess annotations will allow you to tag some cross cutting concerns when they don’t fit the pattern. E.g. setterDogsAreNice(). There could be an annotation that lets the system know that this is NOT a property. However things get dicy.
We are all going to go hog-wild with the new shiny toy that is annotations. It is human nature :) Over time we will work out the subset of items that should use this style, and the areas in which you shouldn’t. Having code with a ratio of 100:1 annotations:code is going to happen, and it doesn’t seem to readable to me.
So I think there will be SOME marriage between AOP and annotations, and it will be interesting to find the balance. I mean, some annotations can be considered a cross-cutting concern ;)
*runs off after his tail*
May 14th, 2004 at 2:46 pm
Absolutely agreed. We need to find a balance.
Slapping @Inject all over the code when we mean a setter seems insane and pointless. We’ve had JavaBeans for many years – we all know what a setter is, we only need to mark things that look like setters but are not.
If we need to add metadata to code, sure annotations are the way. I just think we should consider very carefully when annotations are really required in code. Lets only force their introduction into source code when they are really required.
Note that the presence of annotations at runtime is quite different to how littered with annotations your source code can be. We’re all agreeing with annotations in the bytecode for containers to use – I’m just arguing for some restraint on annoation hell – even the hello-world EJB 3.0 example looks way too annotation polluted for me.
May 14th, 2004 at 3:15 pm
I still think the type-safe way annotations are being introduced is flawed for a lot of cases. It would be nice to have an additional facility for just generic annotated metadata which isn’t typed or linked to a particular annotation interface. Sometimes you just want some data about a class that’s outside the class itself.
For instance, the EJB annotations are only going to be usable in an environment with the j2ee.jar… It would be nice to just be able to introspect for some of this data without needing to be tied to the particular implementation. What if, instead, the definition of @Service was dependent on what implementation was available (or what code made use of the fact that @Service was tagged on a class). This would be a lot more powerful and dynamic, IMHO.
May 14th, 2004 at 3:44 pm
But why pollute your POJO and its type system by adding a setter that you will never invoke?
Now multiply this by the number of injections that you want and you won’t even recognize your object any more because it will have all these useless methods.
May 15th, 2004 at 2:19 am
Cedric – thats the whole point of constructor based dependency injection! Don’t bother with pointless @Inject annotations or useless setters. Just write a constructor!