Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 17070 invoked from network); 3 Jan 2003 16:48:57 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 3 Jan 2003 16:48:56 -0000 Received: (qmail 26895 invoked by uid 97); 3 Jan 2003 16:50:13 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 26832 invoked by uid 97); 3 Jan 2003 16:50:11 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 26796 invoked by uid 98); 3 Jan 2003 16:50:10 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) X-Server-Uuid: 12CEA60A-EC9A-454A-BAC6-79DF5D30668A Message-ID: From: "Stepanossov, Kirill" To: "'Avalon Developers List'" Subject: RE: [general][attributes][clazz][A5] metadata & the java world Date: Fri, 3 Jan 2003 11:48:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) X-WSS-ID: 120B601A3227612-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N JSR 175 "A Metadata Facility for the JavaTM Programming Language" is going to be released by the end of this year as the part of J2SE 1.5 "Tiger" release. >From JSR 175 home page : 2.5 Please give a short description of the underlying technology or technologies: A Java programming language feature for metadata, plus a runtime format for metadata information, plus runtime APIs for accessing metadata information -----Original Message----- From: Leo Simons [mailto:leosimons@apache.org] Sent: Friday, January 03, 2003 10:38 AM To: avalon-dev@jakarta.apache.org Cc: commons-dev@jakarta.apache.org Subject: [general][attributes][clazz][A5] metadata & the java world Hi gang, (commons peeps, my first post here I think, did read http://jakarta.apache.org/commons/charter.html but couldn't find anything on mailing list conventions so hope all is ok) read a few books on .net 'n stuff last week. Got me thinking again on metadata in the java world. I'm gonna throw an overview of various stuff out at y'all, along with some thoughts. Additions/corrections much needed I suspect ;) ---------------- .Net ---------------- .net stores metadata in compiled tables, basically mapping a reference (to a class, object, method, whatever) to a serialized representation of an attribute. An attribute is simply a serializable object extending a base Attribute class, very bean-like in nature. In C#, you apply attributes to objects by placing the constructor for the attribute between square brackets, and optionally including a list of properties to set. here's how'd might work in "Java.Net" pseudocode: [Avalon.Attributes.Lifestyle("singlethreaded", poolable=true)] class MyClass {} [Avalon.Attributes.Lifestyle("threadsafe")] class MyClass2 {} would be preprocessed into something like: class MyClass { static public Attributes[] _att; static { _att = new Attributes[1]; _att[0] = new Avalon.Attributes.Lifestyle("singlethreaded"); _att[0].setPoolable(true); } } class MyClass2 { static public Attributes[] _att; static { _att = new Attributes[1]; _att[0] = new Avalon.Attributes.Lifestyle("threadsafe"); } } and the _att stuff is then serialize()d and stored into a table, ie resulting in something like (in some hypothetical serialization format I just made up): MyAssembly.jar!/META-INF/ClassMetaData.properties ------------------------------------------------- MyClass.attributes=array:1:Avalon.Attributes.Lifestyle(f0:singlethreaded:f1: *:f2:1): MyClass2.attributes=array:1:Avalon.Attributes.Lifestyle(f0:threadsafe:f1:*:f 2:*): When the class loads, the attributes are deserialized and are then easily accessible through introspection tools, ie you have something like class AttributeUtil { public static boolean isSet(Object o, String attributeName) { ... }; public static Attribute getAttribute(Object o, String attributeName ) { ... }; } There's more to it of course (for example, if you leave out constructor argument and property info, you can leave off the (), and you can also often do without the full package spec), but the basic idea is simple enough. ---------------- Avalon ---------------- As putting [] in your sourcefiles is a bit troublesome (most editors won't cope, for one), Pete (or someone else, doesn't matter, but he was the first to commit some code dealing with this that I saw) had the bright and obvious idea some time ago to put the metadata in the javadoc comments instead, ie the modified example becomes: /** * @attribute Avalon.Attributes.Lifestyle("singlethreaded", * poolable=true) */ class MyClass {} /** * @attribute Avalon.Attributes.Lifestyle("threadsafe") */ class MyClass2 {} and as it is somewhat cumbersome to do actual preprocessing, the idea was to just store the metadata information somewhere well-known (where the utility classes would know how to find it). So instead of MyAssembly.jar!/META-INF/ClassMetaData.properties ------------------------------------------------- MyClass.attributes=array:1:Avalon.Attributes.Lifestyle(f0:singlethreaded:f1: *:f2:1): MyClass2.attributes=array:1:Avalon.Attributes.Lifestyle(f0:threadsafe:f1:*:f 2:*): what we get is: MyAssembly.jar!/MyClass.xinfo ----------------------------- MyAssembly.jar!/MyClass2.xinfo ------------------------------ So far so good. Of course, with a verbose xml format for storing the metadata information, it is also possible to edit and maintain the xml files by hand. There's one big difference though: with .Net, basically their designers figured out a compact way to specify the metadata by closely tying their semantics to objects. The way we're going now, with the metadata dtds, we loose some compactness, but more importantly the close ties are gone. "Custom metadata" is more difficult with the avalon setup. (note: none of the above actually works; it's just pseudocode examples) ------------------ Commons Attributes ------------------ Commons Attributes (which I just took a first look at) is more similar to the .Net setup. It also uses QDox for parsing, but instead of defining some xml scheme, simply stores a serialized properties file. This is neat and simple (there's very little code neccessary to make it all work, the attribute parsing being handled by QDox). Commons Attributes atm doesn't define a standard location to store attribute properties, nor does it contain code to automatically load the properties from that location and construct metadata object from them. There's also less possibility for more complex setups than with the .Net way, as an attribute is a name/value pair rather than a potentially complex object. ---------------- Commons Clazz ---------------- Then there's Commons Clazz, which does a lot more, full of reflection tools and the like. There's also the idea within Clazz to support metadata, I'm not quite sure where they're at just yet. No website available yet, the only docs are @ http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons-sandbox/clazz/P ROPOSAL.html?rev=1.2 As there's less docs I have less of an opinion on Clazz, but it looks complex to me. ---------------- QDox, XDoclet ---------------- The QDox and XDoclet folks are also working on metadata stuff themselves I believe. Haven't looked at it much, but wanna. I'd say it'd be best to seperate the javadoc parsing from the metadata semantics. --------------------- So which way forward? --------------------- I'm currently thinking about which way to go with avalon re: all this. I'm still liking the approach taken in .net/C# the most. I think a way forward might be to only so slightly extend Commons Attributes to support the "constructor-with-property", or basically the GlorifiedHashMap, along with defining a common location for metadata to be stored in jar files, and along with an avalon container that handles the reading writing of that data and automatically loads it for all managed components. I'm not liking the complexity and size of Clazz very much atm (for dealing with this metadata thing that is; I think it'll be good at accomplishing its primary goal of reflection done right). Avalon peeps, I think a good place to work on the basics is Jakarta Commons; what we need first is some utility code for constructing and destructing metadata, the IoC specifics 'n stuff can come later. With gmane setup, it is no longer neccessary to subscribe to yet-another-gazillion-messages-a-day list :D cheers all, - Leo -- To unsubscribe, e-mail: For additional commands, e-mail: ------------------------------------------------------------------------------ This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. -- To unsubscribe, e-mail: For additional commands, e-mail: