commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitri Plotnikov <>
Subject Re: [clazz] Supported object model list
Date Sat, 26 Oct 2002 16:22:18 GMT
I agree that BeanInfo is a good model to build on. However, I would like to
emphasize a few fundamental difficiencies in BeanInfo:

1. Introspector is too class name centric: it uses the class name to create
other class names and look up information that way.  This produces two types
of problems:
        a) what do you do if the class is automatically generated (e.g. by
the EJB container)?
        b) what if there is whole category of classes for which we want to
generate BeanInfo in a certain way?  You cannot have a "generic" BeanInfo
for multiple classes.

2. BeanInfo and PropertyDescriptors specifically give you some methods
(readMethod, writeMethod etc) to call instead of calling those methods
themselves.  What this does is that you cannot support models like maps,
delegated accessors, collections etc, because for those there is no "get" or
"set" method to call at all.

3. BeanInfo mixes apples and oranges a lot - you find there information
about access to the property at run time as well as how to edit it inside an
IDE.  I am not opposed to centralized access to all kinds of information,
but I think the information itself should be properly compartmentalized.

That said, I agree with you that loose coupling with the target class has
the disadvantages you mentioned.  So, I guess we need to find a solution
that is well balanced simplicity and flexibility.

- Dmitri

----- Original Message -----
From: "Steve Downey" <>
To: "Jakarta Commons Developers List" <>
Sent: Friday, October 25, 2002 8:15 PM
Subject: Re: [clazz] Supported object model list

On Friday 25 October 2002 07:07 pm, Stephen Colebourne wrote:
> Other object models that could be considered:
> Swing
> neither strike me as essential.
> However, providing base support for Map properties in beans seems
> to me. We should support beans with simple (atomic) properties, array
> properties, List properties and Map properties. The act of deciding what
> an SimpleArray/ListMap property (ie. what the methods are what etc. is
> pluggable)
Perhaps we should take a view of eventually proposing a JSR for it. The fact
that the java bean spec doesn't address collection properties means that
everyone creates their own, similar, workarounds.

I think a good aproach for pluggability is the BeanInfo class. It's well
defined how to create a BeanInfo that overides the default java bean
behavior. In fact, that's one of the reasons you have to use Introspection
deal with javabeans correctly.

There is a lot to critisise about the BeanInfo spec, though. The loose
coupling between a BeanInfo and it's class has resulted in genuine java
for example.

Hejlsberg's approach of requiring an inner class has some advantages.

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message