You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Tim Kuntz (JIRA)" <de...@velocity.apache.org> on 2010/01/28 02:28:34 UTC

[jira] Created: (VELOCITY-753) IntrospectionUtils.isMethodInvocationConvertible() returns true for NumberFormat.format(double) method with a Float.class argument

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


[jira] Commented: (VELOCITY-753) IntrospectionUtils.isMethodInvocationConvertible() returns true for NumberFormat.format(double) method with a Float.class argument

Posted by "Nathan Bubna (JIRA)" <de...@velocity.apache.org>.
    [ 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org


[jira] Resolved: (VELOCITY-753) IntrospectionUtils.isMethodInvocationConvertible() returns true for NumberFormat.format(double) method with a Float.class argument

Posted by "Nathan Bubna (JIRA)" <de...@velocity.apache.org>.
     [ https://issues.apache.org/jira/browse/VELOCITY-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nathan Bubna resolved VELOCITY-753.
-----------------------------------

       Resolution: Fixed
    Fix Version/s: 2.0
                   1.7

> 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
>             Fix For: 1.7, 2.0
>
>
> 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org