commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [beanutils] moving reflection classes out of beanutils
Date Sat, 07 Dec 2002 09:50:37 GMT

On Friday, December 6, 2002, at 06:51 PM, Costin Manolache wrote:

> scolebourne@btopenworld.com wrote:
>
>>>  from:    Jeff  Robertson <Jeff.Robertson@magnetbanking.com>
>>>> From: Rodney Waldhoff [mailto:rwaldhoff@apache.org]
>>> Costin> If duplication is a concern - then just use
>>> Costin> beanutils ( however duplication is explicitely
>>> Costin> allowed in commons AFAIK).
>>>
>>> Robert> i've been convinced that beanutils is
>>> Robert> not the right place for this code.
>>>
>>> Rodney> And I'm convinced that lang isn't the right place either.  Let'
>>> s
>>> split the
>>> Rodney> difference and propose commons-reflect or commons-reflection or
>>> whatever,
>>> Rodney> and end this thread.
>>>
>> Jeff> As I think several people have pointed out, isn't that what "clazz"
>> is Jeff> supposed to be?
>>
>> No. [clazz] is high level pluggable introspection.
>
>
> Please stop this nonsense "where it should be".
>
> Code will be where people write it - if someone wants to write and 
> maintain
> reflection code in clazz, do so. Same for lang, beanutils, ant or tomcat.
> If you don't want to maintain the reflection code in beanutils - don't.

there is a very strong argument for sharing basic reflection code. that's 
why people are interested in finding the best place for it.

the sun reflection code (pre java 1.4 at least) is very buggy. components 
that rely on reflection need to have a reliable set of utilities with 
workarounds for these bugs. these need to be well tested and reliable 
since more complex introspection/introspection alternative system are 
going to be built on top.

sharing these components means that a bug can be fixed in one place rather 
than five or six. bugs and workarounds found will benefit all components 
which use reflection.

it means that users can be directed to a single canonical version. the 
effort which would have gone into maintaining duplicate versions can be 
used to create comprehensive unit tests so that we don't get so many bugs 
to fix.

duplication means supporting different versions each with their own 
particular bugs. users will have to shop around for a version that has the 
fixes in that they need.

- robert


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


Mime
View raw message