db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-3069) Derby does not resolve functions bound to methods with varargs.
Date Mon, 10 Dec 2012 15:09:22 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Rick Hillegas updated DERBY-3069:

    Attachment: derby-3069-05-aa-executeVarargs.diff

Attaching derby-3069-05-aa-executeVarargs.diff. This patch wires in bind() and generate()
logic for vararg routines so that they can now be invoked. Many more tests need to be written
but this patch supplies some initial test cases for invoking vararg routines. I am running
regression tests now.

Touches the following files:


M       java/engine/org/apache/derby/iapi/services/loader/Java5ClassInspector.java
M       java/engine/org/apache/derby/iapi/services/loader/ClassInspector.java

Added a method to introspect whether a Java method is a varargs method.


M       java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java

Fixed a comment and the declaration of the pi() system method.


M       java/engine/org/apache/derby/impl/sql/compile/MethodCallNode.java
M       java/engine/org/apache/derby/impl/sql/compile/NewInvocationNode.java
M       java/engine/org/apache/derby/impl/sql/compile/StaticMethodCallNode.java

A couple changes:

1) For a varargs routine, at bind() time coerce the trailing invocation parameters to the
declared type of the varargs argument. This involved factoring out the coercion logic into
a separate method: coerceMethodParameter().

2) For a varargs routine, at generate() time stuff the trailing, coerced invocation parameters
into an array, which is the actual generated vararg argument. This involved factoring the
parameter-generating logic into a separate method: generateAndCastOneParameter().

I also changed the formatting of the unreadable code I was touching and corrected one of my
pet peeves: putting brackets around one-line consequences of "if" statements. This makes the
changes to these classes look more substantial.


A       java/testing/org/apache/derbyTesting/functionTests/tests/lang/VarargsRoutines.java
M       java/testing/org/apache/derbyTesting/functionTests/tests/lang/build.xml
M       java/testing/org/apache/derbyTesting/functionTests/tests/lang/VarargsTest.java

More tests.

> 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:,,,,,,,
>            Reporter: Rick Hillegas
>            Assignee: Rick Hillegas
>              Labels: derby_triage10_10
>         Attachments: derby-3069-01-varargs-aa.diff, derby-3069-01-varargs-ab.diff, derby-3069-02-backout.diff,
derby-3069-03-aa-varargsSyntax.diff, derby-3069-03-ab-varargsSyntax.diff, derby-3069-04-aa-shortenRoutineNamesInUpgradeTest.diff,
derby-3069-05-aa-executeVarargs.diff, Varargs.html, 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message