[jira] [Comment Edited] (GROOVY-9272) Support switch expression
[
https://issues.apache.org/jira/browse/GROOVY-9272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17348926#comment-17348926
]
Daniel Sun edited comment on GROOVY-9272 at 5/21/21, 1:42 AM:
--
{quote}
It sounds like there was a prototype for the ClosureExpression option. Does
that still exist? That first option does still have the benefit of simplicity.
It may give Groovy most of what the Java switch expression provides.
{quote}
Yep. We already have a prototype for the ClosureExpression option in 2019/11/5.
The implementation still exists but need a little polishment, e.g. support
{{yield}}, abandon support for mixed {{:}} and {{->}}
See also: https://github.com/danielsun1106/groovy-parser/tree/switch-expression
was (Author: daniel_sun):
{quote}
It sounds like there was a prototype for the ClosureExpression option. Does
that still exist? That first option does still have the benefit of simplicity.
It may give Groovy most of what the Java switch expression provides.
{quote}
Yep. We already have a prototype for the ClosureExpression option in 2019/11/5.
The implementation still exists but need a little polishment, e.g. support
{{yield}}, abandon support for mixed {{:}} and {{->}}
> Support switch expression
> -
>
> Key: GROOVY-9272
> URL: https://issues.apache.org/jira/browse/GROOVY-9272
> Project: Groovy
> Issue Type: New Feature
>Reporter: Daniel Sun
>Priority: Major
>
> See JEP 325( [https://openjdk.java.net/jeps/325] )
> [https://blog.codefx.org/java/switch-expressions/]
> [https://dzone.com/articles/jdk-12-switch-statementsexpressions-in-action]
> [https://blog.idrsolutions.com/2019/03/java-12-switch-expressions-explained-in-5-minutes/]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-9272) Support switch expression
[
https://issues.apache.org/jira/browse/GROOVY-9272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17348926#comment-17348926
]
Daniel Sun edited comment on GROOVY-9272 at 5/21/21, 1:42 AM:
--
{quote}
It sounds like there was a prototype for the ClosureExpression option. Does
that still exist? That first option does still have the benefit of simplicity.
It may give Groovy most of what the Java switch expression provides.
{quote}
Yep. We already have a prototype for the ClosureExpression option in 2019/11/5.
The implementation still exists but need a little polishment, e.g. abandon
support for mixed {{:}} and {{->}}
See also: https://github.com/danielsun1106/groovy-parser/tree/switch-expression
was (Author: daniel_sun):
{quote}
It sounds like there was a prototype for the ClosureExpression option. Does
that still exist? That first option does still have the benefit of simplicity.
It may give Groovy most of what the Java switch expression provides.
{quote}
Yep. We already have a prototype for the ClosureExpression option in 2019/11/5.
The implementation still exists but need a little polishment, e.g. support
{{yield}}, abandon support for mixed {{:}} and {{->}}
See also: https://github.com/danielsun1106/groovy-parser/tree/switch-expression
> Support switch expression
> -
>
> Key: GROOVY-9272
> URL: https://issues.apache.org/jira/browse/GROOVY-9272
> Project: Groovy
> Issue Type: New Feature
>Reporter: Daniel Sun
>Priority: Major
>
> See JEP 325( [https://openjdk.java.net/jeps/325] )
> [https://blog.codefx.org/java/switch-expressions/]
> [https://dzone.com/articles/jdk-12-switch-statementsexpressions-in-action]
> [https://blog.idrsolutions.com/2019/03/java-12-switch-expressions-explained-in-5-minutes/]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9272) Support switch expression
[
https://issues.apache.org/jira/browse/GROOVY-9272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17348926#comment-17348926
]
Daniel Sun commented on GROOVY-9272:
{quote}
It sounds like there was a prototype for the ClosureExpression option. Does
that still exist? That first option does still have the benefit of simplicity.
It may give Groovy most of what the Java switch expression provides.
{quote}
Yep. We already have a prototype for the ClosureExpression option in 2019/11/5.
The implementation still exists but need a little polishment, e.g. support
{{yield}}, abandon support for mixed {{:}} and {{->}}
> Support switch expression
> -
>
> Key: GROOVY-9272
> URL: https://issues.apache.org/jira/browse/GROOVY-9272
> Project: Groovy
> Issue Type: New Feature
>Reporter: Daniel Sun
>Priority: Major
>
> See JEP 325( [https://openjdk.java.net/jeps/325] )
> [https://blog.codefx.org/java/switch-expressions/]
> [https://dzone.com/articles/jdk-12-switch-statementsexpressions-in-action]
> [https://blog.idrsolutions.com/2019/03/java-12-switch-expressions-explained-in-5-minutes/]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-10055) STC does not support self bounded types
[
https://issues.apache.org/jira/browse/GROOVY-10055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17348713#comment-17348713
]
Marcin Zajaczkowski commented on GROOVY-10055:
--
I believe have bumped into the same problem with:
{code:java}
WebClient.create(getBaseHttpUrl())
.get()
.uri("/path")
.accept(MediaType.APPLICATION_JSON)
.header("Authorization", "any")
Groovyc: [Static type checking] - Cannot call S#header(java.lang.String,
java.lang.String[]) with arguments [java.lang.String, groovy.lang.String{code}
accept() is defined as:
{code:java}
interface RequestHeadersSpec> {
S accept(MediaType... acceptableMediaTypes);
... {code}
When I explicitly cast the result of accept() to a typed class
(RequestHeadersSpec) the compilation passes.
It worked fine with 3.0.7 (Spock 2.0 final uses 3.0.8 which generates the
problem)
> STC does not support self bounded types
> ---
>
> Key: GROOVY-10055
> URL: https://issues.apache.org/jira/browse/GROOVY-10055
> Project: Groovy
> Issue Type: Improvement
> Components: Static compilation, Static Type Checker
>Affects Versions: 3.0.8
>Reporter: Damir Murat
>Assignee: Eric Milles
>Priority: Major
>
> Some popular libraries use self bounded types for creating builder
> hierarchies. For example,
> PostgreSQLContainer (from Tescontainers library) is declared as
> {code}
> public class PostgreSQLContainer>
> extends JdbcDatabaseContainer
> {code}
> where JdbcDatabaseContainer is declared as
> {code}
> public abstract class JdbcDatabaseContainer JdbcDatabaseContainer> extends GenericContainer implements
> LinkableContainer
> {code}
> and so on.
> In the following example (tested with Groovy Console), I'm trying to create
> and modify such an object with its corresponding fluent API:
> {code}
> import org.testcontainers.containers.PostgreSQLContainer
> import groovy.transform.CompileStatic
> @Grab("org.testcontainers:testcontainers:1.15.3")
> @Grab("org.testcontainers:postgresql:1.15.3")
> @CompileStatic
> class TestcontainersTester {
> static void testSome() {
> PostgreSQLContainer postgresqlServer = new PostgreSQLContainer()
> .withExposedPorts(5432)
> .withEnv(["TZ": "Europe/Paris"])
> .withDatabaseName("my_database")
> .withUsername("user")
> .withPassword("pass")
> // Working alternative 1
> //PostgreSQLContainer postgresqlServer = new
> PostgreSQLContainer>>>()
> //.withExposedPorts(5432)
> //.withEnv(["TZ": "Europe/Paris"])
> //.withDatabaseName("my_database")
> //.withUsername("user")
> //.withPassword("pass")
> // Working alternative 2
> //PostgreSQLContainer postgresqlServer = new PostgreSQLContainer<>()
> //postgresqlServer.withExposedPorts(5432)
> //postgresqlServer.withEnv(["TZ": "Europe/Paris"])
> //postgresqlServer.withDatabaseName("my_database")
> //postgresqlServer.withUsername("user")
> //postgresqlServer.withPassword("pass")
> println postgresqlServer
> }
> }
> TestcontainersTester.testSome();
> {code}
> Unfortunately, STC complains with several errors:
> {code}
> 4 compilation errors:
> [Static type checking] - Cannot call SELF#withEnv(java.util.Map
> ) with arguments [java.util.LinkedHashMap
> ]
> at line: 11, column: 17
> [Static type checking] - Cannot find matching method
> java.lang.Object#withDatabaseName(java.lang.String). Please check if the
> declared type is correct and if the method exists.
> at line: 12, column: 26
> [Static type checking] - Cannot find matching method
> java.lang.Object#withUsername(java.lang.String). Please check if the declared
> type is correct and if the method exists.
> at line: 13, column: 22
> [Static type checking] - Cannot find matching method
> java.lang.Object#withPassword(java.lang.String). Please check if the declared
> type is correct and if the method exists.
> at line: 9, column: 44
> {code}
> There are two working alternatives in the example. "Alternative 1" is not
> really practical, but maybe it can help with solving the issue. "Alternative
> 2" is an actual practical workaround that can be further improved by using
> the "with" method.
> Tnx
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GROOVY-10100) groovyc infers the wrong type when using a method reference of a function with varargs
[
https://issues.apache.org/jira/browse/GROOVY-10100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles reassigned GROOVY-10100:
Assignee: Eric Milles
> groovyc infers the wrong type when using a method reference of a function
> with varargs
> --
>
> Key: GROOVY-10100
> URL: https://issues.apache.org/jira/browse/GROOVY-10100
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Reporter: Thodoris Sotiropoulos
>Assignee: Eric Milles
>Priority: Major
>
> I have the following program
>
> {code:java}
> import java.util.function.Function;
> class Foo {
> public T method(Object... args) {
> return null;
> }
> }
> class Bar {
> public static void test(T a) {
> Foo x = new Foo<>();
> Function b = x::method;
> T y = b.apply(new String[] {"str"});
> }
> }
> public class Main {
> public static void main(String[] args) {
> Bar.test(1);
> }
> }
> {code}
> h3. Actual Behaviour
> {code:java}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> groovy4.groovy: 14: [Static type checking] - Cannot assign value of type
> java.lang.String[] to variable of type T
> @ line 14, column 15.
>T y = b.apply(new String[] {"str"});
> ^1 error
> {code}
> h3. Expected Behaviour
> Compile successfully
>
> Note that if I remove the `extends` from the parameterized function, the code
> compiles as expected.
>
> Tested against master
> https://github.com/apache/groovy/commit/9961a67db31f7889cfb9a927ccc26c3ece0e41b9
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GROOVY-10098) Unexpected behaviour when the return type of a closure is a type parameter
[
https://issues.apache.org/jira/browse/GROOVY-10098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles resolved GROOVY-10098.
--
Fix Version/s: 4.0.0-beta-2
Resolution: Fixed
> Unexpected behaviour when the return type of a closure is a type parameter
> --
>
> Key: GROOVY-10098
> URL: https://issues.apache.org/jira/browse/GROOVY-10098
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Reporter: Thodoris Sotiropoulos
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0-beta-2
>
>
> This may be a recent regression.
> I have the following program
> {code:java}
> class Foo {
> T f Foo(T f) {
> this.f = f
> }
> T foo() {
> Closure clos = { -> f}
> clos()
> }
> }
> {code}
> h3. Actual behaviour
> {code:java}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> test.groovy: 10: [Static type checking] - Cannot return value of type
> java.lang.Object on method returning type T
> @ line 10, column 5.
>clos()
>^1 error
> {code}
> h3. Expected behaviour
> Compile successfully
> h3. Comment
> The code works as expected if I remove the bound from the type parameter of
> class `Foo`.
>
> Tested against
> https://github.com/apache/groovy/commit/f3d030afaaae44eca567ead74e68efb932831b08
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GROOVY-10098) Unexpected behaviour when the return type of a closure is a type parameter
[
https://issues.apache.org/jira/browse/GROOVY-10098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles reassigned GROOVY-10098:
Assignee: Eric Milles
> Unexpected behaviour when the return type of a closure is a type parameter
> --
>
> Key: GROOVY-10098
> URL: https://issues.apache.org/jira/browse/GROOVY-10098
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Reporter: Thodoris Sotiropoulos
>Assignee: Eric Milles
>Priority: Major
>
> This may be a recent regression.
> I have the following program
> {code:java}
> class Foo {
> T f Foo(T f) {
> this.f = f
> }
> T foo() {
> Closure clos = { -> f}
> clos()
> }
> }
> {code}
> h3. Actual behaviour
> {code:java}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> test.groovy: 10: [Static type checking] - Cannot return value of type
> java.lang.Object on method returning type T
> @ line 10, column 5.
>clos()
>^1 error
> {code}
> h3. Expected behaviour
> Compile successfully
> h3. Comment
> The code works as expected if I remove the bound from the type parameter of
> class `Foo`.
>
> Tested against
> https://github.com/apache/groovy/commit/f3d030afaaae44eca567ead74e68efb932831b08
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-8111) Stack overflow between WideningCategories lowestUpperBound and parameterizeLowestUpperBound
[
https://issues.apache.org/jira/browse/GROOVY-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-8111:
Affects Version/s: 4.0.0-beta-1
> Stack overflow between WideningCategories lowestUpperBound and
> parameterizeLowestUpperBound
> ---
>
> Key: GROOVY-8111
> URL: https://issues.apache.org/jira/browse/GROOVY-8111
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.14, 3.0.8, 4.0.0-beta-1
>Reporter: Eric Milles
>Priority: Critical
>
> I have run into this stack overflow error a few times when editing a Groovy
> file. Consider the following:
> {code:groovy}
> // excerpt of org.apache.commons.lang3.tuple.Pair
> class Pair implements Map.Entry, Comparable>,
> Serializable {
> public final L left
> public final R right
> private Pair(final L left, final R right) {
> this.left = left
> this.right = right
> }
> static Pair of(final L left, final R right) {
> return new Pair<>(left, right)
> }
> L getKey() { left }
> R getValue() { right }
> R setValue(R value) { right }
> int compareTo(Pair that) { 0 }
> }
> @groovy.transform.TypeChecked
> def test(thing) {
> thing != null ?: Pair.of('', ['']) // STCV is trying to get LUB of boolean
> and Pair>
> }
> test(null)
> {code}
> Captured on Groovy 2.4.9:
> {code:java}
> java.lang.StackOverflowError
> at org.codehaus.groovy.ast.ClassNode.getText(ClassNode.java:1686)
> at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:813)
> at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:810)
> at
> org.codehaus.groovy.ast.ClassNode.declaresInterface(ClassNode.java:1082)
> at
> org.codehaus.groovy.ast.ClassNode.implementsInterface(ClassNode.java:1060)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.implementsInterfaceOrIsSubclassOf(StaticTypeCheckingSupport.java:798)
> at
> org.codehaus.groovy.ast.tools.GenericsUtils.extractSuperClassGenerics(GenericsUtils.java:434)
> at
> org.codehaus.groovy.ast.tools.GenericsUtils.parameterizeType(GenericsUtils.java:228)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.findGenericsTypeHolderForClass(WideningCategories.java:269)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:233)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-8111) Stack overflow between WideningCategories lowestUpperBound and parameterizeLowestUpperBound
[
https://issues.apache.org/jira/browse/GROOVY-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-8111:
Priority: Critical (was: Major)
> Stack overflow between WideningCategories lowestUpperBound and
> parameterizeLowestUpperBound
> ---
>
> Key: GROOVY-8111
> URL: https://issues.apache.org/jira/browse/GROOVY-8111
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.14, 3.0.8
>Reporter: Eric Milles
>Priority: Critical
>
> I have run into this stack overflow error a few times when editing a Groovy
> file. Consider the following:
> {code:groovy}
> // excerpt of org.apache.commons.lang3.tuple.Pair
> class Pair implements Map.Entry, Comparable>,
> Serializable {
> public final L left
> public final R right
> private Pair(final L left, final R right) {
> this.left = left
> this.right = right
> }
> static Pair of(final L left, final R right) {
> return new Pair<>(left, right)
> }
> L getKey() { left }
> R getValue() { right }
> R setValue(R value) { right }
> int compareTo(Pair that) { 0 }
> }
> @groovy.transform.TypeChecked
> def test(thing) {
> thing != null ?: Pair.of('', ['']) // STCV is trying to get LUB of boolean
> and Pair>
> }
> test(null)
> {code}
> Captured on Groovy 2.4.9:
> {code:java}
> java.lang.StackOverflowError
> at org.codehaus.groovy.ast.ClassNode.getText(ClassNode.java:1686)
> at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:813)
> at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:810)
> at
> org.codehaus.groovy.ast.ClassNode.declaresInterface(ClassNode.java:1082)
> at
> org.codehaus.groovy.ast.ClassNode.implementsInterface(ClassNode.java:1060)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.implementsInterfaceOrIsSubclassOf(StaticTypeCheckingSupport.java:798)
> at
> org.codehaus.groovy.ast.tools.GenericsUtils.extractSuperClassGenerics(GenericsUtils.java:434)
> at
> org.codehaus.groovy.ast.tools.GenericsUtils.parameterizeType(GenericsUtils.java:228)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.findGenericsTypeHolderForClass(WideningCategories.java:269)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:233)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-8111) Stack overflow between WideningCategories lowestUpperBound and parameterizeLowestUpperBound
[
https://issues.apache.org/jira/browse/GROOVY-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17348589#comment-17348589
]
Eric Milles edited comment on GROOVY-8111 at 5/20/21, 3:22 PM:
---
Finally found this again. And note this error crashed the IDE editor, so it
becomes very difficult to try and resolve.
was (Author: emilles):
Finally found this again.
> Stack overflow between WideningCategories lowestUpperBound and
> parameterizeLowestUpperBound
> ---
>
> Key: GROOVY-8111
> URL: https://issues.apache.org/jira/browse/GROOVY-8111
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.14, 3.0.8
>Reporter: Eric Milles
>Priority: Critical
>
> I have run into this stack overflow error a few times when editing a Groovy
> file. Consider the following:
> {code:groovy}
> // excerpt of org.apache.commons.lang3.tuple.Pair
> class Pair implements Map.Entry, Comparable>,
> Serializable {
> public final L left
> public final R right
> private Pair(final L left, final R right) {
> this.left = left
> this.right = right
> }
> static Pair of(final L left, final R right) {
> return new Pair<>(left, right)
> }
> L getKey() { left }
> R getValue() { right }
> R setValue(R value) { right }
> int compareTo(Pair that) { 0 }
> }
> @groovy.transform.TypeChecked
> def test(thing) {
> thing != null ?: Pair.of('', ['']) // STCV is trying to get LUB of boolean
> and Pair>
> }
> test(null)
> {code}
> Captured on Groovy 2.4.9:
> {code:java}
> java.lang.StackOverflowError
> at org.codehaus.groovy.ast.ClassNode.getText(ClassNode.java:1686)
> at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:813)
> at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:810)
> at
> org.codehaus.groovy.ast.ClassNode.declaresInterface(ClassNode.java:1082)
> at
> org.codehaus.groovy.ast.ClassNode.implementsInterface(ClassNode.java:1060)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.implementsInterfaceOrIsSubclassOf(StaticTypeCheckingSupport.java:798)
> at
> org.codehaus.groovy.ast.tools.GenericsUtils.extractSuperClassGenerics(GenericsUtils.java:434)
> at
> org.codehaus.groovy.ast.tools.GenericsUtils.parameterizeType(GenericsUtils.java:228)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.findGenericsTypeHolderForClass(WideningCategories.java:269)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:233)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-8111) Stack overflow between WideningCategories lowestUpperBound and parameterizeLowestUpperBound
[
https://issues.apache.org/jira/browse/GROOVY-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-8111:
Description:
I have run into this stack overflow error a few times when editing a Groovy
file. Consider the following:
{code:groovy}
// excerpt of org.apache.commons.lang3.tuple.Pair
class Pair implements Map.Entry, Comparable>,
Serializable {
public final L left
public final R right
private Pair(final L left, final R right) {
this.left = left
this.right = right
}
static Pair of(final L left, final R right) {
return new Pair<>(left, right)
}
L getKey() { left }
R getValue() { right }
R setValue(R value) { right }
int compareTo(Pair that) { 0 }
}
@groovy.transform.TypeChecked
def test(thing) {
thing != null ?: Pair.of('', ['']) // STCV is trying to get LUB of boolean
and Pair>
}
test(null)
{code}
Captured on Groovy 2.4.9:
{code:java}
java.lang.StackOverflowError
at org.codehaus.groovy.ast.ClassNode.getText(ClassNode.java:1686)
at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:813)
at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:810)
at
org.codehaus.groovy.ast.ClassNode.declaresInterface(ClassNode.java:1082)
at
org.codehaus.groovy.ast.ClassNode.implementsInterface(ClassNode.java:1060)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.implementsInterfaceOrIsSubclassOf(StaticTypeCheckingSupport.java:798)
at
org.codehaus.groovy.ast.tools.GenericsUtils.extractSuperClassGenerics(GenericsUtils.java:434)
at
org.codehaus.groovy.ast.tools.GenericsUtils.parameterizeType(GenericsUtils.java:228)
at
org.codehaus.groovy.ast.tools.WideningCategories.findGenericsTypeHolderForClass(WideningCategories.java:269)
at
org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:233)
at
org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
at
org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
at
org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
at
org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
at
org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
at
org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
at
org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
{code}
was:
I have run into this stack overflow error a few times when editing a Groovy
file. Consider the following:
{code:groovy}
// excerpt of org.apache.commons.lang3.tuple.Pair
class Pair implements Map.Entry, Comparable>,
Serializable {
public final L left
public final R right
private Pair(final L left, final R right) {
this.left = left
this.right = right
}
static Pair of(final L left, final R right) {
return new Pair<>(left, right)
}
L getKey() { left }
R getValue() { right }
R setValue(R value) { right }
int compareTo(Pair that) { 0 }
}
@groovy.transform.TypeChecked
def test(thing) {
thing != null ?: Pair.of('', ['']) // STCV is trying to get LUB of boolean
and Pair>
}
test(null)
{code}
The problem appears in {{WideningCategories}}' {{lowestUpperBound}} and
{{parameterizeLowestUpperBound}}.
Captured on Groovy 2.4.9:
{code:java}
java.lang.StackOverflowError
at org.codehaus.groovy.ast.ClassNode.getText(ClassNode.java:1686)
at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:813)
at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:810)
at
org.codehaus.groovy.ast.ClassNode.declaresInterface(ClassNode.java:1082)
at
org.codehaus.groovy.ast.ClassNode.implementsInterface(ClassNode.java:1060)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.implementsInterfaceOrIsSubclassOf(StaticTypeCheckingSupport.java:798)
at
org.codehaus.groovy.ast.tools.GenericsUtils.extractSuperClassGenerics(GenericsUtils.java:434)
at
org.codehaus.groovy.ast.tools.GenericsUtils.parameterizeType(GenericsUtils.java:228)
at
org.codehaus.groovy.ast.tools.WideningCategories.findGenericsTypeHolderForClass(WideningCategories.java:269)
at
org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:233)
at
org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
at
org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
at
[jira] [Updated] (GROOVY-8111) Stack overflow between WideningCategories lowestUpperBound and parameterizeLowestUpperBound
[
https://issues.apache.org/jira/browse/GROOVY-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-8111:
Affects Version/s: 3.0.8
> Stack overflow between WideningCategories lowestUpperBound and
> parameterizeLowestUpperBound
> ---
>
> Key: GROOVY-8111
> URL: https://issues.apache.org/jira/browse/GROOVY-8111
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.14, 3.0.8
>Reporter: Eric Milles
>Priority: Major
>
> I have run into this stack overflow error a few times when editing a Groovy
> file. Consider the following:
> {code:groovy}
> // excerpt of org.apache.commons.lang3.tuple.Pair
> class Pair implements Map.Entry, Comparable>,
> Serializable {
> public final L left
> public final R right
> private Pair(final L left, final R right) {
> this.left = left
> this.right = right
> }
> static Pair of(final L left, final R right) {
> return new Pair<>(left, right)
> }
> L getKey() { left }
> R getValue() { right }
> R setValue(R value) { right }
> int compareTo(Pair that) { 0 }
> }
> @groovy.transform.TypeChecked
> def test(thing) {
> thing != null ?: Pair.of('', ['']) // STCV is trying to get LUB of boolean
> and Pair>
> }
> test(null)
> {code}
> The problem appears in {{WideningCategories}}' {{lowestUpperBound}} and
> {{parameterizeLowestUpperBound}}.
> Captured on Groovy 2.4.9:
> {code:java}
> java.lang.StackOverflowError
> at org.codehaus.groovy.ast.ClassNode.getText(ClassNode.java:1686)
> at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:813)
> at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:810)
> at
> org.codehaus.groovy.ast.ClassNode.declaresInterface(ClassNode.java:1082)
> at
> org.codehaus.groovy.ast.ClassNode.implementsInterface(ClassNode.java:1060)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.implementsInterfaceOrIsSubclassOf(StaticTypeCheckingSupport.java:798)
> at
> org.codehaus.groovy.ast.tools.GenericsUtils.extractSuperClassGenerics(GenericsUtils.java:434)
> at
> org.codehaus.groovy.ast.tools.GenericsUtils.parameterizeType(GenericsUtils.java:228)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.findGenericsTypeHolderForClass(WideningCategories.java:269)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:233)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-10099) A single null argument to a varargs parameter is received as null
[
https://issues.apache.org/jira/browse/GROOVY-10099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17348592#comment-17348592
]
Rachel Greenham commented on GROOVY-10099:
--
I'll go at it at the weekend.
I was wondering if part of the original confusion/debate was because in groovy
Object[] and Object... are treated interchangeably, based simply on whether the
last parameter's type is an array type, whereas that's not the case in Java.
Therefore, in the immediate aftermath of Java getting varargs, GROOVY_1026
maybe was an attempt at keeping things behaving as they did before, for
Object[] methods.
I don't think we can tell if a Groovy method was declared with Object..., as
its Method::isVarArgs just returns true either way, but Java does let one
distinguish. If we need to reduce the footprint of the change it might be to
restrict it to calling Java classes' (does not implement GroovyObject) methods
where isVarArgs() returns true, cache that in CachedMethod because it's those
java methods that tend to assume they'll never receive null. But I expect the
first preference would be to have a simpler change that is consistent
everywhere. If it doesn't tear the world down around our ears!
> 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
> Fix For: 4.x
>
> Attachments: VarArgsTest.groovy, VarArgsTest.jsh
>
>
> (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
[jira] [Updated] (GROOVY-8111) Stack overflow between WideningCategories lowestUpperBound and parameterizeLowestUpperBound
[
https://issues.apache.org/jira/browse/GROOVY-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-8111:
Description:
I have run into this stack overflow error a few times when editing a Groovy
file. Consider the following:
{code:groovy}
// excerpt of org.apache.commons.lang3.tuple.Pair
class Pair implements Map.Entry, Comparable>,
Serializable {
public final L left
public final R right
private Pair(final L left, final R right) {
this.left = left
this.right = right
}
static Pair of(final L left, final R right) {
return new Pair<>(left, right)
}
L getKey() { left }
R getValue() { right }
R setValue(R value) { right }
int compareTo(Pair that) { 0 }
}
@groovy.transform.TypeChecked
def test(thing) {
thing != null ?: Pair.of('', ['']) // STCV is trying to get LUB of boolean
and Pair>
}
test(null)
{code}
The problem appears in {{WideningCategories}}' {{lowestUpperBound}} and
{{parameterizeLowestUpperBound}}.
Captured on Groovy 2.4.9:
{code:java}
java.lang.StackOverflowError
at org.codehaus.groovy.ast.ClassNode.getText(ClassNode.java:1686)
at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:813)
at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:810)
at
org.codehaus.groovy.ast.ClassNode.declaresInterface(ClassNode.java:1082)
at
org.codehaus.groovy.ast.ClassNode.implementsInterface(ClassNode.java:1060)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.implementsInterfaceOrIsSubclassOf(StaticTypeCheckingSupport.java:798)
at
org.codehaus.groovy.ast.tools.GenericsUtils.extractSuperClassGenerics(GenericsUtils.java:434)
at
org.codehaus.groovy.ast.tools.GenericsUtils.parameterizeType(GenericsUtils.java:228)
at
org.codehaus.groovy.ast.tools.WideningCategories.findGenericsTypeHolderForClass(WideningCategories.java:269)
at
org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:233)
at
org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
at
org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
at
org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
at
org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
at
org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
at
org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
at
org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
{code}
was:
I have run into this stack overflow error a few times when editing a Groovy
file. Consider the following:
{code:groovy}
// excerpt of org.apache.commons.lang3.tuple.Pair
class Pair implements Map.Entry, Comparable>,
Serializable {
public final L left
public final R right
private Pair(final L left, final R right) {
this.left = left
this.right = right
}
static Pair of(final L left, final R right) {
return new Pair<>(left, right)
}
L getKey() { left }
R getValue() { right }
R setValue(R value) { right }
int compareTo(Pair that) { 0 }
}
@groovy.transform.TypeChecked
def test(thing) {
thing != null ?: Pair.of('', [''])
}
test(null)
{code}
The problem appears in WideningCategories.lowestUpperBound and its callees.
Captured on Groovy 2.4.9:
{code:java}
java.lang.StackOverflowError
at org.codehaus.groovy.ast.ClassNode.getText(ClassNode.java:1686)
at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:813)
at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:810)
at
org.codehaus.groovy.ast.ClassNode.declaresInterface(ClassNode.java:1082)
at
org.codehaus.groovy.ast.ClassNode.implementsInterface(ClassNode.java:1060)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.implementsInterfaceOrIsSubclassOf(StaticTypeCheckingSupport.java:798)
at
org.codehaus.groovy.ast.tools.GenericsUtils.extractSuperClassGenerics(GenericsUtils.java:434)
at
org.codehaus.groovy.ast.tools.GenericsUtils.parameterizeType(GenericsUtils.java:228)
at
org.codehaus.groovy.ast.tools.WideningCategories.findGenericsTypeHolderForClass(WideningCategories.java:269)
at
org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:233)
at
org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
at
org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
at
[jira] [Updated] (GROOVY-8111) Stack overflow between WideningCategories lowestUpperBound and parameterizeLowestUpperBound
[
https://issues.apache.org/jira/browse/GROOVY-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-8111:
Description:
I have run into this stack overflow error a few times when editing a Groovy
file. Consider the following:
{code:groovy}
// excerpt of org.apache.commons.lang3.tuple.Pair
class Pair implements Map.Entry, Comparable>,
Serializable {
public final L left
public final R right
private Pair(final L left, final R right) {
this.left = left
this.right = right
}
static Pair of(final L left, final R right) {
return new Pair<>(left, right)
}
L getKey() { left }
R getValue() { right }
R setValue(R value) { right }
int compareTo(Pair that) { 0 }
}
@groovy.transform.TypeChecked
def test(thing) {
thing != null ?: Pair.of('', [''])
}
test(null)
{code}
The problem appears in WideningCategories.lowestUpperBound and its callees.
Captured on Groovy 2.4.9:
{code:java}
java.lang.StackOverflowError
at org.codehaus.groovy.ast.ClassNode.getText(ClassNode.java:1686)
at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:813)
at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:810)
at
org.codehaus.groovy.ast.ClassNode.declaresInterface(ClassNode.java:1082)
at
org.codehaus.groovy.ast.ClassNode.implementsInterface(ClassNode.java:1060)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.implementsInterfaceOrIsSubclassOf(StaticTypeCheckingSupport.java:798)
at
org.codehaus.groovy.ast.tools.GenericsUtils.extractSuperClassGenerics(GenericsUtils.java:434)
at
org.codehaus.groovy.ast.tools.GenericsUtils.parameterizeType(GenericsUtils.java:228)
at
org.codehaus.groovy.ast.tools.WideningCategories.findGenericsTypeHolderForClass(WideningCategories.java:269)
at
org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:233)
at
org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
at
org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
at
org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
at
org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
at
org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
at
org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
at
org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
{code}
was:
I have run into this stack overflow error a few times when editing a Groovy
file with, for example, a Map with generics specified and the value type has
generics as well.
The problem appears in WideningCategories.lowestUpperBound and its callees.
Captured on Groovy 2.4.9:
{code}
java.lang.StackOverflowError
at org.codehaus.groovy.ast.ClassNode.getText(ClassNode.java:1686)
at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:813)
at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:810)
at
org.codehaus.groovy.ast.ClassNode.declaresInterface(ClassNode.java:1082)
at
org.codehaus.groovy.ast.ClassNode.implementsInterface(ClassNode.java:1060)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.implementsInterfaceOrIsSubclassOf(StaticTypeCheckingSupport.java:798)
at
org.codehaus.groovy.ast.tools.GenericsUtils.extractSuperClassGenerics(GenericsUtils.java:434)
at
org.codehaus.groovy.ast.tools.GenericsUtils.parameterizeType(GenericsUtils.java:228)
at
org.codehaus.groovy.ast.tools.WideningCategories.findGenericsTypeHolderForClass(WideningCategories.java:269)
at
org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:233)
at
org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
at
org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
at
org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
at
org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
at
org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
at
org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
at
org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
{code}
> Stack overflow between WideningCategories lowestUpperBound and
> parameterizeLowestUpperBound
[jira] [Updated] (GROOVY-8111) Stack overflow between WideningCategories lowestUpperBound and parameterizeLowestUpperBound
[
https://issues.apache.org/jira/browse/GROOVY-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-8111:
Affects Version/s: 2.5.14
> Stack overflow between WideningCategories lowestUpperBound and
> parameterizeLowestUpperBound
> ---
>
> Key: GROOVY-8111
> URL: https://issues.apache.org/jira/browse/GROOVY-8111
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.14
>Reporter: Eric Milles
>Priority: Major
>
> I have run into this stack overflow error a few times when editing a Groovy
> file. Consider the following:
> {code:groovy}
> // excerpt of org.apache.commons.lang3.tuple.Pair
> class Pair implements Map.Entry, Comparable>,
> Serializable {
> public final L left
> public final R right
> private Pair(final L left, final R right) {
> this.left = left
> this.right = right
> }
> static Pair of(final L left, final R right) {
> return new Pair<>(left, right)
> }
> L getKey() { left }
> R getValue() { right }
> R setValue(R value) { right }
> int compareTo(Pair that) { 0 }
> }
> @groovy.transform.TypeChecked
> def test(thing) {
> thing != null ?: Pair.of('', [''])
> }
> test(null)
> {code}
> The problem appears in WideningCategories.lowestUpperBound and its callees.
> Captured on Groovy 2.4.9:
> {code:java}
> java.lang.StackOverflowError
> at org.codehaus.groovy.ast.ClassNode.getText(ClassNode.java:1686)
> at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:813)
> at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:810)
> at
> org.codehaus.groovy.ast.ClassNode.declaresInterface(ClassNode.java:1082)
> at
> org.codehaus.groovy.ast.ClassNode.implementsInterface(ClassNode.java:1060)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.implementsInterfaceOrIsSubclassOf(StaticTypeCheckingSupport.java:798)
> at
> org.codehaus.groovy.ast.tools.GenericsUtils.extractSuperClassGenerics(GenericsUtils.java:434)
> at
> org.codehaus.groovy.ast.tools.GenericsUtils.parameterizeType(GenericsUtils.java:228)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.findGenericsTypeHolderForClass(WideningCategories.java:269)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:233)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (GROOVY-8111) Stack overflow between WideningCategories lowestUpperBound and parameterizeLowestUpperBound
[
https://issues.apache.org/jira/browse/GROOVY-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles reopened GROOVY-8111:
-
Finally found this again.
> Stack overflow between WideningCategories lowestUpperBound and
> parameterizeLowestUpperBound
> ---
>
> Key: GROOVY-8111
> URL: https://issues.apache.org/jira/browse/GROOVY-8111
> Project: Groovy
> Issue Type: Bug
>Reporter: Eric Milles
>Priority: Major
>
> I have run into this stack overflow error a few times when editing a Groovy
> file with, for example, a Map with generics specified and the value type has
> generics as well.
> The problem appears in WideningCategories.lowestUpperBound and its callees.
> Captured on Groovy 2.4.9:
> {code}
> java.lang.StackOverflowError
> at org.codehaus.groovy.ast.ClassNode.getText(ClassNode.java:1686)
> at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:813)
> at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:810)
> at
> org.codehaus.groovy.ast.ClassNode.declaresInterface(ClassNode.java:1082)
> at
> org.codehaus.groovy.ast.ClassNode.implementsInterface(ClassNode.java:1060)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.implementsInterfaceOrIsSubclassOf(StaticTypeCheckingSupport.java:798)
> at
> org.codehaus.groovy.ast.tools.GenericsUtils.extractSuperClassGenerics(GenericsUtils.java:434)
> at
> org.codehaus.groovy.ast.tools.GenericsUtils.parameterizeType(GenericsUtils.java:228)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.findGenericsTypeHolderForClass(WideningCategories.java:269)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:233)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.parameterizeLowestUpperBound(WideningCategories.java:250)
> at
> org.codehaus.groovy.ast.tools.WideningCategories.lowestUpperBound(WideningCategories.java:203)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-10099) A single null argument to a varargs parameter is received as null
[
https://issues.apache.org/jira/browse/GROOVY-10099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17348559#comment-17348559
]
Paul King commented on GROOVY-10099:
If you have a fix and the test suite completes successfully bar one or more of
those specific tests in VarargsMethodTest, then I think we would be in good
shape and a PR would be very welcome including the test changes. If numerous
other things break, then I think we would have some more thinking to do before
deciding on the best fix. Up to you in that scenario, whether you want to
submit a PR at this stage.
> 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
> Fix For: 4.x
>
> Attachments: VarArgsTest.groovy, VarArgsTest.jsh
>
>
> (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
[jira] [Created] (GROOVY-10100) groovyc infers the wrong type when using a method reference of a function with varargs
Thodoris Sotiropoulos created GROOVY-10100:
--
Summary: groovyc infers the wrong type when using a method
reference of a function with varargs
Key: GROOVY-10100
URL: https://issues.apache.org/jira/browse/GROOVY-10100
Project: Groovy
Issue Type: Bug
Components: Static Type Checker
Reporter: Thodoris Sotiropoulos
I have the following program
{code:java}
import java.util.function.Function;
class Foo {
public T method(Object... args) {
return null;
}
}
class Bar {
public static void test(T a) {
Foo x = new Foo<>();
Function b = x::method;
T y = b.apply(new String[] {"str"});
}
}
public class Main {
public static void main(String[] args) {
Bar.test(1);
}
}
{code}
h3. Actual Behaviour
{code:java}
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
groovy4.groovy: 14: [Static type checking] - Cannot assign value of type
java.lang.String[] to variable of type T
@ line 14, column 15.
T y = b.apply(new String[] {"str"});
^1 error
{code}
h3. Expected Behaviour
Compile successfully
Note that if I remove the `extends` from the parameterized function, the code
compiles as expected.
Tested against master
https://github.com/apache/groovy/commit/9961a67db31f7889cfb9a927ccc26c3ece0e41b9
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-10099) A single null argument to a varargs parameter is received as null
[
https://issues.apache.org/jira/browse/GROOVY-10099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17348314#comment-17348314
]
Rachel Greenham commented on GROOVY-10099:
--
Noting that the current behaviour is deliberate and specifically tested for in
VarargsMethodTest.groovy, so that too would need to be changed, so implying
some kind of discussion on _whether_ to do so...
Should I just submit the patch, including the test change, and if so, as a PR
on GitHub?
> 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
> Fix For: 4.x
>
> Attachments: VarArgsTest.groovy, VarArgsTest.jsh
>
>
> (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
[jira] [Updated] (GROOVY-10099) A single null argument to a varargs parameter is received as null
[
https://issues.apache.org/jira/browse/GROOVY-10099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-10099:
---
Fix Version/s: 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
> Fix For: 4.x
>
> Attachments: VarArgsTest.groovy, VarArgsTest.jsh
>
>
> (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
[jira] [Updated] (GROOVY-10099) A single null argument to a varargs parameter is received as null
[
https://issues.apache.org/jira/browse/GROOVY-10099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rachel Greenham updated GROOVY-10099:
-
Description:
(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 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]
{code}
was:
(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
[jira] [Updated] (GROOVY-10099) A single null argument to a varargs parameter is received as null
[
https://issues.apache.org/jira/browse/GROOVY-10099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rachel Greenham updated GROOVY-10099:
-
Description:
(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 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]
{code}
was:
(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
[jira] [Created] (GROOVY-10099) A single null argument to a varargs parameter is received as null
Rachel Greenham created GROOVY-10099:
Summary: 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
Attachments: VarArgsTest.groovy, VarArgsTest.jsh
(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 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]
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
