Re: New Reflection/Beans API

Stephen Colebourne wrote:

> Hi,
> Well, you'll never guess what I've been working on today...
> 
> My interest in this comes from the Joda project (www.joda.org). There I am
> developing code which aims to build upon the current JavaBean spec and to
> provide more functionality. Already working are Java (non-BCEL) versions of
> an API. However, there are places where it is slow, and it is memory hungry.
> This is where I have started to use BCEL (I've only started today, so I
> haven't got too far yet).
> 
> The API includes a Bean interface which is to be implemented by all beans.
> This provides access to each property of the bean:
> interface Bean {
>  Map getPropertyMap();
>  Property getProperty(String propertyName);
>  Class getBeanType();
>  Object cloneDeep();
> }
> interface Property {
>  void set(Object object);
>  Object toObject();
>  boolean isReadOnly();
>  boolean isModifiable();
>  void setReadOnly();
>  void setModifiable(boolean);
>  String getPropertyName();
>  Class getPropertyType();
>  String getContentName();
>  Class getContentType();
>  boolean equalsValue(Object object)
>  void addPropertyChangeListener(PropertyChangeListener)
>  void removePropertyChangeListener(PropertyChangeListener)
>  void firePropertyChange(Object from, Object to)
> }
> 
> 
>>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
>>
> 
> I agree with most of these. BeanInfo is more trouble than its worth. XML/DB
> can build upon the architecture rather than needing to be BCELed in at a low
> level. I would also add
> * Allow properties to be added by applications on demand
> * Generate from an interface, abstract class or real class
> 
> For interfaces and abstract methods, things are easy - just generate code
> according to some default setup. But a factory is required to actually
> create the objects - and people hate factories (and beans really should have
> a no-args public constructor)
> 
> Thus a normal class would need to be modified on load. My thought was that
> any options could be set as API calls with the method being replaced.
> public void setSurname(String surname) {
>   // some application logic
>  BeanGen.createSet(flags);
>   // some application logic
> }
> 
> Well, thats what I'm looking at anyway ;-)
> 
> 
> Reflection
> ----------
> I'm more interested in the Beans side, but...
> 
> For statics, isn't it a case of passing null in where the object ref would
> go? That's what Java reflction does.


Yes, but how do you call a method without having an object you can cast
to something. I.e., you need some kind of dispatcher, but where does it
come from?

Cheers
	Markus