I think you guys didn’t cover one use of annotations that is in my opinion probably the best — as a joinpoint that aspect pointcuts can be defined against.

I really believe that annotations/attributes are the best pointcut targets. When used that way, they both document the members they are on and allow very easy application of aspects that doesn’t depend on the naming conventions. @Transactional and @Cached are great examples — they really don’t do anything by themselves other than document the method they are on, but they provide a very simple way to define a pointcut for transaction and cache aspects.

I wish I was at Cortina, seems like there were some good discussions there this year. Well, there is always next year, hopefully Jimmy will give me bit more advance notice than this year

Actually, I did a little experiment which shows that - even with a Runtime retention policy - annotated classes do not need their annotations present at runtime. This was a bug in JDK 1.5 (present in at least 1.5.0-02), but it was fixed recently (1.5.0-06 or an earlier release).

To do the same experiment, just create an annotation, a class with is annotation with it (let’s call it A), and a class which uses A (let’s call that B). If you run B when the annotation is on the classpath, A.class.getAnnotations() shows the annotation. When the annotation is not on the classpath, the annotation is simply not there: no NoClassDefFoundError.

If the classloader can’t find the class definition (*.class) for a RetentionPolicy.RUNTIME annotation, you will get a NoClassDefFoundError when loading the annotated class. For the other retention policies, the annotation is not visible at runtime.

-in an ideal world, all configuration information is under SCM, all deployment and configuraton is automated.

-in a complex project, different people own different parts of the config, the DBA, the sysadmin, the router administrator. They dont code. But they can sometimes be persuaded to write their own config files and keep them under SCM.

-where annotations in source is good is when the source provides lots of the information itself, like class and method names, types, etc. Why repeat this information (possibly incorrectly) in a config file?

-but the stuff in the code, it should only be a hint. I may defined the table and column names in my EJB annotations, but the DBA has the right to override them.

-what is wrong is having to edit the source or rebuild a WAR/EAR file just to deploy on a different target. Because someone always ends up deploying the wrong one