Well, I would expect a little bit more since .NET already provides more. It's not just about passive metadata (like a XML file, for instance) but it's about "active metadata" (or whatever we called it), active in the sense that the metadata could trigger/implement some runtime behavior... Think AOP (Aspect Oriented Programming). My point is that if they want to do it right and I'm sure they do (and will :-)) they're going to have to change/extend the current VM and that's take time and a lot of intelligent people. I wouldn't worry about the need for intelligent people since Joshua Bloch is already there. The issue here is time as always.
Now I would like to clarify what I mean by active metadata. Imagine the following scenario: you want all the calls to the method foo to be automagically logged for you. After browsing the java.util.logging documentation you discover that all you have to do is to tag the method with the Log attribute (the samples uses the C# syntax that looks a lot like IDL):
package foo.bar;
import java.util.logging.Level;
import java.util.logging.attributes.Log; // fictional attribute class
import javax.xml.attributes.XmlElement; // fictional attribute class
[XmlElement(Namespace="urn:foo:bar")] // Passive metadata (someone might use this)
public class Bar implements java.io.Serializable
{
[Log(Logger="foo.bar")] // Active metadata (introduce runtime behavior)
public void foo()
{
//1) Logger.getLogger("foo.bar").enter("foo") implicitly called by attribute
...
//2) Logger.getLogger("foo.bar").leave("foo") implicitly called by attribute
}
}
The lines marked 1 and 2 are behavior introduced automagically by the attribute, you don't have to type those lines but the method behaves as if you did. So, somehow, the runtime will have to change to give attributes a chance to pre and post process method calls when they need to.
Can we live without it? Yes, we have AspectJ, XDoclet and IContract. But, frankly, I think attributes and "active metadata" would be a nice addition to our toolset.
Rodrigo
----- Original Message -----
> >From the points there, it is exactly XDoclet isn't it.... afaik, no other
'code annotation tools' provide the framework that XDoclet
> does - includeing the 'Definition of a runtime delivery format for
metadata and of runtime APIs so that tools and libraries can
> accesss metadata information at deployment time and at runtime'.
Speaking of which.... it would be fairly straightforward to have XDoclet
create an XML file (or some other metadata format, perhaps even serialized
objects generated from post processing of the XML?) for each class processed
and create a utility to make all that information available to the class at
runtime.
Anyone ever considered this? Done it?
Its not really necessary, generally speaking, since XDoclet builds the
pieces we need at runtime anyhow, except in a more narrow/specific way. A
generalized mechanism could be an interesting addition, and beat this JSR
release for sure, and compete head-to-head with .NET's capabilities.
What kinds of suggestions do folks have for how such a mechanism would work?
Via Castor maybe (? I don't know Castor's details)?
Erik
_______________________________________________
Xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user
