XRAI thoughts. Ara speaketh thusly: This one's a new idea from me. You already know that .Net provides a runtime-based system for accessing attributes (@tags), so you can simply do something like anobj.getClass().getAttribute("ejb.bean") for example, whereas in java you read an xml file, and XDoclet is a compile time system which reads attributes. JSR 175 works on a runtime system, but for now what do you think about a simple simulation of a runtime attribute access API? So the idea behind XRAI is a post-proccessor ant task which reads source code and modifies the compiled classes with BCEL and injects some static fields to classes. It injects things like private static final Attribute[] attributes = new Attribute[]{new Attribute("ejb.bean", ...)} and with a naming convention for method level tags too. You'll be able to access the tags with an API like this: AClass.getAttribute("ejb.bean"). Looks very simple and feasible imho. Ideas?
The basic ideas is great. We currently desperately need something like this for our AOP-framework. For example, we need to be able to add tags like "@permission write" or "@transaction required" to classes which our interceptors then can utilize to do different things. So the idea is very welcome. But the suggested solution, while technically interesting, does have some drawbacks. First of all, adding static methods is bad because you then can't make generic code that uses them since that can only be done if the methods are part of an interface. But then you run the risk of clashing with existing methods. Second, this would mean that compiled classes only behaved *one* way, and that this behaviour was stored in compiled code. No good.
Here's an alternative solution: the access could be done through a static method in some utility class. Something like this:
ClassAttributes.getAttribute(someClass,someName)
and ClassAttributes.getAttribute(someClass,someMethod, someName)
to allow for both class- and method-level attributes. The implementation should simply look for a serialized object named someClass.getName()+".ser" using the someClass.getResource() mechanism. I.e. the data is stored in serialized objects. This is good because then this data is potentially updateable at runtime (=simply overwrite the serialized object), it can be stored in a database (=create a classloader that works that way), and you can have *many* sets of behaviours (=simply change what serialized objects are packaged with the app). This would be easy to implement, wouldn't need any fancy BCEL stuff, and would have the nice benefits outlined above. [Random thoughts]
I particularly like the ClassAttributes.getAttribute() approach which would allow different AttributeResolver implementations to be used while preserving a simple API for developers to access the attributes. e.g.
The files on the classpath could be serialized objects or plain text or XML etc. If the attributes are mostly textual, I'd prefer to use properties files or XML as the format; then at deployment time the attributes could be easily tweeked if required. I'm not a big fan of serialized object files.
