Jochen Wiedmann (JIRA) wrote:
I apologize, but I am unhappy with the overloading.
While I accept, that it might be suitable in certain situations, I do not think
that it should be the default.
Well, I very much disagree. I believe that overloading is an inherent
and very useful part of the Java programming language, and that any
library that purports to make a java class's methods available over some
external mechanism should support it to the maximum degree possible.
> In particular, I do not think that the selection of the right method
> via reflection should occur with any method invocation. That's
> something we had in version 2 and have just successfully managed to
> get rid of.
Hmm, an interesting point, although not one I feel is sufficient to
justify discarding support for a feature common to both the Java
language and the XML-RPC protocol.
IMO, the AbstractReflectiveHandlerMapping should support a single
> method per name only. There is no reason for not adding more
> complicated subclasses, if you like that.
I don't like this approach, because that means that any existing
subclasses of AbstractReflectiveHandlerMapping lose the option of
supporting reflection, short of subclassing those, too.
Rather, if you really feel that reflection is a negative, why not add a
mechanism for choosing to use it within
AbstractReflectiveHandlerMapping, and disable it by default? If it is
done by a public setter method, then minimal additional work in
subclasses would be required to support both options. Different
handlers could be constructed based on the setting of a field, so that
reflective overhead is not added when overloading is disabled.
-Walter
