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 Sat, 07 Dec 2002 06:59:33 GMT
Craig R. McClanahan wrote:

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

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

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.

( well, you can  do all the introspection witha single class - both ant and 
tomcat3 are basically doing 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.

My point is that it would be better if the new package would focus
on doing what it has to do - API, implementation, features.

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.


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

View raw message