[ https://issues.apache.org/jira/browse/FLINK-5826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15871338#comment-15871338 ]
Zhuoluo Yang commented on FLINK-5826: ------------------------------------- I have already made a small modification in {code}UserDefinedFunctionUtils.getSignature(){code}. The basic idea is that we let the "Object..." and "Any*" pass and return the corresponding signature. This modification works for Java only. The Scala will fail. Since the code generation is to generate a Java codes, There will be some problem call {code} eval(Seq<Any>) {/code} in generated Java. However, there will be no problem at all in calling {code}eval(Object... args}{code} in generated Java. > UDF/UDTF should support variable types and variable arguments > ------------------------------------------------------------- > > Key: FLINK-5826 > URL: https://issues.apache.org/jira/browse/FLINK-5826 > Project: Flink > Issue Type: Improvement > Reporter: Zhuoluo Yang > Assignee: Zhuoluo Yang > > In some cases, UDF/UDTF should support variable types and variable arguments. > Many UDF/UDTF developers wish to make the # of arguments and types flexible > to users. They try to make their functions flexible. > Thus, we should support the following styles of UDF/UDTFs. > for example 1, in Java > {code:java} > public class SimpleUDF extends ScalarFunction { > public int eval(Object... args) { > // do something > } > } > {code} > for example 2, in Scala > {code} > class SimpleUDF extends ScalarFunction { > def eval(args: Any*): Int = { > // do something > } > } > {code} > If we modify the code in UserDefinedFunctionUtils.getSignature() and make > both signatures pass. The first example will work normally. However, the > second example will raise an exception. > {noformat} > Caused by: org.codehaus.commons.compiler.CompileException: Line 58, Column 0: > No applicable constructor/method found for actual parameters > "java.lang.String"; candidates are: "public java.lang.Object > test.SimpleUDF.eval(scala.collection.Seq)" > at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:11523) > ~[janino-3.0.6.jar:?] > at > org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:8679) > ~[janino-3.0.6.jar:?] > at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:8539) > ~[janino-3.0.6.jar:?] > {noformat} > The reason is that Scala will do a sugary modification to the signature of > the method. The mothod {code} def eval(args: Any*){code} will become > {code}def eval(args: scala.collection.Seq<Any>){code} in the class file. > The code generation has been done in Java. If we use java style > {code}eval(Object... args){code} to call the Scala method, it will raise the > above exception. > However, I can't always restrict users to use Java to write a UDF/UDTF. Any > ideas in variable types and variable arguments of Scala UDF/UDTFs to prevent > the compilation failure? -- This message was sent by Atlassian JIRA (v6.3.15#6346)