[jira] [Created] (GROOVY-10727) How to customize built-in methods

2022-08-23 Thread zhao (Jira)
zhao created GROOVY-10727:
-

 Summary: How to customize built-in methods
 Key: GROOVY-10727
 URL: https://issues.apache.org/jira/browse/GROOVY-10727
 Project: Groovy
  Issue Type: Question
Reporter: zhao


for example,I have a script like this
{code:java}
//代码占位符
def data=businessInterface([12332],["key":"value"]){code}
Now i want to create businessinterface with this built-in method like print

how should i develop in java environment



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (GROOVY-10521) Compiler complains about abstract method not implemented when implementing trait

2022-08-23 Thread Paul King (Jira)


[ 
https://issues.apache.org/jira/browse/GROOVY-10521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17583936#comment-17583936
 ] 

Paul King commented on GROOVY-10521:


Snapshots for 4+ are in the Apache snapshot repo:
[https://groovy.apache.org/snapshots.html]

Snapshots for versions up to and including 3.x (and mirrors of non-snapshot 
releases for all versions) are in the groovy.jfrog.io repo.

 

> Compiler complains about abstract method not implemented when implementing 
> trait
> 
>
> Key: GROOVY-10521
> URL: https://issues.apache.org/jira/browse/GROOVY-10521
> Project: Groovy
>  Issue Type: Bug
>  Components: Compiler
>Affects Versions: 4.0.1
>Reporter: Lóránt Pintér
>Assignee: Eric Milles
>Priority: Major
>  Labels: traits
> Fix For: 4.0.5
>
>
> I have a trait called 
> [ProviderAssertions|https://github.com/gradle/gradle/blob/c692f2a1d2baa03f975c443ddc746d885cf84ee2/subprojects/model-core/src/testFixtures/groovy/org/gradle/api/internal/provider/ProviderAssertions.groovy]
>  that is successfully implemented by a number of {{spock.lang.Specification}} 
> types. However, when compiling this class with Groovy 4.0.1-SNAPSHOT:
> It fails with the following error:
> {code}
> :model-core:compileTestGroovy FAILED  
> Note: Some input files use or override a deprecated API.  
> Note: Recompile with -Xlint:deprecation for details.  
> Note: 
> /Users/lptr/Workspace/gradle/gradle/subprojects/model-core/src/test/groovy/org/gradle/internal/instantiation/generator/AsmBackedClassGeneratorTest.java
>  uses unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> startup failed:   
> /Users/lptr/Workspace/gradle/gradle/subprojects/model-core/src/test/groovy/org/gradle/api/internal/provider/DefaultProviderFactoryTest.groovy:
>  27: Can't have an abstract method in a non-abstract class. The class 
> 'org.gradle.api.internal.provider.DefaultProviderFactoryTest' must be 
> declared abstract or the method 'void 
> assertHasProducer(org.gradle.api.internal.provider.ProviderInternal, 
> org.gradle.api.Task, org.gradle.api.Task[])' must be implemented.
>  @ line 27, column 1. 
>class DefaultProviderFactoryTest extends Specification implements 
> ProviderAssertions { 
>^  
> 1 error   
> {code}
> https://github.com/gradle/gradle/blob/c692f2a1d2baa03f975c443ddc746d885cf84ee2/subprojects/model-core/src/test/groovy/org/gradle/api/internal/provider/DefaultProviderFactoryTest.groovy#L27
> https://ge.gradle.org/s/mz3m6drw3kzog/console-log?task=:model-core:compileTestGroovy
> The same code works with Groovy 3.0.9, and it even compiled with Groovy 
> 4.0.0-beta-1.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (GROOVY-10521) Compiler complains about abstract method not implemented when implementing trait

2022-08-23 Thread Eric Milles (Jira)


[ 
https://issues.apache.org/jira/browse/GROOVY-10521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17583876#comment-17583876
 ] 

Eric Milles commented on GROOVY-10521:
--

I was able to build successfully this afternoon. 

> Compiler complains about abstract method not implemented when implementing 
> trait
> 
>
> Key: GROOVY-10521
> URL: https://issues.apache.org/jira/browse/GROOVY-10521
> Project: Groovy
>  Issue Type: Bug
>  Components: Compiler
>Affects Versions: 4.0.1
>Reporter: Lóránt Pintér
>Assignee: Eric Milles
>Priority: Major
>  Labels: traits
> Fix For: 4.0.5
>
>
> I have a trait called 
> [ProviderAssertions|https://github.com/gradle/gradle/blob/c692f2a1d2baa03f975c443ddc746d885cf84ee2/subprojects/model-core/src/testFixtures/groovy/org/gradle/api/internal/provider/ProviderAssertions.groovy]
>  that is successfully implemented by a number of {{spock.lang.Specification}} 
> types. However, when compiling this class with Groovy 4.0.1-SNAPSHOT:
> It fails with the following error:
> {code}
> :model-core:compileTestGroovy FAILED  
> Note: Some input files use or override a deprecated API.  
> Note: Recompile with -Xlint:deprecation for details.  
> Note: 
> /Users/lptr/Workspace/gradle/gradle/subprojects/model-core/src/test/groovy/org/gradle/internal/instantiation/generator/AsmBackedClassGeneratorTest.java
>  uses unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> startup failed:   
> /Users/lptr/Workspace/gradle/gradle/subprojects/model-core/src/test/groovy/org/gradle/api/internal/provider/DefaultProviderFactoryTest.groovy:
>  27: Can't have an abstract method in a non-abstract class. The class 
> 'org.gradle.api.internal.provider.DefaultProviderFactoryTest' must be 
> declared abstract or the method 'void 
> assertHasProducer(org.gradle.api.internal.provider.ProviderInternal, 
> org.gradle.api.Task, org.gradle.api.Task[])' must be implemented.
>  @ line 27, column 1. 
>class DefaultProviderFactoryTest extends Specification implements 
> ProviderAssertions { 
>^  
> 1 error   
> {code}
> https://github.com/gradle/gradle/blob/c692f2a1d2baa03f975c443ddc746d885cf84ee2/subprojects/model-core/src/test/groovy/org/gradle/api/internal/provider/DefaultProviderFactoryTest.groovy#L27
> https://ge.gradle.org/s/mz3m6drw3kzog/console-log?task=:model-core:compileTestGroovy
> The same code works with Groovy 3.0.9, and it even compiled with Groovy 
> 4.0.0-beta-1.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (GROOVY-8788) Inconsistency in extension method selection with @CompileStatic

2022-08-23 Thread Eric Milles (Jira)


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

Eric Milles resolved GROOVY-8788.
-
Fix Version/s: 5.0.0-alpha-1
   Resolution: Fixed

https://github.com/apache/groovy/commit/14946ff27a60d74b5d07c1b9a63f02624283c863

> Inconsistency in extension method selection with @CompileStatic
> ---
>
> Key: GROOVY-8788
> URL: https://issues.apache.org/jira/browse/GROOVY-8788
> Project: Groovy
>  Issue Type: Bug
>  Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.15, 2.5.2
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
>  Labels: breaking
> Fix For: 5.0.0-alpha-1
>
>
> Given properly registered extension class:
> {code:java|title=MyExtensions.java}
> public class MyExtensions {
> public static void foo(Object self, String s) {
> System.out.println("Object#foo(String)");
> }
> public static void foo(String self, Object o) {
> System.out.println("String#foo(Object)");
> }
> }
> {code}
> Run
> {code:java|title=playground.groovy}
> void usageExt() {
> "".foo("") // prints "Object#foo(String)" which is correct
> }
> @groovy.transform.CompileStatic
> void usageExtStatic() {
> "".foo("") // prints "String#foo(Object)" which is questionable
> }
> usageExt()
> usageExtStatic()
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (GROOVY-8788) Inconsistency in extension method selection with @CompileStatic

2022-08-23 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/GROOVY-8788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17583845#comment-17583845
 ] 

ASF GitHub Bot commented on GROOVY-8788:


eric-milles merged PR #1768:
URL: https://github.com/apache/groovy/pull/1768




> Inconsistency in extension method selection with @CompileStatic
> ---
>
> Key: GROOVY-8788
> URL: https://issues.apache.org/jira/browse/GROOVY-8788
> Project: Groovy
>  Issue Type: Bug
>  Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.15, 2.5.2
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
>  Labels: breaking
>
> Given properly registered extension class:
> {code:java|title=MyExtensions.java}
> public class MyExtensions {
> public static void foo(Object self, String s) {
> System.out.println("Object#foo(String)");
> }
> public static void foo(String self, Object o) {
> System.out.println("String#foo(Object)");
> }
> }
> {code}
> Run
> {code:java|title=playground.groovy}
> void usageExt() {
> "".foo("") // prints "Object#foo(String)" which is correct
> }
> @groovy.transform.CompileStatic
> void usageExtStatic() {
> "".foo("") // prints "String#foo(Object)" which is questionable
> }
> usageExt()
> usageExtStatic()
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [groovy] eric-milles merged pull request #1768: GROOVY-8788: STC: prefer closer parameter match over receiver-type match

2022-08-23 Thread GitBox


eric-milles merged PR #1768:
URL: https://github.com/apache/groovy/pull/1768


-- 
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-10521) Compiler complains about abstract method not implemented when implementing trait

2022-08-23 Thread Eric Milles (Jira)


[ 
https://issues.apache.org/jira/browse/GROOVY-10521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17583823#comment-17583823
 ] 

Eric Milles commented on GROOVY-10521:
--

Each build pushes a snapshot: 
https://github.com/apache/groovy/actions/runs/2912982184

I don't know when the snapshot is published to groovy.jfrog.io or if that 
practice has changed.

> Compiler complains about abstract method not implemented when implementing 
> trait
> 
>
> Key: GROOVY-10521
> URL: https://issues.apache.org/jira/browse/GROOVY-10521
> Project: Groovy
>  Issue Type: Bug
>  Components: Compiler
>Affects Versions: 4.0.1
>Reporter: Lóránt Pintér
>Assignee: Eric Milles
>Priority: Major
>  Labels: traits
> Fix For: 4.0.5
>
>
> I have a trait called 
> [ProviderAssertions|https://github.com/gradle/gradle/blob/c692f2a1d2baa03f975c443ddc746d885cf84ee2/subprojects/model-core/src/testFixtures/groovy/org/gradle/api/internal/provider/ProviderAssertions.groovy]
>  that is successfully implemented by a number of {{spock.lang.Specification}} 
> types. However, when compiling this class with Groovy 4.0.1-SNAPSHOT:
> It fails with the following error:
> {code}
> :model-core:compileTestGroovy FAILED  
> Note: Some input files use or override a deprecated API.  
> Note: Recompile with -Xlint:deprecation for details.  
> Note: 
> /Users/lptr/Workspace/gradle/gradle/subprojects/model-core/src/test/groovy/org/gradle/internal/instantiation/generator/AsmBackedClassGeneratorTest.java
>  uses unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> startup failed:   
> /Users/lptr/Workspace/gradle/gradle/subprojects/model-core/src/test/groovy/org/gradle/api/internal/provider/DefaultProviderFactoryTest.groovy:
>  27: Can't have an abstract method in a non-abstract class. The class 
> 'org.gradle.api.internal.provider.DefaultProviderFactoryTest' must be 
> declared abstract or the method 'void 
> assertHasProducer(org.gradle.api.internal.provider.ProviderInternal, 
> org.gradle.api.Task, org.gradle.api.Task[])' must be implemented.
>  @ line 27, column 1. 
>class DefaultProviderFactoryTest extends Specification implements 
> ProviderAssertions { 
>^  
> 1 error   
> {code}
> https://github.com/gradle/gradle/blob/c692f2a1d2baa03f975c443ddc746d885cf84ee2/subprojects/model-core/src/test/groovy/org/gradle/api/internal/provider/DefaultProviderFactoryTest.groovy#L27
> https://ge.gradle.org/s/mz3m6drw3kzog/console-log?task=:model-core:compileTestGroovy
> The same code works with Groovy 3.0.9, and it even compiled with Groovy 
> 4.0.0-beta-1.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (GROOVY-10099) A single null argument to a varargs parameter is received as null

2022-08-23 Thread Eric Milles (Jira)


[ 
https://issues.apache.org/jira/browse/GROOVY-10099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17583790#comment-17583790
 ] 

Eric Milles commented on GROOVY-10099:
--

https://github.com/apache/groovy/commit/7824bd62fc4cc21e1a6b6b376f4835f6f6049d1a

> 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
>Reporter: Rachel Greenham
>Assignee: Eric Milles
>Priority: Major
>  Labels: varargs
> 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}
> Output seen:
> {cod

[jira] [Commented] (GROOVY-6146) Calling a Java vararg method from Groovy with a null argument cast to the vararg type behaves differently than in Java

2022-08-23 Thread Eric Milles (Jira)


[ 
https://issues.apache.org/jira/browse/GROOVY-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17583789#comment-17583789
 ] 

Eric Milles commented on GROOVY-6146:
-

https://github.com/apache/groovy/commit/7824bd62fc4cc21e1a6b6b376f4835f6f6049d1a

> 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
>Reporter: David Tonhofer
>Assignee: Eric Milles
>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.10#820010)


[jira] [Comment Edited] (GROOVY-8737) STC Method resolution fails if other methods with more parameters exist

2022-08-23 Thread Eric Milles (Jira)


[ 
https://issues.apache.org/jira/browse/GROOVY-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17583717#comment-17583717
 ] 

Eric Milles edited comment on GROOVY-8737 at 8/23/22 6:18 PM:
--

https://github.com/apache/groovy/commit/50026f1feee51c7bdf5f340100ff801d486f08e9
https://github.com/apache/groovy/commit/7824bd62fc4cc21e1a6b6b376f4835f6f6049d1a


was (Author: emilles):
https://github.com/apache/groovy/commit/50026f1feee51c7bdf5f340100ff801d486f08e9

> 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, Static Type Checker
>Affects Versions: 2.4.15, 3.0.0-alpha-3, 2.5.1
>Reporter: Patric Bechtel
>Assignee: Eric Milles
>Priority: Major
>  Labels: varargs
> Fix For: 4.0.5, 2.5.19, 3.0.13
>
>
> 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.10#820010)


[jira] [Updated] (GROOVY-8737) STC Method resolution fails if other methods with more parameters exist

2022-08-23 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-8737:

Fix Version/s: 2.5.19

> 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, Static Type Checker
>Affects Versions: 2.4.15, 3.0.0-alpha-3, 2.5.1
>Reporter: Patric Bechtel
>Assignee: Eric Milles
>Priority: Major
>  Labels: varargs
> Fix For: 4.0.5, 2.5.19, 3.0.13
>
>
> 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.10#820010)


[jira] [Updated] (GROOVY-8737) STC Method resolution fails if other methods with more parameters exist

2022-08-23 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-8737:

Fix Version/s: 3.0.13

> 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, Static Type Checker
>Affects Versions: 2.4.15, 3.0.0-alpha-3, 2.5.1
>Reporter: Patric Bechtel
>Assignee: Eric Milles
>Priority: Major
>  Labels: varargs
> Fix For: 4.0.5, 3.0.13
>
>
> 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.10#820010)


[jira] [Resolved] (GROOVY-6146) Calling a Java vararg method from Groovy with a null argument cast to the vararg type behaves differently than in Java

2022-08-23 Thread Eric Milles (Jira)


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

Eric Milles resolved GROOVY-6146.
-
Resolution: Won't Fix

GROOVY-10099 and associated pull requests have much discussion.  There is 
little that can be done without RTTI.  {{InvocationWriter}} has been updated to 
handle variadic scenarios with info available.  Static compilation is the way 
to go here.

> 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
>Reporter: David Tonhofer
>Assignee: Eric Milles
>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.10#820010)


[jira] [Assigned] (GROOVY-6146) Calling a Java vararg method from Groovy with a null argument cast to the vararg type behaves differently than in Java

2022-08-23 Thread Eric Milles (Jira)


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

Eric Milles reassigned GROOVY-6146:
---

Assignee: Eric Milles

> 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
>Reporter: David Tonhofer
>Assignee: Eric Milles
>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.10#820010)


[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

2022-08-23 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-6146:

Environment: (was: Fedora Release 17)

> 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
>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.10#820010)


[jira] [Commented] (GROOVY-10099) A single null argument to a varargs parameter is received as null

2022-08-23 Thread Eric Milles (Jira)


[ 
https://issues.apache.org/jira/browse/GROOVY-10099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17583735#comment-17583735
 ] 

Eric Milles commented on GROOVY-10099:
--

It is consistent with Java calling conventions that a {{null}} literal in the 
last position is for the array and not a single-element array.  Yes, this can 
be influenced with a typecast in Java and static Groovy.  And an expression can 
muddy the waters as well.  Long story short, the runtime lacks any info about 
the static nature of a {{null}} value.  I don't think it would be good to have 
3 sets of behaviors -- dynamic/legacy, type-checked and static compilation.

> 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
>Reporter: Rachel Greenham
>Priority: Major
>  Labels: breaking, varargs
> 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 demonst

[jira] [Assigned] (GROOVY-10099) A single null argument to a varargs parameter is received as null

2022-08-23 Thread Eric Milles (Jira)


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

Eric Milles reassigned GROOVY-10099:


Assignee: Eric Milles

> 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
>Reporter: Rachel Greenham
>Assignee: Eric Milles
>Priority: Major
>  Labels: varargs
> 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}
> Output seen:
> {code:java}
> name: the static name 1
> params is null? false
> params length is 1
> [blah]
> name: the static

[jira] [Resolved] (GROOVY-10099) A single null argument to a varargs parameter is received as null

2022-08-23 Thread Eric Milles (Jira)


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

Eric Milles resolved GROOVY-10099.
--
Resolution: Won't Fix

> 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
>Reporter: Rachel Greenham
>Assignee: Eric Milles
>Priority: Major
>  Labels: varargs
> 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}
> Output seen:
> {code:java}
> name: the static name 1
> params is null? false
> params length is 1
> [blah]
> name: the static name

[jira] [Updated] (GROOVY-10099) A single null argument to a varargs parameter is received as null

2022-08-23 Thread Eric Milles (Jira)


 [ 
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: breaking varargs)

> 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
>Reporter: Rachel Greenham
>Priority: Major
>  Labels: varargs
> 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}
> Output seen:
> {code:java}
> name: the static name 1
> params is null? false
> params length is 1
> [blah]
> name: the static name 2
> params is nul

[jira] [Updated] (GROOVY-10099) A single null argument to a varargs parameter is received as null

2022-08-23 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-10099:
-
Environment: (was: Observed on Groovy 3.0.8 on macOS Big Sur (Intel), 
but I don't think that's relevant; it'll be everywhere.)

> 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
>Reporter: Rachel Greenham
>Priority: Major
>  Labels: breaking, varargs
> 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}
> Output seen:
> {code:java}
> name: the static n

[jira] [Updated] (GROOVY-10099) A single null argument to a varargs parameter is received as null

2022-08-23 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-10099:
-
Labels: breaking varargs  (was: varargs)

> 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: breaking, varargs
> 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}
> Outpu

[jira] [Updated] (GROOVY-10099) A single null argument to a varargs parameter is received as null

2022-08-23 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-10099:
-
Fix Version/s: (was: 4.x)

> 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
> 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}
> Output seen:
> {code:java}

[GitHub] [groovy] eric-milles commented on pull request #1601: GROOVY-10099: Resolve ambiguous varargs behaviour in dynamic mode by recourse to compiler-stage information

2022-08-23 Thread GitBox


eric-milles commented on PR #1601:
URL: https://github.com/apache/groovy/pull/1601#issuecomment-1224298737

   -1 for me
   
   I will look over your tests and see about adding them to the build at least 
to demonstrate GROOVY-10099.
   
   `InvocationWriter#loadArguments` already has significant checking/handling 
for variadic situations.  And `null` is supposed to represent the array, not an 
array with one `null` element.  I think the safe advice is to use 
`@CompileStatic` if you have a scenario that passes a single nullable argument 
for the array parameter and you don't want to wrap in your code.


-- 
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



[GitHub] [groovy] eric-milles closed pull request #1601: GROOVY-10099: Resolve ambiguous varargs behaviour in dynamic mode by recourse to compiler-stage information

2022-08-23 Thread GitBox


eric-milles closed pull request #1601: GROOVY-10099: Resolve ambiguous varargs 
behaviour in dynamic mode by recourse to compiler-stage information
URL: https://github.com/apache/groovy/pull/1601


-- 
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-10099) A single null argument to a varargs parameter is received as null

