[jira] [Comment Edited] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[
https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15447782#comment-15447782
]
Andrew Garcia edited comment on GROOVY-7683 at 8/30/16 2:38 AM:
Linking to [Groovy-7623|https://issues.apache.org/jira/browse/GROOVY-7623] as
it claims to be a possible solution path to this memory leak issue.
was (Author: gsandrew):
Linking to[#Groovy-7623] as it claims to be a possible solution path to this
memory leak issue
> Memory leak when using Groovy as JSR-223 scripting language.
>
>
> Key: GROOVY-7683
> URL: https://issues.apache.org/jira/browse/GROOVY-7683
> Project: Groovy
> Issue Type: Bug
> Components: GroovyScriptEngine
>Affects Versions: 2.4.5
> Environment: OS: tested on Mac OS X El Capitan and Windows 10.
> JVM: tested on 1.8.0_60 and 1.8.0_65.
>Reporter: Arkadiusz Gasinski
> Labels: jsr-223
> Attachments:
> 0001-GROOVY-7683-replace-hard-reference-from-ClassInfo-to.patch, Screen Shot
> 2016-08-16 at 10.53.04 PM.png
>
>
> We have a Java EE 7 web application in production that when handling single
> HTTP request can load and execute up to several Groovy scripts using the
> jsr-223 API. This application is deployed to GlassFish 4.1 server cluster
> with 4 instances, each having 8 GB of RAM available (Xmx=8g). We have to
> restart them every couple of days (3-4), because of leaking memory. After
> analyzing a couple of heap dumps, our main suspect is Groovy with its
> MetaMethodIndex$Entry class (the below table shows the top object from one of
> the heap dumps).
> ||Class Name||Objects||Shallow Heap||Retained Heap||
> |MetaMethodIndex$Entry| 3 360 001 | 188 160 056 | >= 305 408 024
> To confirm our suspicions, I created simple Maven project with a single test
> case. The project is available on
> [GitHub|https://github.com/jigga/groovy-jsr223-leak]. The test case executes
> 10 different scripts (minimal differences) obtained from a single template
> 2 times in 64 worker threads (the main thread is put to sleep for 10
> seconds before starting worker threads, so that one can attach JVisualVM to
> the test process). After all threads are done, System.gc() is called to
> provoke full GC. Attaching to the process in which tests are run with
> JVisualVM reveals that the memory is not reclaimed.
> To run the test in your local environment, simply clone the
> [GitHub|https://github.com/jigga/groovy-jsr223-leak] project and run:
> {code}
> mvn test
> {code}
> The same test can be run with the *-Dlanguage=javascript* system option,
> which switches ScriptEngine from Groovy to Nashorn and uses slightly modified
> script template (only syntactical differences).
> {code}
> mvn -Dlanguage=javascript test
> {code}
> Running the test case using built-in Nashorn engine reveals no problems - all
> allocated memory is reclaimed after full GC.
> I know that the test case is run in Java SE environment, but I guess that it
> clearly reflects the issue. If it's not enough, I can create an arquillian
> test case.
> This may be a possible duplicate of
> [GROOVY-7109|https://issues.apache.org/jira/browse/GROOVY-7109].
> Any workarounds for this issue would be greatly appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[
https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15447782#comment-15447782
]
Andrew Garcia edited comment on GROOVY-7683 at 8/30/16 2:38 AM:
Linking to[#Groovy-7623] as it claims to be a possible solution path to this
memory leak issue
was (Author: gsandrew):
Linking to https://issues.apache.org/jira/browse/GROOVY-7623 as it claims to be
a possible solution path to this memory leak issue
> Memory leak when using Groovy as JSR-223 scripting language.
>
>
> Key: GROOVY-7683
> URL: https://issues.apache.org/jira/browse/GROOVY-7683
> Project: Groovy
> Issue Type: Bug
> Components: GroovyScriptEngine
>Affects Versions: 2.4.5
> Environment: OS: tested on Mac OS X El Capitan and Windows 10.
> JVM: tested on 1.8.0_60 and 1.8.0_65.
>Reporter: Arkadiusz Gasinski
> Labels: jsr-223
> Attachments:
> 0001-GROOVY-7683-replace-hard-reference-from-ClassInfo-to.patch, Screen Shot
> 2016-08-16 at 10.53.04 PM.png
>
>
> We have a Java EE 7 web application in production that when handling single
> HTTP request can load and execute up to several Groovy scripts using the
> jsr-223 API. This application is deployed to GlassFish 4.1 server cluster
> with 4 instances, each having 8 GB of RAM available (Xmx=8g). We have to
> restart them every couple of days (3-4), because of leaking memory. After
> analyzing a couple of heap dumps, our main suspect is Groovy with its
> MetaMethodIndex$Entry class (the below table shows the top object from one of
> the heap dumps).
> ||Class Name||Objects||Shallow Heap||Retained Heap||
> |MetaMethodIndex$Entry| 3 360 001 | 188 160 056 | >= 305 408 024
> To confirm our suspicions, I created simple Maven project with a single test
> case. The project is available on
> [GitHub|https://github.com/jigga/groovy-jsr223-leak]. The test case executes
> 10 different scripts (minimal differences) obtained from a single template
> 2 times in 64 worker threads (the main thread is put to sleep for 10
> seconds before starting worker threads, so that one can attach JVisualVM to
> the test process). After all threads are done, System.gc() is called to
> provoke full GC. Attaching to the process in which tests are run with
> JVisualVM reveals that the memory is not reclaimed.
> To run the test in your local environment, simply clone the
> [GitHub|https://github.com/jigga/groovy-jsr223-leak] project and run:
> {code}
> mvn test
> {code}
> The same test can be run with the *-Dlanguage=javascript* system option,
> which switches ScriptEngine from Groovy to Nashorn and uses slightly modified
> script template (only syntactical differences).
> {code}
> mvn -Dlanguage=javascript test
> {code}
> Running the test case using built-in Nashorn engine reveals no problems - all
> allocated memory is reclaimed after full GC.
> I know that the test case is run in Java SE environment, but I guess that it
> clearly reflects the issue. If it's not enough, I can create an arquillian
> test case.
> This may be a possible duplicate of
> [GROOVY-7109|https://issues.apache.org/jira/browse/GROOVY-7109].
> Any workarounds for this issue would be greatly appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[
https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15447782#comment-15447782
]
Andrew Garcia edited comment on GROOVY-7683 at 8/30/16 2:37 AM:
Linking to https://issues.apache.org/jira/browse/GROOVY-7623 as it claims to be
a possible solution path to this memory leak issue
was (Author: gsandrew):
Linking to Groovy-7623 as it claims to be a possible solution path to this
memory leak issue
> Memory leak when using Groovy as JSR-223 scripting language.
>
>
> Key: GROOVY-7683
> URL: https://issues.apache.org/jira/browse/GROOVY-7683
> Project: Groovy
> Issue Type: Bug
> Components: GroovyScriptEngine
>Affects Versions: 2.4.5
> Environment: OS: tested on Mac OS X El Capitan and Windows 10.
> JVM: tested on 1.8.0_60 and 1.8.0_65.
>Reporter: Arkadiusz Gasinski
> Labels: jsr-223
> Attachments:
> 0001-GROOVY-7683-replace-hard-reference-from-ClassInfo-to.patch, Screen Shot
> 2016-08-16 at 10.53.04 PM.png
>
>
> We have a Java EE 7 web application in production that when handling single
> HTTP request can load and execute up to several Groovy scripts using the
> jsr-223 API. This application is deployed to GlassFish 4.1 server cluster
> with 4 instances, each having 8 GB of RAM available (Xmx=8g). We have to
> restart them every couple of days (3-4), because of leaking memory. After
> analyzing a couple of heap dumps, our main suspect is Groovy with its
> MetaMethodIndex$Entry class (the below table shows the top object from one of
> the heap dumps).
> ||Class Name||Objects||Shallow Heap||Retained Heap||
> |MetaMethodIndex$Entry| 3 360 001 | 188 160 056 | >= 305 408 024
> To confirm our suspicions, I created simple Maven project with a single test
> case. The project is available on
> [GitHub|https://github.com/jigga/groovy-jsr223-leak]. The test case executes
> 10 different scripts (minimal differences) obtained from a single template
> 2 times in 64 worker threads (the main thread is put to sleep for 10
> seconds before starting worker threads, so that one can attach JVisualVM to
> the test process). After all threads are done, System.gc() is called to
> provoke full GC. Attaching to the process in which tests are run with
> JVisualVM reveals that the memory is not reclaimed.
> To run the test in your local environment, simply clone the
> [GitHub|https://github.com/jigga/groovy-jsr223-leak] project and run:
> {code}
> mvn test
> {code}
> The same test can be run with the *-Dlanguage=javascript* system option,
> which switches ScriptEngine from Groovy to Nashorn and uses slightly modified
> script template (only syntactical differences).
> {code}
> mvn -Dlanguage=javascript test
> {code}
> Running the test case using built-in Nashorn engine reveals no problems - all
> allocated memory is reclaimed after full GC.
> I know that the test case is run in Java SE environment, but I guess that it
> clearly reflects the issue. If it's not enough, I can create an arquillian
> test case.
> This may be a possible duplicate of
> [GROOVY-7109|https://issues.apache.org/jira/browse/GROOVY-7109].
> Any workarounds for this issue would be greatly appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7647) Incorrect line information for debug
[
https://issues.apache.org/jira/browse/GROOVY-7647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15447783#comment-15447783
]
Paul King commented on GROOVY-7647:
---
May or may not be related to GROOVY-4063.
> Incorrect line information for debug
>
>
> Key: GROOVY-7647
> URL: https://issues.apache.org/jira/browse/GROOVY-7647
> Project: Groovy
> Issue Type: Bug
> Components: class generator, Compiler
>Affects Versions: 2.4.5
>Reporter: Egor Ushakov
>
> Try to debug the code:
> {code}
> boolean boolVar = false; //line 15
> if (boolVar) { // set breakpoint here and step over //line 16
> print "ok"; //line 17
> } // end of file //line 18
> {code}
> It steps over to the line with print even though it is not executed.
> Seems that compiler does not generate line info for the last block (line 18):
> {code}
> public java.lang.Object run();
> descriptor: ()Ljava/lang/Object;
> flags: ACC_PUBLIC
> Code:
> stack=3, locals=3, args_size=1
> 0: invokestatic #18 // Method
> $getCallSiteArray:()[Lorg/codehaus/groovy/runtime/callsite/CallSite;
> 3: astore_1
> 4: iconst_0
> 5: istore_2
> 6: iload_2
> 7: pop
> 8: iload_2
> 9: ifeq 28
> 12: aload_1
> 13: ldc #41 // int 1
> 15: aaload
> 16: aload_0
> 17: ldc #43 // String ok
> 19: invokeinterface #47, 3 // InterfaceMethod
> org/codehaus/groovy/runtime/callsite/CallSite.callCurrent:(Lgroovy/lang/GroovyObject;Ljava/lang/Object;)Ljava/lang/Object;
> 24: areturn
> 25: goto 30
> 28: aconst_null
> 29: areturn
> 30: aconst_null
> 31: areturn
> LocalVariableTable:
> Start Length Slot Name Signature
> 0 30 0 this Lsdfklajsdlkjas/test;
> 6 24 2 boolVar Z
> LineNumberTable:
> line 15: 4
> line 16: 8
> line 17: 12
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[
https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15447782#comment-15447782
]
Andrew Garcia commented on GROOVY-7683:
---
Linking to Groovy-7623 as it claims to be a possible solution path to this
memory leak issue
> Memory leak when using Groovy as JSR-223 scripting language.
>
>
> Key: GROOVY-7683
> URL: https://issues.apache.org/jira/browse/GROOVY-7683
> Project: Groovy
> Issue Type: Bug
> Components: GroovyScriptEngine
>Affects Versions: 2.4.5
> Environment: OS: tested on Mac OS X El Capitan and Windows 10.
> JVM: tested on 1.8.0_60 and 1.8.0_65.
>Reporter: Arkadiusz Gasinski
> Labels: jsr-223
> Attachments:
> 0001-GROOVY-7683-replace-hard-reference-from-ClassInfo-to.patch, Screen Shot
> 2016-08-16 at 10.53.04 PM.png
>
>
> We have a Java EE 7 web application in production that when handling single
> HTTP request can load and execute up to several Groovy scripts using the
> jsr-223 API. This application is deployed to GlassFish 4.1 server cluster
> with 4 instances, each having 8 GB of RAM available (Xmx=8g). We have to
> restart them every couple of days (3-4), because of leaking memory. After
> analyzing a couple of heap dumps, our main suspect is Groovy with its
> MetaMethodIndex$Entry class (the below table shows the top object from one of
> the heap dumps).
> ||Class Name||Objects||Shallow Heap||Retained Heap||
> |MetaMethodIndex$Entry| 3 360 001 | 188 160 056 | >= 305 408 024
> To confirm our suspicions, I created simple Maven project with a single test
> case. The project is available on
> [GitHub|https://github.com/jigga/groovy-jsr223-leak]. The test case executes
> 10 different scripts (minimal differences) obtained from a single template
> 2 times in 64 worker threads (the main thread is put to sleep for 10
> seconds before starting worker threads, so that one can attach JVisualVM to
> the test process). After all threads are done, System.gc() is called to
> provoke full GC. Attaching to the process in which tests are run with
> JVisualVM reveals that the memory is not reclaimed.
> To run the test in your local environment, simply clone the
> [GitHub|https://github.com/jigga/groovy-jsr223-leak] project and run:
> {code}
> mvn test
> {code}
> The same test can be run with the *-Dlanguage=javascript* system option,
> which switches ScriptEngine from Groovy to Nashorn and uses slightly modified
> script template (only syntactical differences).
> {code}
> mvn -Dlanguage=javascript test
> {code}
> Running the test case using built-in Nashorn engine reveals no problems - all
> allocated memory is reclaimed after full GC.
> I know that the test case is run in Java SE environment, but I guess that it
> clearly reflects the issue. If it's not enough, I can create an arquillian
> test case.
> This may be a possible duplicate of
> [GROOVY-7109|https://issues.apache.org/jira/browse/GROOVY-7109].
> Any workarounds for this issue would be greatly appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GROOVY-6180) Type checker skip mode not always applied to anonymous inner classes
[ https://issues.apache.org/jira/browse/GROOVY-6180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-6180: -- Component/s: Static Type Checker > Type checker skip mode not always applied to anonymous inner classes > > > Key: GROOVY-6180 > URL: https://issues.apache.org/jira/browse/GROOVY-6180 > Project: Groovy > Issue Type: Bug > Components: Static Type Checker >Reporter: Cédric Champeau >Assignee: Cédric Champeau > Fix For: 2.1.4 > > > In some circumstances, the type checker would try to statically compile > anonymous inner class nodes even if the enclosing method is skipped. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (GROOVY-7037) getAt as Operator Throws if given Fixed and Variable Arguments
[
https://issues.apache.org/jira/browse/GROOVY-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15447137#comment-15447137
]
Paul King edited comment on GROOVY-7037 at 8/29/16 9:48 PM:
+1 for Jochen's workaround in your case.
I don't believe this is a regression. I tried the above examples on 1.8.9 and
get the same behavior.
The wrapping behavior seems very old too - before my time with Groovy it
appears. Looking through history there seems like a very old syntax {{s[1:2]}}
that was changed to allow either {{s[1,2]}} or {{s[1..2]}}. The former being
wrapped into a list, the latter not since it is already a list. I believe to
support fragments like:
{code}
def s = 'elephant'.toList()
assert s[7,5,1,1].join() == 'tall'
assert s[5..7].join() == 'ant'
assert s[4..5,7].join() == 'hat'
{code}
The final case wraps the range and single integer and then the DGM method
flattens them later.
was (Author: paulk):
+1 for Jochen's workaround in your case.
I don't believe this is a regression. I tried the above examples on 1.8.9 and
get the same behavior.
The wrapping behavior seems very old too - before my time with Groovy it
appears. Looking through history there seems like a very old syntax {{s[1:2]}}
that was changed to allow either {{s[1,2]}} or {{s[1..2]}}. The former being
wrapped into a list, the latter not since it is already a list. I believe to
support fragments like:
{code}
def s = 'elephant'.toList()
assert s[7,5,1,1].join() == 'tall'
assert s[5..7].join() == 'ant'
assert s[4..5,7].join() == 'hat'
{code}
The final case wraps the range and single integer and then flattens them.
> getAt as Operator Throws if given Fixed and Variable Arguments
> --
>
> Key: GROOVY-7037
> URL: https://issues.apache.org/jira/browse/GROOVY-7037
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.3.6, 2.4.0-beta-2
> Environment: RHEL 6.5 x64
>Reporter: Steve Amerige
>Priority: Minor
> Attachments: Test.groovy
>
>
> The getAt method for indexing fails when variable arguments are used with []
> if any fixed arguments are present. For example:
> {code}
> class Test
> {
>def getAt(String s) { return s }
>def getAt(String s, Integer x) { return "$s $x" }
>// def getAt(Object... o) { return o } // This would succeed
>def getAt(String s, Object... a) { return "$s $a" }
>static void main(String[] args)
>{
> Test t = new Test()
> assert t['a'] == 'a'
> assert t['b', 2] == 'b 2'
> assert t.getAt('c', 3, true) == 'c [3, true]'
> assert t['c', 3, true] == 'c [3, true]' // This throws an exception
>}
> }
> {code}
> The above produces:
> {noformat}
> Exception thrown
> java.lang.IllegalArgumentException: wrong number of arguments
> at Test.main(ConsoleScript42:14)
> {noformat}
> Workaround: do not use fixed and variable arguments at the same time and use
> only variable arguments as in the case shown commented out above:
> getAt(Object... o). This is less-than desirable, however, because it
> restricts the user from using method overloading to separate out
> distinctly-different logic and forces the user to do runtime checks and
> implement control structure when using the single varargs method. In this
> case, however, the bug severity is mitigated by the fact that the user can
> explicitly use the "getAt" invocation instead of using the [ ] operator
> notation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GROOVY-7037) getAt as Operator Throws if given Fixed and Variable Arguments
[
https://issues.apache.org/jira/browse/GROOVY-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15445582#comment-15445582
]
Paul King edited comment on GROOVY-7037 at 8/29/16 9:22 PM:
In some sense this isn't specific to {{getAt}}. Consider this code:
{code}
import static groovy.test.GroovyAssert.shouldFail
class Test {
def x(String s, Integer i) { "1:$s $i" }
def x(String s, Integer... is) { "2:$s $is" }
}
def t = new Test()
assert t.x('a', 1) == '1:a 1' // (1)
assert t.x('b') == '2:b []'// (2)
assert t.x('c', 2, 3) == '2:c [2, 3]' // (2)
assert t.x('d', 4, 5, 6) == '2:d [4, 5, 6]'// (2)
assert t.x(['e', 7]) == '1:e 7'// (3)
def ex = shouldFail(IllegalArgumentException) {
t.x(['f', 8, 9]) // (4)
}
assert ex.message == 'wrong number of arguments'
{code}
Groovy does normal argument matching, giving preference to non-varargs matches
(1) but matching varargs if needed (2).
Also, if a list argument is provided and no method with a list parameter is
found, an attempt is made to spread the list which matches if a method having
the correct number and types of arguments can be found (3). But in the case of
varargs, with a list argument, then the IllegalArgumentException can occur.
Unfortunately for the shorthand {{getAt}} syntax, the arguments are always
wrapped in a list, so the chances are higher of seeing this error. So, to
address this issue, we'd either have to make the list spreading logic smarter
for all methods or do some special hacking for getAt.
was (Author: paulk):
In some sense this isn't specific to {{getAt}}. Consider this code:
{code}
import static groovy.test.GroovyAssert.shouldFail
class Test {
def x(String s, Integer i) { "1:$s $i" }
def x(String s, Integer... is) { "2:$s $is" }
}
assert new Test().x('a', 1) == '1:a 1'// (1)
assert new Test().x('b') == '2:b []' // (2)
assert new Test().x('c', 2, 3) == '2:c [2, 3]'// (2)
assert new Test().x('d', 4, 5, 6) == '2:d [4, 5, 6]' // (2)
assert new Test().x(['e', 7]) == '1:e 7' // (3)
def ex = shouldFail(IllegalArgumentException) {
new Test().x(['f', 8, 9]) // (4)
}
assert ex.message == 'wrong number of arguments'
{code}
Groovy does normal argument matching, giving preference to non-varargs matches
(1) but matching varargs if needed (2).
Also, if a list argument is provided and no method with a list parameter is
found, an attempt is made to spread the list which matches if a method having
the correct number and types of arguments can be found (3). But in the case of
varargs, with a list argument, then the IllegalArgumentException can occur.
Unfortunately for the shorthand {{getAt}} syntax, the arguments are always
wrapped in a list, so the chances are higher of seeing this error. So, to
address this issue, we'd either have to make the list spreading logic smarter
for all methods or do some special hacking for getAt.
> getAt as Operator Throws if given Fixed and Variable Arguments
> --
>
> Key: GROOVY-7037
> URL: https://issues.apache.org/jira/browse/GROOVY-7037
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.3.6, 2.4.0-beta-2
> Environment: RHEL 6.5 x64
>Reporter: Steve Amerige
>Priority: Minor
> Attachments: Test.groovy
>
>
> The getAt method for indexing fails when variable arguments are used with []
> if any fixed arguments are present. For example:
> {code}
> class Test
> {
>def getAt(String s) { return s }
>def getAt(String s, Integer x) { return "$s $x" }
>// def getAt(Object... o) { return o } // This would succeed
>def getAt(String s, Object... a) { return "$s $a" }
>static void main(String[] args)
>{
> Test t = new Test()
> assert t['a'] == 'a'
> assert t['b', 2] == 'b 2'
> assert t.getAt('c', 3, true) == 'c [3, true]'
> assert t['c', 3, true] == 'c [3, true]' // This throws an exception
>}
> }
> {code}
> The above produces:
> {noformat}
> Exception thrown
> java.lang.IllegalArgumentException: wrong number of arguments
> at Test.main(ConsoleScript42:14)
> {noformat}
> Workaround: do not use fixed and variable arguments at the same time and use
> only variable arguments as in the case shown commented out above:
> getAt(Object... o). This is less-than desirable, however, because it
> restricts the user from using method overloading to separate out
> distinctly-different logic and forces the user to do runtime checks and
> implement control structure when using the single varargs method. In this
> case, however, the bug severity is mitigated by the fact that the user can
> explicitly use the "getAt"
[jira] [Commented] (GROOVY-7037) getAt as Operator Throws if given Fixed and Variable Arguments
[
https://issues.apache.org/jira/browse/GROOVY-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15446378#comment-15446378
]
Jochen Theodorou commented on GROOVY-7037:
--
almost forgot.. is it confirmed this is a regression?
> getAt as Operator Throws if given Fixed and Variable Arguments
> --
>
> Key: GROOVY-7037
> URL: https://issues.apache.org/jira/browse/GROOVY-7037
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.3.6, 2.4.0-beta-2
> Environment: RHEL 6.5 x64
>Reporter: Steve Amerige
>Priority: Minor
> Attachments: Test.groovy
>
>
> The getAt method for indexing fails when variable arguments are used with []
> if any fixed arguments are present. For example:
> {code}
> class Test
> {
>def getAt(String s) { return s }
>def getAt(String s, Integer x) { return "$s $x" }
>// def getAt(Object... o) { return o } // This would succeed
>def getAt(String s, Object... a) { return "$s $a" }
>static void main(String[] args)
>{
> Test t = new Test()
> assert t['a'] == 'a'
> assert t['b', 2] == 'b 2'
> assert t.getAt('c', 3, true) == 'c [3, true]'
> assert t['c', 3, true] == 'c [3, true]' // This throws an exception
>}
> }
> {code}
> The above produces:
> {noformat}
> Exception thrown
> java.lang.IllegalArgumentException: wrong number of arguments
> at Test.main(ConsoleScript42:14)
> {noformat}
> Workaround: do not use fixed and variable arguments at the same time and use
> only variable arguments as in the case shown commented out above:
> getAt(Object... o). This is less-than desirable, however, because it
> restricts the user from using method overloading to separate out
> distinctly-different logic and forces the user to do runtime checks and
> implement control structure when using the single varargs method. In this
> case, however, the bug severity is mitigated by the fact that the user can
> explicitly use the "getAt" invocation instead of using the [ ] operator
> notation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7037) getAt as Operator Throws if given Fixed and Variable Arguments
[
https://issues.apache.org/jira/browse/GROOVY-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15446375#comment-15446375
]
Jochen Theodorou commented on GROOVY-7037:
--
I think the error is actually in getAt the list wrapping was done because back
then we did not support vargs. I was not aware of the list wrapping here at
all. So to me the real error is the list wrapping and then method matching, and
depending on the automated list unwrap of Groovy. And the part to fix is the
list wrapping imho. This would be a breaking change of course. There is a
workaround for the problem I would like to propose:
{code}
def getAt(List l){ this.getAt(*l) }
{code}
this will call getAt again, as normal method, so it will properly dispatch for
you. The method would be called for any getAt with more than one argument. A
warning though, if you want to have a getAt that reacts to list, you will have
to have that logic here as well. And if you have a list containing itself, this
will probably result in a stack overflow
> getAt as Operator Throws if given Fixed and Variable Arguments
> --
>
> Key: GROOVY-7037
> URL: https://issues.apache.org/jira/browse/GROOVY-7037
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.3.6, 2.4.0-beta-2
> Environment: RHEL 6.5 x64
>Reporter: Steve Amerige
>Priority: Minor
> Attachments: Test.groovy
>
>
> The getAt method for indexing fails when variable arguments are used with []
> if any fixed arguments are present. For example:
> {code}
> class Test
> {
>def getAt(String s) { return s }
>def getAt(String s, Integer x) { return "$s $x" }
>// def getAt(Object... o) { return o } // This would succeed
>def getAt(String s, Object... a) { return "$s $a" }
>static void main(String[] args)
>{
> Test t = new Test()
> assert t['a'] == 'a'
> assert t['b', 2] == 'b 2'
> assert t.getAt('c', 3, true) == 'c [3, true]'
> assert t['c', 3, true] == 'c [3, true]' // This throws an exception
>}
> }
> {code}
> The above produces:
> {noformat}
> Exception thrown
> java.lang.IllegalArgumentException: wrong number of arguments
> at Test.main(ConsoleScript42:14)
> {noformat}
> Workaround: do not use fixed and variable arguments at the same time and use
> only variable arguments as in the case shown commented out above:
> getAt(Object... o). This is less-than desirable, however, because it
> restricts the user from using method overloading to separate out
> distinctly-different logic and forces the user to do runtime checks and
> implement control structure when using the single varargs method. In this
> case, however, the bug severity is mitigated by the fact that the user can
> explicitly use the "getAt" invocation instead of using the [ ] operator
> notation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GROOVY-7922) Static type checking not strict enough in the presence of ambiguous method matching
[
https://issues.apache.org/jira/browse/GROOVY-7922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-7922:
--
Description:
This example:
{code}
import groovy.transform.CompileStatic
interface FooA {}
interface FooB {}
class FooAB implements FooA, FooB {}
@CompileStatic
class TestGroovy {
static void test() { println new TestGroovy().foo(new FooAB()) }
def foo(FooB x) { 43 }
def foo(FooA x) { 42 }
}
TestGroovy.test()
{code}
Should probably throw some kind of ambiguous method error during compilation to
match Java (and dynamic Groovy's runtime error).
was:
This example:
{code}
import groovy.transform.CompileStatic
interface FooA {}
interface FooB {}
class FooAB implements FooA, FooB {}
@CompileStatic
class TestGroovy {
static void test() { println new TestGroovy().foo(new FooAB()) }
def foo(FooB x) { 43 }
def foo(FooA x) { 42 }
}
TestGroovy.test()
{code}
Should probably throw some kind of ambiguous method error during compilation to
match Java (and dynamic Groovy).
> Static type checking not strict enough in the presence of ambiguous method
> matching
> ---
>
> Key: GROOVY-7922
> URL: https://issues.apache.org/jira/browse/GROOVY-7922
> Project: Groovy
> Issue Type: Bug
>Reporter: Paul King
>
> This example:
> {code}
> import groovy.transform.CompileStatic
> interface FooA {}
> interface FooB {}
> class FooAB implements FooA, FooB {}
> @CompileStatic
> class TestGroovy {
> static void test() { println new TestGroovy().foo(new FooAB()) }
> def foo(FooB x) { 43 }
> def foo(FooA x) { 42 }
> }
> TestGroovy.test()
> {code}
> Should probably throw some kind of ambiguous method error during compilation
> to match Java (and dynamic Groovy's runtime error).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (GROOVY-7922) Static type checking not strict enough in the presence of ambiguous method matching
Paul King created GROOVY-7922:
-
Summary: Static type checking not strict enough in the presence of
ambiguous method matching
Key: GROOVY-7922
URL: https://issues.apache.org/jira/browse/GROOVY-7922
Project: Groovy
Issue Type: Bug
Reporter: Paul King
This example:
{code}
import groovy.transform.CompileStatic
interface FooA {}
interface FooB {}
class FooAB implements FooA, FooB {}
@CompileStatic
class TestGroovy {
static void test() { println new TestGroovy().foo(new FooAB()) }
def foo(FooB x) { 43 }
def foo(FooA x) { 42 }
}
TestGroovy.test()
{code}
Should probably throw some kind of ambiguous method error during compilation to
match Java (and dynamic Groovy).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (GROOVY-7920) Simple getAt example produces a BUG exception
[
https://issues.apache.org/jira/browse/GROOVY-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-7920.
---
Resolution: Fixed
Assignee: Paul King
Fix Version/s: 2.5.0-beta-1
Proposed PR merged. Thanks for reporting the issue. Fixed just on master for
now (targeting 2.5).
> Simple getAt example produces a BUG exception
> -
>
> Key: GROOVY-7920
> URL: https://issues.apache.org/jira/browse/GROOVY-7920
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.4.7
> Environment: OS X, gradle 3.0
>Reporter: Panayotis Katsaloulis
>Assignee: Paul King
>Priority: Minor
> Fix For: 2.5.0-beta-1
>
>
> When I created this simple class:
> {code}
> package com.panayotis
> import groovy.transform.CompileStatic
> @CompileStatic
> class TestGroovy {
> void test() { new TestGroovy()[3] }
> def getAt(def x) { 42 }
> }
> {code}
> when compiling with gradle I was informed that there is a bug and I should
> report it.
> This is the simplest class I could make.
> The exception follows
> {noformat}
> org.gradle.api.tasks.TaskExecutionException: Execution failed for task
> ':compileGroovy'.
> at
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69)
> at
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:46)
> at
> org.gradle.api.internal.tasks.execution.PostExecutionAnalysisTaskExecuter.execute(PostExecutionAnalysisTaskExecuter.java:35)
> at
> org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:64)
> at
> org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58)
> at
> org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:52)
> at
> org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52)
> at
> org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:53)
> at
> org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
> at
> org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:203)
> at
> org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:185)
> at
> org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:74)
> at
> org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:55)
> at
> org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.process(DefaultTaskPlanExecutor.java:32)
> at
> org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:110)
> at
> org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTaskExecutionAction.java:37)
> at
> org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37)
> at
> org.gradle.execution.DefaultBuildExecuter.access$000(DefaultBuildExecuter.java:23)
> at
> org.gradle.execution.DefaultBuildExecuter$1.proceed(DefaultBuildExecuter.java:43)
> at
> org.gradle.execution.DryRunBuildExecutionAction.execute(DryRunBuildExecutionAction.java:32)
> at
> org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37)
> at
> org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:30)
> at
> org.gradle.initialization.DefaultGradleLauncher$4.run(DefaultGradleLauncher.java:153)
> at org.gradle.internal.Factories$1.create(Factories.java:22)
> at
> org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91)
> at
> org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:53)
> at
> org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:150)
> at
> org.gradle.initialization.DefaultGradleLauncher.access$200(DefaultGradleLauncher.java:32)
> at
> org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:98)
> at
> org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:92)
> at
> org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91)
> at
[jira] [Commented] (GROOVY-7920) Simple getAt example produces a BUG exception
[
https://issues.apache.org/jira/browse/GROOVY-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15445806#comment-15445806
]
ASF GitHub Bot commented on GROOVY-7920:
Github user asfgit closed the pull request at:
https://github.com/apache/groovy/pull/399
> Simple getAt example produces a BUG exception
> -
>
> Key: GROOVY-7920
> URL: https://issues.apache.org/jira/browse/GROOVY-7920
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.4.7
> Environment: OS X, gradle 3.0
>Reporter: Panayotis Katsaloulis
>Priority: Minor
>
> When I created this simple class:
> {code}
> package com.panayotis
> import groovy.transform.CompileStatic
> @CompileStatic
> class TestGroovy {
> void test() { new TestGroovy()[3] }
> def getAt(def x) { 42 }
> }
> {code}
> when compiling with gradle I was informed that there is a bug and I should
> report it.
> This is the simplest class I could make.
> The exception follows
> {noformat}
> org.gradle.api.tasks.TaskExecutionException: Execution failed for task
> ':compileGroovy'.
> at
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69)
> at
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:46)
> at
> org.gradle.api.internal.tasks.execution.PostExecutionAnalysisTaskExecuter.execute(PostExecutionAnalysisTaskExecuter.java:35)
> at
> org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:64)
> at
> org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58)
> at
> org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:52)
> at
> org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52)
> at
> org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:53)
> at
> org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
> at
> org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:203)
> at
> org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:185)
> at
> org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:74)
> at
> org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:55)
> at
> org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.process(DefaultTaskPlanExecutor.java:32)
> at
> org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:110)
> at
> org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTaskExecutionAction.java:37)
> at
> org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37)
> at
> org.gradle.execution.DefaultBuildExecuter.access$000(DefaultBuildExecuter.java:23)
> at
> org.gradle.execution.DefaultBuildExecuter$1.proceed(DefaultBuildExecuter.java:43)
> at
> org.gradle.execution.DryRunBuildExecutionAction.execute(DryRunBuildExecutionAction.java:32)
> at
> org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37)
> at
> org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:30)
> at
> org.gradle.initialization.DefaultGradleLauncher$4.run(DefaultGradleLauncher.java:153)
> at org.gradle.internal.Factories$1.create(Factories.java:22)
> at
> org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91)
> at
> org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:53)
> at
> org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:150)
> at
> org.gradle.initialization.DefaultGradleLauncher.access$200(DefaultGradleLauncher.java:32)
> at
> org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:98)
> at
> org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:92)
> at
> org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91)
> at
> org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:63)
>
[GitHub] groovy pull request #399: GROOVY-7920: Simple getAt example produces a BUG e...
Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/399 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Comment Edited] (GROOVY-7037) getAt as Operator Throws if given Fixed and Variable Arguments
[
https://issues.apache.org/jira/browse/GROOVY-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15445582#comment-15445582
]
Paul King edited comment on GROOVY-7037 at 8/29/16 11:23 AM:
-
In some sense this isn't specific to {{getAt}}. Consider this code:
{code}
import static groovy.test.GroovyAssert.shouldFail
class Test {
def x(String s, Integer i) { "1:$s $i" }
def x(String s, Integer... is) { "2:$s $is" }
}
assert new Test().x('a', 1) == '1:a 1'// (1)
assert new Test().x('b') == '2:b []' // (2)
assert new Test().x('c', 2, 3) == '2:c [2, 3]'// (2)
assert new Test().x('d', 4, 5, 6) == '2:d [4, 5, 6]' // (2)
assert new Test().x(['e', 7]) == '1:e 7' // (3)
def ex = shouldFail(IllegalArgumentException) {
new Test().x(['f', 8, 9]) // (4)
}
assert ex.message == 'wrong number of arguments'
{code}
Groovy does normal argument matching, giving preference to non-varargs matches
(1) but matching varargs if needed (2).
Also, if a list argument is provided and no method with a list parameter is
found, an attempt is made to spread the list which matches if a method having
the correct number and types of arguments can be found (3). But in the case of
varargs, with a list argument, then the IllegalArgumentException can occur.
Unfortunately for the shorthand {{getAt}} syntax, the arguments are always
wrapped in a list, so the chances are higher of seeing this error. So, to
address this issue, we'd either have to make the list spreading logic smarter
for all methods or do some special hacking for getAt.
was (Author: paulk):
In some sense this isn't specific to {{getAt}}. Consider this code:
{code}
import static groovy.test.GroovyAssert.shouldFail
class Test {
def x(String s, Integer i) { "1:$s $i" }
def x(String s, Integer... is) { "2:$s $is" }
}
assert new Test().x('a', 1) == '1:a 1'// (1)
assert new Test().x('b') == '2:b []' // (2)
assert new Test().x('c', 2, 3) == '2:c [2, 3]'// (2)
assert new Test().x('d', 4, 5, 6) == '2:d [4, 5, 6]' // (2)
assert new Test().x(['e', 7]) == '1:e 7' // (3)
def ex = shouldFail(IllegalArgumentException) {
new Test().x(['f', 8, 9]) // (4)
}
assert ex.message == 'wrong number of arguments'
{code}
Groovy does normal argument matching, giving preference to non-varargs matches
(1) but matching varargs if needed (2).
Also, if a list argument is provided and no method with a list parameter is
found, an attempt is made to spread the list which matches if a method having
the correct number and types of arguments can be found (3). But in the case of
varargs, with a list argument, then the IllegalArgumentException can occur.
Unfortunately for the shorthand {{getAt}} syntax, the arguments are always
wrapped in a list, so the chances are higher of seeing this error. So, to "fix"
this error, we'd either have to make the list spreading logic smarter for all
methods or do some special hacking for getAt.
> getAt as Operator Throws if given Fixed and Variable Arguments
> --
>
> Key: GROOVY-7037
> URL: https://issues.apache.org/jira/browse/GROOVY-7037
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.3.6, 2.4.0-beta-2
> Environment: RHEL 6.5 x64
>Reporter: Steve Amerige
>Priority: Minor
> Attachments: Test.groovy
>
>
> The getAt method for indexing fails when variable arguments are used with []
> if any fixed arguments are present. For example:
> {code}
> class Test
> {
>def getAt(String s) { return s }
>def getAt(String s, Integer x) { return "$s $x" }
>// def getAt(Object... o) { return o } // This would succeed
>def getAt(String s, Object... a) { return "$s $a" }
>static void main(String[] args)
>{
> Test t = new Test()
> assert t['a'] == 'a'
> assert t['b', 2] == 'b 2'
> assert t.getAt('c', 3, true) == 'c [3, true]'
> assert t['c', 3, true] == 'c [3, true]' // This throws an exception
>}
> }
> {code}
> The above produces:
> {noformat}
> Exception thrown
> java.lang.IllegalArgumentException: wrong number of arguments
> at Test.main(ConsoleScript42:14)
> {noformat}
> Workaround: do not use fixed and variable arguments at the same time and use
> only variable arguments as in the case shown commented out above:
> getAt(Object... o). This is less-than desirable, however, because it
> restricts the user from using method overloading to separate out
> distinctly-different logic and forces the user to do runtime checks and
> implement control structure when using the single varargs method. In this
> case, however, the bug severity is mitigated by the fact that the user can
>
[jira] [Commented] (GROOVY-7037) getAt as Operator Throws if given Fixed and Variable Arguments
[
https://issues.apache.org/jira/browse/GROOVY-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15445582#comment-15445582
]
Paul King commented on GROOVY-7037:
---
In some sense this isn't specific to {{getAt}}. Consider this code:
{code}
import static groovy.test.GroovyAssert.shouldFail
class Test {
def x(String s, Integer i) { "1:$s $i" }
def x(String s, Integer... is) { "2:$s $is" }
}
assert new Test().x('a', 1) == '1:a 1'// (1)
assert new Test().x('b') == '2:b []' // (2)
assert new Test().x('c', 2, 3) == '2:c [2, 3]'// (2)
assert new Test().x('d', 4, 5, 6) == '2:d [4, 5, 6]' // (2)
assert new Test().x(['e', 7]) == '1:e 7' // (3)
def ex = shouldFail(IllegalArgumentException) {
new Test().x(['f', 8, 9]) // (4)
}
assert ex.message == 'wrong number of arguments'
{code}
Groovy does normal argument matching, giving preference to non-varargs matches
(1) but matching varargs if needed (2).
Also, if a list argument is provided and no method with a list parameter is
found, an attempt is made to spread the list which matches if a method having
the correct number and types of arguments can be found (3). But in the case of
varargs, with a list argument, then the IllegalArgumentException can occur.
Unfortunately for the shorthand {{getAt}} syntax, the arguments are always
wrapped in a list, so the chances are higher of seeing this error..
> getAt as Operator Throws if given Fixed and Variable Arguments
> --
>
> Key: GROOVY-7037
> URL: https://issues.apache.org/jira/browse/GROOVY-7037
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.3.6, 2.4.0-beta-2
> Environment: RHEL 6.5 x64
>Reporter: Steve Amerige
>Priority: Minor
> Attachments: Test.groovy
>
>
> The getAt method for indexing fails when variable arguments are used with []
> if any fixed arguments are present. For example:
> {code}
> class Test
> {
>def getAt(String s) { return s }
>def getAt(String s, Integer x) { return "$s $x" }
>// def getAt(Object... o) { return o } // This would succeed
>def getAt(String s, Object... a) { return "$s $a" }
>static void main(String[] args)
>{
> Test t = new Test()
> assert t['a'] == 'a'
> assert t['b', 2] == 'b 2'
> assert t.getAt('c', 3, true) == 'c [3, true]'
> assert t['c', 3, true] == 'c [3, true]' // This throws an exception
>}
> }
> {code}
> The above produces:
> {noformat}
> Exception thrown
> java.lang.IllegalArgumentException: wrong number of arguments
> at Test.main(ConsoleScript42:14)
> {noformat}
> Workaround: do not use fixed and variable arguments at the same time and use
> only variable arguments as in the case shown commented out above:
> getAt(Object... o). This is less-than desirable, however, because it
> restricts the user from using method overloading to separate out
> distinctly-different logic and forces the user to do runtime checks and
> implement control structure when using the single varargs method. In this
> case, however, the bug severity is mitigated by the fact that the user can
> explicitly use the "getAt" invocation instead of using the [ ] operator
> notation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] groovy pull request #360: `ObjectRange` and `IntRange` iteration and steppin...
Github user paplorinc closed the pull request at: https://github.com/apache/groovy/pull/360 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
