commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [Reflect] Summary of points and relationship with BeanUtils
Date Thu, 20 Jun 2002 03:06:37 GMT

On Wed, 19 Jun 2002, Michael A. Smith wrote:

> Date: Wed, 19 Jun 2002 15:40:35 -0500 (CDT)
> From: Michael A. Smith <>
> Reply-To: Jakarta Commons Developers List <>
> To: Jakarta Commons Developers List <>
> Subject: Re: [Reflect] Summary of points and relationship with BeanUtils
> On Wed, 19 Jun 2002, Stephen Colebourne wrote:
> > > therefore
> > > code cannot be refactored from existing released components into the
> > > sandbox.
> >
> > I think this is a timing issue. Promoting Lang to Commons will probably only
> > occur when Lang is ready for a release. But, for Lang to be ready for a
> > release it would need to already have the low level reflection code in it.
> > Chicken and egg.
> I haven't followed this thread too closely, but I'm not sure where the
> chicken and egg are.  Rather than *moving* the code to lang, you can
> *copy* it.  Then, BeanUtils or whatever can still depend on its own
> version until the lang version is released.  Then, BeanUtils can update
> (when they're ready) to use the new version that exists in the released
> version of lang, assuming, of course, that the version in lang is as
> good, or better, than the version already in BeanUtils.

This seems like a reasonable compromise approach. If you can convince me
and the other BeanUtils committers that this will meet our long term needs
for low level reflection and introspection support, then we'll do what
Robert suggested -- "delegate and deprecate".

> btw, I'd prefer if this reflection stuff was in a package other than
> lang.  When I think of the "lang" package, I think of stuff like
> "Strings", "Integers", etc.  "Predicate" "Closure" and "Factory"
> probably apply there as well.  Essentially, the most basic of basic
> coding stuff that just plainly doesn't exist in the java APIs.  Any type
> of layer over reflection/introspection is a layer above what I view
> "lang" to be
> Then again, I'm probably missing something my not digesting all of the
> thread first...

My only concern is one that was recently expressed about BeanUtils (which,
I agree, is primarily focused on JavaBean properties) -- it sounds like
[lang] runs the risk of bloat and lack of focus also.  I'd personally
rather see small, tightly focused packages for "introspect" and "reflect"
(and probably some of the other stuff in mind for lang) that can be
released independently as needed, since the scope of those concepts is
pretty clear.  Chartering a package for "everything that ought to be in
the standard Java APIs but is not" doesn't seem quite so clear and concise
.. :-)

> regards,
> michael


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

View raw message