2022-08-23 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/GROOVY-10099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17583728#comment-17583728
 ] 

ASF GitHub Bot commented on GROOVY-10099:
-

eric-milles commented on PR #1601:
URL: https://github.com/apache/groovy/pull/1601#issuecomment-1224298737

   -1 for me
   
   I will look over your tests and see about adding them to the build at least 
to demonstrate GROOVY-10099.
   
   `InvocationWriter#loadArguments` already has significant checking/handling 
for variadic situations.  And `null` is supposed to represent the array, not an 
array with one `null` element.  I think the safe advice is to use 
`@CompileStatic` if you have a scenario that passes a single nullable argument 
for the array parameter and you don't want to wrap in your code.




> 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 dynam

[jira] [Commented] (GROOVY-10099) A single null argument to a varargs parameter is received as null

2022-08-23 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/GROOVY-10099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17583729#comment-17583729
 ] 

ASF GitHub Bot commented on GROOVY-10099:
-

eric-milles closed pull request #1601: GROOVY-10099: Resolve ambiguous varargs 
behaviour in dynamic mode by recourse to compiler-stage information
URL: https://github.com/apache/groovy/pull/1601




> 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 
> obvi

[jira] [Commented] (GROOVY-10521) Compiler complains about abstract method not implemented when implementing trait

