Metadata Public Review Gets Some Feedback

from http://www.theserverside.com/news/thread.tss?thread_id=22334

The much awaited JSR 175: Metadata for Java released a public review draft last week. This was the first time that many people had seen the fruit of the expert groups labor. It didn't take too long for some thoughts to come in. Ted Neward, an expert group member, has replied to some of the thoughts, giving some reasoning behind the decisions that were made.

Disclaimer: Ted's crazy ideas are solely his own, and do not necessarily represent the expert group

Ara Abrahamian, or XDoclet fame, placed his 2 cents.

His first concern is "Why annotation types are interfaces and not regular classes?"

"Why annotation types are interfaces and not regular classes?! .Net Annotations types are normal classes. Normal classes are better for annotation types because, you know, you can put code in a real class, but in an interface you just define stuff! Being interface-based leads to some limitations: for example if you want to define a Factor annotation type and the value should be a float value in 0.0 to 1.0 range you just can't do that, you can't write a piece of code to check that the annotation declared by user is valid. I think annotations are a declarative way of defining metadata, right? So the annotation should also be checked/validated where it's declared in the code, not during runtime when a piece of code finally uses it!"

Ted responds by letting us know the restrictions in .NET, and then discussing the fact that "an annotation should not, should never, in fact, influence the outcome of a compilation or execution unless it is explicitly retrieved and tested via a runtime/Reflective API."

His reason? "Using attributes as markers for use by AOP and MOP tools is fine; expecting annotations to provide code themselves is a dangerous game we didn't want to get into. (And lest anybody in blogland think that we don't understand the power of such languages/tools, please remember that Gregor Kiczales, Mr. AspectJ himself, was a member of this JSR and was the first to enforce the idea that we were building an attribute/annotation system, not an MOP or AOP system.)"

Ara then asks why there is no support for attribute subclassing. Ted reasons that using composition for this task makes sense, and not have polymorphic attributes is just fine. An example of this composition in the XDoclet world is:

@EjbFinder(signature="java.util.List findBla()", @WebLogicFinderQuery("select blabla weblogic specific"))

Finally, Ara asks,

"And finally I'm not sure the spec is friendly to compile time tools such as XDoclet or UML diagram tools. Generating stub like classes for Annotation is not a beautiful solution."

Ted wants to make sure that the distinction between XDoclet and JSR 175 is clear: "we are not about creating code-generation tools with this spec, and XDoclet is first and foremost a code-generation tool. JSR 175 is purely about metadata, nothing more."

I didn't see any response to Ara's concern about the runtime API, which he thinks isn't as rich as the .NET api. He would like to see some methods such as: Annotations.getClassWithAnnotationTypeOf(Class annotationType), Class.getMethodsWithAnnotation(Class annotationType), and more. Ara claims that, ".Net has a far richer runtime API, support for wildcards and many goodies and convenience methods".

Sam Pullara, of BEA, thought that the draft spec had a hole, in that: "There is no specification for the processing of these annotations in the document. They don't talk about what an end user needs to do once they have an annotated source file and a set of annotations in order to completely process that source file."

Ted doesn't think this is fair: "Personally, I'm not sure what Sam is concerned about: the tools necessary to process the code depend on what annotations you used in your code. If, for example, you create a .java file with annotations in it as defined by a JDO vendor, then for "complete" processing, you need to run the JDO enhancer over your .class files, just as you do today."

What are your thoughts?

Links

Ted Neward in JSR 175 comments

Ara Abrahamian in JSR175 Thoughts

Sam Pullara in JSR-175... Great spec for the language, totally ignores tools

TheServerSide original coverage: JSR 175: Metadata for Java in Public Review