On Saturday, November 2, 2002, at 10:34 AM, Stephen Colebourne wrote: <snip>
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.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 ;-)
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: <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
