|
Extending Metadata Recognition
The Java programming language metadata facility (JSR 175) for J2SE 1.5 foments discussion at The ServerSide Symposium 2004
by Kito Mann
Posted June 16, 2004
I spent May 6-8 at TheServerSide Symosium in Las Vegas, Nevada (see Resources), a small conference focused on technical sessions to the highly technical and critical audience of TheServerSide.com (see Resources). On the final day, I attended Ted Neward's discussion on custom attributes in Java. Attributes are currently being developed as Java Specification Request (JSR) 175 (see Resources) and will be part of J2SE 1.5 ("Tiger"), which is scheduled for release later this year. Neward made a point of saying that all of this information hasn't yet been finalized, so take the contents herein with a grain of salt.
Neward started the discussion by pointing out some early hacks in the Java language that could have been handled with attributes, most notably serialization. To mark a class as serializable, we have to use the marker interface Serializable. That interface works relatively well at the class level, but what about something more granular like marking a field to keep it from being serialized? There are several options, such as naming patterns, but none of them are particularly elegant, and the solution was to add the transient keyword to the language. This solution is pretty kludgy, and it only works if you're Sun.
The rest of us end up with marker interfaces and about a million XML documents for Enterprise JavaBeans (EJBs), Java Data Objects (JDO), servlets, Java Management Extensions (JMX), Remote Method Invocation (RMI), and so on. JavaDoc comments are helpful too, especially for code generation (witness XDoclet), but they aren't included in bytecode, so they can't be interpreted at runtime or after compilation.
The solution then is to allow us to support arbitrary annotations—metadata—for our classes, fields, methods, and so on. Metadata doesn't replace tools like XDoclet that generate code based on JavaDoc comments; rather, it's a feature that a future version of these tools might use instead of JavaDoc comments. In many ways, they formalize and extend some of the current usage of JavaDoc comments.
Annotations are implemented as special classes that look like interfaces, and consequently have no implementation. Their goal is to provide additional information about your code, and that's it. Once you've defined an annotation, you can use it to declare additional information about your code at many different levels (package, type, field, method, parameter, and so on). You can also control when the annotations are available (source only, class file, or runtime), and whether or not they will be documented. As a simple example, consider this annotation:
public @interface
RequestForEnhancement
{
int id();
String synopsis;
String engineer() default
"[unassigned]";
String date() default
"[unimplemented]";
}
As you can see, this interface looks strange. There are, however, quite a few restrictions: no "extends," fields, nested classes, interfaces, enums or annotations, static initializers, or generics. (Enums and generics are part of J2SE 1.5 as well.)
Back to top
|