You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Costin Manolache <cm...@yahoo.com> on 2002/12/06 16:41:08 UTC
Re: [beanutils] moving reflection classes out of beanutils
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
problems.
> 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.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by robert burrell donkin <ro...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Saturday, December 7, 2002, at 09:32 PM, Henri Yandell wrote:
<snip>
> So... we let Robert/Stephen/others finish up with reflect in lang while
> copying across modifications that occur to those areas in beanutils...
unfortunately, the modifications and fixes can't be copied across.
the public API of the MethodUtils in beanutils is not precisely defined
enough to allow this. we need a new API which has precise, testable method
definitions so that it's clear what a bug is.
> then we have big argument then? :)
true
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 6 Dec 2002, Costin Manolache wrote:
> Craig R. McClanahan wrote:
>
> 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.
>
Because reflection and beans are different things. Many things will want
to do reflection, but won't have any interest in some form of bean API.
The same holds for BeanUtils' Convertor system. Many things will want to
use this, but have no interest in Beans.
Having to deal with a library which is created with a context of JavaBeans
means that the Convertor and Reflection APIs will be tainted by this
context.
> > 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.
Yep. And ConstructorUtils/MethodUtils are outside the scope of BeanUtils
in my view, even if the PROPOSAL does provide some mention of
reflection/introspection utilities.
> 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.
Agreed. It's always better to debate a piece of code when it's sitting and
ready for inclusion in a particular library somewhere, especially with
something like reflection where it's pretty independent of the surrounding
library.
So... we let Robert/Stephen/others finish up with reflect in lang while
copying across modifications that occur to those areas in beanutils...
then we have big argument then? :)
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by Costin Manolache <cm...@yahoo.com>.
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.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 6 Dec 2002, Costin Manolache wrote:
> 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.
Nothing illegal with 2 versions anyway. If there are duplicate versions,
with no difference in religion between those versions, I would question
the rightness. Especially if it came from the same 'group' of developers.
[Not that I'm stating that Commons is a group of developers in any way]
> >> 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.
So work stops on beanutils and BeanUtilsTNG is created? Why can't it be
removed? I agree that such a removal should imply a large version number
change, ie) BeanUtils 2.0, but what states that Commons libraries have to
follow slow-release deprecation methods?
> This start to look like dependency spaghetti to me, and it does create
> problems.
Yep. Reality is we are going to have N libraries with M dependencies,
where N and M will only get bigger at a rate slightly faster than we can
manage it.
Do we need to have a common plan in Commons? Or do we do our best to
ensure there are no dependencies between projects, ie) each one is
stand-alone and has some kind of copying system for internal function
calls [ie) we copy the jar, change the bytecode to a different package
name, an obfuscated one].
> > 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.
While this kind of view is an important one to have in the community [as
detailed in a long thread on jakarta-general or apache-community] in that
it helps to deal with potential forking and potential project-death, it
does seem that the philosophy should be to work together until such a
point as working together is not possible, and then to allow the
community-healing mores to come into play.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 6 Dec 2002, Costin Manolache wrote:
> Date: Fri, 06 Dec 2002 07:41:08 -0800
> From: Costin Manolache <cm...@yahoo.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: commons-dev@jakarta.apache.org
> Subject: Re: [beanutils] moving reflection classes out of beanutils
>
> 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
> problems.
>
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).
>
> > 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.
>
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.
> Costin
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>