commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [lang] MethodUtils
Date Sat, 02 Nov 2002 09:58:25 GMT
On Saturday, November 2, 2002, at 05:40 AM, Craig R. McClanahan wrote:
> On Fri, 1 Nov 2002, robert burrell donkin wrote:


>> 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.
> I have a very strong piece of advice for the [lang] developers (which,
> among other things, will be translated into a -1 on any attempt to convert
> [beanutils] to depend on a [lang] implementation that doesn't correspond
> to the expectations outlined below).
> If the *default* method resolution for picking the correct method is
> different from the default resolution that the Java compiler does for
> figuring out which method to call for hard-coded method references, I
> would suggest that that the resolution algorithm is totally broken and
> should be rejected out of hand.  There is no reason to expect users of
> [lang] to expect anything different from this.
> It doesn't matter any more if it makes sense or not -- this is the Java
> world as it really exists.  Deal with it, or plan on being ignored.
> If the available non-default algorithms work on some more "sane" or
> "rational" algorithms (from our point of view as library developers), that
> is fine -- as long as the user has to *deliberatey* choose to be different
> from what the normal expectations would be.

some good points strongly made. i think that's helped to clarify some 
things for me.

i'm not sure that the lang API should end up with a default method - just 
a range of clearly defined ones. components using the library should pick 
the one which is most appropriate.

from a beanutils and digester perspective, i wouldn't give users the 
choice - i'd say that compiler equivalence is definitely what's needed. so 
those components should use the compiler equivalent methods in the API.

one major problem with the current MethodUtil's implementation is that it'
s aims are fuzzy. the aim should have been to find methods exactly as the 
compiler does. in practice, i suspect that the workarounds for the bugs in 
reflection implementations may mean that some methods which shouldn't be 
found, are found. we've also got some methods in there that allow users to 
rely on the reflection ideosyncracies of whatever JVM they're currently 
running on. this (with hindsight) was probably a poor idea.

so i'd like a cleaner and clearer API.

if beanutils finds either more or less methods than the compiler would, 
then IMHO both cases are equally buggy. but this isn't clear in the 
current API. the current situation allows users quite reasonably to rely 
on behaviour that should IMHO be buggy (ie replying on beanutils to find 
methods which wouldn't be found by the compiler).

how does this sound to everyone?

- robert

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message