commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [clazz] Scope?
Date Sun, 27 Oct 2002 12:01:28 GMT
Scope, hmm, yes its a little tricky to define, which has been a concern of
mine too.

Use case 1:
Provide standardised access to Beans - a replacement to Introspector.
This covers simple, array, List and Map properties.
It also covers non-standard naming conventions, eg. other than 'get' and

Use case 2:
Property may not be a simple method call on the object.
This enables a Map of data on the Bean to be treated as real properties.

Use case 3:
Handle non-standard Bean types.
This covers the ground that DynaBean covers. Beans that aren't written as a
new class, but instantiated instead as instances of the same class.

Use case 4:
To be able to store attributes (meta-data) against classes.
Initially conceived as just a store used at runtime, has developed into the
ability to pickup values from XML files, and generated source/byte code.

#1, #2 and #3 are the key ones for tools such as Betwixt, Jexl, JXPath and
so on to be able to locate what properties there are on an object in a
pluggable way.

#4 just seems to drop out as an additional benefit. It wasn't my immediate

There is possibly a question of whether there is one or two projects here. I
would like to keep it as one for the moment. If the metadata stuff becomes a
big thing then the bean stuff breaks out at that point.


----- Original Message -----
From: "John Yu" <>
> I've been following the threads on [clazz]. There're many intriguing ideas
> floating around. However, it is still unclear to me what/how the package
> tries to achieve in concrete terms. What's described in "proposal.html" is
> pretty abstract.
> (But I understand the project is still at an "exploring" stage and various
> ideas are been explored.)
> It seems to me [clazz] tries to deal with the following areas:
>     * Implement a clone of delegators (aka bound method references).
>     * Implement some doclet-like meta-attributes for "annotating" Java
> classes; these meta-attributes are sort of orthogonal to the object model.
>     * Generalize java.lang.reflect.* and java.beans.*; this seems to be a
> followup work of BeanUtils.
>     * Provide a generic metaclass framework capable of altering class
> definitions at runtime. Very ambitious!
> (Of course, a metaclass framework is a superset of all. If this can be
> done, all the other will fall into places.)
>     * Source code pre-processing and generation
>     * Byte-code generation via BCEL
>     * Dynamic Proxy
> Have I missed anything? (Avalon has been mentioned many times in the
> threads. I'm not familiar with Alavon. I may have misunderstood stuff.)
> If a generic metaclass framework is the goal, I'd suggest to take a look
> some existing meta-object protocols (MOP) as they have strong theoretical
> foundations. Two MOPs come to my minds are IBM's SOM C++ metaclass
> framework
> and OpenJava (
> Anyway, back to my question: Do we need to clarify the scope?
> --
> John Yu
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message