[jira] [Closed] (GROOVY-8535) FieldNode constructor appears to call setType incorrectly
[
https://issues.apache.org/jira/browse/GROOVY-8535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-8535.
-
> FieldNode constructor appears to call setType incorrectly
> -
>
> Key: GROOVY-8535
> URL: https://issues.apache.org/jira/browse/GROOVY-8535
> Project: Groovy
> Issue Type: Improvement
>Affects Versions: 2.4.15
>Reporter: Eric Milles
>Assignee: Paul King
>Priority: Major
> Fix For: 2.5.6, 3.0.0-alpha-5
>
>
> If initial value expression is non-null, the first call to {{setType}}
> appears to have no effect.
> {code:java}
> public FieldNode(String name, int modifiers, ClassNode type, ClassNode
> owner, Expression initialValueExpression) {
> this.name = name;
> this.modifiers = modifiers;
> this.type = type;
> if (this.type == ClassHelper.DYNAMIC_TYPE && initialValueExpression
> != null)
> this.setType(initialValueExpression.getType());
> this.setType(type);
> this.originType = type;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-8238) multiple-catch statement behaves strangely
[
https://issues.apache.org/jira/browse/GROOVY-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-8238.
-
> multiple-catch statement behaves strangely
> --
>
> Key: GROOVY-8238
> URL: https://issues.apache.org/jira/browse/GROOVY-8238
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.4.6
> Environment: Windows 10
>Reporter: Gert Grossmann
>Assignee: Paul King
>Priority: Major
> Fix For: 2.5.6, 3.0.0-alpha-5
>
>
> {code:java}
> try {
> throw new AnyJavaException()
> } catch ( AnyJavaException1 | AnyJavaException2 e ) {
> println e.message
> }
> {code}
> This works as expected. But following does not:
> {code:java}
> try {
> throw new AnyJavaException()
> } catch ( AnyJavaException | AnyGroovyException e ) {
> println e.message
> }
> {code}
> You get:
> {noformat}
> java.lang.ClassCastException: AnyJavaException cannot be cast to
> groovy.lang.GroovyObject
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-7996) Using with method with a closure that references a protected property produces ClassCastException
[
https://issues.apache.org/jira/browse/GROOVY-7996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-7996.
-
> Using with method with a closure that references a protected property
> produces ClassCastException
> -
>
> Key: GROOVY-7996
> URL: https://issues.apache.org/jira/browse/GROOVY-7996
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.7
>Reporter: Graeme Rocher
>Assignee: Paul King
>Priority: Major
> Fix For: 2.5.6, 3.0.0-alpha-5
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following example:
> {code}
> class Foo {
> Object propertyMissing(String name) {
> return "stuff"
> }
>
> void build(Closure callable) {
> this.with(callable)
> }
> }
> @groovy.transform.CompileStatic
> class Bar {
> protected List bar = []
>
> boolean doStuff() {
> Foo foo = new Foo()
> foo.build {
>return bar.isEmpty()
> }
> }
> }
> new Bar().doStuff()
> {code}
> Produces
> {code}
> java.lang.ClassCastException: java.lang.String cannot be cast to
> java.util.List
> at Bar$_doStuff_closure1.doCall(ConsoleScript3:19)
> at Bar$_doStuff_closure1.call(ConsoleScript3)
> at
> org.codehaus.groovy.runtime.DefaultGroovyMethods.with(DefaultGroovyMethods.java:242)
> at Bar.doStuff(ConsoleScript3:18)
> at Ba
> {code}
> The equivalent code without CompileStatic prints:
> {code}
> Result: false
> {code}
> The behaviour of both should be he same IMO
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-8971) The VMPlugin configureClassNode method should retain parameter name information when available
[ https://issues.apache.org/jira/browse/GROOVY-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-8971. - > The VMPlugin configureClassNode method should retain parameter name > information when available > -- > > Key: GROOVY-8971 > URL: https://issues.apache.org/jira/browse/GROOVY-8971 > Project: Groovy > Issue Type: Improvement >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 2.5.6, 3.0.0-alpha-5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GROOVY-5852) Static import on demand resolves capitalised reference
[
https://issues.apache.org/jira/browse/GROOVY-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-5852.
-
> Static import on demand resolves capitalised reference
> --
>
> Key: GROOVY-5852
> URL: https://issues.apache.org/jira/browse/GROOVY-5852
> Project: Groovy
> Issue Type: Sub-task
> Components: Compiler
>Reporter: Maxim Medvedev
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 2.5.6, 3.0.0-alpha-5
>
>
> get a class
> {code}
> class Constants {
> static final pi = 3.14 //final property with implicit getter
> }
> {code}
> and another one
> {code}
> import static Constants.*
> println Pi // first reference
> println Constants.Pi //second reference
> {code}
> IMHO both references to pi should throw a MissingPropertyException as they
> have capitalised first letter. Or both of them should not. Now first
> reference works while the second ref does not.
> BTW if we provide explicit 'public' modifier to pi, both references fail.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-8967) @Immutable not handling property default values from map constructor
[
https://issues.apache.org/jira/browse/GROOVY-8967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-8967.
-
> @Immutable not handling property default values from map constructor
>
>
> Key: GROOVY-8967
> URL: https://issues.apache.org/jira/browse/GROOVY-8967
> Project: Groovy
> Issue Type: Bug
>Reporter: Paul King
>Assignee: Paul King
>Priority: Major
> Fix For: 2.5.6, 3.0.0-alpha-5
>
>
> {code:java}
> import groovy.transform.Immutable
> @Immutable
> class Thing {
> String value = "default"
> }
> def thing = new Thing()
> assert thing.value == "default"
> {code}
> Gives:
> {noformat}
> Assertion failed:
> assert thing.value == "default"
>| | |
>| null false
>Thing(null)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-2773) Strange behaviour when passing chained methods (methodA().methodB().etc()) as parameters
[
https://issues.apache.org/jira/browse/GROOVY-2773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-2773.
-
> Strange behaviour when passing chained methods (methodA().methodB().etc()) as
> parameters
>
>
> Key: GROOVY-2773
> URL: https://issues.apache.org/jira/browse/GROOVY-2773
> Project: Groovy
> Issue Type: Sub-task
> Components: Compiler
> Environment: Ubuntu Gutsy Gibbon
>Reporter: Stephen Cresswell
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 2.5.6, 3.0.0-alpha-5
>
> Attachments: groovybug.tar.gz
>
>
> {code}
> import org.joda.time.DateTime
> import static org.joda.time.DateTimeZone
> class EWUtils {
> static DateTime nowUTC() {
> return new DateTime(UTC)
> }
> }
> //Inside a test case
> import static EWUtils.nowUTC
> ...
> DateTime baseDate = nowUTC()
> println "${baseDate.minusWeeks(1)} ${baseDate.minusWeeks(1).millis}"
> println "${nowUTC().minusWeeks(1)} ${nowUTC().minusWeeks(1).millis}"
> // The output
> 2008-04-16T18:40:09.698Z 1208371209698
> 2008-04-16T18:40:09.709Z 1208976009709
> {code}
> The second println statement demonstrates the bug. The epoch time is
> approximately equal to the current time instead of being a week old as in the
> first example.
> The bug only manifests when nowUTC() belongs to another class - if I move it
> into the same class as the test it's OK
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-3446) Method call resolves to statically imported method instead of equally named local method
[
https://issues.apache.org/jira/browse/GROOVY-3446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-3446.
-
> Method call resolves to statically imported method instead of equally named
> local method
>
>
> Key: GROOVY-3446
> URL: https://issues.apache.org/jira/browse/GROOVY-3446
> Project: Groovy
> Issue Type: Sub-task
> Components: Compiler
>Affects Versions: 1.7-beta-1
>Reporter: Peter Niederwieser
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 2.5.6, 3.0.0-alpha-5
>
>
> {code}
> package groovy.bugs
> import static java.lang.System.currentTimeMillis
> class Groovy3446_Bug extends GroovyTestCase {
> void testLocalMethodFavoredOverStaticallyImportedMethod() {
> assert currentTimeMillis() == "local method called"
> }
> def currentTimeMillis() {
> "local method called"
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-8968) Upgrade picocli to 3.9.2 from 3.7.0
[ https://issues.apache.org/jira/browse/GROOVY-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-8968. - > Upgrade picocli to 3.9.2 from 3.7.0 > --- > > Key: GROOVY-8968 > URL: https://issues.apache.org/jira/browse/GROOVY-8968 > Project: Groovy > Issue Type: Dependency upgrade > Components: command line processing >Affects Versions: 2.5.5 >Reporter: Remko Popma >Assignee: Remko Popma >Priority: Major > Fix For: 2.5.6 > > > Upgrade picocli to 3.9.2 from 3.7.0. > Potential impact: small change in usage help message format in > https://github.com/remkop/picocli/releases/tag/v3.8.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GROOVY-8964) MissingMethodException when trying to resolve overload with variable arguments
[
https://issues.apache.org/jira/browse/GROOVY-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-8964.
-
> MissingMethodException when trying to resolve overload with variable arguments
> --
>
> Key: GROOVY-8964
> URL: https://issues.apache.org/jira/browse/GROOVY-8964
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.5
> Environment: Windows
>Reporter: Alexey Subach
>Assignee: Paul King
>Priority: Critical
> Fix For: 2.5.6, 3.0.0-alpha-5
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Minimal script to reproduce the issue:
> {code}
> #!/usr/bin/env groovy
> class Example {
> void method(String... args) {
> }
> static void method(List args, File workDirectory, Appendable out,
> Appendable err) {
> }
> void execute() {
> method("a", "b", "c", "d")
> }
> }
> Example ex = new Example()
> ex.execute()
> {code}
> Running this script on Windows produces the following exception:
> {code}
> Caught: groovy.lang.MissingMethodException: No signature of method: static
> Example.method() is applicable for argument types: (String, String, String,
> String) values: [a, b, c, d]
> Possible solutions: method([Ljava.lang.String;), method(java.util.List,
> java.io.File, java.lang.Appendable, java.lang.Appendable)
> groovy.lang.MissingMethodException: No signature of method: static
> Example.method() is applicable for argument types: (String, String, String,
> String) values: [a, b, c, d]
> Possible solutions: method([Ljava.lang.String;), method(java.util.List,
> java.io.File, java.lang.Appendable, java.lang.Appendable)
> at Example.execute(Hello.groovy:12)
> at Example$execute.call(Unknown Source)
> at Hello.run(Hello.groovy:17)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-8951) Traits defining getter conflicts with generated getter (improvements for pre-compiled case)
[
https://issues.apache.org/jira/browse/GROOVY-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-8951.
-
> Traits defining getter conflicts with generated getter (improvements for
> pre-compiled case)
> ---
>
> Key: GROOVY-8951
> URL: https://issues.apache.org/jira/browse/GROOVY-8951
> Project: Groovy
> Issue Type: Bug
> Components: Stub generator / Joint compiler
>Reporter: Keegan Witt
>Assignee: Paul King
>Priority: Major
> Fix For: 2.5.6, 3.0.0-alpha-5
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code:java}
> class Foo { }
> trait GetFoo {
> abstract Foo getFoo()
> }
> class BaseFooSpec {
> Foo foo
> }
> class FooSpec extends BaseFooSpec implements GetFoo { }
> {code}
> Generates a stub for FooSpec with
> {code:java}
> public class FooSpec
> extends BaseFooSpec implements
> GetFoo,groovy.lang.GroovyObject {
> ;
> @groovy.transform.Generated() @groovy.transform.Internal() public
> groovy.lang.MetaClass getMetaClass() { return (groovy.lang.MetaClass)null;}
> @groovy.transform.Generated() @groovy.transform.Internal() public void
> setMetaClass(groovy.lang.MetaClass mc) { }
> @groovy.transform.Generated() @groovy.transform.Internal() public
> java.lang.Object invokeMethod(java.lang.String method, java.lang.Object
> arguments) { return null;}
> @groovy.transform.Generated() @groovy.transform.Internal() public
> java.lang.Object getProperty(java.lang.String property) { return null;}
> @groovy.transform.Generated() @groovy.transform.Internal() public void
> setProperty(java.lang.String property, java.lang.Object value) { }
> public abstract Foo getFoo();
> }
> {code}
> Note the {{getFoo()}} is still {{abstract}} instead of using the getter
> generated from _BaseFooSpec_.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-8969) Parameter name data is erased when applying traits regardless of --parameters setting
[ https://issues.apache.org/jira/browse/GROOVY-8969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-8969. - > Parameter name data is erased when applying traits regardless of --parameters > setting > - > > Key: GROOVY-8969 > URL: https://issues.apache.org/jira/browse/GROOVY-8969 > Project: Groovy > Issue Type: Bug >Affects Versions: 2.5.5 >Reporter: Graeme Rocher >Assignee: Paul King >Priority: Major > Fix For: 2.5.6, 3.0.0-alpha-5 > > > When Groovy applies a trait to class it erases parameter name data. You can > see this here: > https://github.com/apache/groovy/blob/982bd38b3216ea3143b0d667d2cd47d2c758f884/src/main/java/org/codehaus/groovy/transform/trait/TraitComposer.java#L157 > So regardless whether `-parameters` is specified to the compiler traits will > not retain parameter name information. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GROOVY-8970) Fix typo in MANIFEST.MF: Main-class
[
https://issues.apache.org/jira/browse/GROOVY-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-8970.
-
> Fix typo in MANIFEST.MF: Main-class
> ---
>
> Key: GROOVY-8970
> URL: https://issues.apache.org/jira/browse/GROOVY-8970
> Project: Groovy
> Issue Type: Bug
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Minor
> Fix For: 2.5.6, 3.0.0-alpha-5
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> We should use {{Main-Class}} instead of {{Main-class}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-8272) Extending trait can't execute static method
[
https://issues.apache.org/jira/browse/GROOVY-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-8272.
-
> Extending trait can't execute static method
> ---
>
> Key: GROOVY-8272
> URL: https://issues.apache.org/jira/browse/GROOVY-8272
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.12
>Reporter: James Kleeh
>Assignee: Paul King
>Priority: Critical
> Fix For: 2.5.6, 3.0.0-alpha-5
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code}
> import groovy.transform.CompileStatic
> @CompileStatic
> trait Foo {
> static void go() {
> }
> }
> @CompileStatic
> trait Bar extends Foo {
> void doIt() {
> go()
> }
> }
> {code}
> The above code will produce the following:
> {{[Static type checking] - Cannot find matching method Bar#go(). Please check
> if the declared type is right and if the method exists.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-8873) Fails at runtime with @CompileStatic and two nested with
[
https://issues.apache.org/jira/browse/GROOVY-8873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-8873.
-
> Fails at runtime with @CompileStatic and two nested with
>
>
> Key: GROOVY-8873
> URL: https://issues.apache.org/jira/browse/GROOVY-8873
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.15, 2.5.3
>Reporter: Mauro Molinari
>Assignee: Paul King
>Priority: Major
> Fix For: 2.5.6, 3.0.0-alpha-5
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Consider this class:
> {code:java}
> package testgroovy
> import groovy.transform.CompileStatic
> @CompileStatic
> class Foobar {
>
> static class Foo {
> String aaa = 'aaa'
> String bbb = 'bbb'
> }
>
> static class Bar {
> String ccc = 'ccc'
> }
>
> Foo foo = new Foo()
> Bar bar = new Bar()
>
> void foobar() {
> foo.with {
> bar.with {
> println aaa
> println bbb
> println ccc
> }
> }
> }
> static void main(String[] args) {
> new Foobar().foobar()
> }
> }{code}
> It fails at runtime with:
> {noformat}
> Exception in thread "main" java.lang.ClassCastException:
> testgroovy.Foobar$Bar cannot be cast to groovy.lang.Closure
> at testgroovy.Foobar$_foobar_closure1$_closure2.doCall(Foobar.groovy:23)
> at testgroovy.Foobar$_foobar_closure1$_closure2.call(Foobar.groovy)
> at
> org.codehaus.groovy.runtime.DefaultGroovyMethods.with(DefaultGroovyMethods.java:369)
> at
> org.codehaus.groovy.runtime.DefaultGroovyMethods.with(DefaultGroovyMethods.java:316)
> at testgroovy.Foobar$_foobar_closure1.doCall(Foobar.groovy:22)
> at testgroovy.Foobar$_foobar_closure1.call(Foobar.groovy)
> at
> org.codehaus.groovy.runtime.DefaultGroovyMethods.with(DefaultGroovyMethods.java:369)
> at
> org.codehaus.groovy.runtime.DefaultGroovyMethods.with(DefaultGroovyMethods.java:316)
> at testgroovy.Foobar.foobar(Foobar.groovy:21)
> at testgroovy.Foobar.main(Foobar.groovy:31){noformat}
> It works fine if you remove {{@CompileStatic}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-8972) CompilationUnit#createClassVisitor should use the class node resolver rather than the class loader directly
[ https://issues.apache.org/jira/browse/GROOVY-8972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-8972. - > CompilationUnit#createClassVisitor should use the class node resolver rather > than the class loader directly > --- > > Key: GROOVY-8972 > URL: https://issues.apache.org/jira/browse/GROOVY-8972 > Project: Groovy > Issue Type: Improvement >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 2.5.6, 3.0.0-alpha-5 > > > See: https://groovy.markmail.org/thread/rdv4tvs2hryiie3p -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GROOVY-8073) Map delegate within @CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-8073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-8073.
-
> Map delegate within @CompileStatic
> --
>
> Key: GROOVY-8073
> URL: https://issues.apache.org/jira/browse/GROOVY-8073
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.8
>Reporter: Daniil Ovchinnikov
>Assignee: Paul King
>Priority: Major
> Fix For: 2.5.6, 3.0.0-alpha-5
>
>
> {code}
> @CompileStatic
> class Main {
> static void main(String[] args) {
> def map = [a: 1, b: 2]
> map.with { // Exception in thread "main" java.lang.ClassCastException:
> java.util.LinkedHashMap cannot be cast to groovy.lang.GroovyObject
> println a
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-7812) Static inner classes cannot be accessed from other files when running by 'groovy' command
[
https://issues.apache.org/jira/browse/GROOVY-7812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-7812.
-
> Static inner classes cannot be accessed from other files when running by
> 'groovy' command
> -
>
> Key: GROOVY-7812
> URL: https://issues.apache.org/jira/browse/GROOVY-7812
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.4.6
>Reporter: Nikolay Chashnikov
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 2.5.6, 3.0.0-alpha-5
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Create the following files
> {code:title=Outer.groovy}
> class Outer {
> static class Inner {
> }
> }
> {code}
> {code:title=Main.groovy}
> println new Outer()
> println new Outer.Inner()
> {code}
> and run 'groovy Main.groovy'. It'll fail with the following message:
> {quote}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> /home/.../Main.groovy: 2: unable to resolve class Outer.Inner
> @ line 2, column 9.
>println new Outer.Inner()
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-7687) Bug with @CompileStatic and nested closures
[
https://issues.apache.org/jira/browse/GROOVY-7687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-7687.
-
> Bug with @CompileStatic and nested closures
> ---
>
> Key: GROOVY-7687
> URL: https://issues.apache.org/jira/browse/GROOVY-7687
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.4.5
>Reporter: Marc Ewert
>Assignee: Paul King
>Priority: Major
> Fix For: 2.5.6, 3.0.0-alpha-5
>
>
> I've encountered a strange bug in conjunction with closures, delegates and
> @CompileStatic. The following code works as expected:
> {code}
> import groovy.transform.CompileStatic
> @CompileStatic
> class SimpleTest {
> static class Foo {
> List bars = Arrays.asList(new Bar())
> }
> static class Bar {
> String message
> public String toString() {return message}
> }
> void execute(Foo foo) {
> interactions(foo, {
> bars.each ( { bar -> bar.message = "hello world"})
> })
> }
> void interactions(Foo foo, @DelegatesTo(Foo) Closure closure) {
> closure.delegate = foo
> closure.resolveStrategy = Closure.DELEGATE_FIRST
> closure()
> }
> static void main(String... args) {
> SimpleTest test = new SimpleTest()
> Foo foo = new Foo()
> test.execute(foo)
> println foo.bars
> }
> }
> {code}
> But when the bars member is prefixed with a public modifier the following
> compilation error is thrown
> {code}
> Exception in thread "main" java.lang.ClassCastException:
> SimpleTest$_execute_closure1 cannot be cast to SimpleTest$Foo
> at SimpleTest$_execute_closure1.doCall(SimpleTest.groovy:18)
> at SimpleTest$_execute_closure1.call(SimpleTest.groovy)
> at SimpleTest.interactions(SimpleTest.groovy:25)
> at SimpleTest.execute(SimpleTest.groovy:17)
> at SimpleTest.main(SimpleTest.groovy:31)
> 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:497)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> {code}
> Here the code causing the error:
> {code}
> import groovy.transform.CompileStatic
> @CompileStatic
> class SimpleTest {
> static class Foo {
> public List bars = Arrays.asList(new Bar())
> }
> static class Bar {
> String message
> public String toString() {return message}
> }
> void execute(Foo foo) {
> interactions(foo, {
> bars.each ( { bar -> bar.message = "hello world"})
> })
> }
> void interactions(Foo foo, @DelegatesTo(Foo) Closure closure) {
> closure.delegate = foo
> closure.resolveStrategy = Closure.DELEGATE_FIRST
> closure()
> }
> static void main(String... args) {
> SimpleTest test = new SimpleTest()
> Foo foo = new Foo()
> test.execute(foo)
> println foo.bars
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-8954) VerifyError due to incorrect bytecode produced when a trait super property call also comes from an interface
[
https://issues.apache.org/jira/browse/GROOVY-8954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-8954.
-
> VerifyError due to incorrect bytecode produced when a trait super property
> call also comes from an interface
>
>
> Key: GROOVY-8954
> URL: https://issues.apache.org/jira/browse/GROOVY-8954
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.5
>Reporter: Paul King
>Assignee: Paul King
>Priority: Major
> Fix For: 2.5.6, 3.0.0-alpha-5
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code}
> interface DomainProp {
> boolean isNullable()
> }
> abstract class OrderedProp implements DomainProp { }
> trait Nullable {
> boolean nullable = true
> }
> @groovy.transform.CompileStatic
> abstract class CustomProp extends OrderedProp implements Nullable { }
> println new CustomProp() {}
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-8959) NPE in StaticVerifier
[
https://issues.apache.org/jira/browse/GROOVY-8959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-8959.
-
> NPE in StaticVerifier
> -
>
> Key: GROOVY-8959
> URL: https://issues.apache.org/jira/browse/GROOVY-8959
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.4.16, 2.5.5
>Reporter: Eric Milles
>Assignee: Paul King
>Priority: Major
> Fix For: 2.5.6, 3.0.0-alpha-5
>
>
> I don't have the exact code that created this error, but the fix seems pretty
> simple.
> {code:java}
> // excerpt from StaticVerifier.visitConstructorOrMethod
> public void
> visitVariableExpression(VariableExpression ve) {
> if (exceptions.contains(ve.getName())) return;
> /* GRECLIPSE edit --
> VariableExpression.isInStaticContext is null safe
> Variable av = ve.getAccessedVariable();
> if (av instanceof DynamicVariable ||
> !av.isInStaticContext()) { // this is line 96
> */
> if (ve.getAccessedVariable() instanceof
> DynamicVariable || !ve.isInStaticContext()) {
> // GRECLIPSE end
> addVariableError(ve);
> }
> }
> {code}
> {code}
> java.lang.NullPointerException
> at
> org.codehaus.groovy.control.StaticVerifier$1.visitVariableExpression(StaticVerifier.java:96)
> at
> org.codehaus.groovy.ast.expr.VariableExpression.visit(VariableExpression.java:72)
> at
> org.codehaus.groovy.ast.CodeVisitorSupport.visitPropertyExpression(CodeVisitorSupport.java:302)
> at
> org.codehaus.groovy.ast.expr.PropertyExpression.visit(PropertyExpression.java:57)
> at
> org.codehaus.groovy.control.StaticVerifier.visitConstructorOrMethod(StaticVerifier.java:91)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructor(ClassCodeVisitorSupport.java:162)
> at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1210)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:54)
> at
> org.codehaus.groovy.control.StaticVerifier.visitClass(StaticVerifier.java:54)
> at
> org.codehaus.groovy.control.CompilationUnit$13.call(CompilationUnit.java:241)
> at
> org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1143)
> ... 20 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-8719) Add DelegatesTo annotation to CompilerCustomizationBuilder.withConfig
[
https://issues.apache.org/jira/browse/GROOVY-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-8719.
-
> Add DelegatesTo annotation to CompilerCustomizationBuilder.withConfig
> -
>
> Key: GROOVY-8719
> URL: https://issues.apache.org/jira/browse/GROOVY-8719
> Project: Groovy
> Issue Type: Improvement
>Affects Versions: 2.5.1
>Reporter: Eric Milles
>Assignee: Paul King
>Priority: Minor
> Fix For: 2.5.6, 3.0.0-alpha-5
>
>
> In
> {{org.codehaus.groovy.control.customizers.builder.CompilerCustomizationBuilder}},
> could the {{Closure}} param have a {{DelegatesTo}} annotation indicating
> that the builder is the delegate?
> Proposed:
> {code:java}
> public static CompilerConfiguration withConfig(CompilerConfiguration config,
> @DelegatesTo(type="org.codehaus.groovy.control.customizers.builder.CompilerCustomizationBuilder")
> Closure code) {
> {code}
> I verified that {{delegate}} is {{CompilerCustomizationBuilder}}, {{owner}}
> is the compiler config script type (probably the Closure's declaring type,
> and {{resolveStrategy}} is {{OWNER_FIRST}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-7160) NoSuchMethodError for varargs when type parameter extends interface
[
https://issues.apache.org/jira/browse/GROOVY-7160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-7160.
-
> NoSuchMethodError for varargs when type parameter extends interface
> ---
>
> Key: GROOVY-7160
> URL: https://issues.apache.org/jira/browse/GROOVY-7160
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.3.7, 2.4.0-beta-3
>Reporter: Yu Kobayashi
>Assignee: Paul King
>Priority: Major
> Fix For: 2.5.6, 3.0.0-alpha-5
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Java code
> {code}
> public class Foo {
> public void bar(T... args) {}
> }
> {code}
> Groovy code
> {code}
> @groovy.transform.CompileStatic
> void test() {
> new Foo().bar("a")
> }
> test()
> {code}
> Error message
> {code}
> Caught: java.lang.NoSuchMethodError: Foo.bar([Ljava/lang/Object;)V
> java.lang.NoSuchMethodError: Foo.bar([Ljava/lang/Object;)V
> at test.test(test.groovy:3)
> at test.run(test.groovy:5)
> {code}
> This happens for these two conditions.
> 1. Foo is a separate class and is not an inner class of the Groovy code
> 2. T extends interface
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-4287) CLONE - import of static nested classes in external groovy files is broken
[
https://issues.apache.org/jira/browse/GROOVY-4287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-4287.
-
> CLONE - import of static nested classes in external groovy files is broken
> --
>
> Key: GROOVY-4287
> URL: https://issues.apache.org/jira/browse/GROOVY-4287
> Project: Groovy
> Issue Type: Sub-task
> Components: Compiler
>Affects Versions: 1.7.3
>Reporter: Paul King
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 2.5.6, 3.0.0-alpha-5
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Splitting off problematic but critical case of resolving static nested and
> inner classes in external groovy files from GROOVY-4267. Copying Roshan's
> example from that issue:
> {code:title=Test.groovy}
> import static Outer.*
> // import static Outer.Inner // also fails
> // import Outer.Inner// also fails
> assert Inner.class.name != null
> {code}
> {code:title=Outer.groovy}
> class Outer {
> static class Inner {}
> }
> {code}
> Output:
> {noformat}
> Caught: groovy.lang.MissingPropertyException: No such property: Inner for
> class: Test
> at Test.run(Test.groovy:4)
> {noformat}
> Error message is slightly different for non-static import:
> {noformat}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> Test.groovy: 2: unable to resolve class Outer.Inner
> @ line 2, column 1.
>import Outer.Inner
>^
> 1 error
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-8250) VariableScopeVisitor does not set declaring class on property nodes
[
https://issues.apache.org/jira/browse/GROOVY-8250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-8250.
-
> VariableScopeVisitor does not set declaring class on property nodes
> ---
>
> Key: GROOVY-8250
> URL: https://issues.apache.org/jira/browse/GROOVY-8250
> Project: Groovy
> Issue Type: Bug
>Reporter: Eric Milles
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.0-alpha-4, 2.5.3
>
>
> VariableScopeVisitor.findClassMember creates PropertyNode instances for
> methods (ex: foo.bar will have a property node created if getBar() is
> implemented). This is done inside the MethodNode for loop circa line 165.
> The nodes created by this visitor lack a declaring class setting as well as
> having an improper type. Without these values, type inferencing is more
> difficult for anyone that processes the AST. These are reasonable simple to
> remedy:
> {code}
> private Variable findClassMember(ClassNode cn, String name) {
> if (cn == null) return null;
> if (cn.isScript()) {
> return new DynamicVariable(name, false);
> }
> for (FieldNode fn : cn.getFields()) {
> if (fn.getName().equals(name)) return fn;
> }
> for (MethodNode mn : cn.getMethods()) {
> String pName = getPropertyName(mn);
> // GRECLIPSE edit
> //if (pName != null && pName.equals(name))
> //return new PropertyNode(pName, mn.getModifiers(),
> ClassHelper.OBJECT_TYPE, cn, null, null, null);
> if (pName != null && pName.equals(name)) {
> PropertyNode property = new PropertyNode(pName,
> mn.getModifiers(), getPropertyType(mn), cn, null, null, null);
> property.getField().setDeclaringClass(cn);
> property.setDeclaringClass(cn);
> return property;
> }
> // GRECLIPSE end
> }
> ...
> // GRECLIPSE add
> private ClassNode getPropertyType(MethodNode m) {
> if (m.getReturnType() != ClassHelper.VOID_TYPE) {
> return m.getReturnType();
> }
> return m.getParameters()[0].getType();
> }
> // GRECLIPSE end
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GROOVY-8250) VariableScopeVisitor does not set declaring class on property nodes
[
https://issues.apache.org/jira/browse/GROOVY-8250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-8250.
---
Resolution: Fixed
Assignee: Paul King
Fix Version/s: 3.0.0-alpha-4
2.5.3
Fixed as part of GROOVY-8797, but see the comments wrt limitations on being
able to set the type. If you believe the type information needs further work,
please open a new issue.
> VariableScopeVisitor does not set declaring class on property nodes
> ---
>
> Key: GROOVY-8250
> URL: https://issues.apache.org/jira/browse/GROOVY-8250
> Project: Groovy
> Issue Type: Bug
>Reporter: Eric Milles
>Assignee: Paul King
>Priority: Major
> Fix For: 2.5.3, 3.0.0-alpha-4
>
>
> VariableScopeVisitor.findClassMember creates PropertyNode instances for
> methods (ex: foo.bar will have a property node created if getBar() is
> implemented). This is done inside the MethodNode for loop circa line 165.
> The nodes created by this visitor lack a declaring class setting as well as
> having an improper type. Without these values, type inferencing is more
> difficult for anyone that processes the AST. These are reasonable simple to
> remedy:
> {code}
> private Variable findClassMember(ClassNode cn, String name) {
> if (cn == null) return null;
> if (cn.isScript()) {
> return new DynamicVariable(name, false);
> }
> for (FieldNode fn : cn.getFields()) {
> if (fn.getName().equals(name)) return fn;
> }
> for (MethodNode mn : cn.getMethods()) {
> String pName = getPropertyName(mn);
> // GRECLIPSE edit
> //if (pName != null && pName.equals(name))
> //return new PropertyNode(pName, mn.getModifiers(),
> ClassHelper.OBJECT_TYPE, cn, null, null, null);
> if (pName != null && pName.equals(name)) {
> PropertyNode property = new PropertyNode(pName,
> mn.getModifiers(), getPropertyType(mn), cn, null, null, null);
> property.getField().setDeclaringClass(cn);
> property.setDeclaringClass(cn);
> return property;
> }
> // GRECLIPSE end
> }
> ...
> // GRECLIPSE add
> private ClassNode getPropertyType(MethodNode m) {
> if (m.getReturnType() != ClassHelper.VOID_TYPE) {
> return m.getReturnType();
> }
> return m.getParameters()[0].getType();
> }
> // GRECLIPSE end
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8250) VariableScopeVisitor does not set declaring class on property nodes
[
https://issues.apache.org/jira/browse/GROOVY-8250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773680#comment-16773680
]
Daniel Sun commented on GROOVY-8250:
[~emilles] Do you have any test case to verify the fix?
> VariableScopeVisitor does not set declaring class on property nodes
> ---
>
> Key: GROOVY-8250
> URL: https://issues.apache.org/jira/browse/GROOVY-8250
> Project: Groovy
> Issue Type: Bug
>Reporter: Eric Milles
>Priority: Major
>
> VariableScopeVisitor.findClassMember creates PropertyNode instances for
> methods (ex: foo.bar will have a property node created if getBar() is
> implemented). This is done inside the MethodNode for loop circa line 165.
> The nodes created by this visitor lack a declaring class setting as well as
> having an improper type. Without these values, type inferencing is more
> difficult for anyone that processes the AST. These are reasonable simple to
> remedy:
> {code}
> private Variable findClassMember(ClassNode cn, String name) {
> if (cn == null) return null;
> if (cn.isScript()) {
> return new DynamicVariable(name, false);
> }
> for (FieldNode fn : cn.getFields()) {
> if (fn.getName().equals(name)) return fn;
> }
> for (MethodNode mn : cn.getMethods()) {
> String pName = getPropertyName(mn);
> // GRECLIPSE edit
> //if (pName != null && pName.equals(name))
> //return new PropertyNode(pName, mn.getModifiers(),
> ClassHelper.OBJECT_TYPE, cn, null, null, null);
> if (pName != null && pName.equals(name)) {
> PropertyNode property = new PropertyNode(pName,
> mn.getModifiers(), getPropertyType(mn), cn, null, null, null);
> property.getField().setDeclaringClass(cn);
> property.setDeclaringClass(cn);
> return property;
> }
> // GRECLIPSE end
> }
> ...
> // GRECLIPSE add
> private ClassNode getPropertyType(MethodNode m) {
> if (m.getReturnType() != ClassHelper.VOID_TYPE) {
> return m.getReturnType();
> }
> return m.getParameters()[0].getType();
> }
> // GRECLIPSE end
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GROOVY-7778) CLONE - Enum constructor with value throws "unexpected token" error
[
https://issues.apache.org/jira/browse/GROOVY-7778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-7778.
---
Resolution: Fixed
Assignee: Daniel Sun
Fix Version/s: 3.0.0-alpha-4
Marking as resolved in 3.0.0-alpha-4 though it may have been an earlier version
incorporating the Parrot parser.
> CLONE - Enum constructor with value throws "unexpected token" error
> ---
>
> Key: GROOVY-7778
> URL: https://issues.apache.org/jira/browse/GROOVY-7778
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.4.6
> Environment: Windows 7 Professional
> JDK 1.8.0_45
>Reporter: Brian Ray
>Assignee: Daniel Sun
>Priority: Minor
> Fix For: 3.0.0-alpha-4
>
>
> First time submitter to this JIRA so let me know if I've specified anything
> incorrectly. I just upgraded from 2.4.4 to 2.4.6 and now declaring an enum
> constructor accepting a value as follows:
> {code:title=UsStates.groovy}
> enum UsState {
>
> ID('Idaho'),
> IL('Illinois'),
> IN('Indiana'),
>
> UsState( String value ) { this.value = value }
> private final String value
>
> String toString() { return value }
> }
> println UsState.ID //Idaho
> {code}
> throws the following compile error:
> {code}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> C:\svn_qa\jenkins_trunk\scripts\UsStates.groovy: 7: unexpected token: this @
> line 7, column 29.
> UsState( String value ) { this.value = value }
>^
> 1 error
> {code}
> No such error occurred in 2.4.4, nor does it happen in 2.4.5. Here are a few
> contrasting things that do seem to work in 2.4.6:
> {code:title=UsStatesBoring.groovy}
> enum UsState {
>
> ID,
> IL,
> IN,
> }
> println UsState.ID //ID
> {code}
> {code:title=UsStatesNoEnum.groovy}
> class UsState {
>
> UsState( String value ) { this.value = value }
> private final String value
>
> String toString() { return value }
> }
> final idaho = new UsState('Idaho')
> println idaho //Idaho
> {code}
> Though this seems higher priority than Minor, I can work around it by simply
> downgrading to 2.4.5. I wish there was a Medium priority.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-7778) CLONE - Enum constructor with value throws "unexpected token" error
[
https://issues.apache.org/jira/browse/GROOVY-7778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-7778.
-
> CLONE - Enum constructor with value throws "unexpected token" error
> ---
>
> Key: GROOVY-7778
> URL: https://issues.apache.org/jira/browse/GROOVY-7778
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.4.6
> Environment: Windows 7 Professional
> JDK 1.8.0_45
>Reporter: Brian Ray
>Assignee: Daniel Sun
>Priority: Minor
> Fix For: 3.0.0-alpha-4
>
>
> First time submitter to this JIRA so let me know if I've specified anything
> incorrectly. I just upgraded from 2.4.4 to 2.4.6 and now declaring an enum
> constructor accepting a value as follows:
> {code:title=UsStates.groovy}
> enum UsState {
>
> ID('Idaho'),
> IL('Illinois'),
> IN('Indiana'),
>
> UsState( String value ) { this.value = value }
> private final String value
>
> String toString() { return value }
> }
> println UsState.ID //Idaho
> {code}
> throws the following compile error:
> {code}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> C:\svn_qa\jenkins_trunk\scripts\UsStates.groovy: 7: unexpected token: this @
> line 7, column 29.
> UsState( String value ) { this.value = value }
>^
> 1 error
> {code}
> No such error occurred in 2.4.4, nor does it happen in 2.4.5. Here are a few
> contrasting things that do seem to work in 2.4.6:
> {code:title=UsStatesBoring.groovy}
> enum UsState {
>
> ID,
> IL,
> IN,
> }
> println UsState.ID //ID
> {code}
> {code:title=UsStatesNoEnum.groovy}
> class UsState {
>
> UsState( String value ) { this.value = value }
> private final String value
>
> String toString() { return value }
> }
> final idaho = new UsState('Idaho')
> println idaho //Idaho
> {code}
> Though this seems higher priority than Minor, I can work around it by simply
> downgrading to 2.4.5. I wish there was a Medium priority.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-7778) CLONE - Enum constructor with value throws "unexpected token" error
[
https://issues.apache.org/jira/browse/GROOVY-7778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773520#comment-16773520
]
Daniel Sun commented on GROOVY-7778:
Yep. The issue does not exist in Groovy 3.0.0
> CLONE - Enum constructor with value throws "unexpected token" error
> ---
>
> Key: GROOVY-7778
> URL: https://issues.apache.org/jira/browse/GROOVY-7778
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.4.6
> Environment: Windows 7 Professional
> JDK 1.8.0_45
>Reporter: Brian Ray
>Priority: Minor
>
> First time submitter to this JIRA so let me know if I've specified anything
> incorrectly. I just upgraded from 2.4.4 to 2.4.6 and now declaring an enum
> constructor accepting a value as follows:
> {code:title=UsStates.groovy}
> enum UsState {
>
> ID('Idaho'),
> IL('Illinois'),
> IN('Indiana'),
>
> UsState( String value ) { this.value = value }
> private final String value
>
> String toString() { return value }
> }
> println UsState.ID //Idaho
> {code}
> throws the following compile error:
> {code}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> C:\svn_qa\jenkins_trunk\scripts\UsStates.groovy: 7: unexpected token: this @
> line 7, column 29.
> UsState( String value ) { this.value = value }
>^
> 1 error
> {code}
> No such error occurred in 2.4.4, nor does it happen in 2.4.5. Here are a few
> contrasting things that do seem to work in 2.4.6:
> {code:title=UsStatesBoring.groovy}
> enum UsState {
>
> ID,
> IL,
> IN,
> }
> println UsState.ID //ID
> {code}
> {code:title=UsStatesNoEnum.groovy}
> class UsState {
>
> UsState( String value ) { this.value = value }
> private final String value
>
> String toString() { return value }
> }
> final idaho = new UsState('Idaho')
> println idaho //Idaho
> {code}
> Though this seems higher priority than Minor, I can work around it by simply
> downgrading to 2.4.5. I wish there was a Medium priority.
--
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] [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=16773463#comment-16773463
]
Paul King commented on GROOVY-9003:
---
Overlaps with GROOVY-4653 and GROOVY-8756.
> 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] [Commented] (GROOVY-7778) CLONE - Enum constructor with value throws "unexpected token" error
[
https://issues.apache.org/jira/browse/GROOVY-7778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773456#comment-16773456
]
Paul King commented on GROOVY-7778:
---
This appears fixed in the Parrot parser.
> CLONE - Enum constructor with value throws "unexpected token" error
> ---
>
> Key: GROOVY-7778
> URL: https://issues.apache.org/jira/browse/GROOVY-7778
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.4.6
> Environment: Windows 7 Professional
> JDK 1.8.0_45
>Reporter: Brian Ray
>Priority: Minor
>
> First time submitter to this JIRA so let me know if I've specified anything
> incorrectly. I just upgraded from 2.4.4 to 2.4.6 and now declaring an enum
> constructor accepting a value as follows:
> {code:title=UsStates.groovy}
> enum UsState {
>
> ID('Idaho'),
> IL('Illinois'),
> IN('Indiana'),
>
> UsState( String value ) { this.value = value }
> private final String value
>
> String toString() { return value }
> }
> println UsState.ID //Idaho
> {code}
> throws the following compile error:
> {code}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> C:\svn_qa\jenkins_trunk\scripts\UsStates.groovy: 7: unexpected token: this @
> line 7, column 29.
> UsState( String value ) { this.value = value }
>^
> 1 error
> {code}
> No such error occurred in 2.4.4, nor does it happen in 2.4.5. Here are a few
> contrasting things that do seem to work in 2.4.6:
> {code:title=UsStatesBoring.groovy}
> enum UsState {
>
> ID,
> IL,
> IN,
> }
> println UsState.ID //ID
> {code}
> {code:title=UsStatesNoEnum.groovy}
> class UsState {
>
> UsState( String value ) { this.value = value }
> private final String value
>
> String toString() { return value }
> }
> final idaho = new UsState('Idaho')
> println idaho //Idaho
> {code}
> Though this seems higher priority than Minor, I can work around it by simply
> downgrading to 2.4.5. I wish there was a Medium priority.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-9005) SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1, column -1
[ https://issues.apache.org/jira/browse/GROOVY-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773254#comment-16773254 ] Devin Rosenbauer commented on GROOVY-9005: -- Oh, also, I wanted to add that this worked fine up through at least 2.5.3. I just came across this compilation bug today when trying to upgrade my build to 2.5.6. > SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1, > column -1 > --- > > Key: GROOVY-9005 > URL: https://issues.apache.org/jira/browse/GROOVY-9005 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.5.6 >Reporter: Devin Rosenbauer >Priority: Major > Attachments: GROOVY-9005.zip > > > I'm receiving the above error when attempting to compile certain classes that > have @CompileStatic on either the class or a method within a dynamically > compiled class. The project is a cross-compiled Java / Groovy project with > all classes of both types defined in the "groovy" structure. The error can be > reproduced when a Groovy class extends a Java class which extends a Groovy > class, then a method in the Java class is called from an inner class of the > Groovy class. > The simplest case I can derive to reproduce the failure is attached. > A is the class which fails to compile. A1 and A2 are the Java and Groovy > superclasses, respectively. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-9005) SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1, column -1
[
https://issues.apache.org/jira/browse/GROOVY-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773249#comment-16773249
]
Devin Rosenbauer commented on GROOVY-9005:
--
More information:
It appears that the anonymous inner class's method compiles fine if the type is
given as simply "def" rather than a Java type. So this (with my actual
application class) compiles:
{code:java}
commands.put("name", new Command() {
@Override
def execute() {
def someValue = getObject().toString()
return someValue
}
})
{code}
And this does not:
{code:java}
commands.put("name", new Command() {
@Override
Object execute() {
def someValue = getObject().toString()
return someValue
}
})
{code}
> SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1,
> column -1
> ---
>
> Key: GROOVY-9005
> URL: https://issues.apache.org/jira/browse/GROOVY-9005
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.5.6
>Reporter: Devin Rosenbauer
>Priority: Major
> Attachments: GROOVY-9005.zip
>
>
> I'm receiving the above error when attempting to compile certain classes that
> have @CompileStatic on either the class or a method within a dynamically
> compiled class. The project is a cross-compiled Java / Groovy project with
> all classes of both types defined in the "groovy" structure. The error can be
> reproduced when a Groovy class extends a Java class which extends a Groovy
> class, then a method in the Java class is called from an inner class of the
> Groovy class.
> The simplest case I can derive to reproduce the failure is attached.
> A is the class which fails to compile. A1 and A2 are the Java and Groovy
> superclasses, respectively.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-9005) SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1, column -1
[
https://issues.apache.org/jira/browse/GROOVY-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773241#comment-16773241
]
Eric Milles edited comment on GROOVY-9005 at 2/20/19 6:00 PM:
--
Sure, I would like to see the bug fixed as well. Just trying to hone in on
where exactly the bug lies.
You could isolate the anonymous inner creation to a method. That could be
tagged @CompileDynamic if needed.
{code:groovy}
@CompileStatic
class A extends A1 {
Map getInnerObject() {
Map commands = getBaseMap()
commands.put("name", newCallable())
return commands
}
// could be @CompileDynamic if needed
private Callable newCallable() {
new Callable() {
@Override
String call() {
getObject().toString() // can be qualified with "A.this." if needed,
which may eliminate the error
}
}
}
}
{code}
was (Author: emilles):
Sure, I would like to see the bug fixed as well. Just trying to hone in on
where exactly the bug lies.
You could isolate the anonymous inner creation to a method. That could be
tagged @CompileDynamic if needed.
{code:groovy}
@CompileStatic
class A extends A1 {
Map getInnerObject() {
Map commands = getBaseMap()
commands.put("name", newCallable())
return commands
}
// could be @CompileDynamic if needed
Callable newCallable() {
new Callable() {
@Override
String call() {
getObject().toString() // can be qualified with "A.this." if needed,
which may eliminate the error
}
}
}
}
{code}
> SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1,
> column -1
> ---
>
> Key: GROOVY-9005
> URL: https://issues.apache.org/jira/browse/GROOVY-9005
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.5.6
>Reporter: Devin Rosenbauer
>Priority: Major
> Attachments: GROOVY-9005.zip
>
>
> I'm receiving the above error when attempting to compile certain classes that
> have @CompileStatic on either the class or a method within a dynamically
> compiled class. The project is a cross-compiled Java / Groovy project with
> all classes of both types defined in the "groovy" structure. The error can be
> reproduced when a Groovy class extends a Java class which extends a Groovy
> class, then a method in the Java class is called from an inner class of the
> Groovy class.
> The simplest case I can derive to reproduce the failure is attached.
> A is the class which fails to compile. A1 and A2 are the Java and Groovy
> superclasses, respectively.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-9005) SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1, column -1
[
https://issues.apache.org/jira/browse/GROOVY-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773241#comment-16773241
]
Eric Milles edited comment on GROOVY-9005 at 2/20/19 5:59 PM:
--
Sure, I would like to see the bug fixed as well. Just trying to hone in on
where exactly the bug lies.
You could isolate the anonymous inner creation to a method. That could be
tagged @CompileDynamic if needed.
{code:groovy}
@CompileStatic
class A extends A1 {
Map getInnerObject() {
Map commands = getBaseMap()
commands.put("name", newCallable())
return commands
}
// could be @CompileDynamic if needed
Callable newCallable() {
new Callable() {
@Override
String call() {
getObject().toString() // can be qualified with "A.this." if needed,
which may eliminate the error
}
}
}
}
{code}
was (Author: emilles):
Sure, I would like to see the bug fixed as well. Just trying to hone in on
where exactly the bug lies.
You could isolate the anonymous inner creation to a method. That could be
tagged @CompileDynamic if needed.
{code:groovy}
@CompileStatic
class A extends A1 {
Map getInnerObject() {
Map commands = getBaseMap()
commands.put("name", newCallable())
return commands
}
// could be @CompileDynamic if needed
Callable newCallable() {
new Callable() {
@Override
String call() {
getObject().toString() // can be qualified with "A.this." if needed;
this may eliminate the error
}
}
}
}
{code}
> SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1,
> column -1
> ---
>
> Key: GROOVY-9005
> URL: https://issues.apache.org/jira/browse/GROOVY-9005
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.5.6
>Reporter: Devin Rosenbauer
>Priority: Major
> Attachments: GROOVY-9005.zip
>
>
> I'm receiving the above error when attempting to compile certain classes that
> have @CompileStatic on either the class or a method within a dynamically
> compiled class. The project is a cross-compiled Java / Groovy project with
> all classes of both types defined in the "groovy" structure. The error can be
> reproduced when a Groovy class extends a Java class which extends a Groovy
> class, then a method in the Java class is called from an inner class of the
> Groovy class.
> The simplest case I can derive to reproduce the failure is attached.
> A is the class which fails to compile. A1 and A2 are the Java and Groovy
> superclasses, respectively.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-9005) SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1, column -1
[
https://issues.apache.org/jira/browse/GROOVY-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773241#comment-16773241
]
Eric Milles edited comment on GROOVY-9005 at 2/20/19 5:57 PM:
--
Sure, I would like to see the bug fixed as well. Just trying to hone in on
where exactly the bug lies.
You could isolate the anonymous inner creation to a method. That could be
tagged @CompileDynamic if needed.
{code:groovy}
@CompileStatic
class A extends A1 {
Map getInnerObject() {
Map commands = getBaseMap()
commands.put("name", newCallable())
return commands
}
// could be @CompileDynamic if needed
Callable newCallable() {
new Callable() {
@Override
String call() {
getObject().toString() // can be qualified with "A.this." if needed;
this may eliminate the error
}
}
}
}
{code}
was (Author: emilles):
Sure, I would like to see the bug fixed as well. Just trying to hone in on
where exactly the bug lies.
You could isolate the anonymous inner creation to a method. That could be
tagged @CompileDynamic if needed.
{code:groovy}
@CompileStatic
class A extends A1 {
Map getInnerObject() {
Map commands = getBaseMap()
commands.put("name", newCallable())
return commands
}
// could be @CompileDynamic if needed
Callable newCallable() {
new Callable() {
@Override
String call() {
def someValue = getObject().toString()
return someValue
}
}
}
}
{code}
> SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1,
> column -1
> ---
>
> Key: GROOVY-9005
> URL: https://issues.apache.org/jira/browse/GROOVY-9005
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.5.6
>Reporter: Devin Rosenbauer
>Priority: Major
> Attachments: GROOVY-9005.zip
>
>
> I'm receiving the above error when attempting to compile certain classes that
> have @CompileStatic on either the class or a method within a dynamically
> compiled class. The project is a cross-compiled Java / Groovy project with
> all classes of both types defined in the "groovy" structure. The error can be
> reproduced when a Groovy class extends a Java class which extends a Groovy
> class, then a method in the Java class is called from an inner class of the
> Groovy class.
> The simplest case I can derive to reproduce the failure is attached.
> A is the class which fails to compile. A1 and A2 are the Java and Groovy
> superclasses, respectively.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-9005) SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1, column -1
[ https://issues.apache.org/jira/browse/GROOVY-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773243#comment-16773243 ] Devin Rosenbauer commented on GROOVY-9005: -- I confirmed that your first syntax compiles fine with the SAM closure structure. > SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1, > column -1 > --- > > Key: GROOVY-9005 > URL: https://issues.apache.org/jira/browse/GROOVY-9005 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.5.6 >Reporter: Devin Rosenbauer >Priority: Major > Attachments: GROOVY-9005.zip > > > I'm receiving the above error when attempting to compile certain classes that > have @CompileStatic on either the class or a method within a dynamically > compiled class. The project is a cross-compiled Java / Groovy project with > all classes of both types defined in the "groovy" structure. The error can be > reproduced when a Groovy class extends a Java class which extends a Groovy > class, then a method in the Java class is called from an inner class of the > Groovy class. > The simplest case I can derive to reproduce the failure is attached. > A is the class which fails to compile. A1 and A2 are the Java and Groovy > superclasses, respectively. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-9005) SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1, column -1
[
https://issues.apache.org/jira/browse/GROOVY-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773241#comment-16773241
]
Eric Milles commented on GROOVY-9005:
-
Sure, I would like to see the bug fixed as well. Just trying to hone in on
where exactly the bug lies.
You could isolate the anonymous inner creation to a method. That could be
tagged @CompileDynamic if needed.
{code:groovy}
@CompileStatic
class A extends A1 {
Map getInnerObject() {
Map commands = getBaseMap()
commands.put("name", newCallable())
return commands
}
// could be @CompileDynamic if needed
Callable newCallable() {
new Callable() {
@Override
String call() {
def someValue = getObject().toString()
return someValue
}
}
}
}
{code}
> SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1,
> column -1
> ---
>
> Key: GROOVY-9005
> URL: https://issues.apache.org/jira/browse/GROOVY-9005
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.5.6
>Reporter: Devin Rosenbauer
>Priority: Major
> Attachments: GROOVY-9005.zip
>
>
> I'm receiving the above error when attempting to compile certain classes that
> have @CompileStatic on either the class or a method within a dynamically
> compiled class. The project is a cross-compiled Java / Groovy project with
> all classes of both types defined in the "groovy" structure. The error can be
> reproduced when a Groovy class extends a Java class which extends a Groovy
> class, then a method in the Java class is called from an inner class of the
> Groovy class.
> The simplest case I can derive to reproduce the failure is attached.
> A is the class which fails to compile. A1 and A2 are the Java and Groovy
> superclasses, respectively.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-9005) SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1, column -1
[
https://issues.apache.org/jira/browse/GROOVY-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773221#comment-16773221
]
Eric Milles edited comment on GROOVY-9005 at 2/20/19 5:50 PM:
--
Since you are using Groovy 2.5 (per the issue metadata), here is another way to
write this out:
{code:groovy}
@CompileStatic
class A extends A1 {
Map getInnerObject() {
baseMap.tap {
put('name', { ->
owner.owner.object.toString() // since "owner" here delegates to a
Map, I added a qualifier that would not be required if object expression of
"tap" call was some other type
} as Callable)
}
}
}
{code}
was (Author: emilles):
Since you are using Groovy 2.5 (per the issue metadata), here is another way to
write this out:
{code:groovy}
@CompileStatic
class A extends A1 {
Map getInnerObject() {
baseMap.tap {
put('name', { ->
object.toString()
} as Callable)
}
}
}
{code}
> SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1,
> column -1
> ---
>
> Key: GROOVY-9005
> URL: https://issues.apache.org/jira/browse/GROOVY-9005
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.5.6
>Reporter: Devin Rosenbauer
>Priority: Major
> Attachments: GROOVY-9005.zip
>
>
> I'm receiving the above error when attempting to compile certain classes that
> have @CompileStatic on either the class or a method within a dynamically
> compiled class. The project is a cross-compiled Java / Groovy project with
> all classes of both types defined in the "groovy" structure. The error can be
> reproduced when a Groovy class extends a Java class which extends a Groovy
> class, then a method in the Java class is called from an inner class of the
> Groovy class.
> The simplest case I can derive to reproduce the failure is attached.
> A is the class which fails to compile. A1 and A2 are the Java and Groovy
> superclasses, respectively.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-9005) SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1, column -1
[ https://issues.apache.org/jira/browse/GROOVY-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773236#comment-16773236 ] Devin Rosenbauer commented on GROOVY-9005: -- I will give it a try. Unfortunately, my actual inner class isn't a Callable, but rather an application-specific Command class with more than one method that can be overridden. I could potentially figure out a way to use the "single abstract method" syntax, but I'd rather it work correctly! I was able to work around the issue for now by converting the immediate superclass to Groovy and/or not using CompileStatic in certain areas. The application has a mixed set of classes because I converted it from a Java project to a Groovy project partway through development. What's Java and what's Groovy mainly depends on age. > SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1, > column -1 > --- > > Key: GROOVY-9005 > URL: https://issues.apache.org/jira/browse/GROOVY-9005 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.5.6 >Reporter: Devin Rosenbauer >Priority: Major > Attachments: GROOVY-9005.zip > > > I'm receiving the above error when attempting to compile certain classes that > have @CompileStatic on either the class or a method within a dynamically > compiled class. The project is a cross-compiled Java / Groovy project with > all classes of both types defined in the "groovy" structure. The error can be > reproduced when a Groovy class extends a Java class which extends a Groovy > class, then a method in the Java class is called from an inner class of the > Groovy class. > The simplest case I can derive to reproduce the failure is attached. > A is the class which fails to compile. A1 and A2 are the Java and Groovy > superclasses, respectively. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GROOVY-9006) Static type checking fails on java.sql.Timestamp when compared to null
Devin Rosenbauer created GROOVY-9006:
Summary: Static type checking fails on java.sql.Timestamp when
compared to null
Key: GROOVY-9006
URL: https://issues.apache.org/jira/browse/GROOVY-9006
Project: Groovy
Issue Type: Bug
Components: Static Type Checker
Affects Versions: 2.5.6
Reporter: Devin Rosenbauer
The following class fails when compiled by Groovy 2.5.6 (via Gradle). The error
is:
{noformat}
src/main/groovy/Bug.groovy: 11: [Static type checking] - Reference to method is
ambiguous. Cannot choose between [boolean
java.sql.Timestamp#equals(java.sql.Timestamp), boolean
java.sql.Timestamp#equals(java.lang.Object)]
@ line 11, column 13.
if (timestamp != null) {
^
{noformat}
Class code for {{Bug.groovy}} -
{code:java}
import groovy.transform.TypeChecked
import java.sql.Timestamp
@TypeChecked
class Bug {
public void bug() {
java.sql.Timestamp timestamp = new Timestamp(new Date().getTime());
if (timestamp != null) {
}
}
}
{code}
Expected behavior: Groovy compiles "x != null" without reference to Java's
{{equals}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-9005) SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1, column -1
[
https://issues.apache.org/jira/browse/GROOVY-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773221#comment-16773221
]
Eric Milles commented on GROOVY-9005:
-
Since you are using Groovy 2.5 (per the issue metadata), here is another way to
write this out:
{code:groovy}
@CompileStatic
class A extends A1 {
Map getInnerObject() {
baseMap.tap {
put('name', { ->
object.toString()
} as Callable)
}
}
}
{code}
> SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1,
> column -1
> ---
>
> Key: GROOVY-9005
> URL: https://issues.apache.org/jira/browse/GROOVY-9005
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.5.6
>Reporter: Devin Rosenbauer
>Priority: Major
> Attachments: GROOVY-9005.zip
>
>
> I'm receiving the above error when attempting to compile certain classes that
> have @CompileStatic on either the class or a method within a dynamically
> compiled class. The project is a cross-compiled Java / Groovy project with
> all classes of both types defined in the "groovy" structure. The error can be
> reproduced when a Groovy class extends a Java class which extends a Groovy
> class, then a method in the Java class is called from an inner class of the
> Groovy class.
> The simplest case I can derive to reproduce the failure is attached.
> A is the class which fails to compile. A1 and A2 are the Java and Groovy
> superclasses, respectively.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-9005) SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1, column -1
[
https://issues.apache.org/jira/browse/GROOVY-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773217#comment-16773217
]
Eric Milles commented on GROOVY-9005:
-
I suspected that an anonymous inner class was going to show up in your example.
I had a similar issue (GROOVY-8433) where an anonymous inner, which contains
an implicit parameter "this" is transformed to something that fails to compile.
Could you try your example this way just to see if the alternative syntax using
a closure literal works?
{code:groovy}
@CompileStatic
class A extends A1 {
Map getInnerObject() {
Map commands = getBaseMap()
commands.put('name', { ->
getObject().toString() // otherwise the "this" that gets transformed
is the implicit object expression of this line
} as Callable)
return commands
}
}
{code}
> SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1,
> column -1
> ---
>
> Key: GROOVY-9005
> URL: https://issues.apache.org/jira/browse/GROOVY-9005
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.5.6
>Reporter: Devin Rosenbauer
>Priority: Major
> Attachments: GROOVY-9005.zip
>
>
> I'm receiving the above error when attempting to compile certain classes that
> have @CompileStatic on either the class or a method within a dynamically
> compiled class. The project is a cross-compiled Java / Groovy project with
> all classes of both types defined in the "groovy" structure. The error can be
> reproduced when a Groovy class extends a Java class which extends a Groovy
> class, then a method in the Java class is called from an inner class of the
> Groovy class.
> The simplest case I can derive to reproduce the failure is attached.
> A is the class which fails to compile. A1 and A2 are the Java and Groovy
> superclasses, respectively.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-9005) SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1, column -1
[ https://issues.apache.org/jira/browse/GROOVY-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Devin Rosenbauer updated GROOVY-9005: - Description: I'm receiving the above error when attempting to compile certain classes that have @CompileStatic on either the class or a method within a dynamically compiled class. The project is a cross-compiled Java / Groovy project with all classes of both types defined in the "groovy" structure. The simplest case I can derive to reproduce the failure is attached. was:I'm receiving the above error when attempting to compile certain classes that have @CompileStatic on either the class or a method within a dynamically compiled class. Oddly, it doesn't seem to affect every compile static class I've got, so I'm still trying to narrow down the simplest case. I will return and update with a code sample when I find one. > SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1, > column -1 > --- > > Key: GROOVY-9005 > URL: https://issues.apache.org/jira/browse/GROOVY-9005 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.5.6 >Reporter: Devin Rosenbauer >Priority: Major > Attachments: GROOVY-9005.zip > > > I'm receiving the above error when attempting to compile certain classes that > have @CompileStatic on either the class or a method within a dynamically > compiled class. The project is a cross-compiled Java / Groovy project with > all classes of both types defined in the "groovy" structure. > The simplest case I can derive to reproduce the failure is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GROOVY-9005) SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1, column -1
[ https://issues.apache.org/jira/browse/GROOVY-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Devin Rosenbauer updated GROOVY-9005: - Description: I'm receiving the above error when attempting to compile certain classes that have @CompileStatic on either the class or a method within a dynamically compiled class. The project is a cross-compiled Java / Groovy project with all classes of both types defined in the "groovy" structure. The error can be reproduced when a Groovy class extends a Java class which extends a Groovy class, then a method in the Java class is called from an inner class of the Groovy class. The simplest case I can derive to reproduce the failure is attached. A is the class which fails to compile. A1 and A2 are the Java and Groovy superclasses, respectively. was: I'm receiving the above error when attempting to compile certain classes that have @CompileStatic on either the class or a method within a dynamically compiled class. The project is a cross-compiled Java / Groovy project with all classes of both types defined in the "groovy" structure. The simplest case I can derive to reproduce the failure is attached. > SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1, > column -1 > --- > > Key: GROOVY-9005 > URL: https://issues.apache.org/jira/browse/GROOVY-9005 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.5.6 >Reporter: Devin Rosenbauer >Priority: Major > Attachments: GROOVY-9005.zip > > > I'm receiving the above error when attempting to compile certain classes that > have @CompileStatic on either the class or a method within a dynamically > compiled class. The project is a cross-compiled Java / Groovy project with > all classes of both types defined in the "groovy" structure. The error can be > reproduced when a Groovy class extends a Java class which extends a Groovy > class, then a method in the Java class is called from an inner class of the > Groovy class. > The simplest case I can derive to reproduce the failure is attached. > A is the class which fails to compile. A1 and A2 are the Java and Groovy > superclasses, respectively. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GROOVY-9005) SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1, column -1
[ https://issues.apache.org/jira/browse/GROOVY-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Devin Rosenbauer updated GROOVY-9005: - Attachment: GROOVY-9005.zip > SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1, > column -1 > --- > > Key: GROOVY-9005 > URL: https://issues.apache.org/jira/browse/GROOVY-9005 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.5.6 >Reporter: Devin Rosenbauer >Priority: Major > Attachments: GROOVY-9005.zip > > > I'm receiving the above error when attempting to compile certain classes that > have @CompileStatic on either the class or a method within a dynamically > compiled class. The project is a cross-compiled Java / Groovy project with > all classes of both types defined in the "groovy" structure. > The simplest case I can derive to reproduce the failure is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GROOVY-9005) SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1, column -1
Devin Rosenbauer created GROOVY-9005: Summary: SomeClass.groovy: -1: Access to java.lang.Object#this is forbidden @ line -1, column -1 Key: GROOVY-9005 URL: https://issues.apache.org/jira/browse/GROOVY-9005 Project: Groovy Issue Type: Bug Components: Static compilation Affects Versions: 2.5.6 Reporter: Devin Rosenbauer I'm receiving the above error when attempting to compile certain classes that have @CompileStatic on either the class or a method within a dynamically compiled class. Oddly, it doesn't seem to affect every compile static class I've got, so I'm still trying to narrow down the simplest case. I will return and update with a code sample when I find one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8250) VariableScopeVisitor does not set declaring class on property nodes
[
https://issues.apache.org/jira/browse/GROOVY-8250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773175#comment-16773175
]
Eric Milles commented on GROOVY-8250:
-
I believe this got included in a recent release. Could the appropriate release
notes be updated and this ticket be closed?
> VariableScopeVisitor does not set declaring class on property nodes
> ---
>
> Key: GROOVY-8250
> URL: https://issues.apache.org/jira/browse/GROOVY-8250
> Project: Groovy
> Issue Type: Bug
>Reporter: Eric Milles
>Priority: Major
>
> VariableScopeVisitor.findClassMember creates PropertyNode instances for
> methods (ex: foo.bar will have a property node created if getBar() is
> implemented). This is done inside the MethodNode for loop circa line 165.
> The nodes created by this visitor lack a declaring class setting as well as
> having an improper type. Without these values, type inferencing is more
> difficult for anyone that processes the AST. These are reasonable simple to
> remedy:
> {code}
> private Variable findClassMember(ClassNode cn, String name) {
> if (cn == null) return null;
> if (cn.isScript()) {
> return new DynamicVariable(name, false);
> }
> for (FieldNode fn : cn.getFields()) {
> if (fn.getName().equals(name)) return fn;
> }
> for (MethodNode mn : cn.getMethods()) {
> String pName = getPropertyName(mn);
> // GRECLIPSE edit
> //if (pName != null && pName.equals(name))
> //return new PropertyNode(pName, mn.getModifiers(),
> ClassHelper.OBJECT_TYPE, cn, null, null, null);
> if (pName != null && pName.equals(name)) {
> PropertyNode property = new PropertyNode(pName,
> mn.getModifiers(), getPropertyType(mn), cn, null, null, null);
> property.getField().setDeclaringClass(cn);
> property.setDeclaringClass(cn);
> return property;
> }
> // GRECLIPSE end
> }
> ...
> // GRECLIPSE add
> private ClassNode getPropertyType(MethodNode m) {
> if (m.getReturnType() != ClassHelper.VOID_TYPE) {
> return m.getReturnType();
> }
> return m.getParameters()[0].getType();
> }
> // GRECLIPSE end
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8444) Support unqualified enum constants in switch cases (like Java)
[
https://issues.apache.org/jira/browse/GROOVY-8444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-8444:
Description:
Would it be possible to support this syntax that Java requires for enum
constants in switch statements?
{code:java}
enum SomeEnum { A, B }
void meth(SomeEnum e) {
switch (e) {
case A: // currently this must be qualified, like SomeEnum.A
...
break
case B:
...
break
}
}
meth(someEnumValue) // currently throws MissingPropertyException: No such
property: A for class...
{code}
was:
Would it be possible to support this syntax that Java requires for enum
constants in switch statements?
{code}
enum SomeEnum { A, B }
void meth(SomeEnum e) {
switch (e) {
case A: // currently this must be qualified, like SomeEnum.A
...
break
case B:
...
break
}
}
meth(SomeEnum.A) // currently throws MissingPropertyException: No such
property: A for class...
{code}
> Support unqualified enum constants in switch cases (like Java)
> --
>
> Key: GROOVY-8444
> URL: https://issues.apache.org/jira/browse/GROOVY-8444
> Project: Groovy
> Issue Type: Improvement
>Reporter: Eric Milles
>Priority: Minor
>
> Would it be possible to support this syntax that Java requires for enum
> constants in switch statements?
> {code:java}
> enum SomeEnum { A, B }
> void meth(SomeEnum e) {
> switch (e) {
> case A: // currently this must be qualified, like SomeEnum.A
> ...
> break
> case B:
> ...
> break
> }
> }
> meth(someEnumValue) // currently throws MissingPropertyException: No such
> property: A for class...
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8702) Update public Groovy Web Console to Groovy 2.5.6
[ https://issues.apache.org/jira/browse/GROOVY-8702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Milles updated GROOVY-8702: Summary: Update public Groovy Web Console to Groovy 2.5.6 (was: Update public Groovy Web Console to Groovy 2.5.1) > Update public Groovy Web Console to Groovy 2.5.6 > > > Key: GROOVY-8702 > URL: https://issues.apache.org/jira/browse/GROOVY-8702 > Project: Groovy > Issue Type: Improvement > Components: Groovy Console >Reporter: Eric Milles >Priority: Major > > The public Groovy Web Console (https://groovyconsole.appspot.com/) is > currently deployed with Groovy 2.4.4. Please update to current release > (Groovy 2.5.1 at this time). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GROOVY-8702) Update public Groovy Web Console to Groovy 2.5.6
[ https://issues.apache.org/jira/browse/GROOVY-8702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Milles updated GROOVY-8702: Description: The public Groovy Web Console ([https://groovyconsole.appspot.com/]) is currently deployed with Groovy 2.4.4. Please update to current release (Groovy 2.5.6 at this time). (was: The public Groovy Web Console (https://groovyconsole.appspot.com/) is currently deployed with Groovy 2.4.4. Please update to current release (Groovy 2.5.1 at this time).) > Update public Groovy Web Console to Groovy 2.5.6 > > > Key: GROOVY-8702 > URL: https://issues.apache.org/jira/browse/GROOVY-8702 > Project: Groovy > Issue Type: Improvement > Components: Groovy Console >Reporter: Eric Milles >Priority: Major > > The public Groovy Web Console ([https://groovyconsole.appspot.com/]) is > currently deployed with Groovy 2.4.4. Please update to current release > (Groovy 2.5.6 at this time). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GROOVY-9004) Parser fails to recognize token sequence expression newline bitwise-operator expression
[
https://issues.apache.org/jira/browse/GROOVY-9004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-9004:
Description:
Consider the following:
{code}
1
| 2
// or
true
| false
// or
[]
| whatever
{code}
Each of these expression statements are generating an unexpected token
exception at "|". This is significant because this type of expression sequence
is often used to build Spock data tables. If user adds newline by accident or
formatter does so automatically, the table is no longer recognized and
compilation fails.
This came to me by way of: [https://github.com/groovy/groovy-eclipse/issues/822]
Possibly related: GROOVY-8810
was:
Consider the following:
{code:groovy}
1
| 2
// or
true
| false
// or
[]
| whatever
{code}
Each of these expression statements are generating an unexpected token
exception at "|". This is significant because this type of expression sequence
is often used to build Spock data tables. If user adds newline by accident or
formatter does automatically, the table is no longer recognized and compilation
fails.
This cam to me by way of: https://github.com/groovy/groovy-eclipse/issues/822
Possibly related: GROOVY-8810
> Parser fails to recognize token sequence expression newline bitwise-operator
> expression
> ---
>
> Key: GROOVY-9004
> URL: https://issues.apache.org/jira/browse/GROOVY-9004
> Project: Groovy
> Issue Type: Bug
> Components: parser
>Affects Versions: 2.4.16
>Reporter: Eric Milles
>Priority: Major
>
> Consider the following:
> {code}
> 1
> | 2
> // or
> true
> | false
> // or
> []
> | whatever
> {code}
> Each of these expression statements are generating an unexpected token
> exception at "|". This is significant because this type of expression
> sequence is often used to build Spock data tables. If user adds newline by
> accident or formatter does so automatically, the table is no longer
> recognized and compilation fails.
> This came to me by way of:
> [https://github.com/groovy/groovy-eclipse/issues/822]
> Possibly related: GROOVY-8810
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-9002) groovy-all-2.5.4-indy.jar not available in mavenCentral or jcenter
[
https://issues.apache.org/jira/browse/GROOVY-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773137#comment-16773137
]
Eric Milles commented on GROOVY-9002:
-
One limitation of the POM-based approach is how "indy" is handled.
{{groovy-all-x.y.z-pom}} is nearly equivalent to {{groovy-all-2.4.n.jar}}.
However there is not a nice substitute for {{groovy-all-2.4.n-indy.jar}} that I
am aware of.
That is, this is not available:
{code:xml}
org.codehaus.groovy
groovy-all
x.y.z
indy
pom
{code}
> groovy-all-2.5.4-indy.jar not available in mavenCentral or jcenter
> --
>
> Key: GROOVY-9002
> URL: https://issues.apache.org/jira/browse/GROOVY-9002
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.5.4
> Environment: Groovy / Gradle 5
>Reporter: will mason
>Priority: Critical
> Labels: groovy-all, indy, invokedynamic
>
> Our Gradle build automatically looks for the Groovy version that matches the
> installed Gradel version. This is done because sometimes having an
> incompatible Groovy version with the build causes exceptions in the build.
> Therefore it is impretive for the matching Groovy artefact be available in
> the central repositories.
> {noformat}
> FAILURE: Build failed with an exception.
> * What went wrong:
> Could not resolve all files for configuration
> ':TestingSupport:compileClasspath'.
> > Could not find groovy-all-indy.jar (org.codehaus.groovy:groovy-all:2.5.4).
> {noformat}
> I've looked in both {{mavenCentral}} and {{jcenter}} and the {{groovy-all}}
> indy file is not present.
> The [Invoke dynamic support|http://groovy-lang.org/indy.html] documentation
> page reports that there are two versions of the Groovy all .JAR used.
> The absence of this JAR breaks our build.
> If Groovy is no longer supporting the {{-indy}} version of the JAR-s this
> should be noted in the documentation. I could find nothing about Invoke
> Dynamic in the [Groovy 2.5 release
> notes|http://groovy-lang.org/releasenotes/groovy-2.5.html#releasenotes].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-9004) Parser fails to recognize token sequence expression newline bitwise-operator expression
Eric Milles created GROOVY-9004:
---
Summary: Parser fails to recognize token sequence expression
newline bitwise-operator expression
Key: GROOVY-9004
URL: https://issues.apache.org/jira/browse/GROOVY-9004
Project: Groovy
Issue Type: Bug
Components: parser
Affects Versions: 2.4.16
Reporter: Eric Milles
Consider the following:
{code:groovy}
1
| 2
// or
true
| false
// or
[]
| whatever
{code}
Each of these expression statements are generating an unexpected token
exception at "|". This is significant because this type of expression sequence
is often used to build Spock data tables. If user adds newline by accident or
formatter does automatically, the table is no longer recognized and compilation
fails.
This cam to me by way of: https://github.com/groovy/groovy-eclipse/issues/822
Possibly related: GROOVY-8810
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8998) [GEP]Concatenative Method Calls
[
https://issues.apache.org/jira/browse/GROOVY-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-8998:
---
Description:
h1. *DRAFT*
{code:java}
// lots of temp variable declarations and assignments
def ar = a()
def br = b(3, ar)
def r = c(br, 2)
// inline version of the above code, i.e. nested method calls
def r =
c(
b(
3,
a()
),
2
)
{code}
{code:java}
// leverage the power of DGM `with` to transform nested method calls to method
call chain
def r =
a().with {
b(3, it)
}. with {
c(it, 2)
}
{code}
{code:java}
// Introduce a new syntax to transform the above method call chain to
concatenative method calls
// `_` represents the result of previous part
// `|>` is like a big arrow representing the direction of data flow
// if the target is a variable, `|>` means assignment/declaration
a() |> b(3, _) |> c(_, 2) |> (def r)
{code}
h2. More examples
{code:java}
// `|>` has just a bit higher precedence than assignments, e.g. `=`, `+=`,
`*=`, etc.
6 / a() |> b(3, _) + 9 |> c(_, 2) * 5 |> (def r)
// the above code is equal to
def r =
c(
b(
3,
6 / a()
) + 9,
2
) * 5
{code}
{code:java}
// `|>` has just a bit higher precedence than assignments, e.g. `=`, `+=`,
`*=`, etc.
a(1), 6 / a(2) |> b(_, 3, _) |> (def r)
// the above code is equal to
def r =
b(
a(1)
3,
6 / a(2)
)
{code}
h2. discussion in the dev mailing list
[http://groovy.329449.n5.nabble.com/GEP-Concatenative-Method-Calls-tt5747708.html]
was:
h1. *DRAFT*
{code:java}
// lots of temp variable declarations and assignments
def ar = a()
def br = b(3, ar)
def r = c(br, 2)
// inline version of the above code, i.e. nested method calls
def r =
c(
b(
3,
a()
),
2
)
{code}
{code:java}
// leverage the power of DGM `with` to transform nested method calls to method
call chain
def r =
a().with {
b(3, it)
}. with {
c(it, 2)
}
{code}
{code:java}
// Introduce a new syntax to transform the above method call chain to
concatenative method calls
// `_` represents the result of previous part
// `|>` is like a big arrow representing the direction of data flow
// if the target is a variable, `|>` means assignment/declaration
a() |> b(3, _) |> c(_, 2) |> (def r)
{code}
h2. More examples
{code:java}
// `|>` has just a bit higher precedence than assignments, e.g. `=`, `+=`,
`*=`, etc.
6 / a() |> b(3, _) + 9 |> c(_, 2) * 5 |> (def r)
// the above code is equal to
def r =
c(
b(
3,
6 / a()
) + 9,
2
) * 5
{code}
h2. discussion in the dev mailing list
[http://groovy.329449.n5.nabble.com/GEP-Concatenative-Method-Calls-tt5747708.html]
> [GEP]Concatenative Method Calls
> ---
>
> Key: GROOVY-8998
> URL: https://issues.apache.org/jira/browse/GROOVY-8998
> Project: Groovy
> Issue Type: New Feature
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
>
> h1. *DRAFT*
> {code:java}
> // lots of temp variable declarations and assignments
> def ar = a()
> def br = b(3, ar)
> def r = c(br, 2)
> // inline version of the above code, i.e. nested method calls
> def r =
> c(
> b(
> 3,
> a()
> ),
> 2
> )
> {code}
> {code:java}
> // leverage the power of DGM `with` to transform nested method calls to
> method call chain
> def r =
> a().with {
> b(3, it)
> }. with {
> c(it, 2)
> }
> {code}
> {code:java}
> // Introduce a new syntax to transform the above method call chain to
> concatenative method calls
> // `_` represents the result of previous part
> // `|>` is like a big arrow representing the direction of data flow
> // if the target is a variable, `|>` means assignment/declaration
> a() |> b(3, _) |> c(_, 2) |> (def r)
> {code}
> h2. More examples
> {code:java}
> // `|>` has just a bit higher precedence than assignments, e.g. `=`, `+=`,
> `*=`, etc.
> 6 / a() |> b(3, _) + 9 |> c(_, 2) * 5 |> (def r)
> // the above code is equal to
> def r =
> c(
> b(
> 3,
> 6 / a()
> ) + 9,
> 2
> ) * 5
> {code}
> {code:java}
> // `|>` has just a bit higher precedence than assignments, e.g. `=`, `+=`,
> `*=`, etc.
>
[jira] [Updated] (GROOVY-8998) [GEP]Concatenative Method Calls
[
https://issues.apache.org/jira/browse/GROOVY-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-8998:
---
Description:
h1. *DRAFT*
{code:java}
// lots of temp variable declarations and assignments
def ar = a()
def br = b(3, ar)
def r = c(br, 2)
// inline version of the above code, i.e. nested method calls
def r =
c(
b(
3,
a()
),
2
)
{code}
{code:java}
// leverage the power of DGM `with` to transform nested method calls to method
call chain
def r =
a().with {
b(3, it)
}. with {
c(it, 2)
}
{code}
{code:java}
// Introduce a new syntax to transform the above method call chain to
concatenative method calls
// `_` represents the result of previous part
// `|>` is like a big arrow representing the direction of data flow
// if the target is a variable, `|>` means assignment/declaration
a() |> b(3, _) |> c(_, 2) |> (def r)
{code}
h2. More examples
{code:java}
// `|>` has just a bit higher precedence than assignments, e.g. `=`, `+=`,
`*=`, etc.
6 / a() |> b(3, _) + 9 |> c(_, 2) * 5 |> (def r)
// the above code is equal to
def r =
c(
b(
3,
6 / a()
) + 9,
2
) * 5
{code}
{code:java}
// passing multiple parameters
a(1), 6 / a(2) |> b(_, 3, _) |> (def r)
// the above code is equal to
def r =
b(
a(1)
3,
6 / a(2)
)
{code}
h2. discussion in the dev mailing list
[http://groovy.329449.n5.nabble.com/GEP-Concatenative-Method-Calls-tt5747708.html]
was:
h1. *DRAFT*
{code:java}
// lots of temp variable declarations and assignments
def ar = a()
def br = b(3, ar)
def r = c(br, 2)
// inline version of the above code, i.e. nested method calls
def r =
c(
b(
3,
a()
),
2
)
{code}
{code:java}
// leverage the power of DGM `with` to transform nested method calls to method
call chain
def r =
a().with {
b(3, it)
}. with {
c(it, 2)
}
{code}
{code:java}
// Introduce a new syntax to transform the above method call chain to
concatenative method calls
// `_` represents the result of previous part
// `|>` is like a big arrow representing the direction of data flow
// if the target is a variable, `|>` means assignment/declaration
a() |> b(3, _) |> c(_, 2) |> (def r)
{code}
h2. More examples
{code:java}
// `|>` has just a bit higher precedence than assignments, e.g. `=`, `+=`,
`*=`, etc.
6 / a() |> b(3, _) + 9 |> c(_, 2) * 5 |> (def r)
// the above code is equal to
def r =
c(
b(
3,
6 / a()
) + 9,
2
) * 5
{code}
{code:java}
// `|>` has just a bit higher precedence than assignments, e.g. `=`, `+=`,
`*=`, etc.
a(1), 6 / a(2) |> b(_, 3, _) |> (def r)
// the above code is equal to
def r =
b(
a(1)
3,
6 / a(2)
)
{code}
h2. discussion in the dev mailing list
[http://groovy.329449.n5.nabble.com/GEP-Concatenative-Method-Calls-tt5747708.html]
> [GEP]Concatenative Method Calls
> ---
>
> Key: GROOVY-8998
> URL: https://issues.apache.org/jira/browse/GROOVY-8998
> Project: Groovy
> Issue Type: New Feature
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
>
> h1. *DRAFT*
> {code:java}
> // lots of temp variable declarations and assignments
> def ar = a()
> def br = b(3, ar)
> def r = c(br, 2)
> // inline version of the above code, i.e. nested method calls
> def r =
> c(
> b(
> 3,
> a()
> ),
> 2
> )
> {code}
> {code:java}
> // leverage the power of DGM `with` to transform nested method calls to
> method call chain
> def r =
> a().with {
> b(3, it)
> }. with {
> c(it, 2)
> }
> {code}
> {code:java}
> // Introduce a new syntax to transform the above method call chain to
> concatenative method calls
> // `_` represents the result of previous part
> // `|>` is like a big arrow representing the direction of data flow
> // if the target is a variable, `|>` means assignment/declaration
> a() |> b(3, _) |> c(_, 2) |> (def r)
> {code}
> h2. More examples
> {code:java}
> // `|>` has just a bit higher precedence than assignments, e.g. `=`, `+=`,
> `*=`, etc.
> 6 / a() |> b(3, _) + 9 |> c(_, 2) * 5 |> (def r)
> // the above code is equal to
> def r =
> c(
> b(
>
[jira] [Updated] (GROOVY-8998) [GEP]Concatenative Method Calls
[
https://issues.apache.org/jira/browse/GROOVY-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-8998:
---
Description:
h1. *DRAFT*
{code:java}
// lots of temp variable declarations and assignments
def ar = a()
def br = b(3, ar)
def r = c(br, 2)
// inline version of the above code, i.e. nested method calls
def r =
c(
b(
3,
a()
),
2
)
{code}
{code:java}
// leverage the power of DGM `with` to transform nested method calls to method
call chain
def r =
a().with {
b(3, it)
}. with {
c(it, 2)
}
{code}
{code:java}
// Introduce a new syntax to transform the above method call chain to
concatenative method calls
// `_` represents the result of previous part
// `|>` is like a big arrow representing the direction of data flow
// if the target is a variable, `|>` means assignment/declaration
a() |> b(3, _) |> c(_, 2) |> (def r)
{code}
h2. More examples
{code:java}
// `|>` has just a bit higher precedence than assignments, e.g. `=`, `+=`,
`*=`, etc.
6 / a() |> b(3, _) + 9 |> c(_, 2) * 5 |> (def r)
// the above code is equal to
def r =
c(
b(
3,
6 / a()
) + 9,
2
) * 5
{code}
h2. discussion in the dev mailing list
[http://groovy.329449.n5.nabble.com/GEP-Concatenative-Method-Calls-tt5747708.html]
was:
*DRAFT*
{code:java}
// lots of temp variable declarations and assignments
def ar = a()
def br = b(3, ar)
def r = c(br, 2)
// inline version of the above code, i.e. nested method calls
def r =
c(
b(
3,
a()
),
2
)
{code}
{code:java}
// leverage the power of DGM `with` to transform nested method calls to method
call chain
def r =
a().with {
b(3, it)
}. with {
c(it, 2)
}
{code}
{code:java}
// Introduce a new syntax to transform the above method call chain to
concatenative method calls
// `_` represents the result of previous part
// `|>` is like a big arrow representing the direction of data flow
// if the target is a variable, `|>` means assignment/declaration
a() |> b(3, _) |> c(_, 2) |> (def r)
{code}
{code:java}
// `|>` has just a bit higher precedence than assignments, e.g. `=`, `+=`,
`*=`, etc.
6 / a() |> b(3, _) + 9 |> c(_, 2) * 5 |> (def r)
// the above code is equal to
def r =
c(
b(
3,
6 / a()
) + 9,
2
) * 5
{code}
discussion in the dev mailing list:
[http://groovy.329449.n5.nabble.com/GEP-Concatenative-Method-Calls-tt5747708.html]
> [GEP]Concatenative Method Calls
> ---
>
> Key: GROOVY-8998
> URL: https://issues.apache.org/jira/browse/GROOVY-8998
> Project: Groovy
> Issue Type: New Feature
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
>
> h1. *DRAFT*
> {code:java}
> // lots of temp variable declarations and assignments
> def ar = a()
> def br = b(3, ar)
> def r = c(br, 2)
> // inline version of the above code, i.e. nested method calls
> def r =
> c(
> b(
> 3,
> a()
> ),
> 2
> )
> {code}
> {code:java}
> // leverage the power of DGM `with` to transform nested method calls to
> method call chain
> def r =
> a().with {
> b(3, it)
> }. with {
> c(it, 2)
> }
> {code}
> {code:java}
> // Introduce a new syntax to transform the above method call chain to
> concatenative method calls
> // `_` represents the result of previous part
> // `|>` is like a big arrow representing the direction of data flow
> // if the target is a variable, `|>` means assignment/declaration
> a() |> b(3, _) |> c(_, 2) |> (def r)
> {code}
> h2. More examples
> {code:java}
> // `|>` has just a bit higher precedence than assignments, e.g. `=`, `+=`,
> `*=`, etc.
> 6 / a() |> b(3, _) + 9 |> c(_, 2) * 5 |> (def r)
> // the above code is equal to
> def r =
> c(
> b(
> 3,
> 6 / a()
> ) + 9,
> 2
> ) * 5
> {code}
> h2. discussion in the dev mailing list
>
> [http://groovy.329449.n5.nabble.com/GEP-Concatenative-Method-Calls-tt5747708.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8998) [GEP]Concatenative Method Calls
[
https://issues.apache.org/jira/browse/GROOVY-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-8998:
---
Description:
*DRAFT*
{code:java}
// lots of temp variable declarations and assignments
def ar = a()
def br = b(3, ar)
def r = c(br, 2)
// inline version of the above code, i.e. nested method calls
def r =
c(
b(
3,
a()
),
2
)
{code}
{code:java}
// leverage the power of DGM `with` to transform nested method calls to method
call chain
def r =
a().with {
b(3, it)
}. with {
c(it, 2)
}
{code}
{code:java}
// Introduce a new syntax to transform the above method call chain to
concatenative method calls
// `_` represents the result of previous part
// `|>` is like a big arrow representing the direction of data flow
// if the target is a variable, `|>` means assignment/declaration
a() |> b(3, _) |> c(_, 2) |> (def r)
{code}
{code:java}
// `|>` has just a bit higher precedence than assignments, e.g. `=`, `+=`,
`*=`, etc.
6 / a() |> b(3, _) + 9 |> c(_, 2) * 5 |> (def r)
// the above code is equal to
def r =
c(
b(
3,
6 / a()
) + 9,
2
) * 5
{code}
discussion in the dev mailing list:
[http://groovy.329449.n5.nabble.com/GEP-Concatenative-Method-Calls-tt5747708.html]
was:
*DRAFT*
{code:java}
// lots of temp variable declarations and assignments
def ar = a()
def br = b(3, ar)
def r = c(br, 2)
// inline version of the above code, i.e. nested method calls
def r =
c(
b(
3,
a()
),
2
)
{code}
{code:java}
// leverage the power of DGM `with` to transform nested method calls to method
call chain
def r =
a().with {
b(3, it)
}. with {
c(it, 2)
}
{code}
{code:java}
// Introduce a new syntax to transform the above method call chain to
concatenative method calls
// `_` represents the result of previous part
// `|>` is like a big arrow representing the direction of data flow
// if the target is a variable, `|>` means assignment
a() |> b(3, _) |> c(_, 2) |> r
{code}
{code:java}
// `|>` has just a bit higher precedence than assignments, e.g. `=`, `+=`,
`*=`, etc.
6 / a() |> b(3, _) + 9 |> c(_, 2) * 5 |> r
// the above code is equal to
def r =
c(
b(
3,
6 / a()
) + 9,
2
) * 5
{code}
discussion in the dev mailing list:
[http://groovy.329449.n5.nabble.com/GEP-Concatenative-Method-Calls-tt5747708.html]
> [GEP]Concatenative Method Calls
> ---
>
> Key: GROOVY-8998
> URL: https://issues.apache.org/jira/browse/GROOVY-8998
> Project: Groovy
> Issue Type: New Feature
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
>
> *DRAFT*
> {code:java}
> // lots of temp variable declarations and assignments
> def ar = a()
> def br = b(3, ar)
> def r = c(br, 2)
> // inline version of the above code, i.e. nested method calls
> def r =
> c(
> b(
> 3,
> a()
> ),
> 2
> )
> {code}
> {code:java}
> // leverage the power of DGM `with` to transform nested method calls to
> method call chain
> def r =
> a().with {
> b(3, it)
> }. with {
> c(it, 2)
> }
> {code}
> {code:java}
> // Introduce a new syntax to transform the above method call chain to
> concatenative method calls
> // `_` represents the result of previous part
> // `|>` is like a big arrow representing the direction of data flow
> // if the target is a variable, `|>` means assignment/declaration
> a() |> b(3, _) |> c(_, 2) |> (def r)
> {code}
> {code:java}
> // `|>` has just a bit higher precedence than assignments, e.g. `=`, `+=`,
> `*=`, etc.
> 6 / a() |> b(3, _) + 9 |> c(_, 2) * 5 |> (def r)
> // the above code is equal to
> def r =
> c(
> b(
> 3,
> 6 / a()
> ) + 9,
> 2
> ) * 5
> {code}
> discussion in the dev mailing list:
>
> [http://groovy.329449.n5.nabble.com/GEP-Concatenative-Method-Calls-tt5747708.html]
--
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
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)
