I have looked at the algorithm with which Vel selects among overloaded methods. It is unfortunately kludgy, overcomplicated, and -- which is the biggest problem -- incomplete. It has a FIXME comment that it should be improved to deal with interfaces. Also, it doesn't honor the fact that in reflective method calls an argument of primitive type is represented by an object of the corresponding object type, so a java.lang.Boolean can be passed to a method that expects primitive boolean. There are also widening primitive conversions that should be taken into account when selecting the correct overloaded method (a java.lang.Integer can be passed wherever a primitive int can be passed, and that includes methods that expect primitive int, long, float, and double parameters due to widening conversions).
The JLS has a very clear algorithm (described in section 15.12.2, amended by section 5.3) for selecting the most specific applicable method from all available overloaded methods. I have implemented that algorithm few days back in Freemarker, it works like champ and actually deals with interfaces, primitive-to-object assignments and primitive widening conversions. Beside, the code turned out to be quite elegant as well. I would be happy to rework Velocity's overloaded method selector as well if there's a need for it. Note that this is not a "don't fix if it ain't broken" situation since I consider it *is* broken in the sense that there are situations described above it just doesn't handle. Opinions? -- Attila Szegedi home: http://www.szegedi.org -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
