[
https://issues.apache.org/jira/browse/DERBY-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531590
]
Daniel John Debrunner commented on DERBY-3069:
----------------------------------------------
Thanks Rick, some questions based upon this:
1) When Java resolves to methods with varargs it's a two phase process, so that
if a non-varargs method that matches the arguments exists, it takes precedence
over any varargs methods that matches the arguments. It seems with what you are
describing this paradigm is not followed, which means that the presence of a
varargs method could break an existing application once this improvement is
enabled. One extreme case of this is the method foo(T ...) for any type T will
cause failure when the Java routine with no parameters previously mapped to
foo().
Is this potential to break existing applications intentional, or should the
method resolution follow something similar to Java's two stage process?
http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.12
2) Any issues with INOUT or OUT parameters that end up being mapped to the
varargs? Especially for how the implementation of the varargs method would
access the INOUT/OUT parameters?
3) How about varargs with DYNAMIC RESULT SETS, can the return of the
ResultSet's be through a varargs parameter? I assume not.
4) Java's limitation to a single varargs argument in the last position leads to
a somewhat strange situation. A procedure with multiple SQL parameters of the
same type can map to a varargs method only when DYNAMIC RESULT SETS is zero.
> Derby does not resolve functions bound to methods with varargs.
> ---------------------------------------------------------------
>
> Key: DERBY-3069
> URL: https://issues.apache.org/jira/browse/DERBY-3069
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1,
> 10.2.1.6, 10.2.2.0, 10.3.1.4
> Reporter: Rick Hillegas
> Assignee: Rick Hillegas
> Attachments: derby-3069-01-varargs-aa.diff,
> derby-3069-01-varargs-ab.diff, z.java, z.sql
>
>
> Varargs were added in Java 5. It would be nice if Derby let you invoke a
> function bound to a method with a variable length argument list. The
> Reference Guide states a small number of restrictions for methods which can
> be invoked as Derby functions: They must be public, static, and not have
> arguments which are long datatypes. I see no reason that Derby shouldn't be
> able to resolve and invoke functions which are bound to methods which don't
> suffer these limitations but which have variable argument lists.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
