Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

lachoy (1663)

lachoy
  chris.winters@gmail.com
http://www.cwinters.com/

I am actually Chris Winters; I am actually living in Pittsburgh, Pennsylvania, USA; I am actually married and have three cats. (Guess what one of them is named?) I am the "OpenInteract" guy, which could be good or bad.

Journal of lachoy (1663)

Tuesday July 05, 2005
11:48 AM

Something I don't get about annotations...

[ #25526 ]

I'm just now doing some development under Java 5, a year after it was released. Some of the features like generics + the modified for loop are pretty useful at making code less verbose, something java has always needed. (The angle brackets seem ugly now, but I suspect I'll get used to them like all new syntax.)

Annotations are touted as reducing much of the configuration complexity that seems to follow java apps around, usually in XML files. So instead of a rule declared in some XML file somewhere on your classpath specified in some factory you can instead annotate your class and methods with what was in the XML file But it seems that you're not able to replicate the dynamic runtime nature of that XML file. And that nature is a big part of why you use external configuration!

For instance, one of the examples authors use when describing annotations is security (see JavaWorld article). The example is useful for illustrating what you can do with annotations because everyone understands security. But it seems misleading because in the real world you'll want to load your security roles and policies from somewhere else (database, LDAP server, etc.), and it doesn't appear that you can apply data loaded at runtime to annotations. The alternative is to define in your app general roles ("admin") and then apply your specific roles loaded at runtime to the general roles from the anntations. But then you've added another layer of abstraction and have the potential for dissonance between the two -- what if the annotation role is not granular enough for later application stages?

To fix that you can just go into the source, modify the annotation and recompile, right? Easy enough, but that seems like a big problem when you're trying to create distributable components. Transactions, another often-used annotation example, have a similar problem -- I'd thought one of the benefits of EJB and Spring declarative transactions is that most code doesn't have to know about transactions, you can apply them after the fact. But with annotations we seem to be reversing this trend.

Don't get me wrong, I think annotations are very useful. But they seem more useful in making the development/build process easier -- like generating deployment descriptors, or gluing tests to your application -- than in making runtime deployment simpler.

(I mention seems throughout because I've only read a few articles/docs about annotations, and I could be completely wrong...)

Posted from cwinters.com; read original

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.