commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <craig...@apache.org>
Subject Re: [BeanUtils] Why does needs the method declaring a class to be public
Date Thu, 23 Nov 2006 09:02:32 GMT
On 11/23/06, Henri Yandell <flamefew@gmail.com> wrote:
>
> JIRA reports are good - we've a big backlog in BeanUtils but it's
> starting to go down.
>
> There are a couple of other similar issues (BEANUTILS-157 + BEANUTILS-87).
>
> I don't know why the API is designed to only work with public methods;
> whether that's an aspect of adherence to the spec, by design or
> legacy. Seems that if we're going to use setAccessible, that we could
> just open it to package and private too.
>
> Anyone know why MethodUtils intentionally limits itself?


There is indeed a large dose of "legacy" here ... the early versions of
BeanUtils (which came out of Struts in the pre-1.0 days) were never
consciously designed to be a general purpose bean property manipulation
library (i.e. the "BeanUtils" moniker was something of a stretch :-).  The
sole initial intents were to provide for the type conversions that Digester
needed, plus the "copy request parameters to a form bean" that the
1.xversion of a Struts ActionForm needed.  Hence, there was never any
initial
consideration for supporting the more esoteric cases that a general purpose
framework would need to support.

If BeanUtils is going to continue to evolve on the trajectory that seems to
be epitomized by recent comments on the mailing list and in JIRA issues, it
will need to be modified to deal with scenarios like this.  On the other
hand, more modern approaches to both configuration management (alternative
strategies for parsing configuration files plus completely different
approaches like JAXB), plus the decoupling of modern web frameworks from
hard coded things like a Struts ActionForm, means that my personal need to
care about what happens in BeanUtils is pretty much zero.  I don't consider
it an appropriate place to do innovative development, but if you are
interested in improving support for legacy applications then it is (of
course) fertile ground for incremental improvements -- some of which could
be pretty substantial improvements in usabilty.

Have at it ... but you'll find me watching from the sidelines.

Hen


Craig McClanahan

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message