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: [lang] MethodUtils
Date Fri, 01 Nov 2002 18:36:42 GMT

On Friday, November 1, 2002, at 08:59 AM, Stephen Colebourne wrote:

> From: "robert burrell donkin" <robertburrelldonkin@blueyonder.co.uk>
>> i've taken a quick look and you've made quite a few changes. any pointers
>> you'd like to give me about these changes?
>
> I wanted to ensure that the API allowed a choice between the four options 
> I
> could find:
> Match on specified class only   vs  Match on class and superclasses
> Match on public methods/fields  vs  Match on any field made accessible via
> setAccessible

(presumably, 'Match on class and superclasses' includes superinterfaces)

but that sounds like the right way to write the API. one of the weaknesses 
of MethodUtil's is that the API grew rather than being designed.

> The biggest problem is with the public methods/fields version, because 
> Java
> reflection in 1.3 Sun gives the wrong answers to getField() and getMethod(
> )
> in certain circumstances. (See previous threads - reflection how accurate)

yep. MethodUtils really grew as result of this problem.

(but i didn't know that (all of?) these problems were fixed in java 1.4)

>> i've noticed that you've commented out the invokeMethod implementation. 
>> my
>> first job will be to get that working about. are there any modifications
>> that you need me to make to the commented out code (or is it just a case
>> of get it working again)?
>
> I was going to see if that commented out code did the same thing for 
> Methods
> that I had coded for Fields.

the major aim of the code was to address the problems with finding methods 
by name which you pointed out above. maybe i'll take a look and see how it 
compares with yours.

the algorithm is currently slow and should be rewritten to make it more 
efficient.

what i'd like to do first, though, is just switch the old one back on and 
copy the test cases from beanutils into lang. that should insure that we 
don't lose functionality if the algorithm is changed or replaced.

if most of the problems solved by MethodUtils are fixed in java 1.4, then 
it's important to keep testing on older JVMs. (i'm running 1.3 at the 
moment so that shouldn't be a big problem.)

>> one of the consequences of MethodUtils being in lang is that lang can't
>> depend on commons-logging. i found that without logging, it's nearly
>> impossible to debug some things.
>>
>> what i'd like to do is add a debug boolean and a log method (probably 
>> both
>> private) that logs messages to System.out. this would allow debugging
>> calls to remain in place *but* we'd have to remember to switch the flag
>> back off before committing. is that ok with you?
>
> I am -1 for [lang] to depend on [logging], thus this is the best solution.
> System.err might be better however.

ok, i'll make it System.err.

- 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