JSR 175 comments

from http://www.neward.net/ted/weblog/index.jsp?date=20031109#1068439908500

Recently, I've become aware of some thoughts on the JSR 175 Public Draft. I thought I'd take a few moments to respond on what my thoughts are; please take standard disclaimer with this, in that I don't speak for the entire Expert Group, although we have hashed a lot of these issues out and what you see in the Public Draft *is* reflective of the final thoughts we've sort of (grudgingly, sometimes) come to.

First, to respond to Ara's thoughts. He first asks,

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!

First of all, Ara, you're correct in that .NET attributes are, in fact, normal classes, but they do have some restrictions on them that other classes do not have; first and foremost, you must inherit from System.Attribute, or the compilers won't accept your attribute usage. Secondly, normal classes are not better for annotation types, precisely because normal classes can, in fact, include code, and 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. Anything else would blur the distinction between attributes and metaobject protocols, and lead us down a very slippery slope with this JSR. 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 goes on to ask,

Unfortunately there's no support for attribute subclassing. There are more than just 3-4 @annotations in the real world that contain common fields! Just look at ejb related attributes for example. ejb-name, ejb-ref-name, many other parameters. Weird limitation....

There's no need, since annotations can compose other annotations, thus creating effectively the same thing. Don't get polymorphism confused with composition--we have no need (and no call) for annotation polymorphism.

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.

I'm not sure what stubs you're looking to generate Ara, but please 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.

As a signoff, Ara,

I think it's not possible in any way to use this spec in JDKs prior to JDK 1.5, neither legally nor technically. It's bound to generics, enums and other JDK1.5 specific stuff. We have to wait for JDK 1.5....

And this is a bad thing? Quite frankly, no JDK 1.4 compiler would know what to do with an annotation even if we didn't make use of generics, enums and other JDK 1.5-specific stuff, so....

Sam Pullara, in turn, worries that:

However, after reading the specification, I feel there is a large gaping hole in it. 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.

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.

He also notes in his postscript at the end,

Other problems of note include the requirement for the annotations for compilation. Javac could generate fake annotations based on usage. You would have to get rid of default annotations though.

Absolutely not. Java is a strongly-typed system, and should remain that way. This is something that has been the subject of some debate within the EG, but we're pretty firmly decided that this is something that needs to remain in place. If, for example, you make use of a class, call it Foo, somewhere in your codebase, Foo needs to be available as part of the Java ClassLoader resolution process--javac cannot "fake" a class "based on usage". If it did, thousands of problems would never be resolved until runtime, at which point it's too late to correct. Annotations need to remain type-safe, or we introduce a hole into the Java type system. And that means that your annotation types, regardless of their usage (which includes UML tools and the like) must be present on the compilation path for compilation to succeed. In fact, this is why we have the retention policy--so that certain annotations, such as those used by UML tools, can be left on the "cutting room floor" (to use Josh Bloch's words) during compilation, so that they won't affect compilation process. Of course, that means the actual attribute type itself must be present as part of the compilation path, but c'mon, guys, how hard is it to expect that a developer must have a support .jar in his compilation java.class.path in order to support a UML tool? For most of us, it's another line in an Ant task, assuming his UML tool doesn't double as an IDE and automagically includes it in the first place.