> From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > > 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
