Re: [PROPOSAL] lifecycle release

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)
---------------------------------------------------------------------