commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: [beanutils] moving reflection classes out of beanutils
Date Sat, 07 Dec 2002 21:32:05 GMT

On Fri, 6 Dec 2002, Costin Manolache wrote:

> Craig R. McClanahan wrote:
> I don't know.
> this kind of stuff.
> If the [reflect] package will have the same features and better API -
> then it may be better to mark beanutils as "stable"/"closed" and
> migrate modeler, digester, etc directly to [reflect]. I don't see why
> would we need a 2.x version.
> I don't think we need more than a component for this kind of stuff -
> or at least I would use a single component ( even beanutils ) over
> some reflection that is split in more components. Matter of taste,
> of course - but also complexity, dependencies, spaghetti.

Because reflection and beans are different things. Many things will want
to do reflection, but won't have any interest in some form of bean API.
The same holds for BeanUtils' Convertor system. Many things will want to
use this, but have no interest in Beans.

Having to deal with a library which is created with a context of JavaBeans
means that the Convertor and Reflection APIs will be tainted by this

> > It's clear that ConstructorUtils and MethodUtils belong together,
> > wherever they end up.  But it seems less clear that a move would mean
> > *deleting* MethodUtils from [beanutils].  It's straightforward to leave
> > the existing APIs available (for backwards compatibility), but as wrappers
> > around calls to the new functionality, probably deprecated but at least
> > kept through a 2.x version lifecycle.  That way, the actual functionality
> > is still in one place for easy maintenance/enhancement, we can fix the
> > method names in the new versions, and users of MethodUtils can migrate in
> > a controlled manner, at their own leisure.
> My point is that it would be better if the new package would focus
> on doing what it has to do - API, implementation, features.

Yep. And ConstructorUtils/MethodUtils are outside the scope of BeanUtils
in my view, even if the PROPOSAL does provide some mention of
reflection/introspection utilities.

> When it's ready - we can decide if it makes sense to deprecate ( freeze )
> beanutils entirely, implement it as a wrapper for backward compat -
> or keep it if it fits a different niche.

Agreed. It's always better to debate a piece of code when it's sitting and
ready for inclusion in a particular library somewhere, especially with
something like reflection where it's pretty independent of the surrounding

So... we let Robert/Stephen/others finish up with reflect in lang while
copying across modifications that occur to those areas in beanutils...
then we have big argument then? :)


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

View raw message