commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@centras.lt>
Subject Re: [Reflect] Summary of points and relationship with BeanUtils
Date Wed, 19 Jun 2002 06:42:17 GMT
Ok,
I will start a separate project for code generation someday.
I believe everything ok with your "karma", add proposal and code to cvs and
we will start more meaningful work.


> 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>
>


--
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