Yes, .NET already supports that. But IMO it's a little more complex than it should be (and this might be a good advantage for Java - if the JSR team could make it simple).
This article touches the subject of using attributes to add runtime behavior, the first half discuss a COM based implementation of metadata that I think you can safely skip: http://msdn.microsoft.com/msdnmag/issues/02/03/AOP/AOP.asp Rodrigo ----- Original Message ----- From: "Erik Hatcher" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, March 25, 2002 9:57 PM Subject: Re: [Xdoclet-user] Java meta-data JSR from Sun > I'm going to show my .NET ignorance here, but does it already handle the > active metadata scenario that you gave as an example? Could you elaborate a > bit on what it does provide (or point me to some quick high-level docs that > explain it)? > > Thanks, > Erik > > > ----- Original Message ----- > From: <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, March 25, 2002 6:14 PM > Subject: RE: [Xdoclet-user] Java meta-data JSR from Sun > > > > 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 > > > _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