2022-08-23 Thread Kyle Moore (Jira)


[ 
https://issues.apache.org/jira/browse/GROOVY-10521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17583725#comment-17583725
 ] 

Kyle Moore commented on GROOVY-10521:
-

Thank you [~emilles] - is a {{4.0.5-SNAPSHOT}} build with this fix available 
yet?

> Compiler complains about abstract method not implemented when implementing 
> trait
> 
>
> Key: GROOVY-10521
> URL: https://issues.apache.org/jira/browse/GROOVY-10521
> Project: Groovy
>  Issue Type: Bug
>  Components: Compiler
>Affects Versions: 4.0.1
>Reporter: Lóránt Pintér
>Assignee: Eric Milles
>Priority: Major
>  Labels: traits
> Fix For: 4.0.5
>
>
> I have a trait called 
> [ProviderAssertions|https://github.com/gradle/gradle/blob/c692f2a1d2baa03f975c443ddc746d885cf84ee2/subprojects/model-core/src/testFixtures/groovy/org/gradle/api/internal/provider/ProviderAssertions.groovy]
>  that is successfully implemented by a number of {{spock.lang.Specification}} 
> types. However, when compiling this class with Groovy 4.0.1-SNAPSHOT:
> It fails with the following error:
> {code}
> :model-core:compileTestGroovy FAILED  
> Note: Some input files use or override a deprecated API.  
> Note: Recompile with -Xlint:deprecation for details.  
> Note: 
> /Users/lptr/Workspace/gradle/gradle/subprojects/model-core/src/test/groovy/org/gradle/internal/instantiation/generator/AsmBackedClassGeneratorTest.java
>  uses unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> startup failed:   
> /Users/lptr/Workspace/gradle/gradle/subprojects/model-core/src/test/groovy/org/gradle/api/internal/provider/DefaultProviderFactoryTest.groovy:
>  27: Can't have an abstract method in a non-abstract class. The class 
> 'org.gradle.api.internal.provider.DefaultProviderFactoryTest' must be 
> declared abstract or the method 'void 
> assertHasProducer(org.gradle.api.internal.provider.ProviderInternal, 
> org.gradle.api.Task, org.gradle.api.Task[])' must be implemented.
>  @ line 27, column 1. 
>class DefaultProviderFactoryTest extends Specification implements 
> ProviderAssertions { 
>^  
> 1 error   
> {code}
> https://github.com/gradle/gradle/blob/c692f2a1d2baa03f975c443ddc746d885cf84ee2/subprojects/model-core/src/test/groovy/org/gradle/api/internal/provider/DefaultProviderFactoryTest.groovy#L27
> https://ge.gradle.org/s/mz3m6drw3kzog/console-log?task=:model-core:compileTestGroovy
> The same code works with Groovy 3.0.9, and it even compiled with Groovy 
> 4.0.0-beta-1.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (GROOVY-8737) STC Method resolution fails if other methods with more parameters exist

2022-08-23 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-8737:

Fix Version/s: 4.0.5

> 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, Static Type Checker
>Affects Versions: 2.4.15, 3.0.0-alpha-3, 2.5.1
>Reporter: Patric Bechtel
>Assignee: Eric Milles
>Priority: Major
>  Labels: varargs
> Fix For: 4.0.5
>
>
> 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.10#820010)


[jira] [Resolved] (GROOVY-8737) STC Method resolution fails if other methods with more parameters exist

2022-08-23 Thread Eric Milles (Jira)


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

Eric Milles resolved GROOVY-8737.
-
Resolution: Fixed

https://github.com/apache/groovy/commit/50026f1feee51c7bdf5f340100ff801d486f08e9

> 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, Static Type Checker
>Affects Versions: 2.4.15, 3.0.0-alpha-3, 2.5.1
>Reporter: Patric Bechtel
>Assignee: Eric Milles
>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.10#820010)


[jira] [Updated] (GROOVY-8737) STC Method resolution fails if other methods with more parameters exist

2022-08-23 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-8737:

Environment: (was: Ubuntu 18.04, Java 8u181)

> 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
>Reporter: Patric Bechtel
>Assignee: Eric Milles
>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.10#820010)


[jira] [Updated] (GROOVY-8737) STC Method resolution fails if other methods with more parameters exist

2022-08-23 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-8737:

Component/s: Static Type Checker

> 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, Static Type Checker
>Affects Versions: 2.4.15, 3.0.0-alpha-3, 2.5.1
>Reporter: Patric Bechtel
>Assignee: Eric Milles
>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.10#820010)


[jira] [Commented] (GROOVY-8737) STC Method resolution fails if other methods with more parameters exist

2022-08-23 Thread Eric Milles (Jira)


[ 
https://issues.apache.org/jira/browse/GROOVY-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17583664#comment-17583664
 ] 

Eric Milles commented on GROOVY-8737:
-

When multiple variadic methods match the argument-parameter checks, the 
distance for vargs is smaller for longer parameter lists.  So {{msg(String key, 
Object[] args)}} is dropped as an option.

> 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
>Assignee: Eric Milles
>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.10#820010)


[jira] [Assigned] (GROOVY-8737) STC Method resolution fails if other methods with more parameters exist

2022-08-23 Thread Eric Milles (Jira)


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

Eric Milles reassigned GROOVY-8737:
---

Assignee: Eric Milles

> 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
>Assignee: Eric Milles
>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.10#820010)