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 stage! (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 ;-) Stephen 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), that > > is fine -- as long as the user has to *deliberatey* choose to be different > > 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: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org> > -- To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
