commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [Reflect] Summary of points and relationship with BeanUtils
Date Tue, 18 Jun 2002 21:01:10 GMT
I definitely would like to make BCEL more accesible. However, reflect cannot
depend on BCEL.

Stephen

----- Original Message -----
From: "Juozas Baliuka" <baliuka@mwm.lt>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>;
"Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Tuesday, June 18, 2002 10:58 AM
Subject: Re: [Reflect] Summary of points and relationship with BeanUtils


>
> Hi,
> As I understand we will have utils for java.lang.reflect.* and new
> introspection based on reflect utils.
> You know, I can't find a good place for code generators, this API looks
> like reflection and  uses
> code generation (BCEL) for implementation. I use this code for
optimizations
> and tracing in my "closed" projects and for persistence in simplestore and
> XORM.
>   May be put it to this project ?
>
> At 23:59 2002.06.17 +0100, Stephen Colebourne wrote:
> >Hi,
> >The discussion so far has led me to the following:
> >
> >1) There are lots of ideas in this area
> >2) BeanUtils are concerned that previously tested code will be forgotten
> >3) Various people are concerned that a 'large framework' won't suit them
(if
> >it's large it won't suit me either!)
> >4) There are clearly two levels involved here - reflection helpers and
> >introspection.
> >
> >I believe that (4) answers (2) and (3).
> >
> >Reflect
> >-------
> >On quick inspection, BeanUtils' MethodUtils would make a sound base for
the
> >reflection package. Other methods have been suggested too, and they would
be
> >added.
> >
> >Reflect should be a simple flat static interface just above java
reflection.
> >It should provide those methods that java should but doesn't. It
shouldn't
> >scare anyone and be able to be picked up easily.
> >
> >One suggestion has been that reflect is just adding functionality to the
> >BeanUtils project. I disagree. BeanUtils mandates the bean naming
> >conventions as defined by BeanUtils. This is very specific. Thus my
> >intention is to copy MethodUtils to reflect and add/amend it. My hope
would
> >be that BeanUtils would choose to depend on reflect at a later stage.
> >
> >Introspect
> >-----------
> >This is the higher level part that I first laid out in the proposal. If
> >successful it should tie together JXpath, Betwixt, Joda and maybe BCEL
and
> >BeanUtils. (There are probably others too). It is about class analysis,
and
> >if it fits happily DynaBean type concepts.
> >
> >I think that once there is some dummy code to look at (to explain my
ideas),
> >it might make a little more sense. Patience!
> >
> >BeanUtils
> >----------
> >I don't think that either reflect or introspect replace BeanUtils. The
> >purpose of BeanUtils is to assist with a specific case - working with the
> >java.beans package and the Introspector. This is a perfectly valid case.
> >Introspect is about saying 'the java beans spec is outdated, and so is
> >Introspector'.
> >
> >
> >Naming
> >--------
> >Given these two separate layers - reflect and introspect - I'm tempted to
> >say that either:
> >- two new sub-projects are needed, or
> >- reflect should be part of a reinvigorated lang, and the new project is
> >called 'introspect'
> >
> >I favour the latter at the moment, as reflect will probably just be one
> >class and a jar just for that seems pointless.
> >
> >Stephen
> >
> >
> >--
> >To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> >For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message