commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertdon...@mac.com>
Subject Re: [Reflect] Summary of points and relationship with BeanUtils
Date Wed, 19 Jun 2002 21:23:49 GMT

On Wednesday, June 19, 2002, at 09:40 PM, Michael A. Smith wrote:

> On Wed, 19 Jun 2002, Stephen Colebourne wrote:
>>> therefore
>>> code cannot be refactored from existing released components into the
>>> sandbox.
>>
>> I think this is a timing issue. Promoting Lang to Commons will probably 
>> only
>> occur when Lang is ready for a release. But, for Lang to be ready for a
>> release it would need to already have the low level reflection code in 
>> it.
>> Chicken and egg.
>
> I haven't followed this thread too closely, but I'm not sure where the
> chicken and egg are.  Rather than *moving* the code to lang, you can
> *copy* it.

-1

i'm personally very concerned about duplicating this particular code. it's 
complex and took a long time to get anywhere near reasonably debugged. 
(this is where this thread started.)

i think that - in principal - branching the low level introspection 
utility code is a very bad idea and would consider vetoing any proposal 
which split the low level introspection code base.

> Then, BeanUtils or whatever can still depend on its own
> version until the lang version is released.  Then, BeanUtils can update
> (when they're ready) to use the new version that exists in the released
> version of lang, assuming, of course, that the version in lang is as
> good, or better, than the version already in BeanUtils.

unfortunately, there'd be no good way to compare the two competing bodies 
of code.

i'd be very reluctant to allow any component i'm involved with to switch 
from a well tested code base to a new relatively untested one. also for 
compatibility reasons, i'd have to think hard about allowing the two 
different competing low level introspection code bases to be used by the 
same component. this has unfortunate consequences for stephen's aims.

we'd hoped to find some way around these problems. stephen's plan was to 
aim to move the code that would need to be shared into some neutral 
component which could be shared between the various higher level 
reflection/introspection components. this neutral component needs to be in 
the commons and needs to be released (or have a release planned) so that 
the existing components can depend on it.

this plan would allow the newer higher level components to grow and 
experiment in the sandbox without having to depend on benautils or on 
having to branch the low level introspection code base.

- 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