In reply to a comment by Aviad Ben Dov on Arjen’s post on interoperability versus annotations, I originally wanted to reply on Arjen’s blog, but thought it would be better to post a reply on my own blog, since it was going to be rather lengthy comment.

Aviad is specifically asking Arjen’s opinion on frameworks like Tapestry and X2J. I guess he’s asking for the use of annotations in both frameworks and not about the frameworks in general.

Annotations in my opinion are designed to add metadata to Java artifacts (objects, methods, et cetera), One should however think hard about the consequences of using certain annotations because (as Arjen meant in his original post), you might loose agility when overusing annotations for specific purposes.

Example 1: versioning

Say I have a class Contact (directly taken from the X2J website) and I’m using @Element, @Attribute and @PrimaryKey annotations to realise Java to XML mapping and the other way around. The class (at first sight) can perfectly be serialized to a client by using X2J in combination with a web service). Everything works perfectly well, until the requirements for the web service change (with a new version of the schema as a result). Changing the annotation and the schema would of course work perfectly well, unless the old version of the web service interface still needs to be supported (a common requirement). Remember, we’ve changed the mapping at class-level.

If I don’t want to deploy the new version alongside the old version (two WAR files, whatever), I’m kind of screwed.

If we would have been able to somehow externalize the configuration of the mapping, we might also have been able to choose between a mapping, based on an incoming web service request containing a version of the service being called.


@Element
public class Contact {
@Attribute
@PrimaryKey
String getName() {..}

@InnerElement
@ArrayElement(label=false)
Contact[] getFriendOf() {..}
}


Example 2: location versus definition

If for example I have a class that needs a service to performs its job. Using dependency injection, we can transparently provide the class with its helper. Using Spring we would do this using XML, with other technologies frameworks you can do it using annotations (see the example below).

Whereas with Spring you’re completely decoupling both the location of the service as well as the definition of the service (both contained by the XML file) in the annotation scenario you’ve only decoupled the definition of the service (provided elsewhere in some other configuration), but not the location (it’s still hardcode in the class). This makes it difficult for example to reuse the class outside the environment its intended to live in and where it knows the ‘MyService’ reference is available. Furthermore there’s no way to configure the class twice (with different location parameters) as the annotation is defined at class-level.


public class Helper {

@Resource(name="MyService")
private Service service;
}


** Update
Have a look at Uri’s blog. He’s showing a perfectly valid @Required annotation in my opinion that doesn’t change anything to the behavior of the class and doesn’t impose any difficulties when using this class outside its natural habitat ;-).