While annotations have been very well received by the community, I have repeatedly been asked at JavaOne about the possibility of overriding certain annotations later during the cycle (at deployment time).

Here are a few thoughts on this subject.
 
The overriding is specified in an external XML file which could look like this:

<override>
  <annotation-class names="javax.ejb3.TransactionAttribute" />
  <scope>
    <package names="com.foo" />
    <class names="Account" />
    <method names="deposit withdraw" />
  </scope>
  <overridden-values>
    <value name="value"
           old-value="javax.ejb3.TransactionAttributeType.SUPPORTS" />
           new-value="javax.ejb3.TransactionAttributeType.REQUIRED" />
  </overridden-values>
</override>

An override is specified with three parameters:

1. What annotation type is being overridden .
2. Hani pointed out that he didn’t like space-separated names, which I tend to agree with.
3. The syntax should allow for regular expressions, including the possibility to exclude certain patterns.
4. The scope of the override (which Java elements are impacted:  package, class, method, field, etc…).
5. Which values are overridden and what the new values are.

Notice in the file above that “names” is plural, so you can specify several space-separated elements each time.
 
Anything under a scope is “and’ed” together.  In the example above, only methods named “deposit()” and “withdraw()” inside the class com.foo.Account will be candidates for overriding.  We could imagine having several stanzas to specify that an “or” should be used instead.
 
The stanza specifies the new values that need to be applied to the Java elements targetted by the stanza.  The first part must be a valid name of the annotation type (TransactionAttribute.value() in this example).  Optionally, you can specify an old-value in order to further restrict the scope of the overriding.  In the above example, overriding will only apply if the targetted element has a current transaction attribute “SUPPORTS”.  If it doesn’t, the override will not happen.
 
The matching of the values in the XML file to the actual enum type can be performed through reflection, including enums, since it is possible to retrieve a String version of each enum value.
 
The API could probably be very similar to the existing one:

AnnotationOverrider ao = new AnnotationOverrider("override.xml");
Method m = ...;  // retrieve the method
TransactionType oa = ao.getAnnotation(m, TransactionType.class);
// oa.value() now contains the overridden annotation

Here are some open questions/concerns that have come up so far:

• We should be able to override defaults as well.
   
• Should we make it possible to insert annotations and not just override existing ones?
   
• Specifying compound values could be problematic.
   
• Is the syntax too verbose?  For example, Bill Burke is suggesting to insert entire Java snippets to identify the targets:

    <annotation method="public void setEM(javax.ejb.EntityManager)">
    @javax.ejb.Inject
    </annotation>

I personally think that writing Java code in an XML file is a very strong design smell, and it’s a step backward since we are reintroducing redundancy in the programming model (if you rename this method in your Java code, you need to remember to update the fragile string in your deployment descriptor).

Please let us know what you think.