Re: Stroring runtime attribues in classfile

Jon Tirsén <[email protected]> Wed, 28 May 2003 19:28:50 +0200 (CEST)
Newsgroups gmane.comp.java.nanning.devel
Message-ID <[email protected]>
Interesting experiment. At the moment I'm working hard
to try to stabilize the dependencies that Nanning have
in order to get ready for a 1.0 release. Introducing a
dependency for JavaAssist may be awkward at this time.

I'm thinking about creating some kind of
contrib-structure where sub-components/frameworks are
built along with the core nanning but not to the same
jar-file.

Maybe we can work together to create some kind of
plugin-handling for the attributes-stuff. That way you
could continue to experiment in a contrib-sub-project
with any kind of dependencies you like and when (if?)
things stabilize maybe we could move it back into the
core.

I was thinking in lines of:
The Attributes-class keeps a list of
AttributeProviders, when loading a ClassAttributes it
instantiates it with the specified Class and passes it
to each provider to let it fill in it's values.

I'm free from work tomorrow so I might start working
on this then.

 --- Khalil Bouhamza <[email protected]>
skrev: > 
>       Hi Jon,
> 
>       I have just written  a little thingy that 
> stores the attributes 
> properties  info in the  class file using  byte code
> engineering  via 
> Javassist, now a JBoss project, ( I skimmed through
> ASM docs but it 
> seems it doesn't provide the needed functionality ),
> Javassist lets you 
> embed a byte array as a custom attribute into a java
> class file,  so 
> instead of writing  the properties constructed after
> parsing  the  java 
> source  file into a .attribues property file, we can
> serialize it and 
> store it in  the correspending compiled class file. 
> The good thing 
> about this aproach  is  that  attributes  are 
> stored  in the binary 
> class file instead of a seperate file, and though
> the  classfile is 
> modified, the JVM will just ignore the added
> metadata when loadoing the 
> class, the changes are pretty transparent in that
> respect.  The bad  
> part is that  each  time you compile the class, the
> attribue compiler 
> must run afterwards, second .attributes file are
> pretty verbose and can 
> be modified and tweaked directy, of course a simple
> editor for the 
> embedded properties can also be written. The code is
> very very  rough, 
> there is no proper Exception handling or logging.
> Attribute Inheretence 
> is not implemented,  but I think  doable. I have 
> attched the files that 
> have been modified. I have added a
> ClassFileAttributes  class that 
> stores and  load the  attribute proerties from the
> class files. I have 
> commented some  portions of Attributes and 
> AttributeCompiler so that 
> the new  storage will be used.I have also added a
> classDir File 
> attribute to attributeCompiler indicating  where the
> class files are 
> strored. AttributesTest gives a green bar, but it's
> the only Test I  did 
> run, I have  added some configuration lines to 
> AbstractAttributesTest   
> to fit my  environment,  also to set the classDir
> field on 
> AttributesCompiler. There is a pretty ugly hack in
> AttributesBuilder to 
> get the package  name  of  the parsed java file, The
> code as I said is 
> very very  rough.To run   AttributeTest , you will
> have to set  
> AbstractAttributeTest   classDir  field to point to
> where classes are 
> compiled, on the second run try commenting   
> attributesCompiler.execute(),  the tests should pass
> indicating that the 
> attributes were indeed persisted.
>      I know that right now we have already two ways
> to define 
> attributes, but I feel  this might be of some
> interest. Comments, 
> thoughts  are most welcome.
> 
> Cheers,
> Khalil                
> 

> ATTACHMENT part 2 application/zip
name=nanning-classfileatributes.zip
 

_____________________________________________________
Gå före i kön och få din sajt värderad på nolltid med Yahoo! Express
Se mer på: http://se.docs.yahoo.com/info/express/help/index.html


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge