commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [lang] MethodUtils
Date Sat, 02 Nov 2002 10:34:15 GMT
I agree, with Craig's position. So far I have looked only at the FieldUtils.
What I found was that 1.3 reflection was badly broken, and 1.4 still had a
few oddities. The problem lay with the getField() method. getDecleredField()
was fine.

Thus the only way I can see to replicate hard coded method references is to
write the JLS algorithms ourselves. This is what I tried to do in
FieldUtils. However I must point out that I didn't re-read the JLS, or write
tests. I just worked empirically. So please don't rely on FieldUtils at this
(I put the classes in lang proper not because they were finished, but to
gain more eyeballs and effort ;-)

In addition to the main lookup as a hard coded reference would, I added the
ability to find the 'first match' irrespective of scope, using the
setAccessible() method to gain access. This is a specific boolean flag
choice to use however, so its additional power not less or a default.

Of course the net result of the above is that the lang version might work
differently from the beanutils one if the beanutils one doesn't follow the
JLS. I reckon thats a beanutils issue to solve ;-)


PS. Note that the main problem I had was where a private field in a
superclass should hide a public field in a super-super-class but didn't (in
1.3 reflection).

> On Saturday, November 2, 2002, at 05:40 AM, Craig R. McClanahan wrote:
> > 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),
> > is fine -- as long as the user has to *deliberatey* choose to be
> > from what the normal expectations would be.

> > On Fri, 1 Nov 2002, robert burrell donkin wrote:
> 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:

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

View raw message