Re: [lang] MethodUtils

[robert burrell donkin <ro...@blueyonder.co.uk>]

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

> From: "robert burrell donkin" <ro...@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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] MethodUtils

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Saturday, November 2, 2002, at 01:41 PM, Stephen Colebourne wrote:

<snip>

>> my main issue with the current MethodUtils API is that it not precise in
>> it's definition of expected behaviour. the API does not say 'this methods
>> finds conforms to the JLS spec'. since these methods can be called
>> directly (rather than just as part of beanutils or digester where the
>> required behaviour is clear), this lack precision means that people may
>> rely on these features. therefore changing the algorithm might break 
>> their
>> code.
>
> The comments in [lang] MethodUtils etc. should be tightened. We offer the
> equivalent of:
>  getMethod() accessible
>  getDeclaredMethod() accessible
>  getMethod() ignoring scope
>  getDeclaredMethod() ignoring scope
>
> The first two should follow the JLS spec. The last two we get to define 
> what
> happens.

sounds good to me. we'd need to think clearly on the definition of those 
ignoring scope and get that fixed before we release. but, there's no 
reason why we'd need to wait until those were finished before releasing 
implementations for those following the JLS rules.

since we're most likely going to end up with a series of methods, any 
ideas about naming conventions?

one alternative to actually including them all in the same class might be 
split into two classes (possibly sharing common code). we might have 
PublicMethodUtils for those following the JLS rules and another class for 
those with looser scope (i can't think of a good name for that class right 
now).

- robert


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] MethodUtils

[Stephen Colebourne <sc...@btopenworld.com>]

From: "robert burrell donkin" <ro...@blueyonder.co.uk>
> i don't want to support two implementations. i want to create a correct
> implementation in lang that can be used by beanutils and digester. then i
> can deprecate the MethodUtils in beanutils and leave it to rot.
+1

> my main issue with the current MethodUtils API is that it not precise in
> it's definition of expected behaviour. the API does not say 'this methods
> finds conforms to the JLS spec'. since these methods can be called
> directly (rather than just as part of beanutils or digester where the
> required behaviour is clear), this lack precision means that people may
> rely on these features. therefore changing the algorithm might break their
> code.

The comments in [lang] MethodUtils etc. should be tightened. We offer the
equivalent of:
 getMethod() accessible
 getDeclaredMethod() accessible
 getMethod() ignoring scope
 getDeclaredMethod() ignoring scope

The first two should follow the JLS spec. The last two we get to define what
happens.

Stephen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] MethodUtils

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Saturday, November 2, 2002, at 10:34 AM, Stephen Colebourne wrote:

<snip>

> 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 ;-)

i don't want to support two implementations. i want to create a correct 
implementation in lang that can be used by beanutils and digester. then i 
can deprecate the MethodUtils in beanutils and leave it to rot.

the big problem is with class.getMethod(). this is very badly broken (in 
many JVM's) and does not conform to the JLS (compiler) spec. beanutils and 
other components require reflection that conforms to the JLS spec rather 
than whatever reflection rules various JVM happen to have.

MethodUtil's was factored out from other classes to contain code to cope 
with the bug reports we kept getting from people whose introspection 
failed. i think that the algorithm now finds most methods but might find 
too many.

my main issue with the current MethodUtils API is that it not precise in 
it's definition of expected behaviour. the API does not say 'this methods 
finds conforms to the JLS spec'. since these methods can be called 
directly (rather than just as part of beanutils or digester where the 
required behaviour is clear), this lack precision means that people may 
rely on these features. therefore changing the algorithm might break their 
code.

- robert


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] MethodUtils

[Stephen Colebourne <sc...@btopenworld.com>]

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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] MethodUtils

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Saturday, November 2, 2002, at 05:40 AM, Craig R. McClanahan wrote:
> On Fri, 1 Nov 2002, robert burrell donkin wrote:

<snip>

>> 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] MethodUtils

["Craig R. McClanahan" <cr...@apache.org>]

On Fri, 1 Nov 2002, robert burrell donkin wrote:

> Date: Fri, 1 Nov 2002 18:36:42 +0000
> From: robert burrell donkin <ro...@blueyonder.co.uk>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: [lang] MethodUtils
>
>
> On Friday, November 1, 2002, at 08:59 AM, Stephen Colebourne wrote:
>
> > From: "robert burrell donkin" <ro...@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.
>

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.

Craig McClanahan



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>