This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
metadata is data about data. In this case some indicator of what a class is to replace a marker interface.
IMO that's very dirty indeed, and a marker interface a cleaner way to work. But then I consider the type of something to be code rather than data and mixing code with data (which the use of annotations more often than not is) to be evil incarnate.
Metadata is information that describes the properties of something (a class, member variable, method, etc.).
In Java, there have been several ad-hoc ways of specifying metadata in the past. Marker interfaces are one example, the "transient" keyword is another.
Normally, when a class implements an interface, it tells you something about the data type of instances of the class - it's the normal "is a" relationship that you have with inheritance. For example, if your class implements Runnable, then your object is a Runnable.
With marker interfaces, the inheritance mechanism is abused to specify metadata. For example, if your class implements the marker interface Serializable, it doesn't mean that your object is a Serializable. (The whole sentence "this object is a Serializable" sounds kind of strange.) Instead, it means that the object has a property; it is Serializable.
In Java 5, annotations were added as a generic way of specifying metadata - now we can use annotations instead of the existing ad-hoc ways to specify properties.
In J2EE, metadata about EJBs is stored separately from the source code, in an XML deployment descriptor. This has some advantages; you're not mixing up source code and deployment configuration information. In the new EJB 3.0 standard, XML deployment descriptors have been replaced (or amended by, because you can still use XML deployment descriptors if you want) by annotations. The disadvantage of this is that you're mixing up code and configuration information, the advantage is that you don't have to hack in XML and that you have everything in one place (the source code file).
A book I quote often, Horstmann C, Cornell G, Core Java 2: Vol II-Advanced Features 7/e, Upper Saddle River, NJ: Prentice-Hall (Sun Microsystems Press) (2004), has this paragraph as its very last page before the index (page 972).
It is easy to use annotations that someone else designed. It is also easy to design an annotation interface. But annotations are useless without tools. Building annotation tools is undeniably complex. The examples that we presented in this chapter give you an idea of the possibilities. and we expect many far more sophisticated tools to emerge inthe future. This chapter has given you background knowledge for evaluating annotation tools, and perhaps has piqued your interest in developing your own tools.
Now, it is 18 months since that was written, so thing smay have changed, but the annotation is still a new feature, and we probably don't yet know how it is to be used to its fullest extent.