avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [RT] Attributes (possibly the ravings of a mad man!)
Date Thu, 19 Sep 2002 14:34:58 GMT
> From: Berin Loritsch [mailto:bloritsch@apache.org] 
> 
> As I was going through my pile of papers I printed out to 
> review later (most of which I already did), I stumbled on the 
> BCEL instructions. When they described the class file 
> structure, a lightbulb went off in my head.  At the end of 
> every Class, is space for Class Attributes, including 
> application specific attributes.  The same thing for the end 
> of every method for Method Attributes.
> 
> Instead of embedding descriptors in XML files, we can combine 
> the powers of BCEL and XDoclet to place all the relavant 
> attributes directly in the Class file!  We would first 
> compile the classes the normal way, then apply the 
> XDoclet/BCEL driven filter to add the attributes directly 
> into the class file.
> 
> The important thing is that we would have to override the 
> defineClass(String name, byte[] b, int off, int len) method 
> of the ClassLoader to make it work.  We can offload that into 
> a helper class like I did for JarScanner so that we get the 
> following info:
> 
> interface ClassDescriptor
> {
>      boolean isAvalonClass();  // has attributes
>      Class getClass();         // return the defined class
>      Object getDescriptor();   // will return the Type or Service
>                                // descriptor
> }
> 
> public final class AvalonClassUtil
> {
>      public static ClassDescriptor defineClass( String name,
>                                                 byte[] b,
>                                                 int offset,
>                                                 int length );
> }
> 
> 
> Or something like that.
> 
> Using BCEL to add and read attributes will make our lives 
> easier, although it is entirely possible to have something 
> that will scan the class file without BCEL (to limit the 
> number of runtime dependencies).

Neat idea, very .NET-like, but it seems like a cumbersome way to me.

 + Compatibility: Having our own classloader is fine, but is this
   something that will work in most/all environments?

 + What is the gain, really? We get a two-stage, highly avalon-specific
   compilation process, and the only thing we get rid of is the 
   XML descriptor. (Agreed, we do not need an XML parser anymore,
but...)

 + As I understand it, from a developer POV, what you get with
instrumented
   bytecode is identical to what you get with your JAR scanner - a way
to
   obtain Avalon-specific metainfo about a class.

That said, it is an extremely cool thing. 

Now if we could only find a problem for it to solve.

/LS


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message