Annotations/Attributes: How do they help us?
On Thursday morning at the Cortina Software Architecture Workshop, Erik Dörnenburg held a session entitled Annotations/Attributes: How do they help us? Since I’ve written about these types of class metadata before, I was very interested in this session. Especially since every JSR that comes out of the JCP nowadays seems to add an annotation or two.
Configuration
One of the questions we covered during this talk was whether it is OK to use class metadata for configuration, as for instance a Spring bean definition file is used today. The obvious downside to this approach is that the class requires a recompilation for a configuration change. Because a class may undergo many configuration changes as it goes through its life-cycle from developer environment through testing environment to the live environment, you may need to recompile it quite often!
Martin Fowler pointed out that it is quite alright to use the metadata for configuration defaults, as long as you can override it using some other configuration mechanism. I agree with him on that one. However, it might be a bit unclear how a class is configured exactly in a particular environment: is the class metadata used or the XML configuration file?
Entity Mapping
Another usage of metadata we covered was that of Entity Mappings. Using EJB 3, or Hibernate with Annotations or XDoclet, one can define the entity mapping using metadata. I imagine .NET ORM frameworks like NHibernate have similar functionality.
The question that arises from this is: Is a entity with metadata still a POJO? The consensus in the session was that that it isn’t, since it is tied to a specific framework. This is especially true in .NET, with its strict reference resolving mechanism1.
Domain Specific Language
The final usage was suggested by Mats Helander. He suggested using class metadata for class intent, as a Domain-Specific Language of some sorts. If I remember correctly, the idea was to define one’s own metadata, and to map that metadata to the frameworks you use. The advantage over the previous approach is obvious: you are not tying yourself to a particular framework anymore, you are expressing the semantics of your classes, and map that to the frameworks you use. Obviously, the metadata could also be used for other purposes, such as DSL tools.
I find this way of using metadata really interesting, and I’m looking forward to trying it out in a project some time.
Update 2006-02-14: Erik is going to speak about Domain Annotations at the Software Practice Advancement Conference this March. Looks interesting!
1 - In .NET, if you use a attributed class, you must also add a reference to the assembly containing the attributes, otherwise you get a compilation error. In Java, with looser reference resolving, this does not appear to be the case: the class is simply not annotated if it cannot find the annotations at runtime.
Steve Loughran said,
February 9, 2006 @ 23:28
Given that I work on a deployment/configuration product, SmartFrog (http://smartfrog.org/), you’d expect me to be biased against annotations in code. And I am, if done badly.
-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
Bruce said,
February 10, 2006 @ 1:53
When you said (right at the end) “In Java, with looser reference resolving, this does not appear to be the case: the class is simply not annotated if it cannot find the annotations at runtime.”
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.
Arjen Poutsma said,
February 10, 2006 @ 11:55
Bruce,
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.
A Couple of Dutch Rants » So when SHOULD you use annotations? said,
February 20, 2006 @ 20:02
[…] [1] Uri Boness in Dude, where’s my class? [2] Arjen Poutsma in Annotations/Attributes: How do they help us? [3] Rod Johnson in Ecsaping the Technology Cycle [4] Arjen Poutsma in Annotations vs. Interoperability [5] myself in Re: Annotations vs. Interoperability [6] Uri Boness in Verifying configuration in Spring […]
Aleks Seovic said,
February 24, 2006 @ 6:47
Hi Arjen,
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