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: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
|