commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [beanutils] moving reflection classes out of beanutils
Date Sat, 07 Dec 2002 02:34:10 GMT

On Fri, 6 Dec 2002, Costin Manolache wrote:

> Date: Fri, 06 Dec 2002 07:41:08 -0800
> From: Costin Manolache <>
> Reply-To: Jakarta Commons Developers List <>
> To:
> Subject: Re: [beanutils] moving reflection classes out of beanutils
> robert burrell donkin wrote:
> > what we have is clear duplication. twice the support and twice the
> > maintenance.
> Nobody asks you to support 2 versions. There is nothing wrong with
> duplication ( at least in commons ). You can just maintain and support the
> version you like.
> >> You're recommending deprecation of a released, public-facing API; Rodney
> >> is not.
> >
> > the (beanutils) MethodUtils API sucks. it was written in haste and now in
> > leisure, i regret that it was written in that way.
> It doesn't quite matter. There are people using it ( digester, other
> projects), it was released - we have to live with it. We may learn a lesson
> about APIs and use it next time, but as long as it does what it is supposed
> to do and works - you can't remove it.
> This start to look like dependency spaghetti to me, and it does create
> problems.

I believe that adding a dependency on [lang] or [reflect] would itself be
grounds for a 2.x version number for [beanutils], even with no other
changes (although there would undoubtedly be some).

> > my position has always been that i'm not willing to maintain, support or
> > develop two versions of the basic reflection classes. i've also been
> > convinced that beanutils is not the right places for these canonical
> > versions.
> Good. Then maintain and support the other version.
> > in terms of beanutils, i'm not willing to support a release with code in
> > that no one is willing to support. therefore, i'd think about vetoing any
> > contribution if i thought that no one was willing to offer support for
> > that code and maintain it. but you're willing to do that for
> > ConstructorUtils (and MethodUtils if it can't be deprecated), aren't you
> > rodney?
> ), it's reasonably clean. If Rodney doesn't want to support it - I can and
> I suppose other people will.
> Beanutils is used in tomcat, and if a bug happens we'll have to fix it
> anyway, and I think we can handle that.

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.

> Costin


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

View raw message