[jira] [Updated] (GROOVY-1733) Let boolean operators (||, &&) evaluate to the value instead of the boolean equivalent
[
https://issues.apache.org/jira/browse/GROOVY-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-1733:
--
Fix Version/s: (was: 3.0.0-alpha-1)
> Let boolean operators (||, &&) evaluate to the value instead of the boolean
> equivalent
> --
>
> Key: GROOVY-1733
> URL: https://issues.apache.org/jira/browse/GROOVY-1733
> Project: Groovy
> Issue Type: Improvement
> Components: syntax
>Reporter: Siegfried Puchbauer
>Assignee: Guillaume Delcroix
>Priority: Minor
>
> It would enable you to do some things a lot faster (eg. variable declaration)
> and would improve the current null-save navigation
> examples:
> {code:java}
> def a = 0
> def b = null
> def c = "a string"
> def d = ""
> def val = a || c // c gets evalutated, because the boolean equivalent of a
> (0) is false
> assert a || b == null
> assert c || d == "a string"
> assert d || a == 0
> assert a || "another string" == "a string"
> assert d || "another string" == "another string"
> {code}
> for null-save navigation:
> {code:java}
> def val = aMap?.aProperty?.aSubProperty || "a default Value"
> {code}
> or even for causal execution of code
> {code:java}
> myobject.aMethodThatReturnsNullWhenItFails() || myobject.anotherMethod()
> // myobject.anotherMethod gets only executed the result of the first call
> evalutes to false
> {code}
> The current notation would not be affected in a negative way
> {code:java}
> if(a || b){...} // would still work
> {code}
> you would still have the possibility to get the boolean value by using !!
> eg.
> {code:java}
> assert (0 || 15) instanceof Integer
> assert !!(0 || 15) instanceof Boolean
> {code}
> The only language I know, which supports this currently is JavaScript
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (GROOVY-4906) Double.NaN == Double.Nan should evaluate to false
[ https://issues.apache.org/jira/browse/GROOVY-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-4906: -- Fix Version/s: (was: 3.0.0-alpha-1) > Double.NaN == Double.Nan should evaluate to false > - > > Key: GROOVY-4906 > URL: https://issues.apache.org/jira/browse/GROOVY-4906 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Reporter: Hamlet D'Arcy >Priority: Minor > > I think Double.NaN == Double.NaN should evaluate to false. > The reasons why are documented in the Java Language Specification. > IMO, we should stick with the JLS on this issue and not dispatch to the > .equals method (or whatever GroovyTruth is doing). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GROOVY-2576) Add "implies" operator for boolean expressions
[
https://issues.apache.org/jira/browse/GROOVY-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-2576:
--
Fix Version/s: (was: 3.0.0-alpha-1)
> Add "implies" operator for boolean expressions
> --
>
> Key: GROOVY-2576
> URL: https://issues.apache.org/jira/browse/GROOVY-2576
> Project: Groovy
> Issue Type: New Feature
> Components: syntax
>Reporter: Tord Alenljung
>Assignee: Daniel Sun
>Priority: Minor
>
> Consider supplying an "implies" operator, often denoted {{=>}}, for boolean
> expressions. Example:
> {code}
> if (itIsRaining => iAmUsingUmbrella) {
> println 'I am dry'
> }
> {code}
> {{itIsRaining => iAmUsingUmbrella}} is equivalent with {{!itIsRaining |
> iAmUsingUmbrella}} but the "implies" version is in many cases intutively more
> suitable.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (GROOVY-960) Change the MetaClass methods to not be bean properties
[ https://issues.apache.org/jira/browse/GROOVY-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-960: - Fix Version/s: (was: 3.0.0-alpha-1) > Change the MetaClass methods to not be bean properties > -- > > Key: GROOVY-960 > URL: https://issues.apache.org/jira/browse/GROOVY-960 > Project: Groovy > Issue Type: Improvement > Components: bytecode >Affects Versions: 1.0-JSR-2 >Reporter: Geert Bevin > > Currently, each Groovy class has setMetaClass and getMetaClass methods. This > makes it a valid javabean property that requires special handling in > automated bean handling features of libraries. Imho it would be a good course > of action to replace these methods with: > retrieveMetaClass > provideMetaClass -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GROOVY-2884) Support overloading property setters
[ https://issues.apache.org/jira/browse/GROOVY-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-2884: -- Fix Version/s: (was: 3.0.0-alpha-1) > Support overloading property setters > > > Key: GROOVY-2884 > URL: https://issues.apache.org/jira/browse/GROOVY-2884 > Project: Groovy > Issue Type: New Feature >Reporter: Luke Daley > > When to setters for a given property are defined, setting the property via > assignment should select the most appropriate setter according to the _same_ > method selection criteria that Groovy uses for regular method call dispatch. > Mailing list discussion: > http://www.nabble.com/Setter-overloading---should-it-work--tt17648166.html#a17648166 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GROOVY-2439) Annotation @MetaClass to setup MetaClass declarative
[
https://issues.apache.org/jira/browse/GROOVY-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-2439:
--
Fix Version/s: (was: 3.0.0-alpha-1)
> Annotation @MetaClass to setup MetaClass declarative
>
>
> Key: GROOVY-2439
> URL: https://issues.apache.org/jira/browse/GROOVY-2439
> Project: Groovy
> Issue Type: New Feature
>Affects Versions: 1.5.1
>Reporter: Jörg Gottschling
>Assignee: Jochen Theodorou
>
> An Annotation that tells the compiler what MetaClass to set for this a class.
> @MetaClass(ExpandoMetaClass)
> public class ExtensibleService extends BaseService
> {
> ...
> }
> Perhaps for this case a specialised Annotation would do the Job better:
> @Expando(allowChangesAfterInit = true)
> public class ExtensibleService extends BaseService
> {
> ...
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (GROOVY-3880) Optional Assignment Operator
[ https://issues.apache.org/jira/browse/GROOVY-3880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-3880: -- Fix Version/s: (was: 3.0.0-alpha-1) > Optional Assignment Operator > > > Key: GROOVY-3880 > URL: https://issues.apache.org/jira/browse/GROOVY-3880 > Project: Groovy > Issue Type: Improvement > Components: syntax >Reporter: Michael Martz >Assignee: Daniel Sun > > I find myself writing a lot of code in the following form: > if(data.field) obj.field = data.field > // Or > obj.field = data.field?: obj.field > It would be nice to have a groovy operator to handle this for me. > obj.field ?= data.field -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GROOVY-5291) Add "a ?:= 2" support: should be expanded to "a = a ?: 2"
[
https://issues.apache.org/jira/browse/GROOVY-5291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-5291:
--
Fix Version/s: (was: 3.0.0-alpha-1)
> Add "a ?:= 2" support: should be expanded to "a = a ?: 2"
> -
>
> Key: GROOVY-5291
> URL: https://issues.apache.org/jira/browse/GROOVY-5291
> Project: Groovy
> Issue Type: Improvement
> Components: syntax
>Reporter: Rodrigo Rosenfeld Rosas
>Assignee: Daniel Sun
>
> This would allow the very common useful idiom found in Ruby:
> {noformat}
> variable ||= value
> {noformat}
> Currently we have to write code like this in Groovy:
> {noformat}
> def myMap = [:]
> if (condition) (myMap[someLongNameObject.getKeyId()] =
> myMap[someLongNameObject.getKeyId()] ?: []) << someNewValue
> {noformat}
> Also, if getKeyId() is costly or shouldn't get called more than once for some
> reason, we would have to write it like:
> {noformat}
> def myMap = [:]
> if (condition) {
> def key = someLongNameObject.getKeyId()
> (myMap[key] = myMap[key] ?: []) << someNewValue
> }
> {noformat}
> When it could be simplified as this:
> {noformat}
> if (condition) (myMap[someLongNameObject.getKeyId()] ?:= []) << someNewValue
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (GROOVY-4874) Elvis assignment operator
[
https://issues.apache.org/jira/browse/GROOVY-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-4874:
--
Fix Version/s: (was: 3.0.0-alpha-1)
> Elvis assignment operator
> -
>
> Key: GROOVY-4874
> URL: https://issues.apache.org/jira/browse/GROOVY-4874
> Project: Groovy
> Issue Type: Improvement
> Components: syntax
>Reporter: Uri Moszkowicz
>Assignee: Daniel Sun
>Priority: Minor
>
> It would be nice to have an operator similar to the Elvis operator but for
> assignments.
> {code}
> a ?= b
> {code}
> as a shorthand for
> {code}
> a = b ?: a
> {code}
> I'm not a Ruby expert but from the Groovy mailing list it sounds like Ruby
> has an operator like this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (GROOVY-8144) Invoking a public method declared in a non-public class result in a IllegalAccessError
[
https://issues.apache.org/jira/browse/GROOVY-8144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King reopened GROOVY-8144:
---
> Invoking a public method declared in a non-public class result in a
> IllegalAccessError
> --
>
> Key: GROOVY-8144
> URL: https://issues.apache.org/jira/browse/GROOVY-8144
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.5.0-alpha-1
>Reporter: paolo di tommaso
>Assignee: John Wagenleitner
> Fix For: 2.5.0-beta-1
>
>
> For example:
> {code}
> import groovyx.gpars.agent.Agent
> import groovy.transform.CompileStatic
> @CompileStatic
> class Dummy {
> def void foo() {
> def x = new Agent( [] )
> x.send { List it -> it.add(1) }
> x.await()
> }
> }
> new Dummy().foo()
> java.lang.IllegalAccessError: tried to access class
> groovyx.gpars.agent.AgentBase from class Dummy
> at Dummy.foo(ConsoleScript15:10)
> at Dummy$foo.call(Unknown Source)
> at ConsoleScript15.run(ConsoleScript15:16)
> {code}
> I guess the problem is that AgentBase class is not declared public
> https://github.com/GPars/GPars/blob/master/src/main/groovy/groovyx/gpars/agent/AgentBase.java#L34
> This is a regression, see also this thread
> https://groups.google.com/d/msg/groovy-user/0Ig9mhRLnKk/LWsx1EQbu_4J
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GROOVY-8144) Invoking a public method declared in a non-public class result in a IllegalAccessError
[
https://issues.apache.org/jira/browse/GROOVY-8144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-8144.
---
Resolution: Fixed
> Invoking a public method declared in a non-public class result in a
> IllegalAccessError
> --
>
> Key: GROOVY-8144
> URL: https://issues.apache.org/jira/browse/GROOVY-8144
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.5.0-alpha-1
>Reporter: paolo di tommaso
>Assignee: John Wagenleitner
> Fix For: 2.5.0-beta-1
>
>
> For example:
> {code}
> import groovyx.gpars.agent.Agent
> import groovy.transform.CompileStatic
> @CompileStatic
> class Dummy {
> def void foo() {
> def x = new Agent( [] )
> x.send { List it -> it.add(1) }
> x.await()
> }
> }
> new Dummy().foo()
> java.lang.IllegalAccessError: tried to access class
> groovyx.gpars.agent.AgentBase from class Dummy
> at Dummy.foo(ConsoleScript15:10)
> at Dummy$foo.call(Unknown Source)
> at ConsoleScript15.run(ConsoleScript15:16)
> {code}
> I guess the problem is that AgentBase class is not declared public
> https://github.com/GPars/GPars/blob/master/src/main/groovy/groovyx/gpars/agent/AgentBase.java#L34
> This is a regression, see also this thread
> https://groups.google.com/d/msg/groovy-user/0Ig9mhRLnKk/LWsx1EQbu_4J
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (GROOVY-4189) Removing a metaClass method
[
https://issues.apache.org/jira/browse/GROOVY-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-4189:
--
Fix Version/s: (was: 3.0)
3.x
> Removing a metaClass method
> ---
>
> Key: GROOVY-4189
> URL: https://issues.apache.org/jira/browse/GROOVY-4189
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-jdk
>Affects Versions: 1.7.2
>Reporter: Tim Yates
>Priority: Minor
> Fix For: 3.x
>
>
> Spotted a question on stackoverflow about removing a metaclass method
> The page here
> http://groovy.codehaus.org/JN3525-MetaClasses
> Says you should be able to do it by setting it to null, but we get this:
> {code}
> String.metaClass.foo = { "${delegate}foo" }
> assert 'kung'.foo() == 'kungfoo'
> String.metaClass.foo = null
> assert 'woo'.foo() == 'woofoo'
> {code}
> That last assert should fail (according to the docs), but it passes
> Is this a documentation issue?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (GROOVY-6285) static declared type should influence method selection for null values
[
https://issues.apache.org/jira/browse/GROOVY-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-6285:
--
Fix Version/s: (was: 3.0)
3.x
> static declared type should influence method selection for null values
> --
>
> Key: GROOVY-6285
> URL: https://issues.apache.org/jira/browse/GROOVY-6285
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Affects Versions: 2.1.6
>Reporter: frenchyan
> Fix For: 3.x
>
> Attachments: glu235.groovy
>
>
> See file attached to reproduce the problem: E1 is an exception class, E2
> extends from E1 but define only the constructor with {{String}}.
> using new E2(null) end up calling {{E1(Throwable)}} => calling {{initCause}}
> then fails because the cause has been already been set.
> I am expecting {{E1(String)}} to be called...
> {code}
> > groovy -version
> Groovy Version: 2.1.6 JVM: 1.7.0_25 Vendor: Oracle Corporation OS: Mac OS X
> > groovy glu235.groovy
> called E1.throwable null
> called E2.string null
> Caught: java.lang.IllegalStateException: Can't overwrite cause
> java.lang.IllegalStateException: Can't overwrite cause
> at java_lang_Throwable$initCause.call(Unknown Source)
> at glu235.run(glu235.groovy:43)
> {code}
> Reproducible with groovy 2.0.7 as well.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (GROOVY-3299) Modifying meta-class has no effect in some cases
[ https://issues.apache.org/jira/browse/GROOVY-3299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-3299: -- Fix Version/s: (was: 3.0) 3.x > Modifying meta-class has no effect in some cases > > > Key: GROOVY-3299 > URL: https://issues.apache.org/jira/browse/GROOVY-3299 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 1.6-rc-1 >Reporter: Peter Ledbrook >Priority: Critical > Fix For: 3.x > > Attachments: MetaClassCachingBugTests.groovy, > MetaClassCachingBugWithInterfaceTests.groovy > > > See the attach test case. Basically it seems that the meta class for a class > is cached, but if it is modified (for example via EMC syntax), the cached > version is not updated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GROOVY-2994) String and GString do not commute under plus()
[
https://issues.apache.org/jira/browse/GROOVY-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-2994:
--
Fix Version/s: (was: 3.0)
3.x
> String and GString do not commute under plus()
> --
>
> Key: GROOVY-2994
> URL: https://issues.apache.org/jira/browse/GROOVY-2994
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 1.5.6
>Reporter: Alexander Veit
> Fix For: 3.x
>
>
> assert "${1}" + "2" instanceof GString
> assert "1" + "${2}" instanceof String
> As far as I can see plus() should be commutative throughout the GDK. At least
> it should be commutative for String and GString.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GROOVY-8102) Does/could Groovy support multiple variable definitions in for loop?
[
https://issues.apache.org/jira/browse/GROOVY-8102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-8102.
---
Resolution: Fixed
Fix Version/s: (was: 3.0)
2.6.0-alpha-1
> Does/could Groovy support multiple variable definitions in for loop?
>
>
> Key: GROOVY-8102
> URL: https://issues.apache.org/jira/browse/GROOVY-8102
> Project: Groovy
> Issue Type: Question
> Components: Compiler
>Reporter: Eric Milles
>Assignee: Daniel Sun
>Priority: Minor
> Fix For: 2.6.0-alpha-1
>
>
> I ask this because it has been causing a lot of headaches when we convert
> Java files to Groovy. This form seems to fail and seems reasonably useful:
> {code}
> for (int i = 0, n = list.length; i < n; i +=1) {
> {code}
> It seems the definition of two or more variables in the for initializer is
> not supported.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GROOVY-5652) Semicolon required after coercing to a parameterized (generic) type containing a parameterized (generic) type as its only or last type argument when there is no space b
[ https://issues.apache.org/jira/browse/GROOVY-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-5652. --- Resolution: Fixed Fix Version/s: (was: 3.0) 2.6.0-alpha-1 > Semicolon required after coercing to a parameterized (generic) type > containing a parameterized (generic) type as its only or last type argument > when there is no space between the ending ">>" > -- > > Key: GROOVY-5652 > URL: https://issues.apache.org/jira/browse/GROOVY-5652 > Project: Groovy > Issue Type: Bug > Components: parser-antlr >Affects Versions: 1.8.6 >Reporter: Amy Chuo >Assignee: Daniel Sun > Fix For: 2.6.0-alpha-1 > > > It seems that after coercing an object to a parameterized (generic) type > containing a parameterized (generic) type as its only or last type argument > without putting any space between the ending ">>", a semicolon is needed. > Example: > $ groovy -v > Groovy Version: 1.8.6 JVM: 1.6.0_30 Vendor: Sun Microsystems Inc. OS: Linux > $ groovy -e "def list = [1,2,3,4] as List > println list > println 'bye'" # This works fine. > [1, 2, 3, 4] > bye > $ groovy -e "def list = [[1,2],[3,4]] as List> println list > println 'bye'" # This should work fine, but does not. > org.codehaus.groovy.control.MultipleCompilationErrorsException: startup > failed: > script_from_command_line: 2: expecting EOF, found 'println' @ line 2, column > 1. >println list >^ > 1 error > $ groovy -e "def list = [[1,2],[3,4]] as List
> println list > println 'bye'" # After adding a space between ">>", this works fine. > [[1, 2], [3, 4]] > bye > $ groovy -e "def list = [[1,2],[3,4]] as List
; > println list > println 'bye'" # Or, after adding a semicolon, this works fine. > [[1, 2], [3, 4]] > bye > $ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GROOVY-5309) Wrong line/col info for binary expressions
[
https://issues.apache.org/jira/browse/GROOVY-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-5309.
---
Resolution: Fixed
Fix Version/s: (was: 3.0)
2.6.0-alpha-1
> Wrong line/col info for binary expressions
> --
>
> Key: GROOVY-5309
> URL: https://issues.apache.org/jira/browse/GROOVY-5309
> Project: Groovy
> Issue Type: Bug
> Components: parser-antlr
>Reporter: Guillaume Delcroix
>Assignee: Daniel Sun
>Priority: Minor
> Fix For: 2.6.0-alpha-1
>
>
> {code}
> assert annotationsOfIdField[0]instanceof Id
> {code}
> The binary expression between the assert and instanceof: the end of the line
> / col info is right before instance of, instead of being after the last
> closing square bracket
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GROOVY-6336) Support Java 7 ARM blocks
[ https://issues.apache.org/jira/browse/GROOVY-6336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-6336. --- Resolution: Fixed Fix Version/s: (was: 3.0) 2.6.0-alpha-1 > Support Java 7 ARM blocks > - > > Key: GROOVY-6336 > URL: https://issues.apache.org/jira/browse/GROOVY-6336 > Project: Groovy > Issue Type: New Feature > Components: Compiler >Affects Versions: 2.2.0-beta-2 >Reporter: Tom Dunstan >Assignee: Daniel Sun > Fix For: 2.6.0-alpha-1 > > > Currently Groovy does not have an equivalent to Java 7's ARM blocks. The > closest is adding a method which takes a closure to the class that you'd like > to be auto-closed (or whatever gives you that resource), and implementing the > closing logic in that method. This has a host of problems: > - It's inefficient, requiring multiple method calls and an extra closure > class over the Java solution > - Since the closure-accepting methods are added ad-hoc, they have different > names and quite possibly subtly different behaviour, particularly around what > happens if an exception is thrown during the closing. By contrast this is > well defined in Java 7 so a programmer doesn't have to go hunting for > documentation or source code on the method that they're calling > - If you are trying to work with an existing Java library rather than Groovy > code, you're out of luck, since short of metaclass hacking you won't be able > to add a wrapper method anyway > It would also be nice to keep Groovy and Java syntax as consistent as > possible to ease porting between the two. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GROOVY-5306) Add "a ?= 2" support: should be expanded to "a = a == null ? 2 : a"
[
https://issues.apache.org/jira/browse/GROOVY-5306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-5306.
---
Resolution: Fixed
Fix Version/s: (was: 3.0)
2.6.0-alpha-1
> Add "a ?= 2" support: should be expanded to "a = a == null ? 2 : a"
> ---
>
> Key: GROOVY-5306
> URL: https://issues.apache.org/jira/browse/GROOVY-5306
> Project: Groovy
> Issue Type: Improvement
> Components: syntax
>Reporter: Rodrigo Rosenfeld Rosas
>Assignee: Daniel Sun
> Fix For: 2.6.0-alpha-1
>
>
> I've suggested last week the creation of the "?:=" constructor in Groovy:
> https://jira.codehaus.org/browse/GROOVY-5291
> It was rejected and a new JIRA was requested to be created with a new
> operator.
> Then, I've talked to the Grails users in their mailing list to get some
> feedback, which can be read here:
> http://grails.1312388.n4.nabble.com/Help-improving-Groovy-syntax-tt4384137.html
> Then, Phil DeJarnett has suggested using "?=" instead of "?:=". Not only I
> preferred this suggestion, but I was changed my mind about its meaning too.
> It would be used as a caching/memoization operator mostly. It would be
> similar to Ruby's "||=", except for this specific situation:
> Ruby:
> {code}
> a = nil
> a ||= false # a will be false
> a ||= true # a will be true
> {code}
> That is why "a ||= value" is expanded to "a = a || value"
> But for caching/memoization, I'd prefer "a ?= value" to be expanded to "a = a
> == null ? value : a". This way we would have:
> Proposed Groovy syntax:
> {code}
> def a = null
> a ?= false; assert a == false
> a ?= true; assert a == true
> a = null; a ?= new Object(); assert a instanceof Object
> {code}
> I'll actually fill a new ticket on Ruby Redmine too for proposing the same
> syntax and semanthics :)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GROOVY-5310) Wrong line/col info for statements with whitespace before EOL
[ https://issues.apache.org/jira/browse/GROOVY-5310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-5310. --- Resolution: Fixed Fix Version/s: (was: 3.0) 2.6.0-alpha-1 > Wrong line/col info for statements with whitespace before EOL > - > > Key: GROOVY-5310 > URL: https://issues.apache.org/jira/browse/GROOVY-5310 > Project: Groovy > Issue Type: Bug > Components: parser-antlr >Reporter: Guillaume Delcroix >Assignee: Daniel Sun >Priority: Minor > Fix For: 2.6.0-alpha-1 > > > If there are spaces at the end of a line statement, the space is also > accounted in the lin / col info, instead of being the last (non-whitespace) > character of the statement -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GROOVY-2067) Truth as a method.
[ https://issues.apache.org/jira/browse/GROOVY-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-2067. --- Resolution: Fixed Fix Version/s: (was: 3.0) 2.6.0-alpha-1 > Truth as a method. > -- > > Key: GROOVY-2067 > URL: https://issues.apache.org/jira/browse/GROOVY-2067 > Project: Groovy > Issue Type: Improvement > Components: syntax >Affects Versions: 1.1-beta-2 > Environment: Ubuntu 7.04, Java 1.6.01, Groovy 1.0 >Reporter: Marcos Silva Pereira > Fix For: 2.6.0-alpha-1 > > > With isCase method, you could do any type become a classifier for switch-case > statements. Groovy should deals with truth the same way providing a method > that checks truth. > This could avoid problems like that: > http://thread.gmane.org/gmane.comp.lang.groovy.devel/8507/focus=8519 > And provides to users a way to do any class become a classifier for > conditional statements. The possible names to the methods are: > 1. isTrue > 2. checkTruth > 3. truth > 4. $isTrue > 5. truth > 6. asBool -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GROOVY-3791) Array initializer fails
[
https://issues.apache.org/jira/browse/GROOVY-3791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-3791.
---
Resolution: Fixed
Fix Version/s: (was: 3.0)
2.6.0-alpha-1
> Array initializer fails
> ---
>
> Key: GROOVY-3791
> URL: https://issues.apache.org/jira/browse/GROOVY-3791
> Project: Groovy
> Issue Type: New Feature
> Components: syntax
>Affects Versions: 1.6.4
>Reporter: Steve Buroff
>Assignee: Daniel Sun
>Priority: Minor
> Fix For: 2.6.0-alpha-1
>
> Attachments: arrayInitializer.groovy, ArrayInitializer.java
>
>
> Run the attached one line file and you get:
>
> C:\Temp>groovyc arrayInitializer.groovy
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed,
> arrayInitializer.groovy: 3: No expression for the array constructor call at
> line
> : 3 column: 29. File: arrayInitializer.groovy @ line 3, column 29.
> String[] junk = new String[]{"xxx"};
>^
> 1 error
> =
> Of course the line is perfectly correct. Try the attached java file which is
> an exact
> copy of the groovy file. It compiles fine.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GROOVY-2324) grammar forces usage of lowercase names for commands
[ https://issues.apache.org/jira/browse/GROOVY-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-2324. --- Resolution: Fixed Fix Version/s: (was: 3.0) 2.6.0-alpha-1 > grammar forces usage of lowercase names for commands > > > Key: GROOVY-2324 > URL: https://issues.apache.org/jira/browse/GROOVY-2324 > Project: Groovy > Issue Type: Sub-task > Components: groovy-runtime >Reporter: Jochen Theodorou >Assignee: Daniel Sun > Fix For: 2.6.0-alpha-1 > > > any command "foo bar" where foo starts with an uppercase letter leads the > grammar to recognize that "foo" as a class. we should see if that is really > needed -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GROOVY-4761) Incorrect source location for method call expression
[
https://issues.apache.org/jira/browse/GROOVY-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-4761.
---
Resolution: Fixed
Fix Version/s: (was: 3.0)
2.6.0-alpha-1
> Incorrect source location for method call expression
>
>
> Key: GROOVY-4761
> URL: https://issues.apache.org/jira/browse/GROOVY-4761
> Project: Groovy
> Issue Type: Bug
> Components: parser, parser-antlr
>Affects Versions: 1.8-rc-2
>Reporter: Andrew Eisenberg
>Assignee: Daniel Sun
> Fix For: 2.6.0-alpha-1
>
>
> In this class, the source location for the StaticMethodCallExpression is
> incorrect. The start column coincides with the column for '3' and the end
> includes the whitespace until the comment starts.
> {code}
> class StaticTrying {
>
> public static Class staticMethod(arg) {
>
> }
>
> def foo() {
> def a = staticMethod 3 // extra whitespace
> }
> }
> {code}
> I'm not too concerned about the invalid end column, but the start column
> problem is affecting Groovy-Eclipse.
> I delved a little bit into this. Here is when the situation happens:
> # when the method declaration takes 1 or more parameters
> # the method declaration can be either static or non-static
> # the method call takes exactly 1 argument
> # does not use parens
> # is part of a declaration expression.
> Because of parts 4 and 5, this problem can only occur on Groovy 1.8 because
> on 1.7 it would be a parsing error.
> I tracked this down to an invalid source location for the Antlr AST node
> being passed into {{AntlrParserPlugin.methodCallExpression()}}.
> I originally reported this bug in GRECLIPSE-1031.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GROOVY-4762) Numbers as properties in command expressions
[
https://issues.apache.org/jira/browse/GROOVY-4762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-4762.
---
Resolution: Fixed
Fix Version/s: (was: 3.0)
2.6.0-alpha-1
> Numbers as properties in command expressions
>
>
> Key: GROOVY-4762
> URL: https://issues.apache.org/jira/browse/GROOVY-4762
> Project: Groovy
> Issue Type: Bug
> Components: parser
>Affects Versions: 1.8-rc-3
>Reporter: Maxim Medvedev
>Assignee: Daniel Sun
> Fix For: 2.6.0-alpha-1
>
>
> It is allowed not to surround numbers with quotes in command expressions if
> they are used as properties.
> Is it bug or feature?
>
> {code}
> def get123() {2}
> def foo(i) {this}
> def a = foo(2).'123'
> def b = foo 2 123
> println a
> println b
> {code}
> But if you rename get123() to get123a() the line will throw an exception.
> {code}
> def b = foo 2 123a
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GROOVY-4095) Labeled statements have wrong source position
[
https://issues.apache.org/jira/browse/GROOVY-4095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-4095.
---
Resolution: Fixed
Fix Version/s: (was: 3.0)
2.6.0-alpha-1
> Labeled statements have wrong source position
> -
>
> Key: GROOVY-4095
> URL: https://issues.apache.org/jira/browse/GROOVY-4095
> Project: Groovy
> Issue Type: Bug
> Components: parser
>Affects Versions: 1.7.1
>Reporter: Peter Niederwieser
>Assignee: Daniel Sun
> Fix For: 2.6.0-alpha-1
>
>
> Example:
> {code}
> mylabel:
> foo()
> {code}
> Source position of this statement is [1,8]-[1,9], which is the position of
> the ':' token. Same for all other labeled statements I've checked.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GROOVY-5313) Wrong line/col info for SpreadMapExpressions
[
https://issues.apache.org/jira/browse/GROOVY-5313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-5313.
---
Resolution: Fixed
Fix Version/s: (was: 3.0)
2.6.0-alpha-1
> Wrong line/col info for SpreadMapExpressions
>
>
> Key: GROOVY-5313
> URL: https://issues.apache.org/jira/browse/GROOVY-5313
> Project: Groovy
> Issue Type: Bug
> Components: parser-antlr
>Reporter: Guillaume Delcroix
>Assignee: Daniel Sun
>Priority: Minor
> Fix For: 2.6.0-alpha-1
>
>
> {code}
> def m = [a :1 , b: 2 ]
> def map = [abc: 1, bcd: 2, *:m , cde: 3]
> {code}
> The SpreadMapExpression highlights just the star *, and the m variable is
> highlighted till the comma, instead of just the m character (ie. including
> further whitespace).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GROOVY-8150) Inconsistency in multiple assignment with single variable
[
https://issues.apache.org/jira/browse/GROOVY-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-8150.
---
Resolution: Fixed
Fix Version/s: (was: 3.0)
2.6.0-alpha-1
> Inconsistency in multiple assignment with single variable
> -
>
> Key: GROOVY-8150
> URL: https://issues.apache.org/jira/browse/GROOVY-8150
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.0-alpha-1, 2.4.10
>Reporter: Daniil Ovchinnikov
>Assignee: Daniel Sun
> Fix For: 2.6.0-alpha-1
>
>
> {code}
> def a
> def b = [1]
> a = b
> println "${a} : ${a.class}" // [1] : class java.util.ArrayList
> (a) = b
> println "${a} : ${a.class}" // 1 : class java.lang.Integer
> ((a)) = b
> println "${a} : ${a.class}" // [1] : class java.util.ArrayList
> {code}
> This is confusing. Here are options:
> 1. {{((a)) = b}} should be failed to parse.
> 2. {{((a)) = b}} should behave like {{(a) = b}}, i.e. number of parentheses
> should not matter.
> 3. {{((a)) = b}} and {{(a) = b}} should behave like {{a = b}}. This will
> match the following case also:
> {code}
> class A { def myField }
> def a = new A()
> def b = [1]
> a.myField = b
> assert a.myField == [1]
> (a.myField) = b
> assert a.myField == [1]
> ((a.myField)) = b
> assert a.myField == [1]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GROOVY-7977) Refine the implementation of LRUCache
[ https://issues.apache.org/jira/browse/GROOVY-7977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-7977. --- Resolution: Fixed Fix Version/s: (was: 3.0) 2.6.0-alpha-1 > Refine the implementation of LRUCache > - > > Key: GROOVY-7977 > URL: https://issues.apache.org/jira/browse/GROOVY-7977 > Project: Groovy > Issue Type: Improvement >Affects Versions: 2.4.7 >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Minor > Fix For: 2.6.0-alpha-1 > > Attachments: text.html, text.html, text.html, text.html, text.html, > text.html, text.html, text.html > > > I found the LRUCache that Groovy is using is not efficient enough > because it is based on Collections.synchronizedMap, the LRUCache is used by > some important classes(e.g. ProxyGenerator, Closure), so it can impact the > performance somehow. > I propose to replace the implementation with > Caffeine(https://github.com/ben-manes/caffeine), which is a high performance > caching library for Java 8 and licensed under APL2. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GROOVY-2840) Support "not" for in and instanceof
[ https://issues.apache.org/jira/browse/GROOVY-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-2840. --- Resolution: Fixed Fix Version/s: (was: 3.0) 2.6.0-alpha-1 > Support "not" for in and instanceof > > > Key: GROOVY-2840 > URL: https://issues.apache.org/jira/browse/GROOVY-2840 > Project: Groovy > Issue Type: New Feature > Components: syntax >Affects Versions: 1.5.6, 1.6-beta-1 >Reporter: Mingfai Ma >Assignee: Daniel Sun > Fix For: 2.6.0-alpha-1 > > > It would be nice if we could use: > - (3 !in [2,3,4]) or (3 not in [2,3,4]) instead of (!(3 in [2,3,4])) > - also for instanceof > Remarks: > - It doesn't look like a big issue if it's just "!(x in ['x'])", but when the > line is longer and more complex and when use together with other parenthesis, > skipping one pair of parenthesis means a lot in code clarity. It's just like > in SQL, we can add a NOT to NOT LIKE or NOT IN. > Reference: > http://www.nabble.com/Groovy-syntax--API-enhancement-td16796998.html#a16810531 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GROOVY-4757) Can't compile method with generic signatures and default visibiliy access
[
https://issues.apache.org/jira/browse/GROOVY-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-4757.
---
Resolution: Fixed
Fix Version/s: (was: 3.0)
2.6.0-alpha-1
> Can't compile method with generic signatures and default visibiliy access
> -
>
> Key: GROOVY-4757
> URL: https://issues.apache.org/jira/browse/GROOVY-4757
> Project: Groovy
> Issue Type: Bug
> Components: parser-antlr
>Affects Versions: 1.7.10
>Reporter: Andres Almiray
>Assignee: Daniel Sun
> Fix For: 2.6.0-alpha-1
>
>
> The following script results in a compilation error
> {code}
> class Foo {
> void foo(T t) {}
> }
> f = new Foo()
> // compiler output
> 1 compilation error:
> unexpected token: < at line: 2, column: 5
> {code}
> Adding a visibility accessor makes it work
> {code}
> class Foo {
> public void foo(T t) {}
> }
> f = new Foo()
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GROOVY-8131) Statement continued onto next line is flagged when first character is "="
[ https://issues.apache.org/jira/browse/GROOVY-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-8131. --- Resolution: Fixed Fix Version/s: (was: 3.0) 2.6.0-alpha-1 > Statement continued onto next line is flagged when first character is "=" > - > > Key: GROOVY-8131 > URL: https://issues.apache.org/jira/browse/GROOVY-8131 > Project: Groovy > Issue Type: Bug > Components: Compiler >Affects Versions: 2.4.5 > Environment: Ubuntu Linux > `uname -a`: > Linux biostar 4.4.0-69-generic #90-Ubuntu SMP Thu Mar 16 16:52:31 UTC 2017 > x86_64 x86_64 x86_64 GNU/Linux >Reporter: Richard Elkins >Assignee: Daniel Sun >Priority: Minor > Fix For: 2.6.0-alpha-1 > > Attachments: grbug.java > > > Source code attached (grbug.java). > `javac` v8 compiles variable declarations s1, s2, and s3 successfully. > `groovyc` flags s3: > "unexpected token: = @ line 9, column 3." -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GROOVY-5312) Wrong line/col info for MapEntryExpressions
[ https://issues.apache.org/jira/browse/GROOVY-5312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-5312. --- Resolution: Fixed Fix Version/s: (was: 3.0) 2.6.0-alpha-1 > Wrong line/col info for MapEntryExpressions > --- > > Key: GROOVY-5312 > URL: https://issues.apache.org/jira/browse/GROOVY-5312 > Project: Groovy > Issue Type: Bug > Components: parser-antlr >Reporter: Guillaume Delcroix >Assignee: Daniel Sun >Priority: Minor > Fix For: 2.6.0-alpha-1 > > > Whenever there's a map entry, a named parameter, etc, a MapEntryExpression is > used, but the line / col of MapEntryExpression is just surrounding the > column, instead of the whole key + colon + value. > Another problem with MEE is that the value goes up to the next comma or > closing square bracket (including all potential whitespace), instead of just > stopping at the end of the expression or constant. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GROOVY-3472) Wrong line/column numbers for method and closure blocks
[
https://issues.apache.org/jira/browse/GROOVY-3472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-3472.
---
Resolution: Fixed
Fix Version/s: (was: 3.0)
2.6.0-alpha-1
> Wrong line/column numbers for method and closure blocks
> ---
>
> Key: GROOVY-3472
> URL: https://issues.apache.org/jira/browse/GROOVY-3472
> Project: Groovy
> Issue Type: Bug
> Components: parser
>Affects Versions: 1.5.7
>Reporter: Petr Hejl
>Assignee: Daniel Sun
> Fix For: 2.6.0-alpha-1
>
>
> Under certain circumstances code blocks (BlockStatement) of MethodNode and
> ClosureExpression have just [-1,-1,-1,-1] for line and column numbers, while
> parent (MethodNode, ClosureExpression) is ok. Sometimes even some statements
> in the block have [-1,-1,-1,-1] coordinates.
> Sample - method x:
> {noformat}
> class GroovyClass {
> def x() {
> String a
>
> }
> }
> {noformat}
> In this situation MethodNode [2,5,6,6], code BlockStatement [-1,-1,-1,-1] ,
> ReturnStatement [-1,-1,-1,-1]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GROOVY-6038) Ability to declare inner annotation types
[
https://issues.apache.org/jira/browse/GROOVY-6038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-6038.
---
Resolution: Fixed
Fix Version/s: (was: 3.0)
2.6.0-alpha-1
> Ability to declare inner annotation types
> -
>
> Key: GROOVY-6038
> URL: https://issues.apache.org/jira/browse/GROOVY-6038
> Project: Groovy
> Issue Type: Bug
> Components: syntax
>Reporter: Maxim Medvedev
>Assignee: Daniel Sun
> Fix For: 2.6.0-alpha-1
>
>
> {code}
> @interface Upper {
> @interface Inner {}
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GROOVY-7772) Class. had better to have same meaning of Class::instanceMethod of Java8
[
https://issues.apache.org/jira/browse/GROOVY-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-7772.
---
Resolution: Fixed
Fix Version/s: (was: 3.0)
2.6.0-alpha-1
> Class. had better to have same meaning of
> Class::instanceMethod of Java8
> ---
>
> Key: GROOVY-7772
> URL: https://issues.apache.org/jira/browse/GROOVY-7772
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Affects Versions: 2.4.6
>Reporter: UEHARA Junji
>Assignee: Daniel Sun
>Priority: Minor
> Fix For: 2.6.0-alpha-1
>
>
> Groovy's operator .& for method is similar functionality to Java8's method
> reference operator ::.
> ||No.||lhs||rhs||meaing of Groovy's .& (Closure) ||meaning of java8's ::
> (FunctionalInterface)||
> |1|instance|instanceMethod| { ..args -> instance.instanceMethod(args) | same
> as groovy |
> |2|Class|staticMethod| { ..args -> Class.staticMethod(args) | same as groovy |
> |3|instance|staticMethod| ERROR groovy.lang.MissingMethodException: | Error
> same as groovy (compile error) |
> |4|Class|instanceMethod|error| Function, where method
> instance method of Class which is declared as ```RetType
> instanceMethod(Args..) {...}```. In other words it is interpreted as a
> function which takes LHS Class as the first parameter which additionally
> inserted to the method.)|
> IMHO, i'd like to propose to change the No 4 pattern semantics of groovy
> same as Java 8 's. Because:
> * You can write:
> {code}
> ["a,b,c"].collect ( String. )
> {code}
> instaed of
> {code}
> ["a,b,c"].collect { it.toUpperCase() }
> {code}
> * Can have correspond operator to java8's ::. which is understandablea and
> needed for Java programmers.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GROOVY-3898) Allow the specification of types when initializing multiple iteration variables in a "for" construct
[
https://issues.apache.org/jira/browse/GROOVY-3898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-3898.
---
Resolution: Fixed
Fix Version/s: (was: 3.0)
2.6.0-alpha-1
> Allow the specification of types when initializing multiple iteration
> variables in a "for" construct
>
>
> Key: GROOVY-3898
> URL: https://issues.apache.org/jira/browse/GROOVY-3898
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler, parser, parser-antlr, syntax
>Affects Versions: 1.6.5, 1.7-beta-2
>Reporter: Ed Clark
>Assignee: Daniel Sun
>Priority: Minor
> Fix For: 2.6.0-alpha-1
>
>
> def( int i, int j) = [0,0] works as a stand alone assignment, but it does not
> work in the initialization portion of a for. For example, while
> for( (i, j)=[0,0]; i<10; {i++; j++ }()){ ... }
> compiles
> for( def( int i, int j)=[0,0]; i<10; {i++; j++ }()){ ... }
> does not.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (GROOVY-2067) Truth as a method.
[ https://issues.apache.org/jira/browse/GROOVY-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King reopened GROOVY-2067: --- > Truth as a method. > -- > > Key: GROOVY-2067 > URL: https://issues.apache.org/jira/browse/GROOVY-2067 > Project: Groovy > Issue Type: Improvement > Components: syntax >Affects Versions: 1.1-beta-2 > Environment: Ubuntu 7.04, Java 1.6.01, Groovy 1.0 >Reporter: Marcos Silva Pereira > Fix For: 3.0 > > > With isCase method, you could do any type become a classifier for switch-case > statements. Groovy should deals with truth the same way providing a method > that checks truth. > This could avoid problems like that: > http://thread.gmane.org/gmane.comp.lang.groovy.devel/8507/focus=8519 > And provides to users a way to do any class become a classifier for > conditional statements. The possible names to the methods are: > 1. isTrue > 2. checkTruth > 3. truth > 4. $isTrue > 5. truth > 6. asBool -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (GROOVY-5306) Add "a ?= 2" support: should be expanded to "a = a == null ? 2 : a"
[
https://issues.apache.org/jira/browse/GROOVY-5306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King reopened GROOVY-5306:
---
> Add "a ?= 2" support: should be expanded to "a = a == null ? 2 : a"
> ---
>
> Key: GROOVY-5306
> URL: https://issues.apache.org/jira/browse/GROOVY-5306
> Project: Groovy
> Issue Type: Improvement
> Components: syntax
>Reporter: Rodrigo Rosenfeld Rosas
>Assignee: Daniel Sun
> Fix For: 3.0
>
>
> I've suggested last week the creation of the "?:=" constructor in Groovy:
> https://jira.codehaus.org/browse/GROOVY-5291
> It was rejected and a new JIRA was requested to be created with a new
> operator.
> Then, I've talked to the Grails users in their mailing list to get some
> feedback, which can be read here:
> http://grails.1312388.n4.nabble.com/Help-improving-Groovy-syntax-tt4384137.html
> Then, Phil DeJarnett has suggested using "?=" instead of "?:=". Not only I
> preferred this suggestion, but I was changed my mind about its meaning too.
> It would be used as a caching/memoization operator mostly. It would be
> similar to Ruby's "||=", except for this specific situation:
> Ruby:
> {code}
> a = nil
> a ||= false # a will be false
> a ||= true # a will be true
> {code}
> That is why "a ||= value" is expanded to "a = a || value"
> But for caching/memoization, I'd prefer "a ?= value" to be expanded to "a = a
> == null ? value : a". This way we would have:
> Proposed Groovy syntax:
> {code}
> def a = null
> a ?= false; assert a == false
> a ?= true; assert a == true
> a = null; a ?= new Object(); assert a instanceof Object
> {code}
> I'll actually fill a new ticket on Ruby Redmine too for proposing the same
> syntax and semanthics :)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (GROOVY-3472) Wrong line/column numbers for method and closure blocks
[
https://issues.apache.org/jira/browse/GROOVY-3472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King reopened GROOVY-3472:
---
> Wrong line/column numbers for method and closure blocks
> ---
>
> Key: GROOVY-3472
> URL: https://issues.apache.org/jira/browse/GROOVY-3472
> Project: Groovy
> Issue Type: Bug
> Components: parser
>Affects Versions: 1.5.7
>Reporter: Petr Hejl
>Assignee: Daniel Sun
> Fix For: 3.0
>
>
> Under certain circumstances code blocks (BlockStatement) of MethodNode and
> ClosureExpression have just [-1,-1,-1,-1] for line and column numbers, while
> parent (MethodNode, ClosureExpression) is ok. Sometimes even some statements
> in the block have [-1,-1,-1,-1] coordinates.
> Sample - method x:
> {noformat}
> class GroovyClass {
> def x() {
> String a
>
> }
> }
> {noformat}
> In this situation MethodNode [2,5,6,6], code BlockStatement [-1,-1,-1,-1] ,
> ReturnStatement [-1,-1,-1,-1]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (GROOVY-5311) Wrong line/col info for GStrings
[
https://issues.apache.org/jira/browse/GROOVY-5311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King reopened GROOVY-5311:
---
> Wrong line/col info for GStrings
>
>
> Key: GROOVY-5311
> URL: https://issues.apache.org/jira/browse/GROOVY-5311
> Project: Groovy
> Issue Type: Bug
> Components: parser-antlr
>Reporter: Guillaume Delcroix
>Assignee: Daniel Sun
>Priority: Minor
> Fix For: 3.0
>
>
> GStrings have problems with their various sub parts: the constant strings and
> the variables interpolated.
> With this example:
> {code}
> def gs1 = "-$a-${b}-${->c}-"
> {code}
> The first constant string represents "-$ instead of just the minus sign.
> The second and third constant are -$ instead of just the minus sign again.
> And the last constant is -", instead of just the minus sign, it's going one
> character too far.
> Now on to the variables.
> Variable a is okay.
> Varible b is actually {b} and I think it should be just b
> And the closure expression is jut right too.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (GROOVY-2324) grammar forces usage of lowercase names for commands
[ https://issues.apache.org/jira/browse/GROOVY-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King reopened GROOVY-2324: --- > grammar forces usage of lowercase names for commands > > > Key: GROOVY-2324 > URL: https://issues.apache.org/jira/browse/GROOVY-2324 > Project: Groovy > Issue Type: Sub-task > Components: groovy-runtime >Reporter: Jochen Theodorou >Assignee: Daniel Sun > Fix For: 3.0 > > > any command "foo bar" where foo starts with an uppercase letter leads the > grammar to recognize that "foo" as a class. we should see if that is really > needed -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (GROOVY-5652) Semicolon required after coercing to a parameterized (generic) type containing a parameterized (generic) type as its only or last type argument when there is no space b
[ https://issues.apache.org/jira/browse/GROOVY-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King reopened GROOVY-5652: --- > Semicolon required after coercing to a parameterized (generic) type > containing a parameterized (generic) type as its only or last type argument > when there is no space between the ending ">>" > -- > > Key: GROOVY-5652 > URL: https://issues.apache.org/jira/browse/GROOVY-5652 > Project: Groovy > Issue Type: Bug > Components: parser-antlr >Affects Versions: 1.8.6 >Reporter: Amy Chuo >Assignee: Daniel Sun > Fix For: 3.0 > > > It seems that after coercing an object to a parameterized (generic) type > containing a parameterized (generic) type as its only or last type argument > without putting any space between the ending ">>", a semicolon is needed. > Example: > $ groovy -v > Groovy Version: 1.8.6 JVM: 1.6.0_30 Vendor: Sun Microsystems Inc. OS: Linux > $ groovy -e "def list = [1,2,3,4] as List > println list > println 'bye'" # This works fine. > [1, 2, 3, 4] > bye > $ groovy -e "def list = [[1,2],[3,4]] as List> println list > println 'bye'" # This should work fine, but does not. > org.codehaus.groovy.control.MultipleCompilationErrorsException: startup > failed: > script_from_command_line: 2: expecting EOF, found 'println' @ line 2, column > 1. >println list >^ > 1 error > $ groovy -e "def list = [[1,2],[3,4]] as List
> println list > println 'bye'" # After adding a space between ">>", this works fine. > [[1, 2], [3, 4]] > bye > $ groovy -e "def list = [[1,2],[3,4]] as List
; > println list > println 'bye'" # Or, after adding a semicolon, this works fine. > [[1, 2], [3, 4]] > bye > $ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (GROOVY-5310) Wrong line/col info for statements with whitespace before EOL
[ https://issues.apache.org/jira/browse/GROOVY-5310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King reopened GROOVY-5310: --- > Wrong line/col info for statements with whitespace before EOL > - > > Key: GROOVY-5310 > URL: https://issues.apache.org/jira/browse/GROOVY-5310 > Project: Groovy > Issue Type: Bug > Components: parser-antlr >Reporter: Guillaume Delcroix >Assignee: Daniel Sun >Priority: Minor > Fix For: 3.0 > > > If there are spaces at the end of a line statement, the space is also > accounted in the lin / col info, instead of being the last (non-whitespace) > character of the statement -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (GROOVY-4757) Can't compile method with generic signatures and default visibiliy access
[
https://issues.apache.org/jira/browse/GROOVY-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King reopened GROOVY-4757:
---
> Can't compile method with generic signatures and default visibiliy access
> -
>
> Key: GROOVY-4757
> URL: https://issues.apache.org/jira/browse/GROOVY-4757
> Project: Groovy
> Issue Type: Bug
> Components: parser-antlr
>Affects Versions: 1.7.10
>Reporter: Andres Almiray
>Assignee: Daniel Sun
> Fix For: 3.0
>
>
> The following script results in a compilation error
> {code}
> class Foo {
> void foo(T t) {}
> }
> f = new Foo()
> // compiler output
> 1 compilation error:
> unexpected token: < at line: 2, column: 5
> {code}
> Adding a visibility accessor makes it work
> {code}
> class Foo {
> public void foo(T t) {}
> }
> f = new Foo()
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (GROOVY-4095) Labeled statements have wrong source position
[
https://issues.apache.org/jira/browse/GROOVY-4095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King reopened GROOVY-4095:
---
> Labeled statements have wrong source position
> -
>
> Key: GROOVY-4095
> URL: https://issues.apache.org/jira/browse/GROOVY-4095
> Project: Groovy
> Issue Type: Bug
> Components: parser
>Affects Versions: 1.7.1
>Reporter: Peter Niederwieser
>Assignee: Daniel Sun
> Fix For: 3.0
>
>
> Example:
> {code}
> mylabel:
> foo()
> {code}
> Source position of this statement is [1,8]-[1,9], which is the position of
> the ':' token. Same for all other labeled statements I've checked.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (GROOVY-3898) Allow the specification of types when initializing multiple iteration variables in a "for" construct
[
https://issues.apache.org/jira/browse/GROOVY-3898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King reopened GROOVY-3898:
---
> Allow the specification of types when initializing multiple iteration
> variables in a "for" construct
>
>
> Key: GROOVY-3898
> URL: https://issues.apache.org/jira/browse/GROOVY-3898
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler, parser, parser-antlr, syntax
>Affects Versions: 1.6.5, 1.7-beta-2
>Reporter: Ed Clark
>Assignee: Daniel Sun
>Priority: Minor
> Fix For: 3.0
>
>
> def( int i, int j) = [0,0] works as a stand alone assignment, but it does not
> work in the initialization portion of a for. For example, while
> for( (i, j)=[0,0]; i<10; {i++; j++ }()){ ... }
> compiles
> for( def( int i, int j)=[0,0]; i<10; {i++; j++ }()){ ... }
> does not.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (GROOVY-8150) Inconsistency in multiple assignment with single variable
[
https://issues.apache.org/jira/browse/GROOVY-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King reopened GROOVY-8150:
---
> Inconsistency in multiple assignment with single variable
> -
>
> Key: GROOVY-8150
> URL: https://issues.apache.org/jira/browse/GROOVY-8150
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.0-alpha-1, 2.4.10
>Reporter: Daniil Ovchinnikov
>Assignee: Daniel Sun
> Fix For: 3.0
>
>
> {code}
> def a
> def b = [1]
> a = b
> println "${a} : ${a.class}" // [1] : class java.util.ArrayList
> (a) = b
> println "${a} : ${a.class}" // 1 : class java.lang.Integer
> ((a)) = b
> println "${a} : ${a.class}" // [1] : class java.util.ArrayList
> {code}
> This is confusing. Here are options:
> 1. {{((a)) = b}} should be failed to parse.
> 2. {{((a)) = b}} should behave like {{(a) = b}}, i.e. number of parentheses
> should not matter.
> 3. {{((a)) = b}} and {{(a) = b}} should behave like {{a = b}}. This will
> match the following case also:
> {code}
> class A { def myField }
> def a = new A()
> def b = [1]
> a.myField = b
> assert a.myField == [1]
> (a.myField) = b
> assert a.myField == [1]
> ((a.myField)) = b
> assert a.myField == [1]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (GROOVY-8102) Does/could Groovy support multiple variable definitions in for loop?
[
https://issues.apache.org/jira/browse/GROOVY-8102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King reopened GROOVY-8102:
---
> Does/could Groovy support multiple variable definitions in for loop?
>
>
> Key: GROOVY-8102
> URL: https://issues.apache.org/jira/browse/GROOVY-8102
> Project: Groovy
> Issue Type: Question
> Components: Compiler
>Reporter: Eric Milles
>Assignee: Daniel Sun
>Priority: Minor
> Fix For: 3.0
>
>
> I ask this because it has been causing a lot of headaches when we convert
> Java files to Groovy. This form seems to fail and seems reasonably useful:
> {code}
> for (int i = 0, n = list.length; i < n; i +=1) {
> {code}
> It seems the definition of two or more variables in the for initializer is
> not supported.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (GROOVY-4761) Incorrect source location for method call expression
[
https://issues.apache.org/jira/browse/GROOVY-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King reopened GROOVY-4761:
---
> Incorrect source location for method call expression
>
>
> Key: GROOVY-4761
> URL: https://issues.apache.org/jira/browse/GROOVY-4761
> Project: Groovy
> Issue Type: Bug
> Components: parser, parser-antlr
>Affects Versions: 1.8-rc-2
>Reporter: Andrew Eisenberg
>Assignee: Daniel Sun
> Fix For: 3.0
>
>
> In this class, the source location for the StaticMethodCallExpression is
> incorrect. The start column coincides with the column for '3' and the end
> includes the whitespace until the comment starts.
> {code}
> class StaticTrying {
>
> public static Class staticMethod(arg) {
>
> }
>
> def foo() {
> def a = staticMethod 3 // extra whitespace
> }
> }
> {code}
> I'm not too concerned about the invalid end column, but the start column
> problem is affecting Groovy-Eclipse.
> I delved a little bit into this. Here is when the situation happens:
> # when the method declaration takes 1 or more parameters
> # the method declaration can be either static or non-static
> # the method call takes exactly 1 argument
> # does not use parens
> # is part of a declaration expression.
> Because of parts 4 and 5, this problem can only occur on Groovy 1.8 because
> on 1.7 it would be a parsing error.
> I tracked this down to an invalid source location for the Antlr AST node
> being passed into {{AntlrParserPlugin.methodCallExpression()}}.
> I originally reported this bug in GRECLIPSE-1031.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (GROOVY-3791) Array initializer fails
[
https://issues.apache.org/jira/browse/GROOVY-3791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King reopened GROOVY-3791:
---
> Array initializer fails
> ---
>
> Key: GROOVY-3791
> URL: https://issues.apache.org/jira/browse/GROOVY-3791
> Project: Groovy
> Issue Type: New Feature
> Components: syntax
>Affects Versions: 1.6.4
>Reporter: Steve Buroff
>Assignee: Daniel Sun
>Priority: Minor
> Fix For: 3.0
>
> Attachments: arrayInitializer.groovy, ArrayInitializer.java
>
>
> Run the attached one line file and you get:
>
> C:\Temp>groovyc arrayInitializer.groovy
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed,
> arrayInitializer.groovy: 3: No expression for the array constructor call at
> line
> : 3 column: 29. File: arrayInitializer.groovy @ line 3, column 29.
> String[] junk = new String[]{"xxx"};
>^
> 1 error
> =
> Of course the line is perfectly correct. Try the attached java file which is
> an exact
> copy of the groovy file. It compiles fine.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (GROOVY-7977) Refine the implementation of LRUCache
[ https://issues.apache.org/jira/browse/GROOVY-7977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King reopened GROOVY-7977: --- > Refine the implementation of LRUCache > - > > Key: GROOVY-7977 > URL: https://issues.apache.org/jira/browse/GROOVY-7977 > Project: Groovy > Issue Type: Improvement >Affects Versions: 2.4.7 >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Minor > Fix For: 3.0 > > Attachments: text.html, text.html, text.html, text.html, text.html, > text.html, text.html, text.html > > > I found the LRUCache that Groovy is using is not efficient enough > because it is based on Collections.synchronizedMap, the LRUCache is used by > some important classes(e.g. ProxyGenerator, Closure), so it can impact the > performance somehow. > I propose to replace the implementation with > Caffeine(https://github.com/ben-manes/caffeine), which is a high performance > caching library for Java 8 and licensed under APL2. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (GROOVY-5312) Wrong line/col info for MapEntryExpressions
[ https://issues.apache.org/jira/browse/GROOVY-5312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King reopened GROOVY-5312: --- > Wrong line/col info for MapEntryExpressions > --- > > Key: GROOVY-5312 > URL: https://issues.apache.org/jira/browse/GROOVY-5312 > Project: Groovy > Issue Type: Bug > Components: parser-antlr >Reporter: Guillaume Delcroix >Assignee: Daniel Sun >Priority: Minor > Fix For: 3.0 > > > Whenever there's a map entry, a named parameter, etc, a MapEntryExpression is > used, but the line / col of MapEntryExpression is just surrounding the > column, instead of the whole key + colon + value. > Another problem with MEE is that the value goes up to the next comma or > closing square bracket (including all potential whitespace), instead of just > stopping at the end of the expression or constant. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (GROOVY-4438) Use of an inner enum causes compilation to go into infinite loop
[
https://issues.apache.org/jira/browse/GROOVY-4438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King reopened GROOVY-4438:
---
> Use of an inner enum causes compilation to go into infinite loop
>
>
> Key: GROOVY-4438
> URL: https://issues.apache.org/jira/browse/GROOVY-4438
> Project: Groovy
> Issue Type: Bug
> Components: class generator
>Affects Versions: 1.7.5
>Reporter: Roshan Dawrani
>Assignee: Daniel Sun
>Priority: Critical
> Fix For: 3.0
>
>
> The following piece of code causes the compilation to go into infinite loop
> {code:title=Groovy Compiler - To infinity and beyond..|titleBGColor=#FF}
> enum Outer {
> A, B
> enum Inner{X, Y}
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (GROOVY-8131) Statement continued onto next line is flagged when first character is "="
[ https://issues.apache.org/jira/browse/GROOVY-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King reopened GROOVY-8131: --- > Statement continued onto next line is flagged when first character is "=" > - > > Key: GROOVY-8131 > URL: https://issues.apache.org/jira/browse/GROOVY-8131 > Project: Groovy > Issue Type: Bug > Components: Compiler >Affects Versions: 2.4.5 > Environment: Ubuntu Linux > `uname -a`: > Linux biostar 4.4.0-69-generic #90-Ubuntu SMP Thu Mar 16 16:52:31 UTC 2017 > x86_64 x86_64 x86_64 GNU/Linux >Reporter: Richard Elkins >Assignee: Daniel Sun >Priority: Minor > Fix For: 3.0 > > Attachments: grbug.java > > > Source code attached (grbug.java). > `javac` v8 compiles variable declarations s1, s2, and s3 successfully. > `groovyc` flags s3: > "unexpected token: = @ line 9, column 3." -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (GROOVY-5309) Wrong line/col info for binary expressions
[
https://issues.apache.org/jira/browse/GROOVY-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King reopened GROOVY-5309:
---
> Wrong line/col info for binary expressions
> --
>
> Key: GROOVY-5309
> URL: https://issues.apache.org/jira/browse/GROOVY-5309
> Project: Groovy
> Issue Type: Bug
> Components: parser-antlr
>Reporter: Guillaume Delcroix
>Assignee: Daniel Sun
>Priority: Minor
> Fix For: 3.0
>
>
> {code}
> assert annotationsOfIdField[0]instanceof Id
> {code}
> The binary expression between the assert and instanceof: the end of the line
> / col info is right before instance of, instead of being after the last
> closing square bracket
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (GROOVY-7772) Class. had better to have same meaning of Class::instanceMethod of Java8
[
https://issues.apache.org/jira/browse/GROOVY-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King reopened GROOVY-7772:
---
> Class. had better to have same meaning of
> Class::instanceMethod of Java8
> ---
>
> Key: GROOVY-7772
> URL: https://issues.apache.org/jira/browse/GROOVY-7772
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Affects Versions: 2.4.6
>Reporter: UEHARA Junji
>Assignee: Daniel Sun
>Priority: Minor
> Fix For: 3.0
>
>
> Groovy's operator .& for method is similar functionality to Java8's method
> reference operator ::.
> ||No.||lhs||rhs||meaing of Groovy's .& (Closure) ||meaning of java8's ::
> (FunctionalInterface)||
> |1|instance|instanceMethod| { ..args -> instance.instanceMethod(args) | same
> as groovy |
> |2|Class|staticMethod| { ..args -> Class.staticMethod(args) | same as groovy |
> |3|instance|staticMethod| ERROR groovy.lang.MissingMethodException: | Error
> same as groovy (compile error) |
> |4|Class|instanceMethod|error| Function, where method
> instance method of Class which is declared as ```RetType
> instanceMethod(Args..) {...}```. In other words it is interpreted as a
> function which takes LHS Class as the first parameter which additionally
> inserted to the method.)|
> IMHO, i'd like to propose to change the No 4 pattern semantics of groovy
> same as Java 8 's. Because:
> * You can write:
> {code}
> ["a,b,c"].collect ( String. )
> {code}
> instaed of
> {code}
> ["a,b,c"].collect { it.toUpperCase() }
> {code}
> * Can have correspond operator to java8's ::. which is understandablea and
> needed for Java programmers.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (GROOVY-6336) Support Java 7 ARM blocks
[ https://issues.apache.org/jira/browse/GROOVY-6336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King reopened GROOVY-6336: --- > Support Java 7 ARM blocks > - > > Key: GROOVY-6336 > URL: https://issues.apache.org/jira/browse/GROOVY-6336 > Project: Groovy > Issue Type: New Feature > Components: Compiler >Affects Versions: 2.2.0-beta-2 >Reporter: Tom Dunstan >Assignee: Daniel Sun > Fix For: 3.0 > > > Currently Groovy does not have an equivalent to Java 7's ARM blocks. The > closest is adding a method which takes a closure to the class that you'd like > to be auto-closed (or whatever gives you that resource), and implementing the > closing logic in that method. This has a host of problems: > - It's inefficient, requiring multiple method calls and an extra closure > class over the Java solution > - Since the closure-accepting methods are added ad-hoc, they have different > names and quite possibly subtly different behaviour, particularly around what > happens if an exception is thrown during the closing. By contrast this is > well defined in Java 7 so a programmer doesn't have to go hunting for > documentation or source code on the method that they're calling > - If you are trying to work with an existing Java library rather than Groovy > code, you're out of luck, since short of metaclass hacking you won't be able > to add a wrapper method anyway > It would also be nice to keep Groovy and Java syntax as consistent as > possible to ease porting between the two. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (GROOVY-5313) Wrong line/col info for SpreadMapExpressions
[
https://issues.apache.org/jira/browse/GROOVY-5313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King reopened GROOVY-5313:
---
> Wrong line/col info for SpreadMapExpressions
>
>
> Key: GROOVY-5313
> URL: https://issues.apache.org/jira/browse/GROOVY-5313
> Project: Groovy
> Issue Type: Bug
> Components: parser-antlr
>Reporter: Guillaume Delcroix
>Assignee: Daniel Sun
>Priority: Minor
> Fix For: 3.0
>
>
> {code}
> def m = [a :1 , b: 2 ]
> def map = [abc: 1, bcd: 2, *:m , cde: 3]
> {code}
> The SpreadMapExpression highlights just the star *, and the m variable is
> highlighted till the comma, instead of just the m character (ie. including
> further whitespace).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (GROOVY-6038) Ability to declare inner annotation types
[
https://issues.apache.org/jira/browse/GROOVY-6038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King reopened GROOVY-6038:
---
> Ability to declare inner annotation types
> -
>
> Key: GROOVY-6038
> URL: https://issues.apache.org/jira/browse/GROOVY-6038
> Project: Groovy
> Issue Type: Bug
> Components: syntax
>Reporter: Maxim Medvedev
>Assignee: Daniel Sun
> Fix For: 3.0
>
>
> {code}
> @interface Upper {
> @interface Inner {}
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (GROOVY-4762) Numbers as properties in command expressions
[
https://issues.apache.org/jira/browse/GROOVY-4762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King reopened GROOVY-4762:
---
> Numbers as properties in command expressions
>
>
> Key: GROOVY-4762
> URL: https://issues.apache.org/jira/browse/GROOVY-4762
> Project: Groovy
> Issue Type: Bug
> Components: parser
>Affects Versions: 1.8-rc-3
>Reporter: Maxim Medvedev
>Assignee: Daniel Sun
> Fix For: 3.0
>
>
> It is allowed not to surround numbers with quotes in command expressions if
> they are used as properties.
> Is it bug or feature?
>
> {code}
> def get123() {2}
> def foo(i) {this}
> def a = foo(2).'123'
> def b = foo 2 123
> println a
> println b
> {code}
> But if you rename get123() to get123a() the line will throw an exception.
> {code}
> def b = foo 2 123a
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (GROOVY-4811) exception while compiling annotation type
[
https://issues.apache.org/jira/browse/GROOVY-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-4811.
-
> exception while compiling annotation type
> -
>
> Key: GROOVY-4811
> URL: https://issues.apache.org/jira/browse/GROOVY-4811
> Project: Groovy
> Issue Type: Bug
> Components: parser-antlr
>Affects Versions: 1.8-rc-3, 2.4.0-beta-3
>Reporter: Maxim Medvedev
>Assignee: Paul King
> Fix For: 2.5.0-alpha-1
>
>
> {code}
> @interface Inter {
> String[] bar() default "1"
> }
> {code}
> While compiling this annotation type the compiler throws
> java.lang.ClassCastException: org.codehaus.groovy.ast.expr.ConstantExpression
> cannot be cast to org.codehaus.groovy.ast.expr.ListExpression
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitAnnotationDefaultExpression(AsmClassGenerator.java:316)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitAnnotationDefault(AsmClassGenerator.java:350)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:259)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:123)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:366)
> at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1056)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:50)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitClass(AsmClassGenerator.java:171)
> at
> org.codehaus.groovy.control.CompilationUnit$13.call(CompilationUnit.java:763)
> at
> org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:957)
> at
> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:542)
> at
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:520)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:497)
> at
> org.jetbrains.groovy.compiler.rt.GroovyCompilerWrapper.compile(GroovyCompilerWrapper.java:43)
> at
> org.jetbrains.groovy.compiler.rt.GroovycRunner.main(GroovycRunner.java:128)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> com.intellij.rt.execution.CommandLineWrapper.main(CommandLineWrapper.java:75)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (GROOVY-8131) Statement continued onto next line is flagged when first character is "="
[ https://issues.apache.org/jira/browse/GROOVY-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-8131. - > Statement continued onto next line is flagged when first character is "=" > - > > Key: GROOVY-8131 > URL: https://issues.apache.org/jira/browse/GROOVY-8131 > Project: Groovy > Issue Type: Bug > Components: Compiler >Affects Versions: 2.4.5 > Environment: Ubuntu Linux > `uname -a`: > Linux biostar 4.4.0-69-generic #90-Ubuntu SMP Thu Mar 16 16:52:31 UTC 2017 > x86_64 x86_64 x86_64 GNU/Linux >Reporter: Richard Elkins >Assignee: Daniel Sun >Priority: Minor > Fix For: 3.0 > > Attachments: grbug.java > > > Source code attached (grbug.java). > `javac` v8 compiles variable declarations s1, s2, and s3 successfully. > `groovyc` flags s3: > "unexpected token: = @ line 9, column 3." -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (GROOVY-7750) @Lazy allows instantiation of abstract class
[
https://issues.apache.org/jira/browse/GROOVY-7750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-7750.
-
> @Lazy allows instantiation of abstract class
>
>
> Key: GROOVY-7750
> URL: https://issues.apache.org/jira/browse/GROOVY-7750
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.4.4
>Reporter: Johann
>Assignee: Paul King
>Priority: Minor
> Labels: usability
> Fix For: 2.5.0-alpha-1
>
>
> Given this code:
> {code:java}
> @Lazy
> Foo foo
> abstract class Foo {}
> {code}
> You'll get:
> {code}
> java.lang.InstantiationException
> at
> sun.reflect.InstantiationExceptionConstructorAccessorImpl.newInstance(InstantiationExceptionConstructorAccessorImpl.java:48)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at
> org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:80)
> at
> org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:60)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:235)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:239)
> {code}
> This isn't really helpful. If I mistype a method name, Groovy will help me
> out with suggestions, why not here?
> MODIFICATION by blackdrag:
> @Lazy should recognize this and fail compilation to avoid the initialization
> of an abstract class.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (GROOVY-7540) Add a method to StringGroovyMethods for replacing String pairs supplied as a Map
[
https://issues.apache.org/jira/browse/GROOVY-7540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-7540.
-
> Add a method to StringGroovyMethods for replacing String pairs supplied as a
> Map
>
>
> Key: GROOVY-7540
> URL: https://issues.apache.org/jira/browse/GROOVY-7540
> Project: Groovy
> Issue Type: Improvement
>Reporter: Jochen Kemnade
>Assignee: Paul King
>Priority: Minor
> Fix For: 2.5.0-alpha-1
>
>
> It should be possible to use a map with {{collectReplacements}}, like in
> {code}
> "f006ar".collectReplacements(["0":"o", "6":"b"])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (GROOVY-6617) joint compiler fails to compile groovy class implemented java interface
[
https://issues.apache.org/jira/browse/GROOVY-6617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-6617.
-
> joint compiler fails to compile groovy class implemented java interface
> ---
>
> Key: GROOVY-6617
> URL: https://issues.apache.org/jira/browse/GROOVY-6617
> Project: Groovy
> Issue Type: Bug
> Components: Stub generator / Joint compiler
>Affects Versions: 1.8.6, 2.2.2, 2.3.0, 2.3.1, 2.3.2, 2.3.3, 2.3.4, 2.3.5,
> 2.3.6, 2.3.7, 2.4.6, 2.4.8, 2.4.9, 2.4.10, 2.4.11
> Environment: linux x86-64
> oracle jdk 1.6.0.45, oracle jdk 1.8.0.121
>Reporter: Igor E. Poteryaev
>Assignee: Paul King
>Priority: Minor
> Fix For: 2.5.0-alpha-1
>
> Attachments: groovy-joint-compiler-bug-again.tar,
> groovy-joint-compiler-bug.tar
>
>
> When groovy class implements java interface located in other package with
> method returning array of java objects (not primitive), joint compilation
> fails with org.codehaus.groovy.control.MultipleCompilationErrorsException
> Running joint compiler again compiles this groovy class successfully.
> Attached file contains example files and script to run groovyc in joint
> compiler mode.
> Run ./joint-compile.sh - MultipleCompilationErrorsException
> Run it again - success.
> To reproduce please remove created *.class files
> Reproduced - always.
> Workaround: add package name of returned java class to groovy method
> {code}
> public foo.JavaDataObject[] ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (GROOVY-7606) Upgrade gradle to 2.7
[ https://issues.apache.org/jira/browse/GROOVY-7606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-7606. - > Upgrade gradle to 2.7 > - > > Key: GROOVY-7606 > URL: https://issues.apache.org/jira/browse/GROOVY-7606 > Project: Groovy > Issue Type: Task >Reporter: Pascal Schumacher >Assignee: Pascal Schumacher >Priority: Minor > Fix For: 2.5.0-alpha-1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (GROOVY-7479) Groovy should provide "inits" and "tails" DGM methods for lists
[
https://issues.apache.org/jira/browse/GROOVY-7479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-7479.
-
> Groovy should provide "inits" and "tails" DGM methods for lists
> ---
>
> Key: GROOVY-7479
> URL: https://issues.apache.org/jira/browse/GROOVY-7479
> Project: Groovy
> Issue Type: New Feature
> Components: groovy-jdk
>Reporter: Paul King
>Assignee: Paul King
> Fix For: 2.5.0-alpha-1
>
>
> Similar behaviour to Scala:
> http://www.scala-lang.org/api/2.10.3/index.html#scala.collection.immutable.List
> The relevant bits:
> {{inits}}: Iterates over the init values of this list: the first value will
> be this list and the final one will be an empty list, with the intervening
> values the results of successive applications of init.
> {{tails}}: Iterates over the tail values of this list: the first value will
> be this list and the final one will be an empty list, with the intervening
> values the results of successive applications of tail.
> Rather than Scala's Iterable, I think just returning a list will be fine to
> match other methods like {{combinations}}. If efficiency is a concern we
> could return views (subList) from perhaps a copy of the incoming items.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (GROOVY-7636) NumberMath.getMath suboptimal choice for custom Numbers
[
https://issues.apache.org/jira/browse/GROOVY-7636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-7636.
-
> NumberMath.getMath suboptimal choice for custom Numbers
> ---
>
> Key: GROOVY-7636
> URL: https://issues.apache.org/jira/browse/GROOVY-7636
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Reporter: Thibault Kruse
>Assignee: Paul King
>Priority: Minor
> Fix For: 2.5.0-alpha-1
>
>
> When implementing the java.lang.Number interface with a custom class, the
> groovy NumberMath class file's instanceof check do not find a math, and it
> defaults to IntegerMath. I believe the default should be BigDecimal for
> best-effort compatibility.
> Also when comparing BigDecimal to a true Float or Double, FloatingPointMath
> is used, not BigDecimalMath.
> to reproduce:
> {code}
> static class MyNumber extends Number {
> def n
> MyNumber(n) {
> this.n = n
> }
> int intValue(){n}
> long longValue(){n}
> float floatValue(){n}
> double doubleValue(){n}
> int hashCode(){-n}
> boolean equals(other) {
> if (other instanceof MyNumber) { return n==other.n}
> return false
> }
> String toString() {return Double.toString(floatValue())}
> }
> void testGetMathCustom() {
> //assert getMath(50.0G, Float.valueOf("1.0")) ==
> BigDecimalMath.INSTANCE;
> //assert getMath(50G, Float.valueOf("1.0")) ==
> BigDecimalMath.INSTANCE;
> MyNumber num = new MyNumber(42);
> assert getMath(num) == BigDecimalMath.INSTANCE;
> assert getMath(num, 25) == BigDecimalMath.INSTANCE;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (GROOVY-6537) Support getParsedOptionValue() in OptionAccessor.getProperty()
[
https://issues.apache.org/jira/browse/GROOVY-6537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-6537.
-
> Support getParsedOptionValue() in OptionAccessor.getProperty()
> --
>
> Key: GROOVY-6537
> URL: https://issues.apache.org/jira/browse/GROOVY-6537
> Project: Groovy
> Issue Type: Improvement
> Components: command line processing
>Affects Versions: 2.2.1
>Reporter: Björn Kautler
>Assignee: Paul King
> Labels: CliBuilder
> Fix For: 2.5.0-alpha-1
>
>
> It would be nice if OptionAccessor.getProperty() would also use the
> getParsedOptionValue() before falling back to getOptionValue()
> Currently to use a parsed option value you have to do something like
> {code}
> def cliBuilder = new CliBuilder()
> cliBuilder.d longOpt: 'directory', args: 1, type: File, 'd option'
> def arguments = cliBuilder.parse args
> if (!arguments) {
> System.exit 1
> }
> def directory
> if (arguments.directory) {
>directory = arguments.getParsedOptionValue 'directory'
> } else {
>directory = System.properties.'user.dir' as File
> }
> {code}
> if would be nicer to instead just do
> {code}
> def cliBuilder = new CliBuilder()
> cliBuilder.d longOpt: 'directory', args: 1, type: File, 'd option'
> def arguments = cliBuilder.parse args
> if (!arguments) {
> System.exit 1
> }
> def directory
> if (arguments.directory) {
>directory = arguments.directory
> } else {
>directory = System.properties.'user.dir' as File
> }
> {code}
> I think something along the lines of changing
> {code}
> def getProperty(String name) {
> def methodname = 'getOptionValue'
> if (name.size() > 1 && name.endsWith('s')) {
> def singularName = name[0..-2]
> if (hasOption(singularName)) {
> name = singularName
> methodname += 's'
> }
> }
> if (name.size() == 1) name = name as char
> def result = InvokerHelper.getMetaClass(inner).invokeMethod(inner,
> methodname, name)
> if (null == result) result = inner.hasOption(name)
> if (result instanceof String[]) result = result.toList()
> return result
> }
> {code}
> to
> {code}
> def getProperty(String name) {
> def methodname = 'getOptionValue'
> if (name.size() > 1 && name.endsWith('s')) {
> def singularName = name[0..-2]
> if (hasOption(singularName)) {
> name = singularName
> methodname += 's'
> }
> }
> if (name.size() == 1) name = name as char
> def result = inner.getParsedOptionValue(name)
> if (null == result) result =
> InvokerHelper.getMetaClass(inner).invokeMethod(inner, methodname, name)
> if (null == result) result = inner.hasOption(name)
> if (result instanceof String[]) result = result.toList()
> return result
> }
> {code}
> should do what I mean, as getParsedOptionValue() returns null if no type is
> set or the type is unknown to the TypeHandler.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (GROOVY-8041) The templating engine does not handle properly the binding parameters that contains dot ('.') character
[
https://issues.apache.org/jira/browse/GROOVY-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-8041.
-
> The templating engine does not handle properly the binding parameters that
> contains dot ('.') character
> ---
>
> Key: GROOVY-8041
> URL: https://issues.apache.org/jira/browse/GROOVY-8041
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.7
>Reporter: Bence Takács
>Assignee: Jochen Theodorou
>
> The templating engine does not handle properly the binding parameters that
> contains dot ('.') character
> The below script throws an exception while the assertion passes:
> def template = new groovy.text.SimpleTemplateEngine().createTemplate('Testing
> ${a.b}')
> def params = ['a.b':'working']
> assert params['a.b']
> println template.make(params)
> "groovy.lang.MissingPropertyException: No such property: a for class:
> SimpleTemplateScript22
> at SimpleTemplateScript22.run(SimpleTemplateScript22.groovy:1)
> at Script1.run(Script1.groovy:5)"
> The issue is valid for also StreamingTemplateEngine and GStringTemplateEngine
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (GROOVY-7521) Support Generics with def
[
https://issues.apache.org/jira/browse/GROOVY-7521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-7521.
-
> Support Generics with def
> -
>
> Key: GROOVY-7521
> URL: https://issues.apache.org/jira/browse/GROOVY-7521
> Project: Groovy
> Issue Type: Bug
>Reporter: Suminda Dharmasena
>Assignee: Andres Almiray
>Priority: Minor
>
> You cannot use generics with def.
> {{code}}
> def f(Map i) { ... }
> {{code}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (GROOVY-2324) grammar forces usage of lowercase names for commands
[ https://issues.apache.org/jira/browse/GROOVY-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-2324. - > grammar forces usage of lowercase names for commands > > > Key: GROOVY-2324 > URL: https://issues.apache.org/jira/browse/GROOVY-2324 > Project: Groovy > Issue Type: Sub-task > Components: groovy-runtime >Reporter: Jochen Theodorou >Assignee: Daniel Sun > Fix For: 3.0 > > > any command "foo bar" where foo starts with an uppercase letter leads the > grammar to recognize that "foo" as a class. we should see if that is really > needed -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (GROOVY-6396) same linkedlist code different behavior between groovy and java
[
https://issues.apache.org/jira/browse/GROOVY-6396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-6396.
-
> same linkedlist code different behavior between groovy and java
> ---
>
> Key: GROOVY-6396
> URL: https://issues.apache.org/jira/browse/GROOVY-6396
> Project: Groovy
> Issue Type: Bug
> Components: jdk conflict
>Reporter: boshi
>Assignee: Paul King
> Labels: breaking
> Fix For: 2.5.0-alpha-1
>
>
> I am using `linkedlist` as a stack in groovy
> as doc says, `pop()` take elm from the first
> Stack Method Equivalent Deque Method
> push(e) addFirst(e)
> pop() removeFirst()
> so a `linkedlist` [1,2,3] should pop() 1 2 3
> and it does in Java, but does NOT in groovy. WHY?
> test below
> {code:title=A.java}
> import java.util.*;
>
> public class A{
>
>
> public static void main(String[] args){
>
> String[] x = "1/2/3/".split("/");
> LinkedList stack = new LinkedList(Arrays.asList(x));
> System.out.println(stack.pop());
> }
> }
> {code}
> compile and run
> {noformat}
> $ javac A.java
> $ java A
> 1
> {noformat}
> runing in groovy
> {noformat}
> $ ln -s A.java A.groovy
> $ groovy A.groovy
> 3
> {noformat}
> here is my java and groovy version
> {noformat}
> $ java -version
> java version "1.6.0_51"
> Java(TM) SE Runtime Environment (build 1.6.0_51-b11-457-11M4509)
> Java HotSpot(TM) 64-Bit Server VM (build 20.51-b01-457, mixed mode)
> $ groovy -version
> Groovy Version: 2.1.5 JVM: 1.6.0_51 Vendor: Apple Inc. OS: Mac OS X
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (GROOVY-8150) Inconsistency in multiple assignment with single variable
[
https://issues.apache.org/jira/browse/GROOVY-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-8150.
-
> Inconsistency in multiple assignment with single variable
> -
>
> Key: GROOVY-8150
> URL: https://issues.apache.org/jira/browse/GROOVY-8150
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.0-alpha-1, 2.4.10
>Reporter: Daniil Ovchinnikov
>Assignee: Daniel Sun
> Fix For: 3.0
>
>
> {code}
> def a
> def b = [1]
> a = b
> println "${a} : ${a.class}" // [1] : class java.util.ArrayList
> (a) = b
> println "${a} : ${a.class}" // 1 : class java.lang.Integer
> ((a)) = b
> println "${a} : ${a.class}" // [1] : class java.util.ArrayList
> {code}
> This is confusing. Here are options:
> 1. {{((a)) = b}} should be failed to parse.
> 2. {{((a)) = b}} should behave like {{(a) = b}}, i.e. number of parentheses
> should not matter.
> 3. {{((a)) = b}} and {{(a) = b}} should behave like {{a = b}}. This will
> match the following case also:
> {code}
> class A { def myField }
> def a = new A()
> def b = [1]
> a.myField = b
> assert a.myField == [1]
> (a.myField) = b
> assert a.myField == [1]
> ((a.myField)) = b
> assert a.myField == [1]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (GROOVY-7862) Statically compiled calls to protected methods of an outerclass' superclass result in IllegalAccessErrors
[
https://issues.apache.org/jira/browse/GROOVY-7862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-7862.
-
> Statically compiled calls to protected methods of an outerclass' superclass
> result in IllegalAccessErrors
> -
>
> Key: GROOVY-7862
> URL: https://issues.apache.org/jira/browse/GROOVY-7862
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.7
>Reporter: Shil Sinha
>Assignee: Shil Sinha
> Fix For: 2.5.0-alpha-1
>
>
> Example:
> {code}
> package one;
> public class Base {
> protected int foo() {
> 123
> }
> }
> {code}
> {code}
> package two;
> class SubBase extends Base {
> class Inner {
> int test() {
> foo()
> }
> }
>
> int innerTest() {
> new Inner().test()
> }
> }
> assert new SubBase().innerTest() == 123
> {code}
> The code above will fail with the following error:
> {code}
> java.lang.IllegalAccessError: tried to access method one.Base.foo()I from
> class two.SubBase$Inner
> {code}
> This is due to bridge methods for protected methods not being correctly
> generated (and subsequently used when writing protected method invocations.)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (GROOVY-7488) Depth 1st and Breath 1st taking a closure
[
https://issues.apache.org/jira/browse/GROOVY-7488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-7488.
-
> Depth 1st and Breath 1st taking a closure
> -
>
> Key: GROOVY-7488
> URL: https://issues.apache.org/jira/browse/GROOVY-7488
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-jdk
>Reporter: Suminda Dharmasena
>Assignee: Paul King
>Priority: Minor
> Fix For: 2.5.0-alpha-1
>
>
> E.g.
> n.depthFirst { level, node -> ... }
> NB: there is level
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (GROOVY-5426) ObjectRange.iterator() is reliant on size()
[
https://issues.apache.org/jira/browse/GROOVY-5426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-5426.
-
> ObjectRange.iterator() is reliant on size()
> ---
>
> Key: GROOVY-5426
> URL: https://issues.apache.org/jira/browse/GROOVY-5426
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-jdk
>Affects Versions: 1.8.6
>Reporter: Tim Yates
>Assignee: Paul King
> Fix For: 2.5.0-alpha-1
>
>
> Currently the ObjectRange iterator is reliant on the size of the range.
> If the range is made up of BigInteger or BigDecimal, would it be possible to
> safely change this to call increment or decrement on a current internal value
> until it reaches its destination?
> The problem is exhibited by:
> {code}
> assert [] == (1.0G..2147483648.0G).iterator().take( 2 ).collect()
> {code}
> Where I would expect {{[1, 2]}}
> The problem is that size (being an int) for this range is -2147483648
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (GROOVY-7579) Improve docs for invokeMethod
[ https://issues.apache.org/jira/browse/GROOVY-7579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-7579. - > Improve docs for invokeMethod > - > > Key: GROOVY-7579 > URL: https://issues.apache.org/jira/browse/GROOVY-7579 > Project: Groovy > Issue Type: Documentation > Components: Documentation >Affects Versions: 2.4.5 >Reporter: Aseem Bansal >Assignee: John Wagenleitner > Fix For: 2.4.11 > > > I was reading meta programming documentation when I noticed that "this method > is called when the method you called is not present on a Groovy object" > As per the diagram it is incorrect. It is invoked when methodMissing is not > present. This statement is as per the diagram. > Also as per the answer at this is not an appropriate example > http://stackoverflow.com/questions/19220370/what-is-the-difference-between-invokemethod-and-methodmissing > Saying this because the answer by blackdrag (who I understand is a core > committer to groovy) says that methodMissing should be used instead. > Also the same page mentions "overhead of invokeMethod". It would be nic e to > have a better explanation in the section of invokeMethod itself. > I am not knowledgeable about this so cannot suggest what can be added. But it > would be better to have the explanation in the official docs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (GROOVY-7385) Invalid Integer & Long literals compile when they shouldn't
[ https://issues.apache.org/jira/browse/GROOVY-7385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-7385. - > Invalid Integer & Long literals compile when they shouldn't > --- > > Key: GROOVY-7385 > URL: https://issues.apache.org/jira/browse/GROOVY-7385 > Project: Groovy > Issue Type: Bug > Components: syntax >Affects Versions: 2.4.3 > Environment: Mac OS X >Reporter: Sean Gilligan > Fix For: 2.5.x > > > 2147483648I should be an invalid Integer literal. > 9223372036854775808L should be an invalid Long literal. > Both currently compile (and produce an unexpected value -- well, it would be > the expected value in 2's complement math) > I created some unit tests to show the problem -- not sure if I put them in > the right place, but they do fail as I expect them to. > The Github PR is here: > https://github.com/groovy/groovy-core/pull/657 > The build output is here: > http://ci.groovy-lang.org/viewLog.html?buildId=16410=Groovy_Jdk7Build -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (GROOVY-8088) For @MapConstructor and @TupleConstructor we should provide a default undefined value for better Java compatibility
[ https://issues.apache.org/jira/browse/GROOVY-8088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-8088. - > For @MapConstructor and @TupleConstructor we should provide a default > undefined value for better Java compatibility > --- > > Key: GROOVY-8088 > URL: https://issues.apache.org/jira/browse/GROOVY-8088 > Project: Groovy > Issue Type: Improvement >Reporter: Paul King >Assignee: Paul King > Fix For: 2.5.0-alpha-1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (GROOVY-7772) Class. had better to have same meaning of Class::instanceMethod of Java8
[
https://issues.apache.org/jira/browse/GROOVY-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-7772.
-
> Class. had better to have same meaning of
> Class::instanceMethod of Java8
> ---
>
> Key: GROOVY-7772
> URL: https://issues.apache.org/jira/browse/GROOVY-7772
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Affects Versions: 2.4.6
>Reporter: UEHARA Junji
>Assignee: Daniel Sun
>Priority: Minor
> Fix For: 3.0
>
>
> Groovy's operator .& for method is similar functionality to Java8's method
> reference operator ::.
> ||No.||lhs||rhs||meaing of Groovy's .& (Closure) ||meaning of java8's ::
> (FunctionalInterface)||
> |1|instance|instanceMethod| { ..args -> instance.instanceMethod(args) | same
> as groovy |
> |2|Class|staticMethod| { ..args -> Class.staticMethod(args) | same as groovy |
> |3|instance|staticMethod| ERROR groovy.lang.MissingMethodException: | Error
> same as groovy (compile error) |
> |4|Class|instanceMethod|error| Function, where method
> instance method of Class which is declared as ```RetType
> instanceMethod(Args..) {...}```. In other words it is interpreted as a
> function which takes LHS Class as the first parameter which additionally
> inserted to the method.)|
> IMHO, i'd like to propose to change the No 4 pattern semantics of groovy
> same as Java 8 's. Because:
> * You can write:
> {code}
> ["a,b,c"].collect ( String. )
> {code}
> instaed of
> {code}
> ["a,b,c"].collect { it.toUpperCase() }
> {code}
> * Can have correspond operator to java8's ::. which is understandablea and
> needed for Java programmers.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (GROOVY-5310) Wrong line/col info for statements with whitespace before EOL
[ https://issues.apache.org/jira/browse/GROOVY-5310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-5310. - > Wrong line/col info for statements with whitespace before EOL > - > > Key: GROOVY-5310 > URL: https://issues.apache.org/jira/browse/GROOVY-5310 > Project: Groovy > Issue Type: Bug > Components: parser-antlr >Reporter: Guillaume Delcroix >Assignee: Daniel Sun >Priority: Minor > Fix For: 3.0 > > > If there are spaces at the end of a line statement, the space is also > accounted in the lin / col info, instead of being the last (non-whitespace) > character of the statement -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (GROOVY-5312) Wrong line/col info for MapEntryExpressions
[ https://issues.apache.org/jira/browse/GROOVY-5312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-5312. - > Wrong line/col info for MapEntryExpressions > --- > > Key: GROOVY-5312 > URL: https://issues.apache.org/jira/browse/GROOVY-5312 > Project: Groovy > Issue Type: Bug > Components: parser-antlr >Reporter: Guillaume Delcroix >Assignee: Daniel Sun >Priority: Minor > Fix For: 3.0 > > > Whenever there's a map entry, a named parameter, etc, a MapEntryExpression is > used, but the line / col of MapEntryExpression is just surrounding the > column, instead of the whole key + colon + value. > Another problem with MEE is that the value goes up to the next comma or > closing square bracket (including all potential whitespace), instead of just > stopping at the end of the expression or constant. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (GROOVY-8013) The checking of property names during AST transform attribute processing doesn't take into account includeSuperProperties
[
https://issues.apache.org/jira/browse/GROOVY-8013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-8013.
-
> The checking of property names during AST transform attribute processing
> doesn't take into account includeSuperProperties
> -
>
> Key: GROOVY-8013
> URL: https://issues.apache.org/jira/browse/GROOVY-8013
> Project: Groovy
> Issue Type: Bug
> Components: xforms
>Reporter: Paul King
>Assignee: Paul King
> Fix For: 2.5.0-alpha-1
>
>
> Example shown below is for @ToString but the issue affects numerous xforms:
> {code}
> import groovy.transform.*
> @ToString
> class Foo {
> String baz = 'baz'
> }
> @ToString(includes='baz', includeSuperProperties=true)
> class Bar extends Foo {
> int num = 42
> }
> new Bar().toString()
> // 1 compilation error: Error during @ToString processing: 'includes'
> property 'baz' does not exist.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (GROOVY-6184) Make ClassHelper consistent in how it creates ClassNodes
[
https://issues.apache.org/jira/browse/GROOVY-6184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-6184.
-
> Make ClassHelper consistent in how it creates ClassNodes
>
>
> Key: GROOVY-6184
> URL: https://issues.apache.org/jira/browse/GROOVY-6184
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler
>Reporter: Andrew Eisenberg
>Assignee: Cédric Champeau
> Fix For: 2.4.11
>
>
> The ClassHelper class in almost all cases creates class nodes for its static
> fields using the {{makeWithoutCaching}} method. There are 2 exceptions:
> {{Annotation}} and {{Enum}}. My understanding is that this is a holdover
> from the pre-Java5 days. The problem is that this has huge memory
> ramifications on Groovy-Eclipse. So, I would like to see this changed.
> See this branch for what I am talking about:
> https://github.com/aeisenberg/groovy-core/tree/ClassHelper-ClassNode-generation
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (GROOVY-6319) Canonical annotation should allow property names in toString
[ https://issues.apache.org/jira/browse/GROOVY-6319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-6319. - > Canonical annotation should allow property names in toString > > > Key: GROOVY-6319 > URL: https://issues.apache.org/jira/browse/GROOVY-6319 > Project: Groovy > Issue Type: Improvement > Components: xforms >Reporter: Jeff Storey >Assignee: Paul King >Priority: Minor > Fix For: 2.5.0-alpha-1 > > > It's convenient to be able to use @Canonical instead of @ToString and > @EqualsAndHashCode. @ToString allows you to include property names with > includeNames=true, but @Canonical does not. It would be nice to be able to > print out property names when using @Canonical. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (GROOVY-3791) Array initializer fails
[
https://issues.apache.org/jira/browse/GROOVY-3791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-3791.
-
> Array initializer fails
> ---
>
> Key: GROOVY-3791
> URL: https://issues.apache.org/jira/browse/GROOVY-3791
> Project: Groovy
> Issue Type: New Feature
> Components: syntax
>Affects Versions: 1.6.4
>Reporter: Steve Buroff
>Assignee: Daniel Sun
>Priority: Minor
> Fix For: 3.0
>
> Attachments: arrayInitializer.groovy, ArrayInitializer.java
>
>
> Run the attached one line file and you get:
>
> C:\Temp>groovyc arrayInitializer.groovy
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed,
> arrayInitializer.groovy: 3: No expression for the array constructor call at
> line
> : 3 column: 29. File: arrayInitializer.groovy @ line 3, column 29.
> String[] junk = new String[]{"xxx"};
>^
> 1 error
> =
> Of course the line is perfectly correct. Try the attached java file which is
> an exact
> copy of the groovy file. It compiles fine.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (GROOVY-6090) Reimplement CliBuilder over another CLI API
[ https://issues.apache.org/jira/browse/GROOVY-6090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-6090. - > Reimplement CliBuilder over another CLI API > --- > > Key: GROOVY-6090 > URL: https://issues.apache.org/jira/browse/GROOVY-6090 > Project: Groovy > Issue Type: Wish > Components: command line processing >Affects Versions: 2.1.2 >Reporter: Baruch Sadogursky >Assignee: Paul King >Priority: Minor > Fix For: 2.5.0-alpha-1 > > > current CliBuilder implementation is based on the dead and outdated > commons-cli project, which affects its flexibility, API, design and fimits > its features. > There are better alternatives - commons-cli2, args4j, jcommander, to name a > few. > CLI processing is critical feature for Groovy scripts usability, and lacking > in it drive people away (even devoted Groovy advocates like @russel_winder) > and prevents adoption. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (GROOVY-7607) Upgrade Log4J2 to 2.3
[ https://issues.apache.org/jira/browse/GROOVY-7607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-7607. - > Upgrade Log4J2 to 2.3 > - > > Key: GROOVY-7607 > URL: https://issues.apache.org/jira/browse/GROOVY-7607 > Project: Groovy > Issue Type: Task >Reporter: Pascal Schumacher >Assignee: Pascal Schumacher >Priority: Minor > Fix For: 2.5.0-alpha-1 > > > Upgrade to 2.4 is not possible, as it requires at least Java 7. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (GROOVY-6454) Can't delegate (with the @Delegate annotation) to a method whose name contains a dollar ($) character
[ https://issues.apache.org/jira/browse/GROOVY-6454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-6454. - > Can't delegate (with the @Delegate annotation) to a method whose name > contains a dollar ($) character > - > > Key: GROOVY-6454 > URL: https://issues.apache.org/jira/browse/GROOVY-6454 > Project: Groovy > Issue Type: Bug > Components: Compiler, xforms >Affects Versions: 2.2.0 > Environment: Linux (Ubuntu 12.04), Java SE (Oracle) 1.7.0_45-b18, > Groovy 2.2.0 >Reporter: chocolateboy >Assignee: Paul King > Labels: regression > Fix For: 2.5.0-alpha-1 > > Attachments: dollar_delegate.groovy > > > As of 2.2.0 it's no longer possible to delegate (via the @Delegate > annotation) to a method whose name contains a dollar ($) character. The > attached test case compiles and runs without error under Groovy 2.1.3 and > 2.1.6, but fails to compile with the following error under 2.2.0: > > Caught: groovy.lang.MissingMethodException: No signature of method: > > Delegating.te$t() is applicable for argument types: (java.lang.Integer) > > values: [42] > > Possible solutions: test(java.lang.Integer), wait(), > > getAt(java.lang.String), wait(long), wait(long, int), dump() -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (GROOVY-7961) ObjectRange iterator returns null instead of NoSuchElementException
[
https://issues.apache.org/jira/browse/GROOVY-7961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-7961.
-
> ObjectRange iterator returns null instead of NoSuchElementException
> ---
>
> Key: GROOVY-7961
> URL: https://issues.apache.org/jira/browse/GROOVY-7961
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.7
>Reporter: John Wagenleitner
>Assignee: John Wagenleitner
>Priority: Minor
> Labels: breaking
> Fix For: 2.5.0-alpha-1
>
>
> Calling {{next()}} on an {{ObjectRange}} iterator returns {{null}} when
> {{hasNext{}}} returns false. It should throw {{NoSuchElementException}} to
> adhere to the Iterator contract.
> {code}
> class ObjectRangeItrTest extends GroovyTestCase {
> void testItr() {
> def itr = ('a'..'b').iterator()
> assert itr.next() == 'a'
> assert itr.next() == 'b'
> assert !itr.hasNext()
> shouldFail(NoSuchElementException) {
> println itr.next()
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (GROOVY-8014) @ToString could output properties in a predefined order when 'includes' is used
[
https://issues.apache.org/jira/browse/GROOVY-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-8014.
-
> @ToString could output properties in a predefined order when 'includes' is
> used
> ---
>
> Key: GROOVY-8014
> URL: https://issues.apache.org/jira/browse/GROOVY-8014
> Project: Groovy
> Issue Type: Improvement
> Components: xforms
>Reporter: Paul King
>Assignee: Paul King
> Labels: breaking
> Fix For: 2.5.0-alpha-1
>
>
> Given a class:
> {code}
> class Foo {
> String a, b
> private String c, d
> }
> {code}
> Adding a toString annotation, e.g. {{@ToString(includeFields=true)}} will
> output the properties/fields in an unspecified order - basically the order
> the properties are returned followed by the order that the fields are
> returned. This can be different for different Java versions.
> The proposal is that if {{includes='a,c,b,d'}} is added, then the
> fields/properties will be output in that order. This could be considered a
> breaking change for anyone using 'includes' and relying on the current
> ordering but as mentioned earlier, this is currently different for different
> Java versions and possibly different on different JVMs (e.g. Azul, IBM,
> Oracle, OpenJDK or possibly on different platforms). The proposal will at
> least give a mechanism to have a defined order.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (GROOVY-6928) Support all the Java 6 classes at createSimilarCollection() and createSimilarMap()
[ https://issues.apache.org/jira/browse/GROOVY-6928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-6928. - > Support all the Java 6 classes at createSimilarCollection() and > createSimilarMap() > -- > > Key: GROOVY-6928 > URL: https://issues.apache.org/jira/browse/GROOVY-6928 > Project: Groovy > Issue Type: Improvement > Components: groovy-jdk >Reporter: Yu Kobayashi >Assignee: Cédric Champeau > Fix For: 2.5.0-alpha-1 > > > Added support of all the Java 6 classes in createSimilarCollection() and > createSimilarMap(). > Only Java 1.4 classes were supported. > The pull request is here. > https://github.com/groovy/groovy-core/pull/478 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (GROOVY-4255) BUG! exception in phase 'class generation' ... SpreadExpression should not be visited here
[
https://issues.apache.org/jira/browse/GROOVY-4255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-4255.
-
> BUG! exception in phase 'class generation' ... SpreadExpression should not be
> visited here
> --
>
> Key: GROOVY-4255
> URL: https://issues.apache.org/jira/browse/GROOVY-4255
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 1.7.3, 2.4.0-rc-1
>Reporter: André
>Assignee: Paul King
> Fix For: 2.5.0-alpha-1
>
> Attachments: 4255_v18x.patch
>
>
> this code produces the error:
> println [*it.albumId.text().split(",")]
> BUG! exception in phase 'class generation' in source unit 'Script1.groovy'
> SpreadExpression should not be visited here
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (GROOVY-7792) Update ASM to 5.1
[ https://issues.apache.org/jira/browse/GROOVY-7792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-7792. - > Update ASM to 5.1 > - > > Key: GROOVY-7792 > URL: https://issues.apache.org/jira/browse/GROOVY-7792 > Project: Groovy > Issue Type: Task >Reporter: Pascal Schumacher >Assignee: Pascal Schumacher > Fix For: 2.5.0-alpha-1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (GROOVY-7977) Refine the implementation of LRUCache
[ https://issues.apache.org/jira/browse/GROOVY-7977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-7977. - > Refine the implementation of LRUCache > - > > Key: GROOVY-7977 > URL: https://issues.apache.org/jira/browse/GROOVY-7977 > Project: Groovy > Issue Type: Improvement >Affects Versions: 2.4.7 >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Minor > Fix For: 3.0 > > Attachments: text.html, text.html, text.html, text.html, text.html, > text.html, text.html, text.html > > > I found the LRUCache that Groovy is using is not efficient enough > because it is based on Collections.synchronizedMap, the LRUCache is used by > some important classes(e.g. ProxyGenerator, Closure), so it can impact the > performance somehow. > I propose to replace the implementation with > Caffeine(https://github.com/ben-manes/caffeine), which is a high performance > caching library for Java 8 and licensed under APL2. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (GROOVY-7426) Add "Clear Output" Toolbar button to Groovy Console
[ https://issues.apache.org/jira/browse/GROOVY-7426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-7426. - > Add "Clear Output" Toolbar button to Groovy Console > --- > > Key: GROOVY-7426 > URL: https://issues.apache.org/jira/browse/GROOVY-7426 > Project: Groovy > Issue Type: Improvement > Components: Groovy Console >Reporter: Adrian A. >Assignee: Paul King >Priority: Minor > Labels: contributers-welcome > Fix For: 2.5.0-alpha-1 > > > Please add a toolbar button for the "Clear Output" action too. > After the "Execute Groovy Script", it is the most used action in the console. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (GROOVY-7696) Bug with @TypeChecked and generic properties of Java classes used in binary expressions
[
https://issues.apache.org/jira/browse/GROOVY-7696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-7696.
-
> Bug with @TypeChecked and generic properties of Java classes used in binary
> expressions
> ---
>
> Key: GROOVY-7696
> URL: https://issues.apache.org/jira/browse/GROOVY-7696
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.4.5
>Reporter: Marc Ewert
>Assignee: Paul King
> Fix For: 2.4.6
>
>
> I have the following two Java Classes:
> {code}
> import java.math.BigDecimal;
> public abstract class Attribute {
> private BigDecimal numericValue;
> public abstract T getValue();
> public abstract void setValue(T value);
> public BigDecimal getNumericValue() {
> return numericValue;
> }
> public void setNumericValue(BigDecimal numericValue) {
> this.numericValue = numericValue;
> }
> }
> {code}
> {code}
> import java.math.BigDecimal;
> public class LongAttribute extends Attribute {
> public Long getValue() {
> return getNumericValue() == null ? null :
> getNumericValue().longValue();
> }
> public void setValue(Long value) {
> setNumericValue(BigDecimal.valueOf(value));
> }
> }
> {code}
> And a Groovy test class with @TypeChecked annotation:
> {code}
> import groovy.transform.TypeChecked
> @TypeChecked
> class Scratch {
> public static void main(String[] args) {
> LongAttribute attr = new LongAttribute();
> attr.value = 0L
> println "getter: " + attr.value
> println "smaller as 0? " + (attr.value < 0)
> }
> }
> {code}
> Compiling the class leads to the error message:
> {code}
> Error:(10, 36) Groovyc: [Static type checking] - Cannot find matching method
> java.lang.Object#compareTo(int). Please check if the declared type is right
> and if the method exists.
> {code}
> Removing the @TypeChecked annotation or moving the Java classes into the
> Groovy class as static inner classes suppresses the compilation error.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
