On Friday, November 1, 2002, at 08:59 AM, Stephen Colebourne wrote:
(presumably, 'Match on class and superclasses' includes superinterfaces)From: "robert burrell donkin" <[EMAIL PROTECTED]>I wanted to ensure that the API allowed a choice between the four options Ii've taken a quick look and you've made quite a few changes. any pointers you'd like to give me about these changes?
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
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)
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.i've noticed that you've commented out the invokeMethod implementation. myI was going to see if that commented out code did the same thing for Methods
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)?
that I had coded for Fields.
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>
