Learn how to use the metadata annotations provided in J2SE 5.0

The recent release of J2SE 5.0 (also known by its codename “Tiger”) introduced numerous Java language changes designed to make programming in Java more expressive, developer-friendly, and safe. I covered many of Java’s new features in a September 2003 article entitled “Big Changes Coming for Java”. One significant change I didn’t cover—at the time it hadn’t been fully sketched out—was Java’s Metadata facility. In a new four-part series of articles, beginning with this one, I’ll continue where I left off one year ago and show you how to make the most of Java’s Metadata.

In this first article I’ll explain the purpose of metadata and demonstrate how to use metadata annotations provided in the core J2SE libraries.

In the second article, I’ll show how to write your own annotations (first writing simple ones like @Copyright and then looking at more advanced annotations like those built into the core language).

In the third article, I’ll demonstrate how tools can use annotations at build-time (generating new source or supporting files) and how programs can use annotations at runtime (to change code behavior).

In the fourth and final article, I’ll cover how authoring and deploying Web Services will be much easier in the future thanks to standard metadata annotations under development in JSR-181, for which Oracle is a member of the expert group. (Oracle is an active proponent of increased support for design-time metadata in development tools.)

You say “What I mean is the following: from the import statements in a Java Class,
it is quite clear which classes are used by a certain Class.” That is not quite true, it only tells us what the author of
the code choose to import. He could do import java.util.*; and still not use any of the java.util classes. Furthermore classes
from the same package don’t have to be imported at all.
Your idea version number checking relies heavily on the person making the version annotation in the code.
This person might not even be on you team. Integration with a
versioning tool could make it more robust but indeed, only on Class level.

I’d rather have my versioning tool include label/version tags. Relying on the developer making a change to the version tag seems
a bit dodgy. On the other hand the Tool you propose could actually check whether the version lables made by the Developers
correspond to the labeled release .

Actually the Struts RequestUtils class checks whether it can use the Java 1.4 version URLEncoder.encode() method at runtime with
two parameters. If it can not (code running on <1.4) it will use the deprecated version with one parameter.
But I agree this uses java code …