On Saturday, December 7, 2002, at 06:59 AM, Costin Manolache wrote:
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.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 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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
