I'm not talking about method matching. I'm talking about data type in general. Double data and decimal data are intrinsically different, and Hive shouldn't implicit convert from one to the other. An an example, let's say there is a UDF just returns the input and it only has "double evaluate(double input)" defined. For this, if user passes decimal input to the UDF, hoping to get its decimal number back. In this case, I'd argue that Hive should return an error rather than converting the input to a double and return it. I'd also contend the reverse is also true. GenericUDF overcomes the shortcomings of UDF, where everything becomes explicit.
I thought the point of FunctionRegistry.getMethodInternal() was to find best matching method signature given the arguments, while doing type conversion if necessary.
Yes, that's what hive is doing, but it doesn't mean in order to find a match, any conversion can be performed. And the conversion is implicit. I was arguing that conversion between double and decimal should be explicit. Thus, when finding a match, Hive shouldn't treat double and decimal exchangeable, regardless whether hive is actually doing it or not.
I don't know what this debate is leading to, but Hive has the problem as described in the JIRA and I'm solving it. If you have any feedback, I'd be happy to see it once you actually see the solution.