Re: New Reflection/Beans API

Some ideas can be stolen from this project :
http://www.cs.ncl.ac.uk/research/dependability/reflection/

At 16:27 2002.06.03 +0200, Markus Dahm wrote:
>Hi,
>
>recently there has been some discussion about how to design/implement
>an Reflection and Bean API using BCEL. Since I think it would be a
>very good idea to have such a thing in BCEL, I'd like to start a
>discussion here about the requirements and implementation issues.
>
>This is not a real proposal, just a collection of thoughts and ideas
>where I took some from a previous posting by Stephen Colebourne.
>
>Reflection:
>-----------
>
>How it should work is obvious (!?), we add some code to the class that
>is to used be used reflectively. We could do this statically, i.e., in
>some kind of compiler, or using a class loader, which may be a little
>less performant, but is of course much more flexible.
>
>The benefits of such an API would be
>
>a) increased performance of reflection (measurements?)
>
>b) additional features possible, e.g., we could have a class loader
>that allows to run a chain of class modifiers, where adding reflexive
>behaviour would be just one. I.e., such class modifiers would have a
>method
>
>         public JavaClass modifyClass(JavaClass clazz) { ... }
>
>c) base for a Beans API
>
>The question is how to tell which classes need to be augmented. This
>has to be know statically since we only have one chance to augment the
>class, namely when it is loaded/created. The simpliest approach would
>be to require the class to implement a marker interface, say
>
>         public interface Reflective {}
>
>The other possibility would be to tell the class loader, before the
>class gets loaded, e.g., via some regular expression:
>
>cl.addReflectiveClass("com.foo.beans.*Impl");
>
>One could also restrict access to certain methods and fields.
>
>--------------------------------------------------------------------------------
>
>Given that we want to modify class A
>
>public class A implements Reflective {
>        private String str;
>        private int    x;
>
>        int foo() { }
>        int foo(int x) { }
>}
>
>We would then like to use reflection like this:
>
>    A         a       = new A();
>    JavaClass clazz   = Repository.lookupClass("A");
>    Field[]   fields  = clazz.getFields();
>    Method[]  methods = clazz.getMethods();
>
>    fields[0].setValue(a, "Hello world");
>    Object result = methods[i].invoke(a, new Object[] { new Integer(4711); });
>
>Of course setValue/invoke would throw an exception if the passed
>object does not support our kind of reflection.
>
>    public void setValue(Object target, Object value) throws SomeException {
>      if(target instanceof BCELReflective) {
>        ((BCELReflective)target).BCELsetValue(target, field_name, value);
>      } else if(target == null) { // Access to static field
>        ??????????????
>      }
>    }
>
>However, we have our first problem here: How does this work for static
>fields and methods?
>
>
>As you probably already noticed the class loader or whatever would let A
>implement another interface and implement its methods:
>
>public interface BCELReflective {
>        public void BCELsetValue(String name, Object value);
>        public Object BCELgetValue(String name);
>        public Object BCELinvoke(String name, Object[] args);
>}
>
>These methods would wrap/unwrap the arguments and call the
>corresponding methods or set/get the right field.
>
>
>Problems so far:
>---------------
>
>* As we all know methods may be overloaded thus just using the name is
>   not really sufficient here, instead we could use the method index or
>   some generated identifier. Using the index would allow us to use a
>   fast switch() statement.
>
>* Fields and methods currently do not know their index nor the
>   JavaClass object they belong to. We could pass them in the
>   setValue/invoke argument list.
>
>* How do we implement reflection for static fields and methods?
>
>
>
>Beans (Really just a scratch file of ideas):
>-------------------------------------------
>
>I'm not an expert on Java Beans, but probably many of you are...
>
>What we could have is an extension of ClassGen, say BeanGen that has
>additional methods and an extended InstructionFactory. I know there
>is a class somewhere the Java Bean API such as "BeanAdapter" which
>already implements the default behaviour and can be used as a
>delegatee. I.e., we can use this class in our API.
>
>What we obviously need is a declarative way to tell which features
>we want for our bean. Having an interface with empty methods is a
>very simple approach, but I think we need something more powerful.
>One problem is for example that property names need not to be
>equivalent to field names. Getters and setters may have additional
>checking code that relies on other fields.
>
>Possible features:
>------------------
>* Property objects (i.e. bound to a particular object field)
>* Read-only properties
>* Automagically generated setters, getters, event methods, etc.
>* Generate BeanInfo's for Introspection
>* Generate Beans for alternate sources (XML, DB tables)
>* Collection handling
>* See below :)
>
>Cheers
>         Markus
>
>P.S. The developer list is being archived now.
>
>-------------------------------------------------------------------------------
>The original positing from Stephen Colebourne
>
>
>Scope:
>Reflection - Class, Method, Field, ...
>Bean - Introspector, javabeans
>
>Need:
>- Performance on java1.3 and earlier
>- J2ME
>- Current reliance on javabean spec version 1 that was designed to replace
>ActiveX, not be a domain model.
>- Boring coding of javabean gets/sets (I know tools can help, but I still
>see bugs in gets and sets)
>- Auto generated event methods (bound/constrained properties)
>- Desire for dynamicly created javabeans/ properties (from databases, xml
>etc.)
>- Desire to pass around an object representing a property
>- Desire to change the bean Introspector's lookup mechanism, such as to
>allow private get/set methods to be treated as properties
>- Desire to handle collections properly (they aren't handled at all by beans
>Introspector at the moment
>- Desire to dynamically make a property read only once setup (like const in
>C)
>
>Bean types:
>- Coder writes interface with coded get and set methods, BCEL generates
>implementation on the fly
>- Coder writes abstract class with coded get and set methods, BCEL generates
>implementation on the fly
>- Coder writes real class with coded get and set methods, BCEL modifies
>parts on the fly
>- A general purpose bean, to be used where all the data is dynamic, similar
>to a HashMap
>- A mixture object, where some fields have coded get and set methods, others
>are dynamically created as the application requires
>
>
>OK, so if you haven't guessed, I'm more interested in Beans than Reflection
>on its own (Reflection is fine and useful, but its very low level). Most of
>these ideas come from the Joda project, but I think they represent a good
>idea of what people are using beans for now.
>
>Stephen
>
>
>--
>To unsubscribe, e-mail:   <mailto:[email protected]>
>For additional commands, e-mail: <mailto:[email protected]>