commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: [beanutils] moving reflection classes out of beanutils
Date Fri, 06 Dec 2002 15:41:08 GMT
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 

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


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

View raw message