Stefano Mazzocchi wrote, On 16/03/2003 20.23:
Peter Donald wrote:...
On Sat, 15 Mar 2003 05:51, Stefano Mazzocchi wrote:
This is a totally different argument. Can you outline here how the metadata concept is going to work for JSR 175? would that require a JVM change?
The JSR has not been made public but from the grapevine heres the scoop. The metadata will be store in .class file as "class attributes". So it will not require a JVM change but the utility files to load the metadata will be in the next JVM. However that does not stop us developing our own loader that parses the the .class files using BCEL.
I see.
I don't ;-)
Ok, so I've looked in the JVM spec and now I understand what it means. Here is what class "attributes" are:
http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html#43817
" All attributes have the following general format:
attribute_info { u2 attribute_name_index; u4 attribute_length; u1 info[attribute_length]; } "
"
Certain attributes are predefined as part of the class file specification. The predefined attributes are the SourceFile (�4.7.7), ConstantValue (�4.7.2), Code (�4.7.3), Exceptions (�4.7.4), InnerClasses (�4.7.5), Synthetic (�4.7.6), LineNumberTable (�4.7.8), LocalVariableTable (�4.7.9), and Deprecated (�4.7.10) attributes. Within the context of their use in this specification, that is, in the attributes tables of the class file structures in which they appear, the names of these predefined attributes are reserved.
"
"
Java virtual machine implementations are required to silently ignore attributes they do not recognize.
For instance, defining a new attribute to support vendor-specific debugging is permitted. Because Java virtual machine implementations are required to ignore attributes they do not recognize, class files intended for that particular Java virtual machine implementation will be usable by other implementations even if those implementations cannot make use of the additional debugging information that the class files contain.
"
Ok, so this means that it's easy to add metadata to the .class files...
But once you have that metadata inside your class, how are you going to find out something about it? introspection or direct bytecode manipulation?
...but how does one read it?
I'd assume that one would read them with the Class 'class'.
[RT] BTW, there are attributes that give line numbers in the original source file (4.7.8 The LineNumberTable Attribute)... so we could manipulate the class files to refer to the original xml files of XSPs [/RT]
Those sounds much less elegant than any instanceof() calls. What am I missing?
However from what I understand that the metadata will be extracted from javadocs. A few different proposals have been made but I am not sure what they will pick. Some proposals IIRC are
@meta Fortress{lifecycle="ThreadSafe"} @fortress lifecycle="ThreadSafe" @meta org.apache.avalon.fortress.FortressMetaData("ThreadSafe")
Ok, makes sense.
do you think this is going to be enough for the metadata needs you foresee? just curious.
-- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) ---------------------------------------------------------------------
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
