[jira] [Commented] (GROOVY-8660) Unexpected MethodSelectionException with implicit null argument
[
https://issues.apache.org/jira/browse/GROOVY-8660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446767#comment-17446767
]
Jochen Theodorou commented on GROOVY-8660:
--
I just happen to find this by chance. The mechanism for foo() calling foo(x) is
an eyesore to me for a long time. Yes I wanted to remove it and most people
agreed with it, though it is difficult to know if these know the implications
to existing code. Anyway...
RULE1: For varargs and calling foo(SomeClass...) we basically have the
following rules from Java:
# *foo( )* -> calls foo with empty array of type SomeClass[]
# *foo( null )* -> calls foo with null
# *foo( x )* -> calls foo using the reference provided by x is x is an array
and its element type is a subclass of SomeClass. Otherwise the method is not
applicable
# *foo( y_1, y_2, ..., y_n )* -> calls foo wrapping all y_i in an array if all
the y_i are a subclass of SomeClass. The Array will have the class SomeClass[].
RULE2: For the... let me call it null-expansion we have the following rule:
If normal method selection fails and the call is without arguments try method
selection again with null as argument. In the method distance algorithm any
expansion, that has to be made gives a distance penalty. That means a
foo(someClass...) has a bigger distance for a call foo() than if I would call a
method declared as foo() directly. foo(null) or foo(x) do not have that
penalty, because no additional action has to be taken.
Now let's look at the cases in the issue:
{code:Java}
class OnlySingle {
def foo(a) { "single param: $a" }
}
println new OnlySingle().foo()
// as expected: 'single param: null'
{code}
This means the initial method selection fails and we start a second method
selection with foo(null), which then successfully calls the method. RULE1
{code:Java}
class Both {
def foo(a) { "single param: $a" }
def foo(a, ... b) { "vararg param: $a, $b" }
}
println new Both().foo()
// unexpected:
// MethodSelectionException: Could not find which method foo() to invoke from
this list:
// public java.lang.Object Both#foo(java.lang.Object)
// public transient java.lang.Object Both#foo(java.lang.Object,
[Ljava.lang.Object;)
{code}
Here actually the first method selection fails, since there is no applicable
method without argument. Because of RULE2 we then try foo(null). And unlike the
optimization done, this was supposed to be a full method selection. That means
we are looking at foo(Object) and foo(Object,Object...) to select from. Because
of RULE1 foo(Object,Object...) has a penalty compared to foo(Object), as we
need to do an expansion to fit the varargs call.
This means a correct implementation should not throw an MSE, it should have
selected foo(Object) with null as argument.
> Unexpected MethodSelectionException with implicit null argument
> ---
>
> Key: GROOVY-8660
> URL: https://issues.apache.org/jira/browse/GROOVY-8660
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-2, 2.4.15, 2.5.0
>Reporter: Daniil Ovchinnikov
>Priority: Major
> Labels: varargs
>
> {code:groovy}
> class OnlySingle {
> def foo(a) { "single param: $a" }
> }
> println new OnlySingle().foo()
> // as expected: 'single param: null'
> class OnlyVararg {
> def foo(a, ... b) { "vararg param: $a, $b" }
> }
> println new OnlyVararg().foo()
> // as expected: 'MME: No signature of method: OnlyVararg.foo() is applicable
> for argument types: () values: []'
> class Both {
> def foo(a) { "single param: $a" }
> def foo(a, ... b) { "vararg param: $a, $b" }
> }
> println new Both().foo()
> // unexpected:
> // MethodSelectionException: Could not find which method foo() to invoke from
> this list:
> // public java.lang.Object Both#foo(java.lang.Object)
> // public transient java.lang.Object Both#foo(java.lang.Object,
> [Ljava.lang.Object;)
> {code}
> If the exception is expected then {{OnlyVararg}} case should work too.
> If the exception is unexpected then {{Both#foo(Object)}} should be selected.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (GROOVY-8660) Unexpected MethodSelectionException with implicit null argument
[
https://issues.apache.org/jira/browse/GROOVY-8660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446767#comment-17446767
]
Jochen Theodorou edited comment on GROOVY-8660 at 11/20/21, 7:56 AM:
-
I just happen to find this by chance. The mechanism for foo() calling foo( x )
is an eyesore to me for a long time. Yes I wanted to remove it and most people
agreed with it, though it is difficult to know if these know the implications
to existing code. Anyway...
RULE1: For varargs and calling foo(SomeClass...) we basically have the
following rules from Java:
# *foo( )* -> calls foo with empty array of type SomeClass[]
# *foo( null )* -> calls foo with null
# *foo( x )* -> calls foo using the reference provided by x is x is an array
and its element type is a subclass of SomeClass. Otherwise the method is not
applicable
# *foo( y_1, y_2, ..., y_n )* -> calls foo wrapping all y_i in an array if all
the y_i are a subclass of SomeClass. The Array will have the class SomeClass[].
RULE2: For the... let me call it null-expansion we have the following rule:
If normal method selection fails and the call is without arguments try method
selection again with null as argument. In the method distance algorithm any
expansion, that has to be made gives a distance penalty. That means a
foo(someClass...) has a bigger distance for a call foo() than if I would call a
method declared as foo() directly. foo(null) or foo( x ) do not have that
penalty, because no additional action has to be taken.
Now let's look at the cases in the issue:
{code:Java}
class OnlySingle {
def foo(a) { "single param: $a" }
}
println new OnlySingle().foo()
// as expected: 'single param: null'
{code}
This means the initial method selection fails and we start a second method
selection with foo(null), which then successfully calls the method. RULE1
{code:Java}
class Both {
def foo(a) { "single param: $a" }
def foo(a, ... b) { "vararg param: $a, $b" }
}
println new Both().foo()
// unexpected:
// MethodSelectionException: Could not find which method foo() to invoke from
this list:
// public java.lang.Object Both#foo(java.lang.Object)
// public transient java.lang.Object Both#foo(java.lang.Object,
[Ljava.lang.Object;)
{code}
Here actually the first method selection fails, since there is no applicable
method without argument. Because of RULE2 we then try foo(null). And unlike the
optimization done, this was supposed to be a full method selection. That means
we are looking at foo(Object) and foo(Object,Object...) to select from. Because
of RULE1 foo(Object,Object...) has a penalty compared to foo(Object), as we
need to do an expansion to fit the varargs call.
This means a correct implementation should not throw an MSE, it should have
selected foo(Object) with null as argument.
was (Author: blackdrag):
I just happen to find this by chance. The mechanism for foo() calling foo(x) is
an eyesore to me for a long time. Yes I wanted to remove it and most people
agreed with it, though it is difficult to know if these know the implications
to existing code. Anyway...
RULE1: For varargs and calling foo(SomeClass...) we basically have the
following rules from Java:
# *foo( )* -> calls foo with empty array of type SomeClass[]
# *foo( null )* -> calls foo with null
# *foo( x )* -> calls foo using the reference provided by x is x is an array
and its element type is a subclass of SomeClass. Otherwise the method is not
applicable
# *foo( y_1, y_2, ..., y_n )* -> calls foo wrapping all y_i in an array if all
the y_i are a subclass of SomeClass. The Array will have the class SomeClass[].
RULE2: For the... let me call it null-expansion we have the following rule:
If normal method selection fails and the call is without arguments try method
selection again with null as argument. In the method distance algorithm any
expansion, that has to be made gives a distance penalty. That means a
foo(someClass...) has a bigger distance for a call foo() than if I would call a
method declared as foo() directly. foo(null) or foo(x) do not have that
penalty, because no additional action has to be taken.
Now let's look at the cases in the issue:
{code:Java}
class OnlySingle {
def foo(a) { "single param: $a" }
}
println new OnlySingle().foo()
// as expected: 'single param: null'
{code}
This means the initial method selection fails and we start a second method
selection with foo(null), which then successfully calls the method. RULE1
{code:Java}
class Both {
def foo(a) { "single param: $a" }
def foo(a, ... b) { "vararg param: $a, $b" }
}
println new Both().foo()
// unexpected:
// MethodSelectionException: Could not find which method foo() to invoke from
this list:
// public java.lang.Object Both#foo(java.lang.Object)
// public transient java.lang.Object Both#foo(java.lang.Object,
[Ljava.lang.Object;)
{code}
Here actually
[jira] [Closed] (GROOVY-10216) Avoid unnecessary security checks for each invocation
[
https://issues.apache.org/jira/browse/GROOVY-10216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun closed GROOVY-10216.
---
Fix Version/s: (was: 4.0.0-beta-2)
Resolution: Won't Fix
> Avoid unnecessary security checks for each invocation
> -
>
> Key: GROOVY-10216
> URL: https://issues.apache.org/jira/browse/GROOVY-10216
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Java reflection will do security checks for each invocation, but if
> \{{setAccessible(true)}} called for the accessible objects, the unneccessary
> security checks could be avoided.
> See the result of "Performance Test":
> {code:java}
> FastMethodPerfTest.constructor_reflect_StringCtorCharArray avgt
> 15 18.471 ± 0.510 ns/op
> FastMethodPerfTest.constructor_reflect_accessible_StringCtorCharArray avgt
> 15 17.003 ± 0.528 ns/op
> FastMethodPerfTest.method_reflect_StringStartsWith avgt
> 15 12.264 ± 0.682 ns/op
> FastMethodPerfTest.method_reflect_accessible_StringStartsWith avgt
> 15 9.640 ± 0.732 ns/op
> {code}
> https://github.com/danielsun1106/fast-reflection
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GROOVY-7473) ineffient code generation
[
https://issues.apache.org/jira/browse/GROOVY-7473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles resolved GROOVY-7473.
-
Fix Version/s: 4.0.0-beta-3
Resolution: Fixed
https://github.com/apache/groovy/commit/51749380ff43d1cdfb3164c3a9e858c9d5573b9d
> ineffient code generation
> -
>
> Key: GROOVY-7473
> URL: https://issues.apache.org/jira/browse/GROOVY-7473
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.3
>Reporter: Laurenz Tontsch
>Assignee: Eric Milles
>Priority: Major
> Labels: performance
> Fix For: 4.0.0-beta-3
>
>
> Groovy 2.4.3 generates not the most effient byte code of a simple statement
> like "in".
> e.g. The following statement:
> If object.stringProperty in ["State1", "State2", "State3"
> gets complied in:
> if
> (DefaultTypeTransformation.booleanUnbox((ScriptBytecodeAdapter.createList(new
> Object[] { "State1", "State2", "State3" }) == null ? 1 : 0) != 0 ?
> Boolean.valueOf(object.getStringProperty() == null) :
> Boolean.valueOf(DefaultGroovyMethods.isCase(ScriptBytecodeAdapter.createList(new
> Object[] { "State1", "State2 ", "State3" }), object. getStringProperty ()
> instead of this a more effient construct would be the usage of an static list
> e.g.
> static List l1;
> static {
> l1 = new LinkedList();
> l1.add("State1");
> l1.add("State2");
> l1.add("State3");
> }
> if (DefaultTypeTransformation.booleanUnbox((l1 == null ? 1 : 0) != 0 ?
> Boolean.valueOf(object.getStringProperty() == null) :
> Boolean.valueOf(DefaultGroovyMethods.isCase(l1, object. getStringProperty
> ()
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GROOVY-7473) ineffient code generation
[
https://issues.apache.org/jira/browse/GROOVY-7473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles reassigned GROOVY-7473:
---
Assignee: Eric Milles
> ineffient code generation
> -
>
> Key: GROOVY-7473
> URL: https://issues.apache.org/jira/browse/GROOVY-7473
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.3
>Reporter: Laurenz Tontsch
>Assignee: Eric Milles
>Priority: Major
> Labels: performance
>
> Groovy 2.4.3 generates not the most effient byte code of a simple statement
> like "in".
> e.g. The following statement:
> If object.stringProperty in ["State1", "State2", "State3"
> gets complied in:
> if
> (DefaultTypeTransformation.booleanUnbox((ScriptBytecodeAdapter.createList(new
> Object[] { "State1", "State2", "State3" }) == null ? 1 : 0) != 0 ?
> Boolean.valueOf(object.getStringProperty() == null) :
> Boolean.valueOf(DefaultGroovyMethods.isCase(ScriptBytecodeAdapter.createList(new
> Object[] { "State1", "State2 ", "State3" }), object. getStringProperty ()
> instead of this a more effient construct would be the usage of an static list
> e.g.
> static List l1;
> static {
> l1 = new LinkedList();
> l1.add("State1");
> l1.add("State2");
> l1.add("State3");
> }
> if (DefaultTypeTransformation.booleanUnbox((l1 == null ? 1 : 0) != 0 ?
> Boolean.valueOf(object.getStringProperty() == null) :
> Boolean.valueOf(DefaultGroovyMethods.isCase(l1, object. getStringProperty
> ()
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GROOVY-7473) ineffient code generation
[
https://issues.apache.org/jira/browse/GROOVY-7473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446604#comment-17446604
]
Eric Milles commented on GROOVY-7473:
-
{{BinaryExpressionTransformer#convertInOperatorToTernary}} changes "o.p in
['x','y','z']" to "['x','y','z'] == null ? o.p == null :
['x','y','z'].isCase(o.p)". This could be made simpler for the times where
right expression cannot be null. And if {{isCase}} is overridden for
{{{}NullObject{}}}, it could be "['x','y','z']?.isCase(o.p)" instead of a
ternary.
> ineffient code generation
> -
>
> Key: GROOVY-7473
> URL: https://issues.apache.org/jira/browse/GROOVY-7473
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.3
>Reporter: Laurenz Tontsch
>Priority: Major
> Labels: performance
>
> Groovy 2.4.3 generates not the most effient byte code of a simple statement
> like "in".
> e.g. The following statement:
> If object.stringProperty in ["State1", "State2", "State3"
> gets complied in:
> if
> (DefaultTypeTransformation.booleanUnbox((ScriptBytecodeAdapter.createList(new
> Object[] { "State1", "State2", "State3" }) == null ? 1 : 0) != 0 ?
> Boolean.valueOf(object.getStringProperty() == null) :
> Boolean.valueOf(DefaultGroovyMethods.isCase(ScriptBytecodeAdapter.createList(new
> Object[] { "State1", "State2 ", "State3" }), object. getStringProperty ()
> instead of this a more effient construct would be the usage of an static list
> e.g.
> static List l1;
> static {
> l1 = new LinkedList();
> l1.add("State1");
> l1.add("State2");
> l1.add("State3");
> }
> if (DefaultTypeTransformation.booleanUnbox((l1 == null ? 1 : 0) != 0 ?
> Boolean.valueOf(object.getStringProperty() == null) :
> Boolean.valueOf(DefaultGroovyMethods.isCase(l1, object. getStringProperty
> ()
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GROOVY-7439) Compilation errors using groovy trait and @CompileStatic and @Slf4j("LOG")
[
https://issues.apache.org/jira/browse/GROOVY-7439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-7439:
Labels: traits (was: )
> Compilation errors using groovy trait and @CompileStatic and @Slf4j("LOG")
> --
>
> Key: GROOVY-7439
> URL: https://issues.apache.org/jira/browse/GROOVY-7439
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.4.3
> Environment: Windows 8.1
> Oracle JDK 8.u45
>Reporter: Allen Arakaki
>Priority: Major
> Labels: traits
>
> Compilation errors using groovy trait and @CompileStatic and @Slf4j("LOG")
> Easy to reproduce:
>
> {code}
> import org.slf4j.Logger
> import groovy.transform.CompileStatic
> import groovy.util.logging.Slf4j
> @Slf4j("LOG")
> @CompileStatic
> trait TTest {
> void test1() {
> LOG.debug("Logging test1 ...")
> }
> void test2() {
> //((Logger)LOG).debug("Logging test2 ...")
> }
> }
> {code}
> Results in the following:
> | Error Compilation error: startup failed:
> ..\src\groovy\TTest.groovy: 10: [Static type checking] - Cannot find matching
> method java.lang.Object#debug(java.lang.String). Please check if the declared
> type is right and if the method exists.
> @ line 10, column 5.
> LOG.debug("Logging test1 ...")
> ^
> {code}
> import org.slf4j.Logger
> import groovy.transform.CompileStatic
> import groovy.util.logging.Slf4j
> @Slf4j("LOG")
> @CompileStatic
> trait TTest {
> void test1() {
> //LOG.debug("Logging test1 ...")
> }
> void test2() {
> ((Logger)LOG).debug("Logging test2 ...")
> }
> }
> {code}
> Results in the following error:
> | Error Compilation error: startup failed:
> ..\src\groovy\TTest.groovy: -1: Access to TTest#LOG is forbidden @ line -1,
> column -1.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GROOVY-7436) Multiple inheritance of traits - conflict resolution
[
https://issues.apache.org/jira/browse/GROOVY-7436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-7436:
Labels: traits (was: )
> Multiple inheritance of traits - conflict resolution
>
>
> Key: GROOVY-7436
> URL: https://issues.apache.org/jira/browse/GROOVY-7436
> Project: Groovy
> Issue Type: Improvement
>Reporter: Thornton Chamberlain
>Priority: Major
> Labels: traits
>
> {noformat}
> trait A {
> String exec() {'A'}
> }
> trait B implements A {
> String exec() {'B'}
> }
> trait C implements A {
> }
> class X implements A, B, C {}
> def x = new X()
> assert x.exec() == 'B'
> {noformat}
> An equivalent example in Scala will use the exec() implementation from B, as
> asserted. Groovy will take the implementation from the last declared trait,
> C, which inherits the implementation from A but does not define its own
> implementation. I think Groovy should use the implementation from the last
> declared trait that defines its own implementation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GROOVY-6146) Calling a Java vararg method from Groovy with a null argument cast to the vararg type behaves differently than in Java
[
https://issues.apache.org/jira/browse/GROOVY-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-6146:
Labels: varargs (was: )
> Calling a Java vararg method from Groovy with a null argument cast to the
> vararg type behaves differently than in Java
> --
>
> Key: GROOVY-6146
> URL: https://issues.apache.org/jira/browse/GROOVY-6146
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.1.2
> Environment: Fedora Release 17
>Reporter: David Tonhofer
>Priority: Major
> Labels: varargs
>
> We have this Java class:
> {code:title=JavaReceiver.java|borderStyle=solid}
> public class JavaReceiver {
> public static String receive(String... x) {
> String res = ((x == null) ? "null" : ("an array of size " +
> x.length));
> return "received 'x' is " + res;
> }
> }
> {code}
> which is called from this Java class to verify various effect:
> {code:title=JavaSender.java|borderStyle=solid}
> import org.junit.Test;
> public class JavaSender {
> @Test
> public void sendNothing() {
> System.out.println("sendNothing(): " + JavaReceiver.receive());
> }
> @Test
> public void sendNullWithNoCast() {
> System.out.println("sendNullWithNoCast(): " +
> JavaReceiver.receive(null));
> }
> @Test
> public void sendNullWithCastToString() {
> System.out.println("sendNullWithCastToString(): " +
> JavaReceiver.receive((String)null));
> }
> @Test
> public void sendNullWithCastToArray() {
> System.out.println("sendNullWithCastToArray(): " +
> JavaReceiver.receive((String[])null));
> }
> @Test
> public void sendOneValue() {
> System.out.println("sendOneValue(): " + JavaReceiver.receive("a"));
> }
> @Test
> public void sendThreeValues() {
> System.out.println("sendThreeValues(): " + JavaReceiver.receive("a",
> "b", "c"));
> }
>
> @Test
> public void sendArray() {
> System.out.println("sendArray(): " + JavaReceiver.receive(new
> String[]{"a", "b", "c"}));
> }
> }
> {code}
> Running the test above yields this output:
> sendNothing(): received 'x' is an array of size 0
> sendNullWithNoCast(): received 'x' is null
> sendNullWithCastToString(): received 'x' is an array of size 1
> sendNullWithCastToArray(): received 'x' is null
> sendOneValue(): received 'x' is an array of size 1
> sendThreeValues(): received 'x' is an array of size 3
> sendArray(): received 'x' is an array of size 3
> Using essentially similar code from Groovy:
> {code:title=GroovySender.groovy|borderStyle=solid}
> import org.junit.Test
> class GroovySender {
> @Test
> void sendNothing() {
> System.out << "sendNothing(): " << JavaReceiver.receive() << "\n"
> }
> @Test
> void sendNullWithNoCast() {
> System.out << "sendNullWithNoCast(): " << JavaReceiver.receive(null)
> << "\n"
> }
> @Test
> void sendNullWithCastToString() {
> System.out << "sendNullWithCastToString(): " <<
> JavaReceiver.receive((String)null) << "\n"
> }
> @Test
> void sendNullWithCastToArray() {
> System.out << "sendNullWithCastToArray(): " <<
> JavaReceiver.receive((String[])null) << "\n"
> }
> @Test
> void sendOneValue() {
> System.out << "sendOneValue(): " + JavaReceiver.receive("a") << "\n"
> }
> @Test
> void sendThreeValues() {
> System.out << "sendThreeValues(): " + JavaReceiver.receive("a", "b",
> "c") << "\n"
> }
> @Test
> void sendArray() {
> System.out << "sendArray(): " + JavaReceiver.receive( ["a", "b", "c"]
> as String[] ) << "\n"
> }
> }
> {code}
> Yields the different output:
> sendNothing(): received 'x' is an array of size 0
> sendNullWithNoCast(): received 'x' is null
> *sendNullWithCastToString(): received 'x' is null*
> sendNullWithCastToArray(): received 'x' is null
> sendOneValue(): received 'x' is an array of size 1
> sendThreeValues(): received 'x' is an array of size 3
> sendArray(): received 'x' is an array of size 3
> So the "cast to a String" does not result in a call with the argument
> "String[]{null}".
> Maybe that is expected behaviour though.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (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:all-tabpanel
]
Eric Milles updated GROOVY-7037:
Labels: varargs (was: )
> 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
> Labels: varargs
> 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
(v8.20.1#820001)
[jira] [Updated] (GROOVY-8660) Unexpected MethodSelectionException with implicit null argument
[
https://issues.apache.org/jira/browse/GROOVY-8660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-8660:
Labels: varargs (was: )
> Unexpected MethodSelectionException with implicit null argument
> ---
>
> Key: GROOVY-8660
> URL: https://issues.apache.org/jira/browse/GROOVY-8660
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-2, 2.4.15, 2.5.0
>Reporter: Daniil Ovchinnikov
>Priority: Major
> Labels: varargs
>
> {code:groovy}
> class OnlySingle {
> def foo(a) { "single param: $a" }
> }
> println new OnlySingle().foo()
> // as expected: 'single param: null'
> class OnlyVararg {
> def foo(a, ... b) { "vararg param: $a, $b" }
> }
> println new OnlyVararg().foo()
> // as expected: 'MME: No signature of method: OnlyVararg.foo() is applicable
> for argument types: () values: []'
> class Both {
> def foo(a) { "single param: $a" }
> def foo(a, ... b) { "vararg param: $a, $b" }
> }
> println new Both().foo()
> // unexpected:
> // MethodSelectionException: Could not find which method foo() to invoke from
> this list:
> // public java.lang.Object Both#foo(java.lang.Object)
> // public transient java.lang.Object Both#foo(java.lang.Object,
> [Ljava.lang.Object;)
> {code}
> If the exception is expected then {{OnlyVararg}} case should work too.
> If the exception is unexpected then {{Both#foo(Object)}} should be selected.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GROOVY-7370) Varargs in constructor are not treated correctly when creating instances of anonymous class
[
https://issues.apache.org/jira/browse/GROOVY-7370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-7370:
Labels: varargs (was: )
> Varargs in constructor are not treated correctly when creating instances of
> anonymous class
> ---
>
> Key: GROOVY-7370
> URL: https://issues.apache.org/jira/browse/GROOVY-7370
> Project: Groovy
> Issue Type: Bug
>Reporter: Nikita Artyushov
>Priority: Major
> Labels: varargs
>
> Code snippet to reproduce the bug:
> {code}
> class Test {
> public Test(String... args) {
> println args
> }
> public static void main(String[] args) {
> new Test('oneWord')
> new Test('manyLetters') {
> @Override
> int hashCode() {
> return 1;
> }
> }
> }
> }
> {code}
> expected output:
> {code}
> [oneWord]
> [manyLetters]
> {code}
> actual:
> {code}
> [oneWord]
> [m, a, n, y, L, e, t, t, e, r, s]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GROOVY-8737) STC Method resolution fails if other methods with more parameters exist
[
https://issues.apache.org/jira/browse/GROOVY-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-8737:
Labels: varargs (was: )
> STC Method resolution fails if other methods with more parameters exist
> ---
>
> Key: GROOVY-8737
> URL: https://issues.apache.org/jira/browse/GROOVY-8737
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.15, 3.0.0-alpha-3, 2.5.1
> Environment: Ubuntu 18.04, Java 8u181
>Reporter: Patric Bechtel
>Priority: Major
> Labels: varargs
>
> Given two classes as follows
> {code:java}
> @groovy.transform.CompileStatic
> class A {
> public static String msg( String key, Object[] args ) { "key=$key,
> args=$args" }
> public static String msg( String key, Object[] args, Object[] parts ) {
> "key=$key, args=$args, parts=$parts" }
> public static String msg( String key, Object[] args, String[] names ) {
> "key=$key, args=$args, names=$names" }
> }
> {code}
> and
> {code:java}
> @groovy.transform.CompileStatic
> public class B {
> public static void main( String[] args ) {
> println A.msg( 'hello', [ 'world' ] as Object[] )
> }
> }
> {code}
> will not compile with the error
> {noformat}
> B.groovy: 4: [Static type checking] - Reference to method is ambiguous.
> Cannot choose between [java.lang.String A#msg(java.lang.String,
> java.lang.Object[], java.lang.Object[]), java.lang.String
> A#msg(java.lang.String, java.lang.Object[], java.lang.String[])]
> @ line 4, column 15.
> println A.msg( 'hello', [ 'world' ] as Object[] )
> {noformat}
> Though there's a perfect match for the called method, it tries to choose one
> of the longer signatures.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GROOVY-10100) groovyc infers the wrong type when using a method reference of a function with varargs
[
https://issues.apache.org/jira/browse/GROOVY-10100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10100:
-
Labels: varargs (was: )
> groovyc infers the wrong type when using a method reference of a function
> with varargs
> --
>
> Key: GROOVY-10100
> URL: https://issues.apache.org/jira/browse/GROOVY-10100
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Reporter: Thodoris Sotiropoulos
>Assignee: Eric Milles
>Priority: Major
> Labels: varargs
>
> I have the following program
>
> {code:java}
> import java.util.function.Function;
> class Foo {
> public T method(Object... args) {
> return null;
> }
> }
> class Bar {
> public static void test(T a) {
> Foo x = new Foo<>();
> Function b = x::method;
> T y = b.apply(new String[] {"str"});
> }
> }
> public class Main {
> public static void main(String[] args) {
> Bar.test(1);
> }
> }
> {code}
> h3. Actual Behaviour
> {code:java}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> groovy4.groovy: 14: [Static type checking] - Cannot assign value of type
> java.lang.String[] to variable of type T
> @ line 14, column 15.
>T y = b.apply(new String[] {"str"});
> ^1 error
> {code}
> h3. Expected Behaviour
> Compile successfully
>
> Note that if I remove the `extends` from the parameterized function, the code
> compiles as expected.
>
> Tested against master
> https://github.com/apache/groovy/commit/9961a67db31f7889cfb9a927ccc26c3ece0e41b9
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GROOVY-10099) A single null argument to a varargs parameter is received as null
[
https://issues.apache.org/jira/browse/GROOVY-10099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10099:
-
Labels: varargs (was: )
> A single null argument to a varargs parameter is received as null
> -
>
> Key: GROOVY-10099
> URL: https://issues.apache.org/jira/browse/GROOVY-10099
> Project: Groovy
> Issue Type: Bug
> Environment: Observed on Groovy 3.0.8 on macOS Big Sur (Intel), but I
> don't think that's relevant; it'll be everywhere.
>Reporter: Rachel Greenham
>Priority: Major
> Labels: varargs
> Fix For: 4.x
>
> Attachments: VarArgsTest.groovy, VarArgsTest.jsh
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> (NB: I would set the priority to P2 default to be triaged, but I seem not to
> have that option, so I left it at the default I was presented with.)
> When calling a method with a varargs parameter with a single value, that
> value is wrapped into an array of length 1. This is the behaviour in Java,
> and is the expected behaviour, and _most_ of the time is the behaviour in
> Groovy too.
> But when that single value is null, Groovy will instead just pass the null
> into the method. Java will not do this: You'll get an array with a single
> null in it. Because Groovy's behaviour is unexpected, especially when
> interfacing with Java code, NullPointerExceptions can often ensue.
> Adding to the inconsistencies, if the Groovy code calling the method is in a
> {{@CompileStatic}} context, it behaves just like Java, and the method
> (whether or not _it_ is statically compiled or a dynamic Groovy method)
> receives an array with a null in it.
> So the behaviour in Groovy is inconsistent, both with itself in a
> {{@CompileStatic}} situation, and with Java, and is requiring workarounds in
> Java code to handle this normally-impossible eventuality. (Even if no varargs
> parameter is given you get an empty array, as in fact you do in Groovy too.)
> This may be an "early instalment weirdness": There's an ancient ticket, from
> not long after varargs were introduced into Java, which appears to have
> argued - successfully at the time - that the normal behaviour is a bug:
> https://issues.apache.org/jira/browse/GROOVY-1026
> Further adding to the confusion may be that Groovy usually elides the
> difference between an {{Object[]}} parameter and an {{Object...}} parameter:
> They both behave the same.
> The offending code appears to be in
> org.codehaus.groovy.reflection.ParameterTypes.java in method fitToVars, lines
> 200-215 in master at the time of writing, which even includes a comment that
> "if the last argument is null, then we don't have to do anything", with which
> I respectfully disagree. :) That behaviour should be to return an array with
> a single null in it (Handily, MetaClassHelper.ARRAY_WITH_NULL saves having to
> make a new one.)
> In principle it's an easy fix (although I've left tagging to others as this
> is my first issue here), but there'd be an obvious nervousness about changing
> behaviour like this when there might be a lot of old code out there depending
> on it behaving the way it does now. OTOH the way it behaves now is breaking
> the expectations of those of us coming to Groovy from a lifetime of Java...
> Attachments:
> VarArgsTest.groovy - a script saved from, and runnable in, groovyConsole,
> demonstrating the behaviour. The behaviour is the same regardless of whether
> the console is launched with the -indy option. (The issue was initially
> observed in indy.) The dynamic portion of the test, when run, ends in a
> NullPointerException as Arrays.asList is not expecting a null varargs
> parameter. Output seen (-indy or not):
>
> {code:java}
> name: the static name 1
> params is null? false
> params length is 1
> [blah]
> name: the static name 2
> params is null? false
> params length is 2
> [blah, blue]
> name: the static name 3 with blah=null
> params is null? false
> params length is 1
> [null]
> Arrays.asList(blah)? [null]
> name: the dynamic name 1
> params is null? false
> params length is 1
> [blah]
> name: the dynamic name 2
> params is null? false
> params length is 2
> [blah, blue]
> name: the dynamic name 3 with blah=null
> params is null? true
> Exception thrown
> java.lang.NullPointerException
> ...{code}
> (etc. stack trace not shown for formatting reasons.)
> VarArgsTest.jsh - a jshell script demonstrating Java's behaviour, very
> similar to the groovy test, but omitting the dynamic portion of the test for
> obvious reasons. (The statements in the Groovy script ending in semicolons
> are left that way precisely to mark that they're identical to the Java test.)
> Runnable with
>
> {code:java}
> jshell PRINTING VarArgsTest.jsh
> {code}
>
[jira] [Updated] (GROOVY-8845) @DelegatesTo works only for the first vararg
[
https://issues.apache.org/jira/browse/GROOVY-8845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-8845:
Labels: varargs (was: )
> @DelegatesTo works only for the first vararg
>
>
> Key: GROOVY-8845
> URL: https://issues.apache.org/jira/browse/GROOVY-8845
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.5.3
>Reporter: Daniil Ovchinnikov
>Priority: Major
> Labels: varargs
>
> {code:groovy}
> def md(@DelegatesTo.Target Object target, @DelegatesTo(strategy =
> Closure.DELEGATE_FIRST) Closure... arg) {
> for (Closure a : arg) {
> a.delegate = target
> a.resolveStrategy = Closure.DELEGATE_FIRST
> a()
> }
> }
> class D {
> def foo() { 42 }
> }
> @groovy.transform.CompileStatic
> def test() {
> md(
> new D(),
> { print(foo()) },
> // { print(foo()) }, // [Static type checking] - Cannot find matching
> method ConsoleScript15#foo()
> // { print(foo()) }, // [Static type checking] - Cannot find matching
> method ConsoleScript15#foo()
> )
> }
> test()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GROOVY-10140) No compiler error for invalid transient method modifier
[
https://issues.apache.org/jira/browse/GROOVY-10140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10140:
-
Labels: varargs (was: )
> No compiler error for invalid transient method modifier
> ---
>
> Key: GROOVY-10140
> URL: https://issues.apache.org/jira/browse/GROOVY-10140
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.14, 3.0.8, 4.0.0-alpha-3
>Reporter: Eric Milles
>Priority: Major
> Labels: varargs
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Consider the following:
> {code:groovy}
> class C {
> transient void m() {
> println 'should not compile'
> }
> }
> new C().m()
> {code}
> Groovy happily compiles and executes this code. It should emit and error for
> the invalid modifier "transient" on the method declaration. Similar code in
> Java produces the following error:
> {code}
> Illegal modifier for the method m; only public, protected, private, abstract,
> static, final, synchronized, native & strictfp are permitted
> {code}
> transient overlaps the modifier bit for varargs so this can cause
> difficulties in joint compilation scenarios. -Also the modifier printing
> code leveraged from {{MethodNode#getText}} does not consider the method
> context and prints "transient" for "def foo(... args) {}".-
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GROOVY-10376) Consider supporting property syntax for variadic "getter" methods
Eric Milles created GROOVY-10376:
Summary: Consider supporting property syntax for variadic "getter"
methods
Key: GROOVY-10376
URL: https://issues.apache.org/jira/browse/GROOVY-10376
Project: Groovy
Issue Type: Improvement
Reporter: Eric Milles
Consider the following:
{code:groovy}
@groovy.transform.TypeChecked
class C {
def getFoo(String[] strings) {
}
void test() {
getFoo()
foo
}
}
@groovy.transform.TypeChecked
void test(Class type) {
type.getDeclaredConstructor().newInstance() //
getDeclaredConstructor(Class...)
type.declaredConstructor.newInstance()
}
{code}
Since "getFoo" can be called with zero arguments, does that make it a candidate
for supporting property syntax? I submit this for consideration.
We have style checks that suggest property syntax when "getName()" is
encountered. But this case cannot be converted and so we must live with a
warning or add an exclusion.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GROOVY-10376) Consider supporting property syntax for variadic "getter" methods
[
https://issues.apache.org/jira/browse/GROOVY-10376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10376:
-
Labels: varargs (was: )
> Consider supporting property syntax for variadic "getter" methods
> -
>
> Key: GROOVY-10376
> URL: https://issues.apache.org/jira/browse/GROOVY-10376
> Project: Groovy
> Issue Type: Improvement
>Reporter: Eric Milles
>Priority: Minor
> Labels: varargs
>
> Consider the following:
> {code:groovy}
> @groovy.transform.TypeChecked
> class C {
> def getFoo(String[] strings) {
> }
> void test() {
> getFoo()
> foo
> }
> }
> @groovy.transform.TypeChecked
> void test(Class type) {
> type.getDeclaredConstructor().newInstance() //
> getDeclaredConstructor(Class...)
> type.declaredConstructor.newInstance()
> }
> {code}
> Since "getFoo" can be called with zero arguments, does that make it a
> candidate for supporting property syntax? I submit this for consideration.
> We have style checks that suggest property syntax when "getName()" is
> encountered. But this case cannot be converted and so we must live with a
> warning or add an exclusion.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [groovy] sszuev opened a new pull request #1654: ExtensionModuleTest: add test for comparing LocalDateTime and LocalDate
sszuev opened a new pull request #1654: URL: https://github.com/apache/groovy/pull/1654 In our product we need the ability to compare `java.time.LocalDateTime` and `java.time.LocalDate`. To achieve this we can override java methods in groovy with help of `org.codehaus.groovy.runtime.ExtensionModule`. I think it's pretty important that this functionality is covered by tests in some way: for example, such overriding would not work as expected in the version before GROOVY-9711 (where a java `Comparable#compareTo` was used). See also the relevant discussion in d...@groovy.apache.org: https://lists.apache.org/thread/gtrq2cmk1hz75blx5smr81sqhohdnt6q -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@groovy.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (GROOVY-10232) Massive increase in memory usage due to CacheableCallSite
[ https://issues.apache.org/jira/browse/GROOVY-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446419#comment-17446419 ] Emond Papegaaij commented on GROOVY-10232: -- [~paulk] It's not just Spock, but our entire infrastructure to run tests. Our tests are based on Arquillian, so for Groovy 4 to work, I will need to update our integration for Spock and Arquillian (https://github.com/topicusonderwijs/arquillian-testrunner-spock/tree/spock-2.0-junit5) as well. Also, because the maven coordinates have changed, this will need to be changed in our packaging as well, because Arquillian will need to know which classes to include with the tests to run. As you might understand, this will require a significant effort and the results will not be entirely reliable, because it's all based on experimental releases and things that are not built to work together. The patch applies cleanly on the GROOVY_3.0.X branch, so I did a run with that version. It looks like the problem is fixed. I've reduced the memory settings to the values we used for Groovy 2.5 and no longer get an OutOfMemoryError. > Massive increase in memory usage due to CacheableCallSite > - > > Key: GROOVY-10232 > URL: https://issues.apache.org/jira/browse/GROOVY-10232 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 3.0.9 >Reporter: Emond Papegaaij >Priority: Major > Attachments: Screenshot_20210913_161502.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > When upgrading our tests from Spock 1.3 with Groovy 2.5 to Spock 2.0 with > Groovy 3.0.9, we are seeing issue with memory usage caused by > CacheableCallSite. This memory seems to be retained in classes and is > therefore never freed. A single Spock test class can take as much as 150mb > memory. The total amount of memory sums up to several gigabytes of additional > memory, causing our tests to take about 3 times as much memory as with Spock > 1.3 and Groovy 2.5. -- This message was sent by Atlassian Jira (v8.20.1#820001)
