[
https://issues.apache.org/jira/browse/VELOCITY-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851252#action_12851252
]
Nathan Bubna commented on VELOCITY-753:
---------------------------------------
Ok, the key problem here is that $numberFormatter.format($aFloat) should work.
The catch is that in reflection-land (where Velocity lives), actual arguments
are always objects. In other words, in Java, if you call
numberFormat.format(aFloat), it will call the object method, because aFloat
doesn't convert to a double. But, in reflection-land, Float is
indistinguishable from float. So, format(double) and format(Object) are both
applicable. Right now, it considers the preference between those ambiguous,
with some abstract validity but ultimately wrongly in practice.
The good news is that i can fix that. The quasi-bad news is that resolving
the ambiguity means identifying the most-specific of the two: format(double).
The end result is that numberFormat.format(aFloat) in Java will call a
different method than $numberFormat.format($aFloat) in Velocity. In this
particular case, that shouldn't matter. However, it certainly could matter in
some other corner cases. Still, it would not make sense to call
format(Object) more specific than format(double) or even equivalently specific,
so i'm pretty sure this is the right thing to do.
For those interested in the details, when comparing two parameter types in
different applicable methods, i am now always considering Object.class
parameters to be less specific than anything else, which i think is pretty much
the case in reflection-land where things are always Objects. Please yell at
me if that is a terrible idea. :)
> IntrospectionUtils.isMethodInvocationConvertible() returns true for
> NumberFormat.format(double) method with a Float.class argument
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: VELOCITY-753
> URL: https://issues.apache.org/jira/browse/VELOCITY-753
> Project: Velocity
> Issue Type: Bug
> Components: Engine
> Affects Versions: 1.6.2
> Reporter: Tim Kuntz
>
> NumberFormat has both a format(double) and format(Object) method. When
> evaluated against a Float, IntrospectionUtils is returning true. This causes
> Method.getBestMatch() to throw an AmbigouusException.
> I have included a failing test case below to show this issue.
> Thanks,
> Tim
> import java.io.StringReader;
> import java.io.StringWriter;
> import java.text.NumberFormat;
> import junit.framework.TestCase;
> import org.apache.velocity.VelocityContext;
> import org.apache.velocity.app.Velocity;
> public class VelocityFormatTest extends TestCase {
> public void test_format_of_float() throws Exception {
> // verify format() outside of Velocity
> NumberFormat numberFormat = NumberFormat.getInstance();
> Float aFloat = new Float(5.23);
> assertEquals("5.23", numberFormat.format(aFloat));
> Velocity.init();
> VelocityContext context = new VelocityContext();
> context.put("numberFormatter", numberFormat);
> context.put("aFloat", aFloat);
> StringWriter sw = new StringWriter();
> StringReader sr = new StringReader(
> "float value is
> ${numberFormatter.format($aFloat)}");
> Velocity.evaluate(context, sw, "name", sr);
> String expectedValue = "float value is 5.23";
> assertEquals(expectedValue, sw.toString());
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
