Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: Sat, 7 Dec 2002 10:25:56 +0000
Subject: Re: [beanutils] moving reflection classes out of beanutils
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
From: robert burrell donkin <robertburrelldonkin@blueyonder.co.uk>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Content-Transfer-Encoding: 7bit
In-Reply-To: <ass6ic$ncq$1@main.gmane.org>
Message-Id: <4574FC54-09CE-11D7-8138-003065DC754C@blueyonder.co.uk>


On Saturday, December 7, 2002, at 06:59 AM, Costin Manolache wrote:

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

the plan was to separate out just the reflection utilities leaving 
beanutils focused exclusively on introspection. digester (for example) 
would still need to use beanutils for introspection but may want to 
migrate to the improved reflection utilities.

the critical flaw with the old MethodUtils API is that the method 
contracts are not written in a way that makes it clear what are bugs and 
what aren't. fixing this will mean changing the method symantics. the 
reflection methods will work better but differently. i'd say that's a good 
reason for making it version 2.0.

components using beanutils expect that MethodUtils should work to the java 
language specification. users who use MethodUtils directly rely on the 
method descriptions. they can quite reasonable rely on a feature of the 
current code which deviates from the correct behaviour (as far as the 
other components are concerned).

the flaw also makes it impossible to create comprehensive test cases.

- robert


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>