> Sun/Java starts providing a preprocessor api
Something in addition to the instrumentation API, or replacing it?

The SPI concept is interesting, and would certainly offer a much cleaner way of making the annotation system pluggable, i.e. integrating it with “standard” Java annotation reflection.

sorry, but I didn’t get the point. You just started to provide a shortcut for the tedious task of writing annotation triples (see your motivation example) and you end up with a composite-wrapper that contains literaly exactly that three annotations requiring to type even more characters for the wrapping-stuff? “Yes, you can” save typing effort in cases were you only want to use defaults for the members of a composite…but in any other case using the composition scheme is no better than using the original source annotations. You might argue that in cases I want to change all occurences of a certain scheme than I just have to change the composite. Yes, true, but then I would argue that it’s probably never going to happen if you work with a set of stable annotations. And even if there’s change then I would rather favour a text-processing tool. What you really wanted to do was to provide a c-style preprocessor, but disgiused it in some strange annotation scheme. I guess ant is capable of doing preprocessing stuff…
As I am “The sceptic” I have been waiting ever since annotations arrived for the first projects doing funny stuff with it: Now here’s another example. When is “jakarta commons annotations” going to arrive, which is the (meta) annotation wrapper (like this wrapper for logging frameworks…). And I like the Meta-Annotations of webbeans or what was the name of the next big thing. What I wanted to say with this rant is that you should concider using the right tool for a task, in oyur case a (macro) preprocessor…

My suggstions:
1.) Sun/Java starts providing a preprocessor api (I don’t get the point why anybody refuses to concider a preprocessor, but any other funny stuff is discussed in epic breadth and blind enthusiasm, for instance making java functional…)

2.) The Java framework itself should provide a plugable SPI-API for resolving annotations. Annotations should be allowed to have any number of arguments. A Resolver-SPI-Plugin (SPI function) could analyze the source annotations and provide an interpretation/tranformation into a target set. We would require

2.1 Declaration
@AnnotationBlaBla
@AnnotationSPI(id=FunnyMapper)
public @interface FunnyInterpretedAnnotation {
String useCaseID;
AnnotaionParamList nameValueVarargs;
}

2.2 How to use the Annotation
@FunnyInterpretedAnnotation(UseCaseID=”Bond”)
Agent ofYourMajesty;

2.3 The SPI trafo function
function: SPI( @FunnyInterpretedAnnotation(UseCaseID=”Bond”) ) -> { @NotNull, @CodeNumber(“007″), @Clearance(“Clarence”) }

2.4 SPI function configuration
And then we need some sort of configuration, mapping UseCaseIDs into sets of target annotations…well let’s use xml for that. Oh, wait a minute! annotations were invented partially to overcome xml-hell. Well, seems to be a silly suggeestion then…

But it is definitely an avenue worth pursuing, and certainly a possibility with regard to trying to integrate composite annotations with existing code.

Also, running eclipse:eclipse or eclipse:m2eclipse against the project will leave you with a

<classpathentry kind="src" path="src/test/java/com/qrmedia/pattern/compositeannotation/validation/sample" output="target/test-classes/com/qrmedia/pattern/compositeannotation/validation/sample" excluding="**/*.java"/>

entry in your .classpath. This is a (seemingly unavoidable) result of the way the test resources are configured in the POM – again, required for the validation processor tests – and needs to be removed.
Or right-click on the source folder in Eclipse and select Build Path -> Remove from Build Path.