Comments on: Cedric says no to AOP and annotations http://almaer.com/blog/cedric-says-no-to-aop-and-annotations blogging about life, the universe, and everything tech Tue, 03 Jan 2012 22:08:49 -0800 http://wordpress.org/?v=2.8.4 hourly 1 By: James Strachan http://almaer.com/blog/cedric-says-no-to-aop-and-annotations/comment-page-1#comment-2463 James Strachan Sat, 15 May 2004 09:19:22 +0000 http://almaer.com/blog2/cedric-says-no-to-aop-and-annotations#comment-2463 Cedric - thats the whole point of constructor based dependency injection! Don't bother with pointless @Inject annotations or useless setters. Just write a constructor! Cedric – thats the whole point of constructor based dependency injection! Don’t bother with pointless @Inject annotations or useless setters. Just write a constructor!

]]> By: Cedric http://almaer.com/blog/cedric-says-no-to-aop-and-annotations/comment-page-1#comment-2462 Cedric Fri, 14 May 2004 22:44:38 +0000 http://almaer.com/blog2/cedric-says-no-to-aop-and-annotations#comment-2462 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. 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.

]]> By: Jason Carreira http://almaer.com/blog/cedric-says-no-to-aop-and-annotations/comment-page-1#comment-2461 Jason Carreira Fri, 14 May 2004 22:15:45 +0000 http://almaer.com/blog2/cedric-says-no-to-aop-and-annotations#comment-2461 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. 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.

]]> By: James Strachan http://almaer.com/blog/cedric-says-no-to-aop-and-annotations/comment-page-1#comment-2460 James Strachan Fri, 14 May 2004 21:46:42 +0000 http://almaer.com/blog2/cedric-says-no-to-aop-and-annotations#comment-2460 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. 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.

]]>