[jira] [Created] (GROOVY-7841) Assert fail with @CompileStatic annotaion
paolo di tommaso created GROOVY-7841:
Summary: Assert fail with @CompileStatic annotaion
Key: GROOVY-7841
URL: https://issues.apache.org/jira/browse/GROOVY-7841
Project: Groovy
Issue Type: Bug
Affects Versions: 2.4.5
Reporter: paolo di tommaso
Priority: Minor
The following assert for a non-zero long value fails when annotated with
CompileStatic. For example:
{code}
def foo() {
long value = 17179869184
assert value, "Foo is OK"
}
@groovy.transform.CompileStatic
def bar() {
long value = 17179869184
assert value, "Bar failed"
}
foo()
bar()
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GROOVY-7841) Assert fails with @CompileStatic annotaion
[
https://issues.apache.org/jira/browse/GROOVY-7841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paolo di tommaso updated GROOVY-7841:
-
Summary: Assert fails with @CompileStatic annotaion (was: Assert fail with
@CompileStatic annotaion)
> Assert fails with @CompileStatic annotaion
> --
>
> Key: GROOVY-7841
> URL: https://issues.apache.org/jira/browse/GROOVY-7841
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.5
>Reporter: paolo di tommaso
>Priority: Minor
>
> The following assert for a non-zero long value fails when annotated with
> CompileStatic. For example:
> {code}
> def foo() {
> long value = 17179869184
> assert value, "Foo is OK"
> }
> @groovy.transform.CompileStatic
> def bar() {
> long value = 17179869184
> assert value, "Bar failed"
> }
> foo()
> bar()
> java.lang.AssertionError: Bar failed. Expression: value. Values: value =
> 17179869184
> at ConsoleScript31.bar(ConsoleScript31:10)
> at ConsoleScript31.run(ConsoleScript31:14)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7371) AST xform @Slf4j does not check level guard
[
https://issues.apache.org/jira/browse/GROOVY-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15443353#comment-15443353
]
paolo di tommaso commented on GROOVY-7371:
--
I'm getting this problem in the nextflow project
https://github.com/nextflow-io/nextflow
It's really weird, also because the generated bytecode looks fine:
{code}
public int bar() {
java.lang.Integer count = 0
if (log.isTraceEnabled()) {
log.isTraceEnabled() ? log.trace("$(count++)") : null
}
return count
}
public int foo() {
java.lang.Integer count = 0
log.isTraceEnabled() ? log.trace("$(count++)") : null
return count
}
{code}
Could be possible that for some reason the GString in the `foo` method is
evaluated to be passed as String to the `trace` method ?
> AST xform @Slf4j does not check level guard
> ---
>
> Key: GROOVY-7371
> URL: https://issues.apache.org/jira/browse/GROOVY-7371
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.3.11
>Reporter: paolo di tommaso
>Priority: Minor
>
> Groovy logging AST transformation is supposed to "wrap all calls to
> log.level() into the appropriate log.isLevelEnabled guard, depending on the
> underlying framework "
> http://groovy-lang.org/metaprogramming.html#_logging_improvements
> However the following test fails:
> {code}
> @groovy.util.logging.Slf4j
> class TestLog {
> def bar () {
> int count=0
> if( log.isTraceEnabled() ) {
> log.trace "${count++}"
> }
> return count
> }
> def foo () {
> int count=0
> log.trace "${count++}"
> return count
> }
> }
> assert new TestLog().bar() == 0
> assert new TestLog().foo() == 0
> Assertion failed:
> assert new TestLog().foo() == 0
>| | |
>| 1 false
>TestLog@416b8a53
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GROOVY-7371) AST xform @Slf4j does not check level guard
[
https://issues.apache.org/jira/browse/GROOVY-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15443353#comment-15443353
]
paolo di tommaso edited comment on GROOVY-7371 at 8/28/16 12:17 PM:
I'm getting this problem in the nextflow project
https://github.com/nextflow-io/nextflow
It's really weird, also because the generated bytecode looks fine:
{code}
public java.lang.Object bar() {
java.lang.Integer count = 0
if (log.isTraceEnabled()) {
log.isTraceEnabled() ? log.trace("$(count++)") : null
}
return count
}
public java.lang.Object foo() {
java.lang.Integer count = 0
log.isTraceEnabled() ? log.trace("$(count++)") : null
return count
}
{code}
Could be possible that for some reason the GString in the `foo` method is
evaluated to be passed as String to the `trace` method ?
was (Author: pablo72):
I'm getting this problem in the nextflow project
https://github.com/nextflow-io/nextflow
It's really weird, also because the generated bytecode looks fine:
{code}
public int bar() {
java.lang.Integer count = 0
if (log.isTraceEnabled()) {
log.isTraceEnabled() ? log.trace("$(count++)") : null
}
return count
}
public int foo() {
java.lang.Integer count = 0
log.isTraceEnabled() ? log.trace("$(count++)") : null
return count
}
{code}
Could be possible that for some reason the GString in the `foo` method is
evaluated to be passed as String to the `trace` method ?
> AST xform @Slf4j does not check level guard
> ---
>
> Key: GROOVY-7371
> URL: https://issues.apache.org/jira/browse/GROOVY-7371
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.3.11
>Reporter: paolo di tommaso
>Priority: Minor
>
> Groovy logging AST transformation is supposed to "wrap all calls to
> log.level() into the appropriate log.isLevelEnabled guard, depending on the
> underlying framework "
> http://groovy-lang.org/metaprogramming.html#_logging_improvements
> However the following test fails:
> {code}
> @groovy.util.logging.Slf4j
> class TestLog {
> def bar () {
> int count=0
> if( log.isTraceEnabled() ) {
> log.trace "${count++}"
> }
> return count
> }
> def foo () {
> int count=0
> log.trace "${count++}"
> return count
> }
> }
> assert new TestLog().bar() == 0
> assert new TestLog().foo() == 0
> Assertion failed:
> assert new TestLog().foo() == 0
>| | |
>| 1 false
>TestLog@416b8a53
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7371) AST xform @Slf4j does not check level guard
[
https://issues.apache.org/jira/browse/GROOVY-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15443401#comment-15443401
]
paolo di tommaso commented on GROOVY-7371:
--
I've found a solution, though I'm not sure to understand the reason. It turns
out the problem only arise when running a script with nextflow (that's a Groovy
based DSL).
In the custom compiler configuration I'm importing statically a class that is
annotated with the `Slf4j` annotation.
https://github.com/nextflow-io/nextflow/blob/ig_job_stealing/src/main/groovy/nextflow/script/ScriptRunner.groovy#L263
This is causing the bizarre side effect. Renaming the logger name in the class
statically imported solves the problem.
> AST xform @Slf4j does not check level guard
> ---
>
> Key: GROOVY-7371
> URL: https://issues.apache.org/jira/browse/GROOVY-7371
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.3.11
>Reporter: paolo di tommaso
>Priority: Minor
>
> Groovy logging AST transformation is supposed to "wrap all calls to
> log.level() into the appropriate log.isLevelEnabled guard, depending on the
> underlying framework "
> http://groovy-lang.org/metaprogramming.html#_logging_improvements
> However the following test fails:
> {code}
> @groovy.util.logging.Slf4j
> class TestLog {
> def bar () {
> int count=0
> if( log.isTraceEnabled() ) {
> log.trace "${count++}"
> }
> return count
> }
> def foo () {
> int count=0
> log.trace "${count++}"
> return count
> }
> }
> assert new TestLog().bar() == 0
> assert new TestLog().foo() == 0
> Assertion failed:
> assert new TestLog().foo() == 0
>| | |
>| 1 false
>TestLog@416b8a53
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-8237) Invalid type inference when using CompileStatic annotation
[
https://issues.apache.org/jira/browse/GROOVY-8237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062310#comment-16062310
]
paolo di tommaso commented on GROOVY-8237:
--
It seems the same as https://issues.apache.org/jira/browse/GROOVY-8220
> Invalid type inference when using CompileStatic annotation
> --
>
> Key: GROOVY-8237
> URL: https://issues.apache.org/jira/browse/GROOVY-8237
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: paolo di tommaso
>
> With Groovy 2.4.12 the following snippet report an error
> {code}
> @groovy.transform.CompileStatic
> class Foo {
> String parse(Reader reader) {
> if ( reader == null ) {
> reader = new BufferedReader(reader)
> }
>
> def c
> while ((c = reader.read()) != -1)
>print c as char
> }
> }
> new Foo().parse( new StringReader('abc') )
> {code}
> The following exception is thrown
> {code}
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object 'java.io.StringReader@7a636960' with class 'java.io.StringReader' to
> class 'java.io.BufferedReader'
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (GROOVY-8237) Invalid type inference when using CompileStatic annotation
paolo di tommaso created GROOVY-8237:
Summary: Invalid type inference when using CompileStatic annotation
Key: GROOVY-8237
URL: https://issues.apache.org/jira/browse/GROOVY-8237
Project: Groovy
Issue Type: Bug
Affects Versions: 2.4.12
Reporter: paolo di tommaso
With Groovy 2.4.12 the following snippet report an error
{code}
@groovy.transform.CompileStatic
class Foo {
String parse(Reader reader) {
if ( reader == null ) {
reader = new BufferedReader(reader)
}
def c
while ((c = reader.read()) != -1)
print c as char
}
}
new Foo().parse( new StringReader('abc') )
{code}
The following exception is thrown
{code}
org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
object 'java.io.StringReader@7a636960' with class 'java.io.StringReader' to
class 'java.io.BufferedReader'
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (GROOVY-8220) GroovyCastException with CompileStatic
paolo di tommaso created GROOVY-8220:
Summary: GroovyCastException with CompileStatic
Key: GROOVY-8220
URL: https://issues.apache.org/jira/browse/GROOVY-8220
Project: Groovy
Issue Type: Bug
Affects Versions: 2.5.0-beta-1
Reporter: paolo di tommaso
{code}
@groovy.transform.CompileStatic
class Foo {
CharSequence makeEnv( env, StringBuilder result = new StringBuilder() ) {
if( env instanceof File ) {
env = env.toPath()
}
if( env instanceof String && env.contains('=') ) {
result << 'export ' << env << ';'
}
return result.toString()
}
}
assert new Foo().makeEnv('X=1') == 'export X=1;'
Exception thrown
org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
object 'X=1' with class 'java.lang.String' to class 'java.lang.Iterable'
at Foo.makeEnv(ConsoleScript5:10)
at Foo.makeEnv(ConsoleScript5:4)
at Foo$makeEnv.call(Unknown Source)
at ConsoleScript5.run(ConsoleScript5:20)
{code}
Without CompileStatic it works as expected.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (GROOVY-8237) Invalid type inference when using CompileStatic annotation
[
https://issues.apache.org/jira/browse/GROOVY-8237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16176015#comment-16176015
]
paolo di tommaso commented on GROOVY-8237:
--
Is this patch already merged? Related build still fails. See
http://ci.groovy-lang.org/viewLog.html?buildId=42628=JointBuilds_Nextflow_Groovy24xJointBuild=buildLog
> Invalid type inference when using CompileStatic annotation
> --
>
> Key: GROOVY-8237
> URL: https://issues.apache.org/jira/browse/GROOVY-8237
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: paolo di tommaso
>
> With Groovy 2.4.12 the following snippet report an error
> {code}
> @groovy.transform.CompileStatic
> class Foo {
> String parse(Reader reader) {
> if ( reader == null ) { // != works okay
> reader = new BufferedReader(reader)
> }
>
> def c
> while ((c = reader.read()) != -1)
>print c as char
> }
> }
> new Foo().parse( new StringReader('abc') )
> {code}
> The following exception is thrown
> {code}
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object 'java.io.StringReader@7a636960' with class 'java.io.StringReader' to
> class 'java.io.BufferedReader'
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (GROOVY-8220) GroovyCastException with CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16183715#comment-16183715
]
paolo di tommaso edited comment on GROOVY-8220 at 9/28/17 6:09 AM:
---
Yes, now the CI build is
[green|http://ci.groovy-lang.org/viewLog.html?buildTypeId=JointBuilds_Nextflow_Groovy24xJointBuild=42830]!
Thanks you all.
was (Author: pablo72):
Yes, the the CI build is
[green|http://ci.groovy-lang.org/viewLog.html?buildTypeId=JointBuilds_Nextflow_Groovy24xJointBuild=42830]!
Thanks you all.
> GroovyCastException with CompileStatic
> --
>
> Key: GROOVY-8220
> URL: https://issues.apache.org/jira/browse/GROOVY-8220
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.0-beta-1, 2.4.12
>Reporter: paolo di tommaso
>Assignee: John Wagenleitner
> Fix For: 2.4.13
>
>
> {code}
> @groovy.transform.CompileStatic
> class Foo {
> CharSequence makeEnv( env, StringBuilder result = new StringBuilder() ) {
> if( env instanceof File ) {
> env = env.toPath()
> }
> if( env instanceof String && env.contains('=') ) {
> result << 'export ' << env << ';'
> }
> return result.toString()
> }
> }
> assert new Foo().makeEnv('X=1') == 'export X=1;'
> Exception thrown
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object 'X=1' with class 'java.lang.String' to class 'java.lang.Iterable'
> at Foo.makeEnv(ConsoleScript5:10)
> at Foo.makeEnv(ConsoleScript5:4)
> at Foo$makeEnv.call(Unknown Source)
> at ConsoleScript5.run(ConsoleScript5:20)
> {code}
> Without CompileStatic it works as expected.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8220) GroovyCastException with CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16183715#comment-16183715
]
paolo di tommaso commented on GROOVY-8220:
--
Yes, the the CI build is
[green|http://ci.groovy-lang.org/viewLog.html?buildTypeId=JointBuilds_Nextflow_Groovy24xJointBuild=42830]!
Thanks you all.
> GroovyCastException with CompileStatic
> --
>
> Key: GROOVY-8220
> URL: https://issues.apache.org/jira/browse/GROOVY-8220
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.0-beta-1, 2.4.12
>Reporter: paolo di tommaso
>Assignee: John Wagenleitner
> Fix For: 2.4.13
>
>
> {code}
> @groovy.transform.CompileStatic
> class Foo {
> CharSequence makeEnv( env, StringBuilder result = new StringBuilder() ) {
> if( env instanceof File ) {
> env = env.toPath()
> }
> if( env instanceof String && env.contains('=') ) {
> result << 'export ' << env << ';'
> }
> return result.toString()
> }
> }
> assert new Foo().makeEnv('X=1') == 'export X=1;'
> Exception thrown
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object 'X=1' with class 'java.lang.String' to class 'java.lang.Iterable'
> at Foo.makeEnv(ConsoleScript5:10)
> at Foo.makeEnv(ConsoleScript5:4)
> at Foo$makeEnv.call(Unknown Source)
> at ConsoleScript5.run(ConsoleScript5:20)
> {code}
> Without CompileStatic it works as expected.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8346) The variable [XXX] may be uninitialized
[
https://issues.apache.org/jira/browse/GROOVY-8346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16195668#comment-16195668
]
paolo di tommaso commented on GROOVY-8346:
--
(y)
> The variable [XXX] may be uninitialized
>
>
> Key: GROOVY-8346
> URL: https://issues.apache.org/jira/browse/GROOVY-8346
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.0-beta-1, 2.5.0-beta-2
>Reporter: paolo di tommaso
>
> I'm getting several errors when compiling Groovy 2.5.0-beta-2 (and beta-1)
> related to final variable initialisations.
> For example:
> {code}
> [:compileTestGroovy] WorkflowMetadataTest.groovy: 43: The variable [begin]
> may be uninitialized
> [:compileTestGroovy] . At [43:15] @ line 43, column 15.
> [:compileTestGroovy]final begin = new Date()
> [:compileTestGroovy] ^
> {code}
> Related to the following line
> {code}
> final begin = new Date()
> {code}
> See also
> [here|https://github.com/nextflow-io/nextflow/blob/master/src/test/groovy/nextflow/script/WorkflowMetadataTest.groovy#L43-43],
>
> [here|https://github.com/nextflow-io/nextflow/blob/master/src/test/groovy/nextflow/file/SequentialFileStoreTest.groovy#L40-40]
>
> [here|https://github.com/nextflow-io/nextflow/blob/master/src/test/groovy/nextflow/cloud/CloudConfigTest.groovy#L299-299]
> and
> [here|https://github.com/nextflow-io/nextflow/blob/master/src/test/groovy/nextflow/processor/PublishDirTest.groovy#L96-96]
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8346) The variable [XXX] may be uninitialized
[
https://issues.apache.org/jira/browse/GROOVY-8346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16195662#comment-16195662
]
paolo di tommaso commented on GROOVY-8346:
--
If so, why is it working with 2.4.x ?
> The variable [XXX] may be uninitialized
>
>
> Key: GROOVY-8346
> URL: https://issues.apache.org/jira/browse/GROOVY-8346
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.0-beta-1, 2.5.0-beta-2
>Reporter: paolo di tommaso
>
> I'm getting several errors when compiling Groovy 2.5.0-beta-2 (and beta-1)
> related to final variable initialisations.
> For example:
> {code}
> [:compileTestGroovy] WorkflowMetadataTest.groovy: 43: The variable [begin]
> may be uninitialized
> [:compileTestGroovy] . At [43:15] @ line 43, column 15.
> [:compileTestGroovy]final begin = new Date()
> [:compileTestGroovy] ^
> {code}
> Related to the following line
> {code}
> final begin = new Date()
> {code}
> See also
> [here|https://github.com/nextflow-io/nextflow/blob/master/src/test/groovy/nextflow/script/WorkflowMetadataTest.groovy#L43-43],
>
> [here|https://github.com/nextflow-io/nextflow/blob/master/src/test/groovy/nextflow/file/SequentialFileStoreTest.groovy#L40-40]
>
> [here|https://github.com/nextflow-io/nextflow/blob/master/src/test/groovy/nextflow/cloud/CloudConfigTest.groovy#L299-299]
> and
> [here|https://github.com/nextflow-io/nextflow/blob/master/src/test/groovy/nextflow/processor/PublishDirTest.groovy#L96-96]
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (GROOVY-8346) The variable [XXX] may be uninitialized
paolo di tommaso created GROOVY-8346:
Summary: The variable [XXX] may be uninitialized
Key: GROOVY-8346
URL: https://issues.apache.org/jira/browse/GROOVY-8346
Project: Groovy
Issue Type: Bug
Affects Versions: 2.5.0-beta-2, 2.5.0-beta-1
Reporter: paolo di tommaso
I'm getting several errors when compiling Groovy 2.5.0-beta-2 (and beta-1)
related to final variable initialisations.
For example:
{code}
[:compileTestGroovy] WorkflowMetadataTest.groovy: 43: The variable [begin] may
be uninitialized
[:compileTestGroovy] . At [43:15] @ line 43, column 15.
[:compileTestGroovy]final begin = new Date()
[:compileTestGroovy] ^
{code}
Related to the following line
{code}
final begin = new Date()
{code}
See also
[here|https://github.com/nextflow-io/nextflow/blob/master/src/test/groovy/nextflow/script/WorkflowMetadataTest.groovy#L43-43],
[here|https://github.com/nextflow-io/nextflow/blob/master/src/test/groovy/nextflow/file/SequentialFileStoreTest.groovy#L40-40]
[here|https://github.com/nextflow-io/nextflow/blob/master/src/test/groovy/nextflow/cloud/CloudConfigTest.groovy#L299-299]
and
[here|https://github.com/nextflow-io/nextflow/blob/master/src/test/groovy/nextflow/processor/PublishDirTest.groovy#L96-96]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (GROOVY-8390) ConfigSlurm
paolo di tommaso created GROOVY-8390:
Summary: ConfigSlurm
Key: GROOVY-8390
URL: https://issues.apache.org/jira/browse/GROOVY-8390
Project: Groovy
Issue Type: Bug
Affects Versions: 2.4.12
Reporter: paolo di tommaso
Priority: Minor
The following config snippet returns an invalid config object:
{code}
def CFG = '''
alpha.container = 'foo'
profiles { alpha.container='bar' }
'''
ConfigObject obj = new ConfigSlurper().parse(CFG)
assert obj.alpha.container == 'foo'
assert obj.profiles.alpha.container == 'bar'
{code}
it prints the following error:
{code}
Assertion failed:
assert obj.alpha.container == 'foo'
| | | |
| | bar false
| [container:bar]
[alpha:[container:bar], profiles:[:]]
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (GROOVY-8390) ConfigSlurm returns an invalid config object
[
https://issues.apache.org/jira/browse/GROOVY-8390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paolo di tommaso updated GROOVY-8390:
-
Summary: ConfigSlurm returns an invalid config object (was: ConfigSlurm )
> ConfigSlurm returns an invalid config object
> -
>
> Key: GROOVY-8390
> URL: https://issues.apache.org/jira/browse/GROOVY-8390
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: paolo di tommaso
>Priority: Minor
>
> The following config snippet returns an invalid config object:
> {code}
> def CFG = '''
> alpha.container = 'foo'
> profiles { alpha.container='bar' }
> '''
> ConfigObject obj = new ConfigSlurper().parse(CFG)
> assert obj.alpha.container == 'foo'
> assert obj.profiles.alpha.container == 'bar'
> {code}
> it prints the following error:
> {code}
> Assertion failed:
> assert obj.alpha.container == 'foo'
>| | | |
>| | bar false
>| [container:bar]
>[alpha:[container:bar], profiles:[:]]
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (GROOVY-8571) Variable [XXX] is declared final but is reassigned false positive error
paolo di tommaso created GROOVY-8571:
Summary: Variable [XXX] is declared final but is reassigned false
positive error
Key: GROOVY-8571
URL: https://issues.apache.org/jira/browse/GROOVY-8571
Project: Groovy
Issue Type: Bug
Affects Versions: 2.5.0-rc-2
Reporter: paolo di tommaso
Groovy version 2.5.0-rc-2 may report false positive final variable reassignment
compilation errors.
For example:
{code}
MailerTest.groovy: -1: The variable [PORT] is declared final but is reassigned
{code}
The source code is available at [this
link|https://github.com/nextflow-io/nextflow/blob/90f8dcc5d413af06a76e8f7b3e37c5616f721024/src/test/groovy/nextflow/mail/MailerTest.groovy#L120].
To replicate the issue follow these steps
{code}
git clone https://github.com/nextflow-io/nextflow.git
cd nextflow
CI_GROOVY_VERSION=2.5.0-rc-2 make clean compile test
{code}
Curiously, the CI server build is [reporting a slight version of the same
issue|http://ci.groovy-lang.org/viewLog.html?buildId=49488=buildResultsDiv=JointBuilds_Nextflow_Groovy25xJointBuild#]
including sometimes the correct line number instead of -1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8595) Expected parameter of type XXX but got YYY static compile error
paolo di tommaso created GROOVY-8595:
Summary: Expected parameter of type XXX but got YYY static compile
error
Key: GROOVY-8595
URL: https://issues.apache.org/jira/browse/GROOVY-8595
Project: Groovy
Issue Type: Bug
Components: Static compilation
Affects Versions: 2.5.0-rc-3
Reporter: paolo di tommaso
The following code report a compilation error:
{code:java}
@CompileStatic
class Test {
List foo() {
return []
}
List bar() {
return foo().collect { Foo it -> it.instanceId }
}
}
@CompileStatic
class Foo {
String instanceId
}{code}
Error message
{code:java}
Test.groovy: 36: Expected parameter of type java.lang.String but got
nextflow.Foo
@ line 36, column 32.
return foo().collect { Foo it -> it.instanceId }
^
Test.groovy: 36: [Static type checking] - No such property: instanceId for
class: java.lang.String
@ line 36, column 42.
urn foo().collect { Foo it -> it.instanc{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8571) Variable [XXX] is declared final but is reassigned false positive error
[
https://issues.apache.org/jira/browse/GROOVY-8571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16481239#comment-16481239
]
paolo di tommaso commented on GROOVY-8571:
--
I see, but why the above code would fail? The first time the x is declared but
*not* assigned. Therefore it should be fine to have `x = 'foo'` in the
following line.
> Variable [XXX] is declared final but is reassigned false positive error
> ---
>
> Key: GROOVY-8571
> URL: https://issues.apache.org/jira/browse/GROOVY-8571
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.0-rc-2
>Reporter: paolo di tommaso
>Priority: Major
>
> Groovy version 2.5.0-rc-2 may report false positive final variable
> reassignment compilation errors.
> For example:
> {code}
> MailerTest.groovy: -1: The variable [PORT] is declared final but is reassigned
> {code}
> The source code is available at [this
> link|https://github.com/nextflow-io/nextflow/blob/90f8dcc5d413af06a76e8f7b3e37c5616f721024/src/test/groovy/nextflow/mail/MailerTest.groovy#L120].
>
> To replicate the issue follow these steps
> {code}
> git clone https://github.com/nextflow-io/nextflow.git
> cd nextflow
> CI_GROOVY_VERSION=2.5.0-rc-2 make clean compile test
> {code}
> Curiously, the CI server build is [reporting a slight version of the same
> issue|http://ci.groovy-lang.org/viewLog.html?buildId=49488=buildResultsDiv=JointBuilds_Nextflow_Groovy25xJointBuild#]
> including sometimes the correct line number instead of -1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8640) Cannot find matching comparator method
paolo di tommaso created GROOVY-8640:
Summary: Cannot find matching comparator method
Key: GROOVY-8640
URL: https://issues.apache.org/jira/browse/GROOVY-8640
Project: Groovy
Issue Type: Bug
Components: Static compilation
Affects Versions: 2.5.0
Reporter: paolo di tommaso
The following class static compilation fails
{code:java}
@CompileStatic
class Test {
static private int MAX_LINES = 100
private static class Nested {
@Delegate
private Map delegate = [:]
private String fetch(Path path) {
int c=0
def result = new StringBuilder()
path.withReader { reader ->
String line
while( (line=reader.readLine()) && c++
[jira] [Reopened] (GROOVY-8595) Expected parameter of type XXX but got YYY static compile error
[
https://issues.apache.org/jira/browse/GROOVY-8595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paolo di tommaso reopened GROOVY-8595:
--
The problem is still there when using the spread operator, eg:
{code:java}
@CompileStatic
class Test {
List foo() {
return []
}
List bar() {
return foo() *. instanceId
}
}{code}
Tested with 2.5.0
> Expected parameter of type XXX but got YYY static compile error
> ---
>
> Key: GROOVY-8595
> URL: https://issues.apache.org/jira/browse/GROOVY-8595
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.5.0-rc-3
>Reporter: paolo di tommaso
>Assignee: John Wagenleitner
>Priority: Major
> Fix For: 2.6.0-alpha-4, 3.0.0-alpha-3, 2.5.0
>
>
> The following code report a compilation error:
> {code:java}
> @CompileStatic
> class Test {
> List foo() {
> return []
> }
> List bar() {
> return foo().collect { Foo it -> it.instanceId }
> }
> }
> @CompileStatic
> class Foo {
> String instanceId
> }{code}
>
> Error message
> {code:java}
> Test.groovy: 36: Expected parameter of type java.lang.String but got
> nextflow.Foo
> @ line 36, column 32.
> return foo().collect { Foo it -> it.instanceId }
> ^
> Test.groovy: 36: [Static type checking] - No such property: instanceId for
> class: java.lang.String
> @ line 36, column 42.
> urn foo().collect { Foo it -> it.instanc{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8564) Added support for Java like raw string literals
[
https://issues.apache.org/jira/browse/GROOVY-8564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paolo di tommaso updated GROOVY-8564:
-
Description:
Upcoming version of Java will include a new syntax for raw string literals
using back tick character as string delimiter. For example:
{noformat}
String s = `Doesn't have a \n newline character in it`;
String ss = `a multi-
line-string`;
String sss = ``a string with a single tick (`) character in it``;
String = `a string with two ticks (``) in it`;
String s = `a string literal with gratuitously many ticks
in its delimiter`;{noformat}
You can read more at [this
thread|http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-March/000446.html]
and the [official proposal page|http://openjdk.java.net/jeps/326].
The main difference compared to the Groovy multi-line string literals is that
raw string literals do not require to escape special characters, such as `\`,
`\n`, etc. The string is assigned to the variable exactly how is typed. This
makes it very useful for Groovy based DSL.
was:
Upcoming version of Java will include a new syntax for raw string literals
using back tick character as string delimiter. For example:
{noformat}
String s = `Doesn't have a \n newline character in it`;
String ss = `a multi-
line-string`;
String sss = ``a string with a single tick (`) character in it``;
String = `a string with two ticks (``) in it`;
String s = `a string literal with gratuitously many ticks
in its delimiter`;{noformat}
You can read more in [this
thread|http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-March/000446.html]
and the [official proposal page|http://openjdk.java.net/jeps/326].
The main difference compared to the Groovy multi-line string literals is that
raw string literals do not require to escape special characters, such as `\`,
`\n`, etc. The string is assigned to the variable exactly how is typed. This
makes it very useful for Groovy based DSL.
> Added support for Java like raw string literals
> ---
>
> Key: GROOVY-8564
> URL: https://issues.apache.org/jira/browse/GROOVY-8564
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-3
>Reporter: paolo di tommaso
>Priority: Major
>
> Upcoming version of Java will include a new syntax for raw string literals
> using back tick character as string delimiter. For example:
>
> {noformat}
> String s = `Doesn't have a \n newline character in it`;
> String ss = `a multi-
> line-string`;
> String sss = ``a string with a single tick (`) character in it``;
> String = `a string with two ticks (``) in it`;
> String s = `a string literal with gratuitously many ticks
> in its delimiter`;{noformat}
>
> You can read more at [this
> thread|http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-March/000446.html]
> and the [official proposal page|http://openjdk.java.net/jeps/326].
> The main difference compared to the Groovy multi-line string literals is that
> raw string literals do not require to escape special characters, such as `\`,
> `\n`, etc. The string is assigned to the variable exactly how is typed. This
> makes it very useful for Groovy based DSL.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8564) Added support for Java like raw string literals
[
https://issues.apache.org/jira/browse/GROOVY-8564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paolo di tommaso updated GROOVY-8564:
-
Description:
Upcoming version of Java will include a new syntax for raw string literals
using back tick character as string delimiter. For example:
{noformat}
String s = `Doesn't have a \n newline character in it`;
String ss = `a multi-
line-string`;
String sss = ``a string with a single tick (`) character in it``;
String = `a string with two ticks (``) in it`;
String s = `a string literal with gratuitously many ticks
in its delimiter`;{noformat}
You can read more in [this
thread|http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-March/000446.html]
and the [official proposal page|http://openjdk.java.net/jeps/326].
The main difference compared to the Groovy multi-line string literals is that
raw string literals do not require to escape special characters, such as `\`,
`\n`, etc. The string is assigned to the variable exactly how is typed. This
makes it very useful for Groovy based DSL.
was:
Upcoming version of Java will include a new syntax for raw string literals
using back tick character as string delimiter. For example:
{noformat}
String s = `Doesn't have a \n newline character in it`;
String ss = `a multi-
line-string`;
String sss = ``a string with a single tick (`) character in it``;
String = `a string with two ticks (``) in it`;
String s = `a string literal with gratuitously many ticks
in its delimiter`;{noformat}
You can read more in [this
thread|http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-March/000446.html]
and the [official proposal page|http://openjdk.java.net/jeps/326].
The main difference compared to the Groovy multi-line string literals is that
raw string literals do not require to escape special characters, such as `\`,
`\n`, etc. The string is assigned to the variable exactly how is typed. This
makes it very useful for groovy based DSL.
> Added support for Java like raw string literals
> ---
>
> Key: GROOVY-8564
> URL: https://issues.apache.org/jira/browse/GROOVY-8564
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-3
>Reporter: paolo di tommaso
>Priority: Major
>
> Upcoming version of Java will include a new syntax for raw string literals
> using back tick character as string delimiter. For example:
>
> {noformat}
> String s = `Doesn't have a \n newline character in it`;
> String ss = `a multi-
> line-string`;
> String sss = ``a string with a single tick (`) character in it``;
> String = `a string with two ticks (``) in it`;
> String s = `a string literal with gratuitously many ticks
> in its delimiter`;{noformat}
>
> You can read more in [this
> thread|http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-March/000446.html]
> and the [official proposal page|http://openjdk.java.net/jeps/326].
> The main difference compared to the Groovy multi-line string literals is that
> raw string literals do not require to escape special characters, such as `\`,
> `\n`, etc. The string is assigned to the variable exactly how is typed. This
> makes it very useful for Groovy based DSL.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8564) Added support for Java like raw string literals
paolo di tommaso created GROOVY-8564:
Summary: Added support for Java like raw string literals
Key: GROOVY-8564
URL: https://issues.apache.org/jira/browse/GROOVY-8564
Project: Groovy
Issue Type: Bug
Affects Versions: 3.0.0-alpha-3
Reporter: paolo di tommaso
Upcoming version of Java will include a new syntax for raw string literals
using back tick character as string delimiter. For example:
{noformat}
String s = `Doesn't have a \n newline character in it`;
String ss = `a multi-
line-string`;
String sss = ``a string with a single tick (`) character in it``;
String = `a string with two ticks (``) in it`;
String s = `a string literal with gratuitously many ticks
in its delimiter`;{noformat}
You can read more in [this
thread|http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-March/000446.html]
and the [official proposal page|http://openjdk.java.net/jeps/326].
The main difference compared to the Groovy multi-line string literals is that
raw string literals do not require to escape special characters, such as `\`,
`\n`, etc. The string is assigned to the variable exactly how is typed. This
makes it very useful for groovy based DSL.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-7409) Closure reference a wrong object when is defining inside an iterator
[
https://issues.apache.org/jira/browse/GROOVY-7409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337958#comment-16337958
]
paolo di tommaso commented on GROOVY-7409:
--
Just hit one more time this issue. It's quite nasty because it introduce a
trick behaviour to debug.
> Closure reference a wrong object when is defining inside an iterator
> -
>
> Key: GROOVY-7409
> URL: https://issues.apache.org/jira/browse/GROOVY-7409
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.3.11, 2.4.3
>Reporter: paolo di tommaso
>Priority: Critical
>
> A closure defined inside an iterator containing a reference to the iterating
> item resolves a wrong object instance.
> To reproduce the error take in consideration the following snippet:
> {code}
> interface Alpha {
> abstract void m()
> }
> class Foo implements Alpha {
> void m() { println 'foo' }
> }
> class Bar implements Alpha {
> void m() { println 'bar' }
> }
> List list = [new Foo(), new Bar()]
> def hooks = []
> for( def item : list ) {
> hooks.add { item.m() }
> }
> hooks.each { it.call() }
> {code}
> It prints
> {code}
> bar
> bar
> {code}
> Replacing the `for` iterator with a `for( int i=0; etc ) .. ` prints
> correctly:
> {code}
> foo
> bar
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8716) Could not find matching constructor for java.util.List()
[
https://issues.apache.org/jira/browse/GROOVY-8716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16561746#comment-16561746
]
paolo di tommaso commented on GROOVY-8716:
--
That's good!
> Could not find matching constructor for java.util.List()
>
>
> Key: GROOVY-8716
> URL: https://issues.apache.org/jira/browse/GROOVY-8716
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.1
>Reporter: paolo di tommaso
>Priority: Major
>
> The following Spock test fail
>
> {code:java}
> class Foo extends Specification {
> def 'should create a list' () {
> given:
> def folder = null
> when:
> List results = []
> then:
> true
> cleanup:
> folder?.deleteDir()
> }
> }{code}
>
> The reported error is
> {code:java}
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object '[]' with class 'java.util.LinkedHashSet' to class 'java.util.List'
> due to: groovy.lang.GroovyRuntimeException: Could not find matching
> constructor for: java.util.List()
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8716) Could not find matching constructor for java.util.List()
[
https://issues.apache.org/jira/browse/GROOVY-8716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16559332#comment-16559332
]
paolo di tommaso commented on GROOVY-8716:
--
Even more strange, I've just realised that the error is caused by another
method in the same class. For example:
{code:java}
class FooTest extends Specification {
def 'should create a set' () {
given:
def folder = null
when:
Set results = []
then:
true
cleanup:
folder?.deleteDir()
}
def 'should create a list' () {
given:
def folder = null
when:
List results = []
then:
true
cleanup:
folder?.deleteDir()
}
}
{code}
I've created a GitHub project that replicates the issue at the following link
https://github.com/pditommaso/groovy-issue-8716.
> Could not find matching constructor for java.util.List()
>
>
> Key: GROOVY-8716
> URL: https://issues.apache.org/jira/browse/GROOVY-8716
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.1
>Reporter: paolo di tommaso
>Priority: Major
>
> The following Spock test fail
>
> {code:java}
> class Foo extends Specification {
> def 'should create a list' () {
> given:
> def folder = null
> when:
> List results = []
> then:
> true
> cleanup:
> folder?.deleteDir()
> }
> }{code}
>
> The reported error is
> {code:java}
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object '[]' with class 'java.util.LinkedHashSet' to class 'java.util.List'
> due to: groovy.lang.GroovyRuntimeException: Could not find matching
> constructor for: java.util.List()
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8716) Could not find matching constructor for java.util.List()
paolo di tommaso created GROOVY-8716:
Summary: Could not find matching constructor for java.util.List()
Key: GROOVY-8716
URL: https://issues.apache.org/jira/browse/GROOVY-8716
Project: Groovy
Issue Type: Bug
Affects Versions: 2.5.1
Reporter: paolo di tommaso
The following Spock test fail
{code:java}
class Foo extends Specification {
def 'should create a list' () {
given:
def folder = null
when:
List results = []
then:
true
cleanup:
folder?.deleteDir()
}
}{code}
The reported error is
{code:java}
org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
object '[]' with class 'java.util.LinkedHashSet' to class 'java.util.List' due
to: groovy.lang.GroovyRuntimeException: Could not find matching constructor
for: java.util.List()
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8716) Could not find matching constructor for java.util.List()
[
https://issues.apache.org/jira/browse/GROOVY-8716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558422#comment-16558422
]
paolo di tommaso commented on GROOVY-8716:
--
I guess no. I've noticed that just removing the `given` or `cleanup` component,
it pass.
> Could not find matching constructor for java.util.List()
>
>
> Key: GROOVY-8716
> URL: https://issues.apache.org/jira/browse/GROOVY-8716
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.1
>Reporter: paolo di tommaso
>Priority: Major
>
> The following Spock test fail
>
> {code:java}
> class Foo extends Specification {
> def 'should create a list' () {
> given:
> def folder = null
> when:
> List results = []
> then:
> true
> cleanup:
> folder?.deleteDir()
> }
> }{code}
>
> The reported error is
> {code:java}
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object '[]' with class 'java.util.LinkedHashSet' to class 'java.util.List'
> due to: groovy.lang.GroovyRuntimeException: Could not find matching
> constructor for: java.util.List()
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8761) Exception in phase 'instruction selection'
paolo di tommaso created GROOVY-8761:
Summary: Exception in phase 'instruction selection'
Key: GROOVY-8761
URL: https://issues.apache.org/jira/browse/GROOVY-8761
Project: Groovy
Issue Type: Bug
Affects Versions: 2.5.2
Reporter: paolo di tommaso
Upgrading to groovy 2.5.2 the compiler returns the following error message.
{code:java}
BUG! exception in phase 'instruction selection' in source unit
'/Users/pditommaso/projects/nextflow/src/main/groovy/nextflow/extension/TapOp.groovy'
Tried to overwrite existing meta data
org.codehaus.groovy.ast.expr.PropertyExpression@d9f41[object:
org.codehaus.groovy.ast.expr.VariableExpression@d9f41[variable: this] property:
ConstantExpression[outputs]].
{code}
The class under compilation can be found at [this
link|https://github.com/nextflow-io/nextflow/blob/daded334b2478596d9821fb9049f91e05fc22699/src/main/groovy/nextflow/extension/TapOp.groovy#L36-L117].
the compilation is fine up to groovy 2.5.1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8761) Exception in phase 'instruction selection'
[
https://issues.apache.org/jira/browse/GROOVY-8761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16587267#comment-16587267
]
paolo di tommaso commented on GROOVY-8761:
--
This is the complete error stack trace:
{code}
Error:Groovyc: While compiling nextflow_main: BUG! exception in phase
'instruction selection' in source unit
'/Users/pditommaso/projects/nextflow/src/main/groovy/nextflow/extension/TapOp.groovy'
Tried to overwrite existing meta data
org.codehaus.groovy.ast.expr.PropertyExpression@d9f41[object:
org.codehaus.groovy.ast.expr.VariableExpression@d9f41[variable: this] property:
ConstantExpression[outputs]].
at org.codehaus.groovy.ast.ASTNode.setNodeMetaData(ASTNode.java:154)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.checkOrMarkPrivateAccess(StaticTypeCheckingVisitor.java:501)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.storeField(StaticTypeCheckingVisitor.java:1711)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.existsProperty(StaticTypeCheckingVisitor.java:1473)
at
org.codehaus.groovy.transform.sc.StaticCompilationVisitor.existsProperty(StaticCompilationVisitor.java:522)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.existsProperty(StaticTypeCheckingVisitor.java:1381)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitPropertyExpressionSilent(StaticTypeCheckingVisitor.java:726)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.tryVariableExpressionAsProperty(StaticTypeCheckingVisitor.java:711)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitVariableExpression(StaticTypeCheckingVisitor.java:630)
at
org.codehaus.groovy.ast.expr.VariableExpression.visit(VariableExpression.java:72)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitBinaryExpression(StaticTypeCheckingVisitor.java:785)
at
org.codehaus.groovy.ast.expr.BinaryExpression.visit(BinaryExpression.java:51)
at
org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:122)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(ClassCodeVisitorSupport.java:197)
at
org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:42)
at
org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:88)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:106)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitBlockStatement(StaticTypeCheckingVisitor.java:3628)
at
org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:71)
at
org.codehaus.groovy.ast.CodeVisitorSupport.visitClosureExpression(CodeVisitorSupport.java:227)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitClosureExpression(StaticTypeCheckingVisitor.java:2286)
at
org.codehaus.groovy.ast.expr.ClosureExpression.visit(ClosureExpression.java:49)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethodCallArguments(StaticTypeCheckingVisitor.java:2596)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethodCallExpression(StaticTypeCheckingVisitor.java:3286)
at
org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethodCallExpression(StaticCompilationVisitor.java:397)
at
org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:70)
at
org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:122)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(ClassCodeVisitorSupport.java:197)
at
org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:42)
at
org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:88)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:106)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitBlockStatement(StaticTypeCheckingVisitor.java:3628)
at
org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:71)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:110)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:121)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitConstructorOrMethod(StaticTypeCheckingVisitor.java:2043)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructor(ClassCodeVisitorSupport.java:128)
at
[jira] [Commented] (GROOVY-8761) Exception in phase 'instruction selection'
[
https://issues.apache.org/jira/browse/GROOVY-8761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16587283#comment-16587283
]
paolo di tommaso commented on GROOVY-8761:
--
I confirm that 2.5.3-SNAPSHOT fix the problem. I'm closing this issue.
> Exception in phase 'instruction selection'
> --
>
> Key: GROOVY-8761
> URL: https://issues.apache.org/jira/browse/GROOVY-8761
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.2
>Reporter: paolo di tommaso
>Priority: Major
>
> Upgrading to groovy 2.5.2 the compiler returns the following error message.
>
> {code:java}
> BUG! exception in phase 'instruction selection' in source unit
> '/Users/pditommaso/projects/nextflow/src/main/groovy/nextflow/extension/TapOp.groovy'
> Tried to overwrite existing meta data
> org.codehaus.groovy.ast.expr.PropertyExpression@d9f41[object:
> org.codehaus.groovy.ast.expr.VariableExpression@d9f41[variable: this]
> property: ConstantExpression[outputs]].
> {code}
>
> The class under compilation can be found at [this
> link|https://github.com/nextflow-io/nextflow/blob/daded334b2478596d9821fb9049f91e05fc22699/src/main/groovy/nextflow/extension/TapOp.groovy#L36-L117].
> the compilation is fine up to groovy 2.5.1
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8761) Exception in phase 'instruction selection'
[
https://issues.apache.org/jira/browse/GROOVY-8761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16587273#comment-16587273
]
paolo di tommaso commented on GROOVY-8761:
--
Nice.
> Exception in phase 'instruction selection'
> --
>
> Key: GROOVY-8761
> URL: https://issues.apache.org/jira/browse/GROOVY-8761
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.2
>Reporter: paolo di tommaso
>Priority: Major
>
> Upgrading to groovy 2.5.2 the compiler returns the following error message.
>
> {code:java}
> BUG! exception in phase 'instruction selection' in source unit
> '/Users/pditommaso/projects/nextflow/src/main/groovy/nextflow/extension/TapOp.groovy'
> Tried to overwrite existing meta data
> org.codehaus.groovy.ast.expr.PropertyExpression@d9f41[object:
> org.codehaus.groovy.ast.expr.VariableExpression@d9f41[variable: this]
> property: ConstantExpression[outputs]].
> {code}
>
> The class under compilation can be found at [this
> link|https://github.com/nextflow-io/nextflow/blob/daded334b2478596d9821fb9049f91e05fc22699/src/main/groovy/nextflow/extension/TapOp.groovy#L36-L117].
> the compilation is fine up to groovy 2.5.1
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-8761) Exception in phase 'instruction selection'
[
https://issues.apache.org/jira/browse/GROOVY-8761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paolo di tommaso closed GROOVY-8761.
Resolution: Duplicate
Fix Version/s: 2.5.3
Duplicate of GROOVY-8753
> Exception in phase 'instruction selection'
> --
>
> Key: GROOVY-8761
> URL: https://issues.apache.org/jira/browse/GROOVY-8761
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.2
>Reporter: paolo di tommaso
>Priority: Major
> Fix For: 2.5.3
>
>
> Upgrading to groovy 2.5.2 the compiler returns the following error message.
>
> {code:java}
> BUG! exception in phase 'instruction selection' in source unit
> '/Users/pditommaso/projects/nextflow/src/main/groovy/nextflow/extension/TapOp.groovy'
> Tried to overwrite existing meta data
> org.codehaus.groovy.ast.expr.PropertyExpression@d9f41[object:
> org.codehaus.groovy.ast.expr.VariableExpression@d9f41[variable: this]
> property: ConstantExpression[outputs]].
> {code}
>
> The class under compilation can be found at [this
> link|https://github.com/nextflow-io/nextflow/blob/daded334b2478596d9821fb9049f91e05fc22699/src/main/groovy/nextflow/extension/TapOp.groovy#L36-L117].
> the compilation is fine up to groovy 2.5.1
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8762) Invalid this reference in nested class
paolo di tommaso created GROOVY-8762:
Summary: Invalid this reference in nested class
Key: GROOVY-8762
URL: https://issues.apache.org/jira/browse/GROOVY-8762
Project: Groovy
Issue Type: Bug
Affects Versions: 2.5.1, 2.4.15
Reporter: paolo di tommaso
The following snippet throws an exception when trying to initialise the `y`
attribute
{code:java}
class Foo {
static class Bar extends Closure {
private int x
private int y
Bar(int a) {
super(null, null);
x = a
this.y = a
}
public int getMaximumNumberOfParameters() {
throw new UnsupportedOperationException()
}
public Class[] getParameterTypes() {
throw new UnsupportedOperationException()
}
public Object call(final Object... args) {
throw new UnsupportedOperationException()
}
public Object call(final Object arguments) {
throw new UnsupportedOperationException()
}
public Object call() {
throw new UnsupportedOperationException()
}
}
def doSomething() {
new Bar(1)
}
}
assert new Foo().doSomething()
{code}
Reported error:
{code}
java.lang.NullPointerException
at Foo$Bar.(ConsoleScript8:12)
at Foo.doSomething(ConsoleScript8:37)
at Foo$doSomething.call(Unknown Source)
at ConsoleScript8.run(ConsoleScript8:42)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-7371) AST xform @Slf4j does not check level guard
[
https://issues.apache.org/jira/browse/GROOVY-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paolo di tommaso closed GROOVY-7371.
Resolution: Invalid
> AST xform @Slf4j does not check level guard
> ---
>
> Key: GROOVY-7371
> URL: https://issues.apache.org/jira/browse/GROOVY-7371
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.3.11
>Reporter: paolo di tommaso
>Priority: Minor
>
> Groovy logging AST transformation is supposed to "wrap all calls to
> log.level() into the appropriate log.isLevelEnabled guard, depending on the
> underlying framework "
> http://groovy-lang.org/metaprogramming.html#_logging_improvements
> However the following test fails:
> {code}
> @groovy.util.logging.Slf4j
> class TestLog {
> def bar () {
> int count=0
> if( log.isTraceEnabled() ) {
> log.trace "${count++}"
> }
> return count
> }
> def foo () {
> int count=0
> log.trace "${count++}"
> return count
> }
> }
> assert new TestLog().bar() == 0
> assert new TestLog().foo() == 0
> Assertion failed:
> assert new TestLog().foo() == 0
>| | |
>| 1 false
>TestLog@416b8a53
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GROOVY-7409) Closure reference a wrong object when is defining inside an iterator
[
https://issues.apache.org/jira/browse/GROOVY-7409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paolo di tommaso resolved GROOVY-7409.
--
Resolution: Not A Bug
Yes. Closing as not a bug. Quite tricky tho.
> Closure reference a wrong object when is defining inside an iterator
> -
>
> Key: GROOVY-7409
> URL: https://issues.apache.org/jira/browse/GROOVY-7409
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.3.11, 2.4.3
>Reporter: paolo di tommaso
>Priority: Critical
>
> A closure defined inside an iterator containing a reference to the iterating
> item resolves a wrong object instance.
> To reproduce the error take in consideration the following snippet:
> {code}
> interface Alpha {
> abstract void m()
> }
> class Foo implements Alpha {
> void m() { println 'foo' }
> }
> class Bar implements Alpha {
> void m() { println 'bar' }
> }
> List list = [new Foo(), new Bar()]
> def hooks = []
> for( def item : list ) {
> hooks.add { item.m() }
> }
> hooks.each { it.call() }
> {code}
> It prints
> {code}
> bar
> bar
> {code}
> Replacing the `for` iterator with a `for( int i=0; etc ) .. ` prints
> correctly:
> {code}
> foo
> bar
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-9003) Allow the override of toString and equals methods for collection objects
[
https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16776144#comment-16776144
]
paolo di tommaso edited comment on GROOVY-9003 at 2/24/19 7:45 AM:
---
In principle seems to work, it could be something along these lines:
{code}
Object.metaClass.toString = { ->
if( delegate instanceof List )
return delegate.join('-')
else
return 'foo'
}
class Foo {
}
class Bar {
String toString() { return 'bar' }
}
def f = new Foo()
def b = new Bar()
assert f.toString() =='foo'
assert b.toString() == 'bar'
{code}
However, I've also realised that the following won't work due to GROOVY-2599
{code:java}
assert "$f" =='foo'
{code}
A good opportunity to solve this as well and make string representation
coherent.
was (Author: pablo72):
In principle seems to work, the is something along these lines:
{code}
Object.metaClass.toString = { ->
if( delegate instanceof List )
delegate.join('-')
else
'foo'
}
class Foo {
}
class Bar {
String toString() { return 'bar' }
}
def f = new Foo()
def b = new Bar()
assert f.toString() =='foo'
assert b.toString() == 'bar'
{code}
However, I've also realised that the following won't work due to GROOVY-2599
{code:java}
assert "$f" =='foo'
{code}
A good opportunity to solve this as well and make string representation
coherent.
> Allow the override of toString and equals methods for collection objects
> -
>
> Key: GROOVY-9003
> URL: https://issues.apache.org/jira/browse/GROOVY-9003
> Project: Groovy
> Issue Type: Improvement
>Reporter: paolo di tommaso
>Priority: Major
> Fix For: 3.x
>
>
> Groovy provides a nice string representation for collection objects, however
> the current behaviour do not allow custom collection classes to provide own
> string representation not to implement a custom object identity rule.
> For example:
> {code:java}
> class Mylist extends ArrayList {
> Mylist(Collection c) { super(c) }
> @Override boolean equals(Object o) { throw new
> UnsupportedOperationException () }
> @Override int hashCode() { throw new UnsupportedOperationException () }
> @Override String toString() { return 'CUSTOM STRING' }
> }
> def l = new Mylist([1,2,3])
> assert l.toString() == 'CUSTOM STRING'
> assert "$l" == '[1, 2, 3]'
> def q = new Mylist([1,2,3])
> assert l.equals(q)
> assert l == q
> {code}
> In the {{Mylist}} class the {{toString}} method is not invoked in the string
> interpolation and {{equals}} is not invoked by the {{==}} operator. This
> breaks the java polymorphism contract and create several hassles when
> implementing custom collection classes.
> I would propose to fix this behaviour in Groovy 3.0. It would be enough to
> check if the target class implements the {{toString}} and {{equals}} methods
> otherwise fallback on the current Groovy behaviour.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-9003) Allow the override of toString and equals methods for collection objects
[
https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16776144#comment-16776144
]
paolo di tommaso commented on GROOVY-9003:
--
In principle seems to work, the is something along these lines:
{code}
Object.metaClass.toString = { ->
if( delegate instanceof List )
delegate.join('-')
else
'foo'
}
class Foo {
}
class Bar {
String toString() { return 'bar' }
}
def f = new Foo()
def b = new Bar()
assert f.toString() =='foo'
assert b.toString() == 'bar'
{code}
However, I've also realised that the following won't work due to GROOVY-2599
{code:java}
assert "$f" =='foo'
{code}
A good opportunity to solve this as well and make string representation
coherent.
> Allow the override of toString and equals methods for collection objects
> -
>
> Key: GROOVY-9003
> URL: https://issues.apache.org/jira/browse/GROOVY-9003
> Project: Groovy
> Issue Type: Improvement
>Reporter: paolo di tommaso
>Priority: Major
> Fix For: 3.x
>
>
> Groovy provides a nice string representation for collection objects, however
> the current behaviour do not allow custom collection classes to provide own
> string representation not to implement a custom object identity rule.
> For example:
> {code:java}
> class Mylist extends ArrayList {
> Mylist(Collection c) { super(c) }
> @Override boolean equals(Object o) { throw new
> UnsupportedOperationException () }
> @Override int hashCode() { throw new UnsupportedOperationException () }
> @Override String toString() { return 'CUSTOM STRING' }
> }
> def l = new Mylist([1,2,3])
> assert l.toString() == 'CUSTOM STRING'
> assert "$l" == '[1, 2, 3]'
> def q = new Mylist([1,2,3])
> assert l.equals(q)
> assert l == q
> {code}
> In the {{Mylist}} class the {{toString}} method is not invoked in the string
> interpolation and {{equals}} is not invoked by the {{==}} operator. This
> breaks the java polymorphism contract and create several hassles when
> implementing custom collection classes.
> I would propose to fix this behaviour in Groovy 3.0. It would be enough to
> check if the target class implements the {{toString}} and {{equals}} methods
> otherwise fallback on the current Groovy behaviour.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-9003) Allow the override of toString and equals methods for collection objects
[
https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774960#comment-16774960
]
paolo di tommaso commented on GROOVY-9003:
--
Ouch, was missing this. Not sure it's possible, but what about instead
overriding the toString and equals with using the groovy metaclass for the
Object class in such way it implements the current groovy representation for
collections.
Then subclasses should still be able to provide their own implementation. Does
it make sense ?
> Allow the override of toString and equals methods for collection objects
> -
>
> Key: GROOVY-9003
> URL: https://issues.apache.org/jira/browse/GROOVY-9003
> Project: Groovy
> Issue Type: Improvement
>Reporter: paolo di tommaso
>Priority: Major
> Fix For: 3.x
>
>
> Groovy provides a nice string representation for collection objects, however
> the current behaviour do not allow custom collection classes to provide own
> string representation not to implement a custom object identity rule.
> For example:
> {code:java}
> class Mylist extends ArrayList {
> Mylist(Collection c) { super(c) }
> @Override boolean equals(Object o) { throw new
> UnsupportedOperationException () }
> @Override int hashCode() { throw new UnsupportedOperationException () }
> @Override String toString() { return 'CUSTOM STRING' }
> }
> def l = new Mylist([1,2,3])
> assert l.toString() == 'CUSTOM STRING'
> assert "$l" == '[1, 2, 3]'
> def q = new Mylist([1,2,3])
> assert l.equals(q)
> assert l == q
> {code}
> In the {{Mylist}} class the {{toString}} method is not invoked in the string
> interpolation and {{equals}} is not invoked by the {{==}} operator. This
> breaks the java polymorphism contract and create several hassles when
> implementing custom collection classes.
> I would propose to fix this behaviour in Groovy 3.0. It would be enough to
> check if the target class implements the {{toString}} and {{equals}} methods
> otherwise fallback on the current Groovy behaviour.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-9003) Allow the override of toString and equals methods for collection objects
[
https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774862#comment-16774862
]
paolo di tommaso edited comment on GROOVY-9003 at 2/22/19 7:37 AM:
---
I should have clarified better, the proposal is to skip the groovy
representation when a class *declares* the `toString` method (i.e.
getDeclaredMethod vs getMethod). In this case between the mentioned classes
remain the following:
{code}
Vector, ArrayBlockingQueue, LinkedBlockingDeque, LinkedBlockingQueue,
PriorityBlockingQueue
{code}
However it should be noted that the string representation they implement is the
same as the groovy one.
{code}
def v = new Vector()
v << 1
v << 'hello'
v << 'world'
def a = new java.util.concurrent.ArrayBlockingQueue(1)
a << 1
a << 'hello'
a << 'world'
assert v.toString() == "$v"
assert a.toString() == "$a"
{code}
was (Author: pablo72):
I should have clarified better, the proposal is to skip the groovy
representation when a class *declares* the `toString` method (it
getDeclaredMethod vs getMethod). In this case between the mentioned classes
remain the following:
{code}
Vector, ArrayBlockingQueue, LinkedBlockingDeque, LinkedBlockingQueue,
PriorityBlockingQueue
{code}
However it should be noted that the string representation they implement is the
same as the groovy one.
{code}
def v = new Vector()
v << 1
v << 'hello'
v << 'world'
def a = new java.util.concurrent.ArrayBlockingQueue(1)
a << 1
a << 'hello'
a << 'world'
assert v.toString() == "$v"
assert a.toString() == "$a"
{code}
> Allow the override of toString and equals methods for collection objects
> -
>
> Key: GROOVY-9003
> URL: https://issues.apache.org/jira/browse/GROOVY-9003
> Project: Groovy
> Issue Type: Improvement
>Reporter: paolo di tommaso
>Priority: Major
> Fix For: 3.x
>
>
> Groovy provides a nice string representation for collection objects, however
> the current behaviour do not allow custom collection classes to provide own
> string representation not to implement a custom object identity rule.
> For example:
> {code:java}
> class Mylist extends ArrayList {
> Mylist(Collection c) { super(c) }
> @Override boolean equals(Object o) { throw new
> UnsupportedOperationException () }
> @Override int hashCode() { throw new UnsupportedOperationException () }
> @Override String toString() { return 'CUSTOM STRING' }
> }
> def l = new Mylist([1,2,3])
> assert l.toString() == 'CUSTOM STRING'
> assert "$l" == '[1, 2, 3]'
> def q = new Mylist([1,2,3])
> assert l.equals(q)
> assert l == q
> {code}
> In the {{Mylist}} class the {{toString}} method is not invoked in the string
> interpolation and {{equals}} is not invoked by the {{==}} operator. This
> breaks the java polymorphism contract and create several hassles when
> implementing custom collection classes.
> I would propose to fix this behaviour in Groovy 3.0. It would be enough to
> check if the target class implements the {{toString}} and {{equals}} methods
> otherwise fallback on the current Groovy behaviour.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-9003) Allow the override of toString and equals methods for collection objects
[
https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774862#comment-16774862
]
paolo di tommaso edited comment on GROOVY-9003 at 2/22/19 7:37 AM:
---
I should have clarified better, the proposal is to skip the groovy
representation when a class *declares* the `toString` method (i.e.
getDeclaredMethod vs getMethod). In this case, from the mentioned classes
remain the following:
{code}
Vector, ArrayBlockingQueue, LinkedBlockingDeque, LinkedBlockingQueue,
PriorityBlockingQueue
{code}
However it should be noted that the string representation they implement is the
same as the groovy one.
{code}
def v = new Vector()
v << 1
v << 'hello'
v << 'world'
def a = new java.util.concurrent.ArrayBlockingQueue(1)
a << 1
a << 'hello'
a << 'world'
assert v.toString() == "$v"
assert a.toString() == "$a"
{code}
was (Author: pablo72):
I should have clarified better, the proposal is to skip the groovy
representation when a class *declares* the `toString` method (i.e.
getDeclaredMethod vs getMethod). In this case between the mentioned classes
remain the following:
{code}
Vector, ArrayBlockingQueue, LinkedBlockingDeque, LinkedBlockingQueue,
PriorityBlockingQueue
{code}
However it should be noted that the string representation they implement is the
same as the groovy one.
{code}
def v = new Vector()
v << 1
v << 'hello'
v << 'world'
def a = new java.util.concurrent.ArrayBlockingQueue(1)
a << 1
a << 'hello'
a << 'world'
assert v.toString() == "$v"
assert a.toString() == "$a"
{code}
> Allow the override of toString and equals methods for collection objects
> -
>
> Key: GROOVY-9003
> URL: https://issues.apache.org/jira/browse/GROOVY-9003
> Project: Groovy
> Issue Type: Improvement
>Reporter: paolo di tommaso
>Priority: Major
> Fix For: 3.x
>
>
> Groovy provides a nice string representation for collection objects, however
> the current behaviour do not allow custom collection classes to provide own
> string representation not to implement a custom object identity rule.
> For example:
> {code:java}
> class Mylist extends ArrayList {
> Mylist(Collection c) { super(c) }
> @Override boolean equals(Object o) { throw new
> UnsupportedOperationException () }
> @Override int hashCode() { throw new UnsupportedOperationException () }
> @Override String toString() { return 'CUSTOM STRING' }
> }
> def l = new Mylist([1,2,3])
> assert l.toString() == 'CUSTOM STRING'
> assert "$l" == '[1, 2, 3]'
> def q = new Mylist([1,2,3])
> assert l.equals(q)
> assert l == q
> {code}
> In the {{Mylist}} class the {{toString}} method is not invoked in the string
> interpolation and {{equals}} is not invoked by the {{==}} operator. This
> breaks the java polymorphism contract and create several hassles when
> implementing custom collection classes.
> I would propose to fix this behaviour in Groovy 3.0. It would be enough to
> check if the target class implements the {{toString}} and {{equals}} methods
> otherwise fallback on the current Groovy behaviour.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-9003) Allow the override of toString and equals methods for collection objects
[
https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774862#comment-16774862
]
paolo di tommaso commented on GROOVY-9003:
--
I should have clarified better, the proposal is to skip the groovy
representation when class *declares* the `toString` method (it
getDeclaredMethod vs getMethod). In this case between the mentioned classes
remain the following:
{code}
Vector, ArrayBlockingQueue, LinkedBlockingDeque, LinkedBlockingQueue,
PriorityBlockingQueue
{code}
However it should be noted that the string representation they implement is the
same as the groovy one.
{code}
def v = new Vector()
v << 1
v << 'hello'
v << 'world'
def a = new java.util.concurrent.ArrayBlockingQueue(1)
a << 1
a << 'hello'
a << 'world'
assert v.toString() == "$v"
assert a.toString() == "$a"
{code}
> Allow the override of toString and equals methods for collection objects
> -
>
> Key: GROOVY-9003
> URL: https://issues.apache.org/jira/browse/GROOVY-9003
> Project: Groovy
> Issue Type: Improvement
>Reporter: paolo di tommaso
>Priority: Major
> Fix For: 3.x
>
>
> Groovy provides a nice string representation for collection objects, however
> the current behaviour do not allow custom collection classes to provide own
> string representation not to implement a custom object identity rule.
> For example:
> {code:java}
> class Mylist extends ArrayList {
> Mylist(Collection c) { super(c) }
> @Override boolean equals(Object o) { throw new
> UnsupportedOperationException () }
> @Override int hashCode() { throw new UnsupportedOperationException () }
> @Override String toString() { return 'CUSTOM STRING' }
> }
> def l = new Mylist([1,2,3])
> assert l.toString() == 'CUSTOM STRING'
> assert "$l" == '[1, 2, 3]'
> def q = new Mylist([1,2,3])
> assert l.equals(q)
> assert l == q
> {code}
> In the {{Mylist}} class the {{toString}} method is not invoked in the string
> interpolation and {{equals}} is not invoked by the {{==}} operator. This
> breaks the java polymorphism contract and create several hassles when
> implementing custom collection classes.
> I would propose to fix this behaviour in Groovy 3.0. It would be enough to
> check if the target class implements the {{toString}} and {{equals}} methods
> otherwise fallback on the current Groovy behaviour.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-9003) Allow the override of toString and equals methods for collection objects
[
https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774862#comment-16774862
]
paolo di tommaso edited comment on GROOVY-9003 at 2/22/19 7:37 AM:
---
I should have clarified better, the proposal is to skip the groovy
representation when a class *declares* the `toString` method (it
getDeclaredMethod vs getMethod). In this case between the mentioned classes
remain the following:
{code}
Vector, ArrayBlockingQueue, LinkedBlockingDeque, LinkedBlockingQueue,
PriorityBlockingQueue
{code}
However it should be noted that the string representation they implement is the
same as the groovy one.
{code}
def v = new Vector()
v << 1
v << 'hello'
v << 'world'
def a = new java.util.concurrent.ArrayBlockingQueue(1)
a << 1
a << 'hello'
a << 'world'
assert v.toString() == "$v"
assert a.toString() == "$a"
{code}
was (Author: pablo72):
I should have clarified better, the proposal is to skip the groovy
representation when class *declares* the `toString` method (it
getDeclaredMethod vs getMethod). In this case between the mentioned classes
remain the following:
{code}
Vector, ArrayBlockingQueue, LinkedBlockingDeque, LinkedBlockingQueue,
PriorityBlockingQueue
{code}
However it should be noted that the string representation they implement is the
same as the groovy one.
{code}
def v = new Vector()
v << 1
v << 'hello'
v << 'world'
def a = new java.util.concurrent.ArrayBlockingQueue(1)
a << 1
a << 'hello'
a << 'world'
assert v.toString() == "$v"
assert a.toString() == "$a"
{code}
> Allow the override of toString and equals methods for collection objects
> -
>
> Key: GROOVY-9003
> URL: https://issues.apache.org/jira/browse/GROOVY-9003
> Project: Groovy
> Issue Type: Improvement
>Reporter: paolo di tommaso
>Priority: Major
> Fix For: 3.x
>
>
> Groovy provides a nice string representation for collection objects, however
> the current behaviour do not allow custom collection classes to provide own
> string representation not to implement a custom object identity rule.
> For example:
> {code:java}
> class Mylist extends ArrayList {
> Mylist(Collection c) { super(c) }
> @Override boolean equals(Object o) { throw new
> UnsupportedOperationException () }
> @Override int hashCode() { throw new UnsupportedOperationException () }
> @Override String toString() { return 'CUSTOM STRING' }
> }
> def l = new Mylist([1,2,3])
> assert l.toString() == 'CUSTOM STRING'
> assert "$l" == '[1, 2, 3]'
> def q = new Mylist([1,2,3])
> assert l.equals(q)
> assert l == q
> {code}
> In the {{Mylist}} class the {{toString}} method is not invoked in the string
> interpolation and {{equals}} is not invoked by the {{==}} operator. This
> breaks the java polymorphism contract and create several hassles when
> implementing custom collection classes.
> I would propose to fix this behaviour in Groovy 3.0. It would be enough to
> check if the target class implements the {{toString}} and {{equals}} methods
> otherwise fallback on the current Groovy behaviour.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-9003) Allow the override of toString and equals methods for collection objects
[
https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paolo di tommaso updated GROOVY-9003:
-
Description:
Groovy provides a nice string representation for collection objects, however
the current behaviour do not allow custom collection classes to provide own
string representation not to implement a custom object identity rule.
For example:
{code:java}
class Mylist extends ArrayList {
Mylist(Collection c) { super(c) }
@Override boolean equals(Object o) { throw new UnsupportedOperationException
() }
@Override int hashCode() { throw new UnsupportedOperationException () }
@Override String toString() { return 'CUSTOM STRING' }
}
def l = new Mylist([1,2,3])
assert l.toString() == 'CUSTOM STRING'
assert "$l" == '[1, 2, 3]'
def q = new Mylist([1,2,3])
assert l.equals(q)
assert l == q
{code}
In the {{Mylist}} class the {{toString}} method is not invoked in the string
interpolation and {{equals}} is not invoked by the {{==}} operator. This breaks
the java polymorphism contract and create several hassles when implementing
custom collection classes.
I would propose to fix this behaviour in Groovy 3.0. It would be enough to
check if the target class implements the {{toString}} and {{equals}} methods
otherwise fallback on the current Groovy behaviour.
was:
Groovy provides a nice string representation for collection objects, however
the current behaviour do not allow custom collection classes to provide own
string representation not to implement a custom object identity rule.
For example:
{code:java}
class Mylist extends ArrayList {
Mylist(Collection c) { super(c) }
@Override boolean equals(Object o) { throw new UnsupportedOperationException
() }
@Override int hashCode() { throw new UnsupportedOperationException () }
@Override String toString() { return 'CUSTOM STRING' }
}
def l = new Mylist([1,2,3])
assert l.toString() == 'CUSTOM STRING'
assert "$l" == '[1, 2, 3]'
def q = new Mylist([1,2,3])
assert l.equals(q)
assert l == q
{code}
In the {{Mylist}} class the {{toString}} method is not invoked in the string
interpolation and {{equals}} is not invoked by the {{==}} operator. This breaks
the java polymorphism contract and create several hassles when implementing
custom collection classes.
I would propose to fix this behaviour in Groovy 3.0. It would be enough to
check in the target class implements the {{toString}} and {{equals}} methods
otherwise fallback on the current Groovy behaviour.
> Allow the override of toString and equals methods for collection objects
> -
>
> Key: GROOVY-9003
> URL: https://issues.apache.org/jira/browse/GROOVY-9003
> Project: Groovy
> Issue Type: Improvement
>Reporter: paolo di tommaso
>Priority: Major
> Fix For: 3.x
>
>
> Groovy provides a nice string representation for collection objects, however
> the current behaviour do not allow custom collection classes to provide own
> string representation not to implement a custom object identity rule.
> For example:
> {code:java}
> class Mylist extends ArrayList {
> Mylist(Collection c) { super(c) }
> @Override boolean equals(Object o) { throw new
> UnsupportedOperationException () }
> @Override int hashCode() { throw new UnsupportedOperationException () }
> @Override String toString() { return 'CUSTOM STRING' }
> }
> def l = new Mylist([1,2,3])
> assert l.toString() == 'CUSTOM STRING'
> assert "$l" == '[1, 2, 3]'
> def q = new Mylist([1,2,3])
> assert l.equals(q)
> assert l == q
> {code}
> In the {{Mylist}} class the {{toString}} method is not invoked in the string
> interpolation and {{equals}} is not invoked by the {{==}} operator. This
> breaks the java polymorphism contract and create several hassles when
> implementing custom collection classes.
> I would propose to fix this behaviour in Groovy 3.0. It would be enough to
> check if the target class implements the {{toString}} and {{equals}} methods
> otherwise fallback on the current Groovy behaviour.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-9003) Allow the override of `toString` and `equals` methods for collection objects
paolo di tommaso created GROOVY-9003:
Summary: Allow the override of `toString` and `equals` methods for
collection objects
Key: GROOVY-9003
URL: https://issues.apache.org/jira/browse/GROOVY-9003
Project: Groovy
Issue Type: Improvement
Reporter: paolo di tommaso
Fix For: 3.x
Groovy provides a nice string representation for collection objects, however
this implementation do not allow to custom collection class to override their
own string representation.
For example:
{code:java}
class Mylist extends ArrayList {
Mylist(Collection c) { super(c) }
@Override boolean equals(Object o) { throw new UnsupportedOperationException
() }
@Override int hashCode() { throw new UnsupportedOperationException () }
@Override String toString() { return 'CUSTOM STRING' }
}
def l = new Mylist([1,2,3])
assert l.toString() == 'CUSTOM STRING'
assert "$l" == '[1, 2, 3]'
def q = new Mylist([1,2,3])
assert l.equals(q)
assert l == q
{code}
In the {{Mylist}} class the {{toString}} method is not invoked in the string
interpolation and {{equals}} is not invoked by the {{==}} operator. This breaks
the java polymorphism contract and create several hassles when implementing
custom collection classes.
I would propose to fix this behaviour in Groovy 3.0. It would be enough to
check in the target class implements the {{toString}} and {{equals}} methods
otherwise fallback on the current Groovy behaviour.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-9003) Allow the override of toString and equals methods for collection objects
[
https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paolo di tommaso updated GROOVY-9003:
-
Description:
Groovy provides a nice string representation for collection objects, however
this implementation do not allow custom collection classes to provide own
string representation not to implement a custom object identity rule.
For example:
{code:java}
class Mylist extends ArrayList {
Mylist(Collection c) { super(c) }
@Override boolean equals(Object o) { throw new UnsupportedOperationException
() }
@Override int hashCode() { throw new UnsupportedOperationException () }
@Override String toString() { return 'CUSTOM STRING' }
}
def l = new Mylist([1,2,3])
assert l.toString() == 'CUSTOM STRING'
assert "$l" == '[1, 2, 3]'
def q = new Mylist([1,2,3])
assert l.equals(q)
assert l == q
{code}
In the {{Mylist}} class the {{toString}} method is not invoked in the string
interpolation and {{equals}} is not invoked by the {{==}} operator. This breaks
the java polymorphism contract and create several hassles when implementing
custom collection classes.
I would propose to fix this behaviour in Groovy 3.0. It would be enough to
check in the target class implements the {{toString}} and {{equals}} methods
otherwise fallback on the current Groovy behaviour.
was:
Groovy provides a nice string representation for collection objects, however
this implementation do not allow to custom collection class to override their
own string representation.
For example:
{code:java}
class Mylist extends ArrayList {
Mylist(Collection c) { super(c) }
@Override boolean equals(Object o) { throw new UnsupportedOperationException
() }
@Override int hashCode() { throw new UnsupportedOperationException () }
@Override String toString() { return 'CUSTOM STRING' }
}
def l = new Mylist([1,2,3])
assert l.toString() == 'CUSTOM STRING'
assert "$l" == '[1, 2, 3]'
def q = new Mylist([1,2,3])
assert l.equals(q)
assert l == q
{code}
In the {{Mylist}} class the {{toString}} method is not invoked in the string
interpolation and {{equals}} is not invoked by the {{==}} operator. This breaks
the java polymorphism contract and create several hassles when implementing
custom collection classes.
I would propose to fix this behaviour in Groovy 3.0. It would be enough to
check in the target class implements the {{toString}} and {{equals}} methods
otherwise fallback on the current Groovy behaviour.
> Allow the override of toString and equals methods for collection objects
> -
>
> Key: GROOVY-9003
> URL: https://issues.apache.org/jira/browse/GROOVY-9003
> Project: Groovy
> Issue Type: Improvement
>Reporter: paolo di tommaso
>Priority: Major
> Fix For: 3.x
>
>
> Groovy provides a nice string representation for collection objects, however
> this implementation do not allow custom collection classes to provide own
> string representation not to implement a custom object identity rule.
> For example:
> {code:java}
> class Mylist extends ArrayList {
> Mylist(Collection c) { super(c) }
> @Override boolean equals(Object o) { throw new
> UnsupportedOperationException () }
> @Override int hashCode() { throw new UnsupportedOperationException () }
> @Override String toString() { return 'CUSTOM STRING' }
> }
> def l = new Mylist([1,2,3])
> assert l.toString() == 'CUSTOM STRING'
> assert "$l" == '[1, 2, 3]'
> def q = new Mylist([1,2,3])
> assert l.equals(q)
> assert l == q
> {code}
> In the {{Mylist}} class the {{toString}} method is not invoked in the string
> interpolation and {{equals}} is not invoked by the {{==}} operator. This
> breaks the java polymorphism contract and create several hassles when
> implementing custom collection classes.
> I would propose to fix this behaviour in Groovy 3.0. It would be enough to
> check in the target class implements the {{toString}} and {{equals}} methods
> otherwise fallback on the current Groovy behaviour.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-9003) Allow the override of toString and equals methods for collection objects
[
https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paolo di tommaso updated GROOVY-9003:
-
Summary: Allow the override of toString and equals methods for collection
objects (was: Allow the override of `toString` and `equals` methods for
collection objects )
> Allow the override of toString and equals methods for collection objects
> -
>
> Key: GROOVY-9003
> URL: https://issues.apache.org/jira/browse/GROOVY-9003
> Project: Groovy
> Issue Type: Improvement
>Reporter: paolo di tommaso
>Priority: Major
> Fix For: 3.x
>
>
> Groovy provides a nice string representation for collection objects, however
> this implementation do not allow to custom collection class to override their
> own string representation.
> For example:
> {code:java}
> class Mylist extends ArrayList {
> Mylist(Collection c) { super(c) }
> @Override boolean equals(Object o) { throw new
> UnsupportedOperationException () }
> @Override int hashCode() { throw new UnsupportedOperationException () }
> @Override String toString() { return 'CUSTOM STRING' }
> }
> def l = new Mylist([1,2,3])
> assert l.toString() == 'CUSTOM STRING'
> assert "$l" == '[1, 2, 3]'
> def q = new Mylist([1,2,3])
> assert l.equals(q)
> assert l == q
> {code}
> In the {{Mylist}} class the {{toString}} method is not invoked in the string
> interpolation and {{equals}} is not invoked by the {{==}} operator. This
> breaks the java polymorphism contract and create several hassles when
> implementing custom collection classes.
> I would propose to fix this behaviour in Groovy 3.0. It would be enough to
> check in the target class implements the {{toString}} and {{equals}} methods
> otherwise fallback on the current Groovy behaviour.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-9003) Allow the override of toString and equals methods for collection objects
[
https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paolo di tommaso updated GROOVY-9003:
-
Description:
Groovy provides a nice string representation for collection objects, however
the current behaviour do not allow custom collection classes to provide own
string representation not to implement a custom object identity rule.
For example:
{code:java}
class Mylist extends ArrayList {
Mylist(Collection c) { super(c) }
@Override boolean equals(Object o) { throw new UnsupportedOperationException
() }
@Override int hashCode() { throw new UnsupportedOperationException () }
@Override String toString() { return 'CUSTOM STRING' }
}
def l = new Mylist([1,2,3])
assert l.toString() == 'CUSTOM STRING'
assert "$l" == '[1, 2, 3]'
def q = new Mylist([1,2,3])
assert l.equals(q)
assert l == q
{code}
In the {{Mylist}} class the {{toString}} method is not invoked in the string
interpolation and {{equals}} is not invoked by the {{==}} operator. This breaks
the java polymorphism contract and create several hassles when implementing
custom collection classes.
I would propose to fix this behaviour in Groovy 3.0. It would be enough to
check in the target class implements the {{toString}} and {{equals}} methods
otherwise fallback on the current Groovy behaviour.
was:
Groovy provides a nice string representation for collection objects, however
this implementation do not allow custom collection classes to provide own
string representation not to implement a custom object identity rule.
For example:
{code:java}
class Mylist extends ArrayList {
Mylist(Collection c) { super(c) }
@Override boolean equals(Object o) { throw new UnsupportedOperationException
() }
@Override int hashCode() { throw new UnsupportedOperationException () }
@Override String toString() { return 'CUSTOM STRING' }
}
def l = new Mylist([1,2,3])
assert l.toString() == 'CUSTOM STRING'
assert "$l" == '[1, 2, 3]'
def q = new Mylist([1,2,3])
assert l.equals(q)
assert l == q
{code}
In the {{Mylist}} class the {{toString}} method is not invoked in the string
interpolation and {{equals}} is not invoked by the {{==}} operator. This breaks
the java polymorphism contract and create several hassles when implementing
custom collection classes.
I would propose to fix this behaviour in Groovy 3.0. It would be enough to
check in the target class implements the {{toString}} and {{equals}} methods
otherwise fallback on the current Groovy behaviour.
> Allow the override of toString and equals methods for collection objects
> -
>
> Key: GROOVY-9003
> URL: https://issues.apache.org/jira/browse/GROOVY-9003
> Project: Groovy
> Issue Type: Improvement
>Reporter: paolo di tommaso
>Priority: Major
> Fix For: 3.x
>
>
> Groovy provides a nice string representation for collection objects, however
> the current behaviour do not allow custom collection classes to provide own
> string representation not to implement a custom object identity rule.
> For example:
> {code:java}
> class Mylist extends ArrayList {
> Mylist(Collection c) { super(c) }
> @Override boolean equals(Object o) { throw new
> UnsupportedOperationException () }
> @Override int hashCode() { throw new UnsupportedOperationException () }
> @Override String toString() { return 'CUSTOM STRING' }
> }
> def l = new Mylist([1,2,3])
> assert l.toString() == 'CUSTOM STRING'
> assert "$l" == '[1, 2, 3]'
> def q = new Mylist([1,2,3])
> assert l.equals(q)
> assert l == q
> {code}
> In the {{Mylist}} class the {{toString}} method is not invoked in the string
> interpolation and {{equals}} is not invoked by the {{==}} operator. This
> breaks the java polymorphism contract and create several hassles when
> implementing custom collection classes.
> I would propose to fix this behaviour in Groovy 3.0. It would be enough to
> check in the target class implements the {{toString}} and {{equals}} methods
> otherwise fallback on the current Groovy behaviour.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8978) NPE when accessing protected method from subclass clone
paolo di tommaso created GROOVY-8978:
Summary: NPE when accessing protected method from subclass clone
Key: GROOVY-8978
URL: https://issues.apache.org/jira/browse/GROOVY-8978
Project: Groovy
Issue Type: Bug
Affects Versions: 2.5.6
Reporter: paolo di tommaso
I'm getting a NPE when running this snippet:
{code}
@groovy.transform.CompileStatic
class LazyMap implements Map {
@Delegate protected Map target
LazyMap() {
target = new HashMap<>()
}
}
@groovy.transform.CompileStatic
class TaskConfig extends LazyMap implements Cloneable {
TaskConfig() { }
TaskConfig clone() {
def copy = (TaskConfig)super.clone()
copy.target = new HashMap<>(this.target)
return copy
}
}
{code}
The problem is that `this.target` in the clone method is evaluated to `null`.
It works fine if the classes are not declared CompileStatic. It was also
working fine with groovy version prior to 2.5.6.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-9115) General error during class generation
paolo di tommaso created GROOVY-9115:
Summary: General error during class generation
Key: GROOVY-9115
URL: https://issues.apache.org/jira/browse/GROOVY-9115
Project: Groovy
Issue Type: Bug
Components: Compiler
Affects Versions: 2.5.7
Reporter: paolo di tommaso
Upgrading to Groovy 2.5.7 from 2.5.6 I'm getting the following compiler crash
{code}
General error during class generation: ASM reporting processing error for
nextflow.k8s.client.K8sClient#podCreate with signature
nextflow.k8s.client.K8sResponseJson podCreate(java.util.Map,
java.nio.file.Path) in K8sClient.groovy:149.
/Users/pditommaso/Projects/nextflow/modules/nextflow/src/main/groovy/nextflow/k8s/client/K8sClient.groovy
groovy.lang.GroovyRuntimeException: ASM reporting processing error for
nextflow.k8s.client.K8sClient#podCreate with signature
nextflow.k8s.client.K8sResponseJson podCreate(java.util.Map,
java.nio.file.Path) in K8sClient.groovy:149.
/Users/pditommaso/Projects/nextflow/modules/nextflow/src/main/groovy/nextflow/k8s/client/K8sClient.groovy
at
org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:455)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:132)
at
org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:576)
at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1103)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:54)
at
org.codehaus.groovy.classgen.AsmClassGenerator.visitClass(AsmClassGenerator.java:269)
at
org.codehaus.groovy.control.CompilationUnit$18.call(CompilationUnit.java:854)
at
org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1084)
at
org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:645)
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:623)
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:600)
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:579)
at
org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:179)
at
org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:57)
at
org.gradle.api.internal.tasks.compile.GroovyCompilerFactory$DaemonSideCompiler.execute(GroovyCompilerFactory.java:77)
at
org.gradle.api.internal.tasks.compile.GroovyCompilerFactory$DaemonSideCompiler.execute(GroovyCompilerFactory.java:65)
at
org.gradle.api.internal.tasks.compile.daemon.AbstractDaemonCompiler$CompilerCallable.call(AbstractDaemonCompiler.java:88)
at
org.gradle.api.internal.tasks.compile.daemon.AbstractDaemonCompiler$CompilerCallable.call(AbstractDaemonCompiler.java:76)
at
org.gradle.workers.internal.DefaultWorkerServer.execute(DefaultWorkerServer.java:42)
at
org.gradle.workers.internal.WorkerDaemonServer.execute(WorkerDaemonServer.java:46)
at
org.gradle.workers.internal.WorkerDaemonServer.execute(WorkerDaemonServer.java:30)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.gradle.process.internal.worker.request.WorkerAction.run(WorkerAction.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:155)
at
org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:137)
at
org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404)
at
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
at
org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
at
[jira] [Created] (GROOVY-9127) Cannot set protected field from subclass
paolo di tommaso created GROOVY-9127:
Summary: Cannot set protected field from subclass
Key: GROOVY-9127
URL: https://issues.apache.org/jira/browse/GROOVY-9127
Project: Groovy
Issue Type: Bug
Affects Versions: 2.5.6
Reporter: paolo di tommaso
Consider the following code
{code}
@CompileStatic
abstract class Foo {
protected String field1
String getField1() {
field1
}
}
@CompileStatic
class Bar extends Foo {
void changeField1() {
this.field1 = 'foo'
}
@Override
String getField1() { return 'bar command' }
}
{code}
It fails to compile with the following error message:
{code}
[Static type checking] - Cannot set read-only property: field1
@ line 29, column 9.
this.field1 = 'foo'
^
{code}
Which does not make much sense to me because protected field should be
accessible to subclasses by definition. Tested also with 2.5.8-SNAPSHOT
reporting the same issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-9366) Unable represent literal byte costant
[
https://issues.apache.org/jira/browse/GROOVY-9366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paolo di tommaso updated GROOVY-9366:
-
Description:
Groovy does not allow the definition of literal byte constants. This makes
impossible to express byte constant in some use cases.
First example:
{code:java}
public @interface Version {
byte value();
}
class Foo {
@Version(0x01) String bar
}
Error: Attribute 'value' should have type 'java.lang.Byte'; but found type
'int' in @Version
{code}
Second example:
{code:java}
public @interface Version {
byte value();
}
class Foo {
@Version(1 as byte) String bar
}
Expected '(byte) 1' to be an inline constant of type byte in @Version
at line: 6, column: 14Attribute 'value' should have type 'java.lang.Byte'; but
found type 'java.lang.Object' in @Version
at line: -1, column: -1 {code}
Third example:
{code:java}
public @interface Version {
byte value();
}
class Foo {
public static final byte ONE = 0b01
@Version(ONE) String bar
}
Expected 'ONE' to be an inline constant of type byte not a field expression in
@Version
at line: 7, column: 12Attribute 'value' should have type 'java.lang.Byte'; but
found type 'java.lang.Object' in @Version
at line: -1, column: -1
{code}
was:
Groovy does not allow the definition of literal byte constant. This makes
impossible to express byte constant in some use cases.
First example:
{code:java}
public @interface Version {
byte value();
}
class Foo {
@Version(0x01) String bar
}
Error: Attribute 'value' should have type 'java.lang.Byte'; but found type
'int' in @Version
{code}
Second example:
{code:java}
public @interface Version {
byte value();
}
class Foo {
@Version(1 as byte) String bar
}
Expected '(byte) 1' to be an inline constant of type byte in @Version
at line: 6, column: 14Attribute 'value' should have type 'java.lang.Byte'; but
found type 'java.lang.Object' in @Version
at line: -1, column: -1 {code}
Third example:
{code:java}
public @interface Version {
byte value();
}
class Foo {
public static final byte ONE = 0b01
@Version(ONE) String bar
}
Expected 'ONE' to be an inline constant of type byte not a field expression in
@Version
at line: 7, column: 12Attribute 'value' should have type 'java.lang.Byte'; but
found type 'java.lang.Object' in @Version
at line: -1, column: -1
{code}
> Unable represent literal byte costant
> -
>
> Key: GROOVY-9366
> URL: https://issues.apache.org/jira/browse/GROOVY-9366
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.9
>Reporter: paolo di tommaso
>Priority: Major
>
> Groovy does not allow the definition of literal byte constants. This makes
> impossible to express byte constant in some use cases.
> First example:
> {code:java}
> public @interface Version {
> byte value();
> }
> class Foo {
> @Version(0x01) String bar
> }
> Error: Attribute 'value' should have type 'java.lang.Byte'; but found type
> 'int' in @Version
> {code}
>
> Second example:
> {code:java}
> public @interface Version {
> byte value();
> }
> class Foo {
> @Version(1 as byte) String bar
> }
> Expected '(byte) 1' to be an inline constant of type byte in @Version
> at line: 6, column: 14Attribute 'value' should have type 'java.lang.Byte';
> but found type 'java.lang.Object' in @Version
> at line: -1, column: -1 {code}
>
> Third example:
> {code:java}
> public @interface Version {
> byte value();
> }
> class Foo {
> public static final byte ONE = 0b01
> @Version(ONE) String bar
> }
> Expected 'ONE' to be an inline constant of type byte not a field expression
> in @Version
> at line: 7, column: 12Attribute 'value' should have type 'java.lang.Byte';
> but found type 'java.lang.Object' in @Version
> at line: -1, column: -1
> {code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GROOVY-9366) Unable represent literal byte costant
paolo di tommaso created GROOVY-9366:
Summary: Unable represent literal byte costant
Key: GROOVY-9366
URL: https://issues.apache.org/jira/browse/GROOVY-9366
Project: Groovy
Issue Type: Bug
Affects Versions: 2.5.9
Reporter: paolo di tommaso
Groovy does not allow the definition of literal byte constant. This makes
impossible to express byte constant in some use cases.
First example:
{code:java}
public @interface Version {
byte value();
}
class Foo {
@Version(0x01) String bar
}
Error: Attribute 'value' should have type 'java.lang.Byte'; but found type
'int' in @Version
{code}
Second example:
{code:java}
public @interface Version {
byte value();
}
class Foo {
@Version(1 as byte) String bar
}
Expected '(byte) 1' to be an inline constant of type byte in @Version
at line: 6, column: 14Attribute 'value' should have type 'java.lang.Byte'; but
found type 'java.lang.Object' in @Version
at line: -1, column: -1 {code}
Third example:
{code:java}
public @interface Version {
byte value();
}
class Foo {
public static final byte ONE = 0b01
@Version(ONE) String bar
}
Expected 'ONE' to be an inline constant of type byte not a field expression in
@Version
at line: 7, column: 12Attribute 'value' should have type 'java.lang.Byte'; but
found type 'java.lang.Object' in @Version
at line: -1, column: -1
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GROOVY-9504) Add support for Path to slurper classes
paolo di tommaso created GROOVY-9504: Summary: Add support for Path to slurper classes Key: GROOVY-9504 URL: https://issues.apache.org/jira/browse/GROOVY-9504 Project: Groovy Issue Type: Improvement Components: groovy-yaml, JSON, XML Processing Reporter: paolo di tommaso The classes `JsonSlurper`, `YamlSlurper` and `XmlSlurper` allow the parsing of the content of a file object specified as `File` object, however, it's missing a `parse` method taking the [Path|[https://docs.oracle.com/javase/8/docs/api/java/nio/file/Paths.html]] interface as a argument. As a workaround, it's possible to convert a `File` to a `Path` using the `toPath()` method however this does not fully support the new API features, notably the ability to reference and therefore access foreign files e.g. non-local files such as in-memory, S3, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-9209) Compiler throws an exception in ClassNode#getTypeClass after checking ClassNode#isResolved
[
https://issues.apache.org/jira/browse/GROOVY-9209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17134731#comment-17134731
]
paolo di tommaso commented on GROOVY-9209:
--
This bug is still a source of lot of pains. Any progress would be appreciated.
> Compiler throws an exception in ClassNode#getTypeClass after checking
> ClassNode#isResolved
> --
>
> Key: GROOVY-9209
> URL: https://issues.apache.org/jira/browse/GROOVY-9209
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.5.6
> Environment: intellij idea
>Reporter: Daniil Ovchinnikov
>Priority: Critical
>
> {noformat}
> Error:Groovyc: While compiling mn-gorm-example.main: BUG! exception in phase
> 'canonicalization' in source unit
> '/Users/pditommaso/Projects/mn-gorm-example/src/main/groovy/example/gorm/Bootstrap.groovy'
> JVM class can't be loaded for example.gorm.service.PersonService
> at
> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveJvmClass(AsmReferenceResolver.java:86)
> at
> org.codehaus.groovy.ast.decompiled.DecompiledClassNode.getTypeClass(DecompiledClassNode.java:175)
> at org.codehaus.groovy.ast.ClassNode.getTypeClass(ClassNode.java:1381)
> at
> io.micronaut.ast.groovy.InjectTransform$InjectVisitor.resolveParameterType(InjectTransform.groovy:1117)
> ...
> {noformat}
> {code:java|title=InjectVisitor#resolveParameterType}
> ClassNode parameterType = parameter.type
> if (parameterType.isResolved()) {
> parameterType.typeClass // here
> } else {
> parameterType.name
> }
> {code}
> Code: [https://github.com/pditommaso/mn-gorm-example]
> Steps to reproduce:
> 1. make sure the build is not delegated to Gradle in Preferences | Build,
> Execution, Deployment | Build Tools | Gradle
> 2. rebuild project
> 3. make changes in Person.groovy and Bootstrap.groovy (to mark them as
> subject for recompilation)
> 4. build project
> What happens with {{-Dgroovyc.asm.resolving.only=false}}:
> 1. Bootstrap.groovy and Person.groovy are added to
> {{CompilationUnit#queuedSources}}
> 2. {{ResolveVisitor}} visits Bootstrap.groovy and tries to load PersonService
> 3. {{asmResolving}} flag is set to {{false}} by IntelliJ, this results in
> skipping {{findDecompiled}} call inside
> {{ClassNodeResolver#tryAsLoaderClassOrScript}}
> 4. the PersonService class fails to load because of missing Person class
> 5. {{tryAsScript}} kicks in and adds PersonService to
> {{CompilationUnit#queuedSources}}
> 6. when it comes to Micronaut {{ClassNode#isResolved}} returns {{false}} for
> PersonService
> What happens without {{-Dgroovyc.asm.resolving.only=false}}:
> 1. same
> 2. same
> 3. {{asmResolving}} is not set by IntellliJ
> 4. {{findDecompiled}} returns {{DecompiledClassNode}} for PersonService
> 5. when it comes to Micronaut {{ClassNode#isResolved}} returns {{true}} for
> PersonService, and this results in an exception because the class cannot be
> loaded actually.
> I've tried to fix it in the compiler but I'm not sure what's the proper fix
> would be.
> Please let me know if I can do something within IntelliJ.
> The issue in JB YouTrack for the reference:
> [https://youtrack.jetbrains.com/issue/IDEA-218698]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GROOVY-11211) Unexpected invocation of getter method
paolo di tommaso created GROOVY-11211:
-
Summary: Unexpected invocation of getter method
Key: GROOVY-11211
URL: https://issues.apache.org/jira/browse/GROOVY-11211
Project: Groovy
Issue Type: Bug
Components: groovy-runtime
Affects Versions: 4.0.15
Reporter: paolo di tommaso
The map `get` method is invoked unexpectedly while resolving a closure
delegate.
To replicate the issue consider the following custom Map object in which both
`get` and `invokeMethod` methods are overridden:
{code:java}
class Context implements Map {
@Delegate private Map target
Context(Map target) { this.target = target }
@Override
Object get(Object name) {
if( target.containsKey(name) )
return target.get(name)
throw new Exception('Missing key: ' + name)
}
@Override
Object invokeMethod(String name, Object args) {
if( name == 'foo' )
return 'OK'
else
super.invokeMethod(name, args)
}
}
{code}
Then, a closure tries to invoke the `foo` method via a context delegate, as
shown below:
{code:java}
def closure = { it -> foo() }
closure.delegate = new Context([:])
closure.setResolveStrategy(Closure.DELEGATE_ONLY)
assert closure.call() == 'OK' {code}
The `OK` string should be returned by the closure because `foo` method should
be resolved via the `invokeMethod` method.
However, the above snippet fails with the following message:
{code:java}
java.lang.Exception: Missing key: foo {code}
This code works as expected with Groovy 3.x
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11211) Unexpected invocation of getter method
[
https://issues.apache.org/jira/browse/GROOVY-11211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paolo di tommaso updated GROOVY-11211:
--
Description:
The map `get` method is invoked unexpectedly while resolving a closure
delegate.
To replicate the issue consider the following custom Map object in which both
`get` and `invokeMethod` methods are overridden:
{code:java}
class Context implements Map {
@Delegate private Map target
Context(Map target) { this.target = target }
@Override
Object get(Object name) {
if( target.containsKey(name) )
return target.get(name)
throw new Exception('Missing key: ' + name)
}
@Override
Object invokeMethod(String name, Object args) {
if( name == 'foo' )
return 'OK'
else
super.invokeMethod(name, args)
}
}
{code}
Then, a closure tries to invoke the `foo` method via a context delegate, as
shown below:
{code:java}
def closure = { it -> foo() }
closure.delegate = new Context([:])
closure.setResolveStrategy(Closure.DELEGATE_ONLY)
assert closure.call() == 'OK' {code}
The `OK` string should be returned by the closure because `foo` method should
be resolved via the `invokeMethod` method.
However, the above snippet fails with the following message:
{code:java}
java.lang.Exception: Missing key: foo {code}
This code works as expected with Groovy 3.x
was:
The map `get` method is invoked unexpectedly while resolving a closure
delegate.
To replicate the issue consider the following custom Map object in which both
`get` and `invokeMethod` methods are overridden:
{code:java}
class Context implements Map {
@Delegate private Map target
Context(Map target) { this.target = target }
@Override
Object get(Object name) {
if( target.containsKey(name) )
return target.get(name)
throw new Exception('Missing key: ' + name)
}
@Override
Object invokeMethod(String name, Object args) {
if( name == 'foo' )
return 'OK'
else
super.invokeMethod(name, args)
}
}
{code}
Then, a closure tries to invoke the `foo` method via a context delegate, as
shown below:
{code:java}
def closure = { it -> foo() }
closure.delegate = new Context([:])
closure.setResolveStrategy(Closure.DELEGATE_ONLY)
assert closure.call() == 'OK' {code}
The `OK` string should be returned by the closure because `foo` method should
be resolved via the `invokeMethod` method.
However, the above snippet fails with the following message:
{code:java}
java.lang.Exception: Missing key: foo {code}
This code works as expected with Groovy 3.x
> Unexpected invocation of getter method
> --
>
> Key: GROOVY-11211
> URL: https://issues.apache.org/jira/browse/GROOVY-11211
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 4.0.15
>Reporter: paolo di tommaso
>Priority: Minor
>
> The map `get` method is invoked unexpectedly while resolving a closure
> delegate.
> To replicate the issue consider the following custom Map object in which both
> `get` and `invokeMethod` methods are overridden:
>
> {code:java}
> class Context implements Map {
> @Delegate private Map target
> Context(Map target) { this.target = target }
> @Override
> Object get(Object name) {
> if( target.containsKey(name) )
> return target.get(name)
> throw new Exception('Missing key: ' + name)
> }
> @Override
> Object invokeMethod(String name, Object args) {
> if( name == 'foo' )
> return 'OK'
> else
> super.invokeMethod(name, args)
> }
> }
> {code}
>
> Then, a closure tries to invoke the `foo` method via a context delegate, as
> shown below:
>
> {code:java}
> def closure = { it -> foo() }
> closure.delegate = new Context([:])
> closure.setResolveStrategy(Closure.DELEGATE_ONLY)
> assert closure.call() == 'OK' {code}
>
> The `OK` string should be returned by the closure because `foo` method should
> be resolved via the `invokeMethod` method.
>
> However, the above snippet fails with the following message:
>
> {code:java}
> java.lang.Exception: Missing key: foo {code}
> This code works as expected with Groovy 3.x
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11211) Unexpected invocation of getter method
[
https://issues.apache.org/jira/browse/GROOVY-11211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paolo di tommaso updated GROOVY-11211:
--
Description:
The map `get` method is invoked unexpectedly while resolving a closure
delegate.
To replicate the issue consider the following custom Map object in which both
`get` and `invokeMethod` methods are overridden:
{code:java}
class Context implements Map {
@Delegate private Map target
Context(Map target) { this.target = target }
@Override
Object get(Object name) {
if( target.containsKey(name) )
return target.get(name)
throw new Exception('Missing key: ' + name)
}
@Override
Object invokeMethod(String name, Object args) {
if( name == 'foo' )
return 'OK'
else
super.invokeMethod(name, args)
}
}
{code}
Then, a closure tries to invoke the `foo` method via a context delegate, as
shown below:
{code:java}
def closure = { it -> foo() }
closure.delegate = new Context([:])
closure.setResolveStrategy(Closure.DELEGATE_ONLY)
assert closure.call() == 'OK' {code}
The `OK` string should be returned by the closure because `foo` method should
be resolved via the `invokeMethod` method.
However, the above snippet fails with the following message:
{code:java}
java.lang.Exception: Missing key: foo {code}
This code works as expected with Groovy 3.x
was:
The map `get` method is invoked unexpectedly while resolving a closure
delegate.
To replicate the issue consider the following custom Map object in which both
`get` and `invokeMethod` methods are overridden:
{code:java}
class Context implements Map {
@Delegate private Map target
Context(Map target) { this.target = target }
@Override
Object get(Object name) {
if( target.containsKey(name) )
return target.get(name)
throw new Exception('Missing key: ' + name)
}
@Override
Object invokeMethod(String name, Object args) {
if( name == 'foo' )
return 'OK'
else
super.invokeMethod(name, args)
}
}
{code}
Then, a closure tries to invoke the `foo` method via a context delegate, as
shown below:
{code:java}
def closure = { it -> foo() }
closure.delegate = new Context([:])
closure.setResolveStrategy(Closure.DELEGATE_ONLY)
assert closure.call() == 'OK' {code}
The `OK` string should be returned by the closure because `foo` method should
be resolved via the `invokeMethod` method.
However, the above snippet fails with the following message:
{code:java}
java.lang.Exception: Missing key: foo {code}
This code works as expected with Groovy 3.x
> Unexpected invocation of getter method
> --
>
> Key: GROOVY-11211
> URL: https://issues.apache.org/jira/browse/GROOVY-11211
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 4.0.15
>Reporter: paolo di tommaso
>Priority: Minor
>
> The map `get` method is invoked unexpectedly while resolving a closure
> delegate.
> To replicate the issue consider the following custom Map object in which both
> `get` and `invokeMethod` methods are overridden:
>
> {code:java}
> class Context implements Map {
> @Delegate private Map target
> Context(Map target) { this.target = target }
> @Override
> Object get(Object name) {
> if( target.containsKey(name) )
> return target.get(name)
> throw new Exception('Missing key: ' + name)
> }
> @Override
> Object invokeMethod(String name, Object args) {
> if( name == 'foo' )
> return 'OK'
> else
> super.invokeMethod(name, args)
> }
> }
> {code}
>
> Then, a closure tries to invoke the `foo` method via a context delegate, as
> shown below:
>
> {code:java}
> def closure = { it -> foo() }
> closure.delegate = new Context([:])
> closure.setResolveStrategy(Closure.DELEGATE_ONLY)
> assert closure.call() == 'OK' {code}
>
> The `OK` string should be returned by the closure because `foo` method should
> be resolved via the `invokeMethod` method.
>
> However, the above snippet fails with the following message:
>
> {code:java}
> java.lang.Exception: Missing key: foo {code}
>
> This code works as expected with Groovy 3.x
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-2433) Closure in base class unable to call private methods when invoked from derived class
[ https://issues.apache.org/jira/browse/GROOVY-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842776#comment-17842776 ] paolo di tommaso commented on GROOVY-2433: -- Any chance to have this backported to Groovy 4? > Closure in base class unable to call private methods when invoked from > derived class > > > Key: GROOVY-2433 > URL: https://issues.apache.org/jira/browse/GROOVY-2433 > Project: Groovy > Issue Type: Sub-task > Components: groovy-runtime >Reporter: David Clark >Assignee: Eric Milles >Priority: Major > Fix For: 5.0.0-alpha-1 > > Attachments: testcase.zip > > > Closures defined in base classes are not able to access private methods in > the same base class, when invoked from a derived class. Java visibility > rules imply that this should not happen. When the private methods are made > public, the error disappears. Also, when the closure is converted to a > method the problem also disappears. Compiling and running the TestCase class > included (along with Base class) should reproduce the problem. It's easier > to see the problem than to try and describe it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
