[jira] [Commented] (GROOVY-8455) @TupleConstructor gives wrong ordering when includeSuperFields is set
[
https://issues.apache.org/jira/browse/GROOVY-8455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16334255#comment-16334255
]
ASF GitHub Bot commented on GROOVY-8455:
GitHub user paulk-asert opened a pull request:
https://github.com/apache/groovy/pull/655
GROOVY-8455: @TupleConstructor gives wrong ordering when includeSuper…
…Fields is set
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/paulk-asert/groovy groovy8455
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/655.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #655
commit bdaea09057cc2428df67441df4770c0b196c6f0d
Author: paulk
Date: 2018-01-22T13:28:56Z
GROOVY-8455: @TupleConstructor gives wrong ordering when includeSuperFields
is set
> @TupleConstructor gives wrong ordering when includeSuperFields is set
> -
>
> Key: GROOVY-8455
> URL: https://issues.apache.org/jira/browse/GROOVY-8455
> Project: Groovy
> Issue Type: Bug
>Reporter: Paul King
>Priority: Major
>
> When the {{includeSuperProperties}} flag is set, @TupleConstructor includes
> those properties and historically has done it with properties from parent
> classes first. This is also true if just the {{includeSuperFields}} flag is
> set. When both flags are set the intention was to keep this ordering but
> currently that is not the case.
> Here is an example:
> {code}
> import groovy.transform.*
> class Foopubf{}
> class Foop{}
> class Foopp{}
> class Foo {
> Foop foop1
> public Foopubf foopubf
> protected Short fooProtField = 42
> void setFooPseudoProp(Foopp fpp) {}
> Foopp getFooPseudoProp() { null }
> }
> class Barpubf{}
> class Barp{}
> class Barpp{}
> class Bar extends Foo {
> Barp barp
> public Barpubf barpubf
> protected Integer barProtField = 150
> Barpp getBarPseudoProp() { null }
> void setBarPseudoProp(Barpp bpp) { }
> }
> class Bazpubf{}
> class Bazp{}
> class Bazpp{}
> @TupleConstructor(includeFields=true, includeSuperFields=true,
> includeSuperProperties=true)
> class Baz extends Bar {
> Bazp bazp
> public Bazpubf bazpubf
> protected Long bazProtField = 2000L
> Bazpp getBazPseudoProp() { null }
> void setBazPseudoProp(Bazpp bpp) { }
> }
> Baz.constructors.each {
> println it
> }
> {code}
> which produces:
> {code}
> public
> Baz(Foop,Barp,Foopubf,java.lang.Short,Barpubf,java.lang.Integer,Bazp,Bazpubf,java.lang.Long)
> public
> Baz(Foop,Barp,Foopubf,java.lang.Short,Barpubf,java.lang.Integer,Bazp,Bazpubf)
> public Baz(Foop,Barp,Foopubf,java.lang.Short,Barpubf,java.lang.Integer,Bazp)
> public Baz(Foop,Barp,Foopubf,java.lang.Short,Barpubf,java.lang.Integer)
> public Baz(Foop,Barp,Foopubf,java.lang.Short,Barpubf)
> public Baz(Foop,Barp,Foopubf,java.lang.Short)
> public Baz(Foop,Barp,Foopubf)
> public Baz(Foop,Barp)
> public Baz(Foop)
> public Baz()
> {code}
> Here, {{Barp}} is meant to be the 4th not 2nd param. This is a breaking
> change but I believe that {{includeSuperFields}} is rarely used and the two
> flags together perhaps slightly more so. Given that I am about to add
> JavaBean properties into the mix, it seems best to fix this now. The
> workaround for those requiring the old behavior is to add an {{includes}}
> annotation attribute and specify the required order. For the above example:
> {{includes='foop,barp,foopubf,...'}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8455) @TupleConstructor gives wrong ordering when includeSuperFields is set
[
https://issues.apache.org/jira/browse/GROOVY-8455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16335024#comment-16335024
]
ASF GitHub Bot commented on GROOVY-8455:
Github user asfgit closed the pull request at:
https://github.com/apache/groovy/pull/655
> @TupleConstructor gives wrong ordering when includeSuperFields is set
> -
>
> Key: GROOVY-8455
> URL: https://issues.apache.org/jira/browse/GROOVY-8455
> Project: Groovy
> Issue Type: Bug
>Reporter: Paul King
>Priority: Major
>
> When the {{includeSuperProperties}} flag is set, @TupleConstructor includes
> those properties and historically has done it with properties from parent
> classes first. This is also true if just the {{includeSuperFields}} flag is
> set. When both flags are set the intention was to keep this ordering but
> currently that is not the case.
> Here is an example:
> {code}
> import groovy.transform.*
> class Foopubf{}
> class Foop{}
> class Foopp{}
> class Foo {
> Foop foop1
> public Foopubf foopubf
> protected Short fooProtField = 42
> void setFooPseudoProp(Foopp fpp) {}
> Foopp getFooPseudoProp() { null }
> }
> class Barpubf{}
> class Barp{}
> class Barpp{}
> class Bar extends Foo {
> Barp barp
> public Barpubf barpubf
> protected Integer barProtField = 150
> Barpp getBarPseudoProp() { null }
> void setBarPseudoProp(Barpp bpp) { }
> }
> class Bazpubf{}
> class Bazp{}
> class Bazpp{}
> @TupleConstructor(includeFields=true, includeSuperFields=true,
> includeSuperProperties=true)
> class Baz extends Bar {
> Bazp bazp
> public Bazpubf bazpubf
> protected Long bazProtField = 2000L
> Bazpp getBazPseudoProp() { null }
> void setBazPseudoProp(Bazpp bpp) { }
> }
> Baz.constructors.each {
> println it
> }
> {code}
> which produces:
> {code}
> public
> Baz(Foop,Barp,Foopubf,java.lang.Short,Barpubf,java.lang.Integer,Bazp,Bazpubf,java.lang.Long)
> public
> Baz(Foop,Barp,Foopubf,java.lang.Short,Barpubf,java.lang.Integer,Bazp,Bazpubf)
> public Baz(Foop,Barp,Foopubf,java.lang.Short,Barpubf,java.lang.Integer,Bazp)
> public Baz(Foop,Barp,Foopubf,java.lang.Short,Barpubf,java.lang.Integer)
> public Baz(Foop,Barp,Foopubf,java.lang.Short,Barpubf)
> public Baz(Foop,Barp,Foopubf,java.lang.Short)
> public Baz(Foop,Barp,Foopubf)
> public Baz(Foop,Barp)
> public Baz(Foop)
> public Baz()
> {code}
> Here, {{Barp}} is meant to be the 4th not 2nd param. This is a breaking
> change but I believe that {{includeSuperFields}} is rarely used and the two
> flags together perhaps slightly more so. Given that I am about to add
> JavaBean properties into the mix, it seems best to fix this now. The
> workaround for those requiring the old behavior is to add an {{includes}}
> annotation attribute and specify the required order. For the above example:
> {{includes='foop,barp,foopubf,...'}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8440) Groovy's @Immutable annotation should be re-vamped to be a meta-annotation
[ https://issues.apache.org/jira/browse/GROOVY-8440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16336814#comment-16336814 ] ASF GitHub Bot commented on GROOVY-8440: Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/653 > Groovy's @Immutable annotation should be re-vamped to be a meta-annotation > -- > > Key: GROOVY-8440 > URL: https://issues.apache.org/jira/browse/GROOVY-8440 > Project: Groovy > Issue Type: Bug >Reporter: Paul King >Assignee: Paul King >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8093) Final variable analysis broken within closure fields
[
https://issues.apache.org/jira/browse/GROOVY-8093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16353565#comment-16353565
]
ASF GitHub Bot commented on GROOVY-8093:
GitHub user paulk-asert opened a pull request:
https://github.com/apache/groovy/pull/659
GROOVY-8093: Final variable analysis broken within closure fields
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/paulk-asert/groovy groovy8093
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/659.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #659
> Final variable analysis broken within closure fields
>
>
> Key: GROOVY-8093
> URL: https://issues.apache.org/jira/browse/GROOVY-8093
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.5.x
>Reporter: Paul King
>Priority: Major
>
> The following code compiles and runs successfully in 2.4.8 but fails in 2.5
> snapshots:
> {code}
> class Foo {
> public Closure bar = {
> final RANKINGS = ["year": 0, "month": 10]
> }
> }
> new Foo().bar()
> {code}
> Error message is:
> {noformat}
> 1 compilation error:
> The variable [RANKINGS] is declared final but is reassigned
> . At [3:9] at line: 3, column: 9
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8093) Final variable analysis broken within closure fields
[
https://issues.apache.org/jira/browse/GROOVY-8093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16354660#comment-16354660
]
ASF GitHub Bot commented on GROOVY-8093:
Github user asfgit closed the pull request at:
https://github.com/apache/groovy/pull/659
> Final variable analysis broken within closure fields
>
>
> Key: GROOVY-8093
> URL: https://issues.apache.org/jira/browse/GROOVY-8093
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.5.x
>Reporter: Paul King
>Priority: Major
>
> The following code compiles and runs successfully in 2.4.8 but fails in 2.5
> snapshots:
> {code}
> class Foo {
> public Closure bar = {
> final RANKINGS = ["year": 0, "month": 10]
> }
> }
> new Foo().bar()
> {code}
> Error message is:
> {noformat}
> 1 compilation error:
> The variable [RANKINGS] is declared final but is reassigned
> . At [3:9] at line: 3, column: 9
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8477) @Immutable-related transformations should be more configurable
[ https://issues.apache.org/jira/browse/GROOVY-8477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16361829#comment-16361829 ] ASF GitHub Bot commented on GROOVY-8477: GitHub user paulk-asert opened a pull request: https://github.com/apache/groovy/pull/662 GROOVY-8477: @Immutable-related transformations should be more config… …urable You can merge this pull request into a Git repository by running: $ git pull https://github.com/paulk-asert/groovy groovy8477 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/662.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #662 commit b8bcc2d149aa80f1457a76cf3a7be2ab19adfe26 Author: paulk Date: 2018-02-13T05:06:07Z GROOVY-8477: @Immutable-related transformations should be more configurable > @Immutable-related transformations should be more configurable > -- > > Key: GROOVY-8477 > URL: https://issues.apache.org/jira/browse/GROOVY-8477 > Project: Groovy > Issue Type: Improvement >Reporter: Paul King >Priority: Major > > This would allow other immutability libraries to be leveraged, e.g. Guava's > immutable collections. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8471) Contents of META-INF/services/org.codehaus.groovy.source.Extensions conflict with Maven/Jisaw
[
https://issues.apache.org/jira/browse/GROOVY-8471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16363433#comment-16363433
]
ASF GitHub Bot commented on GROOVY-8471:
GitHub user paulk-asert opened a pull request:
https://github.com/apache/groovy/pull/663
GROOVY-8471: Contents of META-INF/services/org.codehaus.groovy.source…
….Extensions conflict with Maven/Jisaw
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/paulk-asert/groovy groovy8471
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/663.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #663
commit 613dd488f9c07d367ef1a3d14f2f5aba82e805be
Author: paulk
Date: 2018-02-14T03:16:22Z
GROOVY-8471: Contents of
META-INF/services/org.codehaus.groovy.source.Extensions conflict with
Maven/Jisaw
> Contents of META-INF/services/org.codehaus.groovy.source.Extensions conflict
> with Maven/Jisaw
> -
>
> Key: GROOVY-8471
> URL: https://issues.apache.org/jira/browse/GROOVY-8471
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1, 2.4.13
>Reporter: Ceki Gülcü
>Priority: Critical
>
> From what [I can
> gather|http://markmail.org/thread/nekeppbvwrfl7hbb#query:+page:1+mid:qtqqcfrw6us6aupz+state:results],
> Jigsaw module resolution analyzes the contents of module-info.class,
> MANIFEST.MF and META-INF/services/* files.
> As such, it turns out that the contents of
> {{src/resources/META-INF/services/org.codehaus.groovy.source.Extensions}}
> prevents groovy-*.jar from being loaded as an automatic module, at least
> within a Maven build.
> [~rfscholte] has pointed out that this is not a Maven specific problem as can
> be verified in JShell by invoking:
> {code}
> java.lang.module.ModuleFinder.of(java.nio.file.Paths.get(artifact)).findAll().stream().findFirst().get().descriptor().name()
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8241) SAM parameter type inference for explicit parameter
[
https://issues.apache.org/jira/browse/GROOVY-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16364596#comment-16364596
]
ASF GitHub Bot commented on GROOVY-8241:
Github user daniel-huss commented on a diff in the pull request:
https://github.com/apache/groovy/pull/643#discussion_r168272512
--- Diff: src/test/groovy/transform/stc/MethodCallsSTCTest.groovy ---
@@ -383,6 +406,94 @@ class MethodCallsSTCTest extends
StaticTypeCheckingTestCase {
''', 'Reference to method is ambiguous'
}
+void testShouldFailWithMultiplePossibleMethods2() {
+shouldFailWithMessages '''
+static String foo(String s) {
+'String'
+}
+static String foo(Integer s) {
+'Integer'
+}
+static String foo(Boolean s) {
+'Boolean'
+}
+['foo',123,true].each { argument ->
+if (argument instanceof String || argument instanceof
Boolean || argument instanceof Integer) {
+foo(argument)
+}
+}
+''', 'Reference to method is ambiguous'
+}
+
+void testInstanceOfOnExplicitParameter() {
+assertScript '''
+1.with { obj ->
+if (obj instanceof String) {
+obj.toUpperCase()
+}
+}
+'''
+}
+
+void testSAMWithExplicitParameter() {
+assertScript '''
+public interface SAM {
+boolean run(String var1, Thread th);
+}
+
+static boolean foo(SAM sam) {
+ sam.run("foo", new Thread())
+}
+
+static def callSAM() {
+foo { str, th ->
+str.toUpperCase().equals(th.getName())
+}
+}
+'''
+}
+
+void testGroovy8241() {
+assertScript '''
+import java.util.function.Predicate
+
+static boolean foo(Predicate p) {
+p.test("foo")
+}
+
+static def testPredicate() {
+foo { it ->
+it.toUpperCase()
--- End diff --
Oh, you're right. I forgot Groovy's interpretation of is simply
:)
> SAM parameter type inference for explicit parameter
> ---
>
> Key: GROOVY-8241
> URL: https://issues.apache.org/jira/browse/GROOVY-8241
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.10
>Reporter: Daniil Ovchinnikov
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 2.5.0-beta-3, 2.6.0-alpha-3, 2.4.14, 3.0.0-alpha-2
>
>
> {code}
> import groovy.transform.CompileStatic
> import java.util.function.Predicate
> @CompileStatic
> static boolean foo(Predicate p) {
> p.test("foo")
> }
> @CompileStatic
> static def testPredicate() {
> foo { // it ->
> it.toUpperCase()
> true
> }
> }
> {code}
> Uncomment {{it}}, compiler will say:
> {noformat}
> Cannot find matching method java.lang.Object#toUpperCase()
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8477) @Immutable-related transformations should be more configurable
[ https://issues.apache.org/jira/browse/GROOVY-8477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16364817#comment-16364817 ] ASF GitHub Bot commented on GROOVY-8477: Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/662 > @Immutable-related transformations should be more configurable > -- > > Key: GROOVY-8477 > URL: https://issues.apache.org/jira/browse/GROOVY-8477 > Project: Groovy > Issue Type: Improvement >Reporter: Paul King >Priority: Major > > This would allow other immutability libraries to be leveraged, e.g. Guava's > immutable collections. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8471) Contents of META-INF/services/org.codehaus.groovy.source.Extensions conflict with Maven/Jisaw
[
https://issues.apache.org/jira/browse/GROOVY-8471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16364818#comment-16364818
]
ASF GitHub Bot commented on GROOVY-8471:
Github user asfgit closed the pull request at:
https://github.com/apache/groovy/pull/663
> Contents of META-INF/services/org.codehaus.groovy.source.Extensions conflict
> with Maven/Jisaw
> -
>
> Key: GROOVY-8471
> URL: https://issues.apache.org/jira/browse/GROOVY-8471
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1, 2.4.13
>Reporter: Ceki Gülcü
>Priority: Critical
>
> From what [I can
> gather|http://markmail.org/thread/nekeppbvwrfl7hbb#query:+page:1+mid:qtqqcfrw6us6aupz+state:results],
> Jigsaw module resolution analyzes the contents of module-info.class,
> MANIFEST.MF and META-INF/services/* files.
> As such, it turns out that the contents of
> {{src/resources/META-INF/services/org.codehaus.groovy.source.Extensions}}
> prevents groovy-*.jar from being loaded as an automatic module, at least
> within a Maven build.
> [~rfscholte] has pointed out that this is not a Maven specific problem as can
> be verified in JShell by invoking:
> {code}
> java.lang.module.ModuleFinder.of(java.nio.file.Paths.get(artifact)).findAll().stream().findFirst().get().descriptor().name()
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-7956) Provide an AST transformation which improves named parameter support
[
https://issues.apache.org/jira/browse/GROOVY-7956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369629#comment-16369629
]
ASF GitHub Bot commented on GROOVY-7956:
GitHub user paulk-asert opened a pull request:
https://github.com/apache/groovy/pull/664
GROOVY-7956: Provide an AST transformation which improves named param…
…eter support
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/paulk-asert/groovy groovy7956
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/664.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #664
commit 43f2c8e47b2072e2c0e42097c4462180af30efdb
Author: paulk
Date: 2018-02-20T00:09:59Z
GROOVY-7956: Provide an AST transformation which improves named parameter
support
> Provide an AST transformation which improves named parameter support
>
>
> Key: GROOVY-7956
> URL: https://issues.apache.org/jira/browse/GROOVY-7956
> Project: Groovy
> Issue Type: New Feature
> Components: GEP
>Reporter: Graeme Rocher
>Priority: Major
>
> In order to aid static compilation for builders we have {{@DelegatesTo}}
> which allows statically compiled code to know what the delegate of a closure
> is.
> This proposal is to allow {{@DelegatesTo}} on {{Map}} types such that IDEs
> and the static compiler can resolve the target type the named arguments are
> to be used on.
> For example:
> {code}
> class Farm {
> void animal(@DelegatesTo(Animal) Map arguments,
> @DelegatesTo(AnimalBuilder) Closure callable) {
> def animal = new Animal(arguments)
> // handle closure
> }
> }
> class Animal { String name }
> {code}
> The following code would then fail to compile :
> {code}
> def farm = new Farm()
> // compilation failure, no name property on Animal
> farm.animal(nam: "Dog") {
> }
> {code}
> It would then be down to IDEs to also provide support for code completion etc.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-7956) Provide an AST transformation which improves named parameter support
[
https://issues.apache.org/jira/browse/GROOVY-7956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369655#comment-16369655
]
ASF GitHub Bot commented on GROOVY-7956:
Github user asfgit closed the pull request at:
https://github.com/apache/groovy/pull/664
> Provide an AST transformation which improves named parameter support
>
>
> Key: GROOVY-7956
> URL: https://issues.apache.org/jira/browse/GROOVY-7956
> Project: Groovy
> Issue Type: New Feature
> Components: GEP
>Reporter: Graeme Rocher
>Priority: Major
>
> In order to aid static compilation for builders we have {{@DelegatesTo}}
> which allows statically compiled code to know what the delegate of a closure
> is.
> This proposal is to allow {{@DelegatesTo}} on {{Map}} types such that IDEs
> and the static compiler can resolve the target type the named arguments are
> to be used on.
> For example:
> {code}
> class Farm {
> void animal(@DelegatesTo(Animal) Map arguments,
> @DelegatesTo(AnimalBuilder) Closure callable) {
> def animal = new Animal(arguments)
> // handle closure
> }
> }
> class Animal { String name }
> {code}
> The following code would then fail to compile :
> {code}
> def farm = new Farm()
> // compilation failure, no name property on Animal
> farm.animal(nam: "Dog") {
> }
> {code}
> It would then be down to IDEs to also provide support for code completion etc.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-7981) Not public constructors for groovy.transform.Immutable anotated class
[ https://issues.apache.org/jira/browse/GROOVY-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372429#comment-16372429 ] ASF GitHub Bot commented on GROOVY-7981: GitHub user paulk-asert opened a pull request: https://github.com/apache/groovy/pull/665 GROOVY-7981: Not public constructors for groovy.transform.Immutable a… …nnotated class You can merge this pull request into a Git repository by running: $ git pull https://github.com/paulk-asert/groovy groovy7981 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/665.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #665 commit e32ca2dc228d5d8212321c5eda81503ff6002760 Author: paulk Date: 2018-02-22T05:25:07Z GROOVY-7981: Not public constructors for groovy.transform.Immutable annotated class > Not public constructors for groovy.transform.Immutable anotated class > - > > Key: GROOVY-7981 > URL: https://issues.apache.org/jira/browse/GROOVY-7981 > Project: Groovy > Issue Type: Improvement >Reporter: Dominik Przybysz >Priority: Major > > groovy.transform.Immutable annotation generates only public constructors for > annotated class. > I want to be able to create class with constructors with another modifiers e. > g. private constructors and define static method create/build/from which will > be the only way to create my immutable class. > The pull request will be provided. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-7981) Not public constructors for groovy.transform.Immutable anotated class
[ https://issues.apache.org/jira/browse/GROOVY-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372511#comment-16372511 ] ASF GitHub Bot commented on GROOVY-7981: Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/665 > Not public constructors for groovy.transform.Immutable anotated class > - > > Key: GROOVY-7981 > URL: https://issues.apache.org/jira/browse/GROOVY-7981 > Project: Groovy > Issue Type: Improvement >Reporter: Dominik Przybysz >Priority: Major > > groovy.transform.Immutable annotation generates only public constructors for > annotated class. > I want to be able to create class with constructors with another modifiers e. > g. private constructors and define static method create/build/from which will > be the only way to create my immutable class. > The pull request will be provided. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-7981) Not public constructors for groovy.transform.Immutable anotated class
[ https://issues.apache.org/jira/browse/GROOVY-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372512#comment-16372512 ] ASF GitHub Bot commented on GROOVY-7981: Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/453 > Not public constructors for groovy.transform.Immutable anotated class > - > > Key: GROOVY-7981 > URL: https://issues.apache.org/jira/browse/GROOVY-7981 > Project: Groovy > Issue Type: Improvement >Reporter: Dominik Przybysz >Priority: Major > > groovy.transform.Immutable annotation generates only public constructors for > annotated class. > I want to be able to create class with constructors with another modifiers e. > g. private constructors and define static method create/build/from which will > be the only way to create my immutable class. > The pull request will be provided. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8480) org.codehaus.groovy.runtime.ExtensionModule should move to META-INF/groovy
[ https://issues.apache.org/jira/browse/GROOVY-8480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373940#comment-16373940 ] ASF GitHub Bot commented on GROOVY-8480: GitHub user paulk-asert opened a pull request: https://github.com/apache/groovy/pull/666 GROOVY-8480: org.codehaus.groovy.runtime.ExtensionModule should move … …to META-INF/groovy You can merge this pull request into a Git repository by running: $ git pull https://github.com/paulk-asert/groovy groovy8480 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/666.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #666 commit 46b6b1164c76dd4da3e37bcc2432d6b8db815cb5 Author: paulk Date: 2018-02-23T05:14:00Z GROOVY-8480: org.codehaus.groovy.runtime.ExtensionModule should move to META-INF/groovy > org.codehaus.groovy.runtime.ExtensionModule should move to META-INF/groovy > -- > > Key: GROOVY-8480 > URL: https://issues.apache.org/jira/browse/GROOVY-8480 > Project: Groovy > Issue Type: Improvement >Reporter: Paul King >Priority: Major > > To avoid confusing Java 9's ModuleFinder. We should fall back to the current > location to handle existing jars. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8480) org.codehaus.groovy.runtime.ExtensionModule should move to META-INF/groovy
[ https://issues.apache.org/jira/browse/GROOVY-8480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375177#comment-16375177 ] ASF GitHub Bot commented on GROOVY-8480: Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/666 > org.codehaus.groovy.runtime.ExtensionModule should move to META-INF/groovy > -- > > Key: GROOVY-8480 > URL: https://issues.apache.org/jira/browse/GROOVY-8480 > Project: Groovy > Issue Type: Improvement >Reporter: Paul King >Priority: Major > > To avoid confusing Java 9's ModuleFinder. We should fall back to the current > location to handle existing jars. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8379) Rework groovy-json FastStringUtils
[ https://issues.apache.org/jira/browse/GROOVY-8379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16376058#comment-16376058 ] ASF GitHub Bot commented on GROOVY-8379: GitHub user paulk-asert opened a pull request: https://github.com/apache/groovy/pull/667 GROOVY-8379: Rework groovy-json FastStringUtils You can merge this pull request into a Git repository by running: $ git pull https://github.com/paulk-asert/groovy groovy8379 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/667.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #667 commit f9c8ae9f71b08b230606b9bcb6e48dc1a2c26a65 Author: paulk Date: 2018-02-25T10:11:03Z GROOVY-8379: Rework groovy-json FastStringUtils > Rework groovy-json FastStringUtils > -- > > Key: GROOVY-8379 > URL: https://issues.apache.org/jira/browse/GROOVY-8379 > Project: Groovy > Issue Type: Task > Components: JSON >Reporter: Paul King >Priority: Major > > Including these aspects: > * Remove JDK4/5 special coding (StringImplementation#OFFSET JDK4/5 enum > variant) > * Perhaps make it a service so that we can perhaps delete the Unsafe version > but allow an external service to provide that or something else if needed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8379) Rework groovy-json FastStringUtils
[ https://issues.apache.org/jira/browse/GROOVY-8379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16380167#comment-16380167 ] ASF GitHub Bot commented on GROOVY-8379: Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/667 > Rework groovy-json FastStringUtils > -- > > Key: GROOVY-8379 > URL: https://issues.apache.org/jira/browse/GROOVY-8379 > Project: Groovy > Issue Type: Task > Components: JSON >Reporter: Paul King >Priority: Major > > Including these aspects: > * Remove JDK4/5 special coding (StringImplementation#OFFSET JDK4/5 enum > variant) > * Perhaps make it a service so that we can perhaps delete the Unsafe version > but allow an external service to provide that or something else if needed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8475) CLONE - I am unable to instantiate objects using the "new" keyword
[
https://issues.apache.org/jira/browse/GROOVY-8475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16384962#comment-16384962
]
ASF GitHub Bot commented on GROOVY-8475:
GitHub user jwagenleitner opened a pull request:
https://github.com/apache/groovy/pull/670
GROOVY-8475: unable to instantiate objects using the "new" keyword in
groovysh
PR #100 was merged into 2_5_X and comments on GROOVY-7562 indicate it
wasn't merged into 2_4_X due to binary compatibility concerns. I think this
backport addresses those concerns and this PR is targeted only for the 2_4_X
branch.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jwagenleitner/groovy 8475-groovysh-new
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/670.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #670
commit c220753e867f733ac7c68a56d5a8dd9aa5ac60dc
Author: John Wagenleitner
Date: 2018-03-04T01:53:40Z
GROOVY-8475: unable to instantiate objects using the "new" keyword in
groovysh
Backport fix "GROOVY-7562 Groovysh: Fix custom class instantiation
impossible with Interpreter Mode" for the 2_4_X branch.
Retain binary compatibilty by retaining and deprecating methods removed
in the original fix that was applied to 2_5_X.
commit 567bd1e525b8752a7594bf594e86596c9e3f19bb
Author: John Wagenleitner
Date: 2018-03-04T04:21:16Z
backport fix GROOVY-7562 for the 2_4_X branch
Groovysh: Fix imports not working at all in interpreter mode
> CLONE - I am unable to instantiate objects using the "new" keyword
> --
>
> Key: GROOVY-8475
> URL: https://issues.apache.org/jira/browse/GROOVY-8475
> Project: Groovy
> Issue Type: Bug
> Components: Groovysh
>Affects Versions: 2.4.0, 2.4.12, 2.4.13
> Environment: Linux - Debian jessie/sid 64 bits
> Linux - Ubuntu 16 64 bits
>Reporter: Rémy Letient
>Priority: Major
> Attachments: image-2018-02-10-18-36-27-122.png, testA.groovy
>
>
> I am embedding Groovysh in a java application. After some tests, I realized
> that the "new" keyword seems to not work in the last groovysh version. When I
> try to do:
> {code}a = new A(){code}
> I obtain: "unable to resolve class A"
> This is an example:
> {code}
> groovy:000> class A {
> class A {
> groovy:001> public A() {
> public A() {
> groovy:002> name = "default"
> name = "default"
> groovy:003> }
> }
> groovy:004> String name;
> String name;
> groovy:005> }
> }
> ===> true
> groovy:000> a = new A()
> a = new A()
> ERROR org.codehaus.groovy.control.MultipleCompilationErrorsException:
> startup failed:
> script14159599676571305654112.groovy: 1: unable to resolve class A
> @ line 1, column 5.
>a = new A()
>^
> 1 error
> {code}
> However, if I use the newInstance method it works:
> {code}
> groovy:000> a = A.newInstance()
> a = A.newInstance()
> ===> A@2154cecb
> {code}
> I tested the same code in the previous version (2.3.7) and it works
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8475) CLONE - I am unable to instantiate objects using the "new" keyword
[
https://issues.apache.org/jira/browse/GROOVY-8475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385438#comment-16385438
]
ASF GitHub Bot commented on GROOVY-8475:
Github user jwagenleitner closed the pull request at:
https://github.com/apache/groovy/pull/670
> CLONE - I am unable to instantiate objects using the "new" keyword
> --
>
> Key: GROOVY-8475
> URL: https://issues.apache.org/jira/browse/GROOVY-8475
> Project: Groovy
> Issue Type: Bug
> Components: Groovysh
>Affects Versions: 2.4.0, 2.4.12, 2.4.13
> Environment: Linux - Debian jessie/sid 64 bits
> Linux - Ubuntu 16 64 bits
>Reporter: Rémy Letient
>Priority: Major
> Attachments: image-2018-02-10-18-36-27-122.png, testA.groovy
>
>
> I am embedding Groovysh in a java application. After some tests, I realized
> that the "new" keyword seems to not work in the last groovysh version. When I
> try to do:
> {code}a = new A(){code}
> I obtain: "unable to resolve class A"
> This is an example:
> {code}
> groovy:000> class A {
> class A {
> groovy:001> public A() {
> public A() {
> groovy:002> name = "default"
> name = "default"
> groovy:003> }
> }
> groovy:004> String name;
> String name;
> groovy:005> }
> }
> ===> true
> groovy:000> a = new A()
> a = new A()
> ERROR org.codehaus.groovy.control.MultipleCompilationErrorsException:
> startup failed:
> script14159599676571305654112.groovy: 1: unable to resolve class A
> @ line 1, column 5.
>a = new A()
>^
> 1 error
> {code}
> However, if I use the newInstance method it works:
> {code}
> groovy:000> a = A.newInstance()
> a = A.newInstance()
> ===> A@2154cecb
> {code}
> I tested the same code in the previous version (2.3.7) and it works
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8422) Incorrect properties copy in Sql.newInstance
[ https://issues.apache.org/jira/browse/GROOVY-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386313#comment-16386313 ] ASF GitHub Bot commented on GROOVY-8422: GitHub user jwagenleitner opened a pull request: https://github.com/apache/groovy/pull/671 GROOVY-8422: Incorrect properties copy in Sql.newInstance The provided Properties should be passed to the DriverManager as-is. A copy is only needed when changes are made to the provided Properties in order to mask sensitive information for logging purposes. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jwagenleitner/groovy 8422-sql-props Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/671.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #671 commit 1f833b4af4e5e5ac667967b55f279e9534d5ec58 Author: John Wagenleitner Date: 2018-03-05T16:35:33Z GROOVY-8422: Incorrect properties copy in Sql.newInstance The provided Properties should be passed to the DriverManager as-is. A copy is only needed when changes are made to the provided Properties in order to mask sensitive information for logging purposes. > Incorrect properties copy in Sql.newInstance > - > > Key: GROOVY-8422 > URL: https://issues.apache.org/jira/browse/GROOVY-8422 > Project: Groovy > Issue Type: Bug > Components: SQL processing >Affects Versions: 2.4.13 >Reporter: Thomas Weise >Priority: Major > > The constructor `Properties(Properties defaults)` does not create a copy, but > a new object with the argument as defaults. That breaks JDBC drivers that > expect the properties to be present in the object directly (enumerating of > keys, containsKey etc.). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8422) Incorrect properties copy in Sql.newInstance
[ https://issues.apache.org/jira/browse/GROOVY-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16387194#comment-16387194 ] ASF GitHub Bot commented on GROOVY-8422: Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/671 > Incorrect properties copy in Sql.newInstance > - > > Key: GROOVY-8422 > URL: https://issues.apache.org/jira/browse/GROOVY-8422 > Project: Groovy > Issue Type: Bug > Components: SQL processing >Affects Versions: 2.4.13 >Reporter: Thomas Weise >Priority: Major > > The constructor `Properties(Properties defaults)` does not create a copy, but > a new object with the argument as defaults. That breaks JDBC drivers that > expect the properties to be present in the object directly (enumerating of > keys, containsKey etc.). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-7624) Collection asImmutable() methods aren't immutable
[
https://issues.apache.org/jira/browse/GROOVY-7624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16387686#comment-16387686
]
ASF GitHub Bot commented on GROOVY-7624:
GitHub user paulk-asert opened a pull request:
https://github.com/apache/groovy/pull/672
GROOVY-7624: Collection asImmutable() methods aren't immutable
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/paulk-asert/groovy groovy7624
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/672.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #672
commit 9326ebe6040bb242d68fc8a835429a846ac9edc1
Author: paulk
Date: 2018-03-06T12:16:29Z
GROOVY-7624: Collection asImmutable() methods aren't immutable
> Collection asImmutable() methods aren't immutable
> -
>
> Key: GROOVY-7624
> URL: https://issues.apache.org/jira/browse/GROOVY-7624
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Affects Versions: 2.4.5
>Reporter: Christopher Smith
>Priority: Minor
>
> The contract for the Collection {{asImmutable()}} methods specify that the
> returned collection is immutable, but in fact the collection is merely
> read-only; it uses {{Collections.unmodifiable*()}}, which wraps an underlying
> collection that is still mutable.
> These methods should return actual immutable collections, either using
> Collections unmodifiables with copies of the underlying collections or using
> an actual immutable backing implementation, a la Guava.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-7624) Collection asImmutable() methods aren't immutable
[
https://issues.apache.org/jira/browse/GROOVY-7624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16388673#comment-16388673
]
ASF GitHub Bot commented on GROOVY-7624:
Github user asfgit closed the pull request at:
https://github.com/apache/groovy/pull/672
> Collection asImmutable() methods aren't immutable
> -
>
> Key: GROOVY-7624
> URL: https://issues.apache.org/jira/browse/GROOVY-7624
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Affects Versions: 2.4.5
>Reporter: Christopher Smith
>Assignee: Paul King
>Priority: Minor
> Labels: breaking
>
> The contract for the Collection {{asImmutable()}} methods specify that the
> returned collection is immutable, but in fact the collection is merely
> read-only; it uses {{Collections.unmodifiable*()}}, which wraps an underlying
> collection that is still mutable.
> These methods should return actual immutable collections, either using
> Collections unmodifiables with copies of the underlying collections or using
> an actual immutable backing implementation, a la Guava.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8501) Switch internal details of @ImmutableBase existing constructor validation
[ https://issues.apache.org/jira/browse/GROOVY-8501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16391244#comment-16391244 ] ASF GitHub Bot commented on GROOVY-8501: GitHub user paulk-asert opened a pull request: https://github.com/apache/groovy/pull/673 GROOVY-8501: Switch internal details of @ImmutableBase existing const… …ructor validation You can merge this pull request into a Git repository by running: $ git pull https://github.com/paulk-asert/groovy groovy8501 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/673.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #673 commit 5fe29c30ba2b96badcf8bfb9a6f147b2f1f5114e Author: paulk Date: 2018-03-08T13:25:24Z GROOVY-8501: Switch internal details of @ImmutableBase existing constructor validation > Switch internal details of @ImmutableBase existing constructor validation > - > > Key: GROOVY-8501 > URL: https://issues.apache.org/jira/browse/GROOVY-8501 > Project: Groovy > Issue Type: Task >Reporter: Paul King >Priority: Major > > Currently @ImmutableBase validates that no existing constructors are present. > It requires @ImmutableBase to appear before @TupleConstructor and > @MapConstructor. It allows @Builder with the InitializerStrategy to have been > processed earlier and uses some node metadata tracking to allow this to > happen. If we change to instead checking for the @Generated annotation > instead of node metadata, these ordering restrictions can be relaxed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8501) Switch internal details of @ImmutableBase existing constructor validation
[ https://issues.apache.org/jira/browse/GROOVY-8501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16392490#comment-16392490 ] ASF GitHub Bot commented on GROOVY-8501: Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/673 > Switch internal details of @ImmutableBase existing constructor validation > - > > Key: GROOVY-8501 > URL: https://issues.apache.org/jira/browse/GROOVY-8501 > Project: Groovy > Issue Type: Task >Reporter: Paul King >Priority: Major > > Currently @ImmutableBase validates that no existing constructors are present. > It requires @ImmutableBase to appear before @TupleConstructor and > @MapConstructor. It allows @Builder with the InitializerStrategy to have been > processed earlier and uses some node metadata tracking to allow this to > happen. If we change to instead checking for the @Generated annotation > instead of node metadata, these ordering restrictions can be relaxed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8334) Java 8 Date/Time type support in Groovy JDK
[ https://issues.apache.org/jira/browse/GROOVY-8334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16404228#comment-16404228 ] ASF GitHub Bot commented on GROOVY-8334: GitHub user bdkosher opened a pull request: https://github.com/apache/groovy/pull/674 GROOVY-8334: Java 8 Date/Time type support in Groovy JDK Reference: https://issues.apache.org/jira/browse/GROOVY-8334 You can merge this pull request into a Git repository by running: $ git pull https://github.com/bdkosher/groovy datetimeapi Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/674.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #674 commit ad02b9ffd5406e95147dfb5c28dfaab69423e787 Author: Joe Wolf Date: 2018-02-18T22:59:12Z initial port of Goodtimes-inspired methods commit 96499c773616a62a75a12e20f34f1e7d3149359f Author: Joe Wolf Date: 2018-03-04T21:55:56Z Fix upto/downto with custom TemporalUnit arg edge cases. Add Period and Duration methods. commit d2878692ab16639bca3e8ee98a6701331e9b7ecf Author: Joe Wolf Date: 2018-03-04T21:56:07Z Merge remote-tracking branch 'upstream/master' into datetimeapi commit 5cddc5188354681bcd01b7c17bb0ec1425c47db7 Author: Joe Wolf Date: 2018-03-14T22:58:52Z Merge remote-tracking branch 'upstream/master' into datetimeapi commit ee994cc44366237dfbd2ce514873618b618fb8de Author: Joe Wolf Date: 2018-03-16T02:34:59Z Merge remote-tracking branch 'upstream/master' into datetimeapi commit 33b50d78d3bc1146b916236a08d32bd6e6a3887c Author: Joe Wolf Date: 2018-03-18T00:46:39Z Merge remote-tracking branch 'upstream/master' into datetimeapi commit 6b8c5c009dd660c4a93b421714f9be03fdbbc257 Author: Joe Wolf Date: 2018-03-18T00:49:45Z use ISO for formatting methods; restrict upto/downto args to same type commit 8c202acf23ca57fd358fbe64f5590a4962b50bf2 Author: Joe Wolf Date: 2018-03-18T00:50:20Z add GDK Date/Time documentation > Java 8 Date/Time type support in Groovy JDK > --- > > Key: GROOVY-8334 > URL: https://issues.apache.org/jira/browse/GROOVY-8334 > Project: Groovy > Issue Type: New Feature > Components: groovy-jdk >Reporter: Joe Wolf >Priority: Major > > Provide Groovy JDK methods for the types in Java 8's java.time package, > similar to the ones which exist for java.util.Date/Calendar. > The [Goodtimes|https://github.com/bdkosher/goodtimes] API can be used as the > inspiration for the added methods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8514) NullPointerException in class MissingMethodException
[
https://issues.apache.org/jira/browse/GROOVY-8514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16404754#comment-16404754
]
ASF GitHub Bot commented on GROOVY-8514:
GitHub user paulk-asert opened a pull request:
https://github.com/apache/groovy/pull/675
GROOVY-8514: NullPointerException in class MissingMethodException
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/paulk-asert/groovy groovy8514
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/675.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #675
commit efede2ab04d641bfc8ed8e77d15df3ae87dfc672
Author: paulk
Date: 2018-03-19T12:46:07Z
GROOVY-8514: NullPointerException in class MissingMethodException
> NullPointerException in class MissingMethodException
>
>
> Key: GROOVY-8514
> URL: https://issues.apache.org/jira/browse/GROOVY-8514
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.14
>Reporter: Dennis K
>Priority: Major
>
> The class {{MissingMethodException}} throws an {{NullPointerException}} on
> {{getMessage()}} if {{arguments}} are null.
> This can happen, if the someone calls {{GroovyScriptEngineImpl.getInterface}}
> and invokes a method without arguments on that interface. And the method is
> not defined in the groovy script.
> The {{InvocationHandler}} calls the method {{invokeImpl}} with {{null}} as
> arguments, because the interface method has no arguments. If the Method is
> not defined in the groovy script. A {{MissingMethodException}} is thrown and
> catched. Than the following {{NoSuchMethodException(var5.getMessage());}} is
> thrown. But {{getMessage()}} itself throws an NPE due to {{arguments}} is
> null.
> From the Java Documentation
> [InvocationHandler|https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/InvocationHandler.html]
> {quote}args - an array of objects containing the values of the arguments
> passed in the method invocation on the proxy instance, or null if interface
> method takes no arguments. Arguments of primitive types are wrapped in
> instances of the appropriate primitive wrapper class, such as
> java.lang.Integer or java.lang.Boolean.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8508) VerifyError calling Comparator.naturalOrder() since Groovy 2.4.14
[
https://issues.apache.org/jira/browse/GROOVY-8508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16404811#comment-16404811
]
ASF GitHub Bot commented on GROOVY-8508:
Github user paulk-asert commented on the pull request:
https://github.com/apache/groovy/commit/b3e042191a7acc1c7bdfdfdc0c39fe93e2de3d94#commitcomment-28156492
If you want to hear latest status of releases etc., the Apache Groovy dev
list is a good one to subscribe to.
wrt asm library - last upgrade of ASM on 2_4_X still has issues, e.g.:
https://issues.apache.org/jira/browse/GROOVY-8508
https://issues.apache.org/jira/browse/GROOVY-8494
Fixing that may yet require revert of ASM version. But if we manage to fix
it without reverting, we can consider another upgrade of ASM. We tend not bump
dependency versions in point releases without a good reason.
> VerifyError calling Comparator.naturalOrder() since Groovy 2.4.14
> --
>
> Key: GROOVY-8508
> URL: https://issues.apache.org/jira/browse/GROOVY-8508
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.4.14
> Environment: macOS
>Reporter: Roman Stumm
>Priority: Blocker
>
> {color:#808080}tested on macOS with Java SE Development Kit 8u162.{color}
> {color:#808080}works with groovy 2.4.13.{color}
> {color:#808080}fails with groovy 2.4.14 ->{color}
> {color:#808080}java.lang.VerifyError: (class:
> java_util_Comparator$naturalOrder, method: callStatic
> signature:{color}{color:#808080}
> (Ljava/lang/Class;[Ljava/lang/Object;)Ljava/lang/Object Illegal type in
> constant pool{color}{color:#808080}
> {color}
> Comparator.naturalOrder()
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8334) Java 8 Date/Time type support in Groovy JDK
[ https://issues.apache.org/jira/browse/GROOVY-8334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16405033#comment-16405033 ] ASF GitHub Bot commented on GROOVY-8334: Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/674 > Java 8 Date/Time type support in Groovy JDK > --- > > Key: GROOVY-8334 > URL: https://issues.apache.org/jira/browse/GROOVY-8334 > Project: Groovy > Issue Type: New Feature > Components: groovy-jdk >Reporter: Joe Wolf >Priority: Major > > Provide Groovy JDK methods for the types in Java 8's java.time package, > similar to the ones which exist for java.util.Date/Calendar. > The [Goodtimes|https://github.com/bdkosher/goodtimes] API can be used as the > inspiration for the added methods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8514) NullPointerException in class MissingMethodException
[
https://issues.apache.org/jira/browse/GROOVY-8514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409898#comment-16409898
]
ASF GitHub Bot commented on GROOVY-8514:
Github user danielsun1106 commented on a diff in the pull request:
https://github.com/apache/groovy/pull/675#discussion_r175422491
--- Diff:
subprojects/groovy-jsr223/src/main/java/org/codehaus/groovy/jsr223/GroovyScriptEngineImpl.java
---
@@ -367,6 +367,22 @@ private Object invokeImpl(Object thiz, String name,
Object... args)
}
}
+private Object invokeImplSafe(Object thiz, String name, Object...
args) {
+if (name == null) {
+throw new NullPointerException("method name is null");
--- End diff --
IllegalArgumentException seems better?
> NullPointerException in class MissingMethodException
>
>
> Key: GROOVY-8514
> URL: https://issues.apache.org/jira/browse/GROOVY-8514
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.14
>Reporter: Dennis K
>Priority: Major
>
> The class {{MissingMethodException}} throws an {{NullPointerException}} on
> {{getMessage()}} if {{arguments}} are null.
> This can happen, if the someone calls {{GroovyScriptEngineImpl.getInterface}}
> and invokes a method without arguments on that interface. And the method is
> not defined in the groovy script.
> The {{InvocationHandler}} calls the method {{invokeImpl}} with {{null}} as
> arguments, because the interface method has no arguments. If the Method is
> not defined in the groovy script. A {{MissingMethodException}} is thrown and
> catched. Than the following {{NoSuchMethodException(var5.getMessage());}} is
> thrown. But {{getMessage()}} itself throws an NPE due to {{arguments}} is
> null.
> From the Java Documentation
> [InvocationHandler|https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/InvocationHandler.html]
> {quote}args - an array of objects containing the values of the arguments
> passed in the method invocation on the proxy instance, or null if interface
> method takes no arguments. Arguments of primitive types are wrapped in
> instances of the appropriate primitive wrapper class, such as
> java.lang.Integer or java.lang.Boolean.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8514) NullPointerException in class MissingMethodException
[
https://issues.apache.org/jira/browse/GROOVY-8514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409897#comment-16409897
]
ASF GitHub Bot commented on GROOVY-8514:
Github user danielsun1106 commented on a diff in the pull request:
https://github.com/apache/groovy/pull/675#discussion_r175424466
--- Diff: src/main/groovy/groovy/lang/MissingMethodException.java ---
@@ -48,7 +48,7 @@ public MissingMethodException(String method, Class type,
Object[] arguments, boo
this.method = method;
this.type = type;
this.isStatic = isStatic;
-this.arguments = arguments;
+this.arguments = arguments == null ? new Object[0] : arguments;
--- End diff --
extract EMPTY_OBJECT_ARRAY to avoid creating object array multiple times?
> NullPointerException in class MissingMethodException
>
>
> Key: GROOVY-8514
> URL: https://issues.apache.org/jira/browse/GROOVY-8514
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.14
>Reporter: Dennis K
>Priority: Major
>
> The class {{MissingMethodException}} throws an {{NullPointerException}} on
> {{getMessage()}} if {{arguments}} are null.
> This can happen, if the someone calls {{GroovyScriptEngineImpl.getInterface}}
> and invokes a method without arguments on that interface. And the method is
> not defined in the groovy script.
> The {{InvocationHandler}} calls the method {{invokeImpl}} with {{null}} as
> arguments, because the interface method has no arguments. If the Method is
> not defined in the groovy script. A {{MissingMethodException}} is thrown and
> catched. Than the following {{NoSuchMethodException(var5.getMessage());}} is
> thrown. But {{getMessage()}} itself throws an NPE due to {{arguments}} is
> null.
> From the Java Documentation
> [InvocationHandler|https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/InvocationHandler.html]
> {quote}args - an array of objects containing the values of the arguments
> passed in the method invocation on the proxy instance, or null if interface
> method takes no arguments. Arguments of primitive types are wrapped in
> instances of the appropriate primitive wrapper class, such as
> java.lang.Integer or java.lang.Boolean.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8514) NullPointerException in class MissingMethodException
[
https://issues.apache.org/jira/browse/GROOVY-8514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410559#comment-16410559
]
ASF GitHub Bot commented on GROOVY-8514:
Github user paulk-asert commented on a diff in the pull request:
https://github.com/apache/groovy/pull/675#discussion_r176602934
--- Diff:
subprojects/groovy-jsr223/src/main/java/org/codehaus/groovy/jsr223/GroovyScriptEngineImpl.java
---
@@ -367,6 +367,22 @@ private Object invokeImpl(Object thiz, String name,
Object... args)
}
}
+private Object invokeImplSafe(Object thiz, String name, Object...
args) {
+if (name == null) {
+throw new NullPointerException("method name is null");
--- End diff --
I'm replicating the existing functionality, so I won't change that.
> NullPointerException in class MissingMethodException
>
>
> Key: GROOVY-8514
> URL: https://issues.apache.org/jira/browse/GROOVY-8514
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.14
>Reporter: Dennis K
>Priority: Major
>
> The class {{MissingMethodException}} throws an {{NullPointerException}} on
> {{getMessage()}} if {{arguments}} are null.
> This can happen, if the someone calls {{GroovyScriptEngineImpl.getInterface}}
> and invokes a method without arguments on that interface. And the method is
> not defined in the groovy script.
> The {{InvocationHandler}} calls the method {{invokeImpl}} with {{null}} as
> arguments, because the interface method has no arguments. If the Method is
> not defined in the groovy script. A {{MissingMethodException}} is thrown and
> catched. Than the following {{NoSuchMethodException(var5.getMessage());}} is
> thrown. But {{getMessage()}} itself throws an NPE due to {{arguments}} is
> null.
> From the Java Documentation
> [InvocationHandler|https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/InvocationHandler.html]
> {quote}args - an array of objects containing the values of the arguments
> passed in the method invocation on the proxy instance, or null if interface
> method takes no arguments. Arguments of primitive types are wrapped in
> instances of the appropriate primitive wrapper class, such as
> java.lang.Integer or java.lang.Boolean.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8514) NullPointerException in class MissingMethodException
[
https://issues.apache.org/jira/browse/GROOVY-8514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410563#comment-16410563
]
ASF GitHub Bot commented on GROOVY-8514:
Github user paulk-asert commented on a diff in the pull request:
https://github.com/apache/groovy/pull/675#discussion_r176603885
--- Diff: src/main/groovy/groovy/lang/MissingMethodException.java ---
@@ -48,7 +48,7 @@ public MissingMethodException(String method, Class type,
Object[] arguments, boo
this.method = method;
this.type = type;
this.isStatic = isStatic;
-this.arguments = arguments;
+this.arguments = arguments == null ? new Object[0] : arguments;
--- End diff --
Done
> NullPointerException in class MissingMethodException
>
>
> Key: GROOVY-8514
> URL: https://issues.apache.org/jira/browse/GROOVY-8514
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.14
>Reporter: Dennis K
>Priority: Major
>
> The class {{MissingMethodException}} throws an {{NullPointerException}} on
> {{getMessage()}} if {{arguments}} are null.
> This can happen, if the someone calls {{GroovyScriptEngineImpl.getInterface}}
> and invokes a method without arguments on that interface. And the method is
> not defined in the groovy script.
> The {{InvocationHandler}} calls the method {{invokeImpl}} with {{null}} as
> arguments, because the interface method has no arguments. If the Method is
> not defined in the groovy script. A {{MissingMethodException}} is thrown and
> catched. Than the following {{NoSuchMethodException(var5.getMessage());}} is
> thrown. But {{getMessage()}} itself throws an NPE due to {{arguments}} is
> null.
> From the Java Documentation
> [InvocationHandler|https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/InvocationHandler.html]
> {quote}args - an array of objects containing the values of the arguments
> passed in the method invocation on the proxy instance, or null if interface
> method takes no arguments. Arguments of primitive types are wrapped in
> instances of the appropriate primitive wrapper class, such as
> java.lang.Integer or java.lang.Boolean.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8525) Binary compatibility issue for GroovyClassLoader between 2.4 vs later branches
[
https://issues.apache.org/jira/browse/GROOVY-8525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16420388#comment-16420388
]
ASF GitHub Bot commented on GROOVY-8525:
GitHub user paulk-asert opened a pull request:
https://github.com/apache/groovy/pull/678
GROOVY-8525: Binary compatibility issue for GroovyClassLoader between…
… 2.4 vs later branches
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/paulk-asert/groovy GROOVY-8525
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/678.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #678
commit 6308dbfc7fa95eaca7a30bc117f4e6628d037506
Author: Paul King
Date: 2018-03-30T10:59:40Z
GROOVY-8525: Binary compatibility issue for GroovyClassLoader between 2.4
vs later branches
> Binary compatibility issue for GroovyClassLoader between 2.4 vs later branches
> --
>
> Key: GROOVY-8525
> URL: https://issues.apache.org/jira/browse/GROOVY-8525
> Project: Groovy
> Issue Type: Task
>Reporter: Paul King
>Priority: Major
>
> Protected fields {{classCache}} and {{sourceCache}} have type
> {{EvictableCache}} instead of {{Map}} in {{java.lang.GroovyClassLoader}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8525) Binary compatibility issue for GroovyClassLoader between 2.4 vs later branches
[
https://issues.apache.org/jira/browse/GROOVY-8525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16421066#comment-16421066
]
ASF GitHub Bot commented on GROOVY-8525:
GitHub user paulk-asert opened a pull request:
https://github.com/apache/groovy/pull/679
GROOVY-8525: Binary compatibility issue for GroovyClassLoader between…
… 2.4 vs later branches (alternative to PR#678)
What I haven't yet checked is whether we need to make some of the delegated
method calls just throw UnsupportedOperationException in order to keep the
claims like @Threadsafe.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/paulk-asert/groovy groovy8525b
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/679.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #679
commit 78dc3c8d6111ab6365f1da519bf027d634803cce
Author: Paul King
Date: 2018-03-30T23:36:57Z
GROOVY-8525: Binary compatibility issue for GroovyClassLoader between 2.4
vs later branches
> Binary compatibility issue for GroovyClassLoader between 2.4 vs later branches
> --
>
> Key: GROOVY-8525
> URL: https://issues.apache.org/jira/browse/GROOVY-8525
> Project: Groovy
> Issue Type: Task
>Reporter: Paul King
>Priority: Major
>
> Protected fields {{classCache}} and {{sourceCache}} have type
> {{EvictableCache}} instead of {{Map}} in {{java.lang.GroovyClassLoader}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8525) Binary compatibility issue for GroovyClassLoader between 2.4 vs later branches
[
https://issues.apache.org/jira/browse/GROOVY-8525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16421139#comment-16421139
]
ASF GitHub Bot commented on GROOVY-8525:
Github user danielsun1106 commented on a diff in the pull request:
https://github.com/apache/groovy/pull/679#discussion_r178419950
--- Diff:
src/main/java/org/codehaus/groovy/runtime/memoize/StampedCommonCache.java ---
@@ -175,6 +174,11 @@ private V compute(K key, ValueProvider valueProvider, bo
return doWithReadLock(c -> c.values());
}
+@Override
+public Set> entrySet() {
+return commonCache.entrySet();
--- End diff --
The code should be protected by `doWithReadLock`, we should do same thing
for `isEmpty` `containsValue`, etc.
> Binary compatibility issue for GroovyClassLoader between 2.4 vs later branches
> --
>
> Key: GROOVY-8525
> URL: https://issues.apache.org/jira/browse/GROOVY-8525
> Project: Groovy
> Issue Type: Task
>Reporter: Paul King
>Priority: Major
>
> Protected fields {{classCache}} and {{sourceCache}} have type
> {{EvictableCache}} instead of {{Map}} in {{java.lang.GroovyClassLoader}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8525) Binary compatibility issue for GroovyClassLoader between 2.4 vs later branches
[
https://issues.apache.org/jira/browse/GROOVY-8525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16421140#comment-16421140
]
ASF GitHub Bot commented on GROOVY-8525:
Github user danielsun1106 commented on a diff in the pull request:
https://github.com/apache/groovy/pull/679#discussion_r178419989
--- Diff:
src/main/java/org/codehaus/groovy/runtime/memoize/StampedCommonCache.java ---
@@ -199,20 +208,35 @@ public int size() {
return doWithReadLock(c -> c.size());
}
+@Override
+public boolean isEmpty() {
+return commonCache.isEmpty();
+}
+
/**
* {@inheritDoc}
*/
@Override
-public V remove(final K key) {
+public V remove(final Object key) {
return doWithWriteLock(c -> c.remove(key));
}
+@Override
+public void putAll(Map m) {
+
--- End diff --
The implementation is missing and should be protected by `doWithWriteLock`
> Binary compatibility issue for GroovyClassLoader between 2.4 vs later branches
> --
>
> Key: GROOVY-8525
> URL: https://issues.apache.org/jira/browse/GROOVY-8525
> Project: Groovy
> Issue Type: Task
>Reporter: Paul King
>Priority: Major
>
> Protected fields {{classCache}} and {{sourceCache}} have type
> {{EvictableCache}} instead of {{Map}} in {{java.lang.GroovyClassLoader}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8525) Binary compatibility issue for GroovyClassLoader between 2.4 vs later branches
[
https://issues.apache.org/jira/browse/GROOVY-8525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16421149#comment-16421149
]
ASF GitHub Bot commented on GROOVY-8525:
Github user paulk-asert commented on a diff in the pull request:
https://github.com/apache/groovy/pull/679#discussion_r178421016
--- Diff:
src/main/java/org/codehaus/groovy/runtime/memoize/StampedCommonCache.java ---
@@ -175,6 +174,11 @@ private V compute(K key, ValueProvider valueProvider, bo
return doWithReadLock(c -> c.values());
}
+@Override
+public Set> entrySet() {
+return commonCache.entrySet();
--- End diff --
true, but I think we have to throw UnsupportedOperationException for
entrySet and keySet because they return a view which might then be modified
under the covers without locks?
> Binary compatibility issue for GroovyClassLoader between 2.4 vs later branches
> --
>
> Key: GROOVY-8525
> URL: https://issues.apache.org/jira/browse/GROOVY-8525
> Project: Groovy
> Issue Type: Task
>Reporter: Paul King
>Priority: Major
>
> Protected fields {{classCache}} and {{sourceCache}} have type
> {{EvictableCache}} instead of {{Map}} in {{java.lang.GroovyClassLoader}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8525) Binary compatibility issue for GroovyClassLoader between 2.4 vs later branches
[
https://issues.apache.org/jira/browse/GROOVY-8525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16421150#comment-16421150
]
ASF GitHub Bot commented on GROOVY-8525:
Github user paulk-asert commented on a diff in the pull request:
https://github.com/apache/groovy/pull/679#discussion_r178421035
--- Diff:
src/main/java/org/codehaus/groovy/runtime/memoize/StampedCommonCache.java ---
@@ -199,20 +208,35 @@ public int size() {
return doWithReadLock(c -> c.size());
}
+@Override
+public boolean isEmpty() {
+return commonCache.isEmpty();
+}
+
/**
* {@inheritDoc}
*/
@Override
-public V remove(final K key) {
+public V remove(final Object key) {
return doWithWriteLock(c -> c.remove(key));
}
+@Override
+public void putAll(Map m) {
+
--- End diff --
Oops, I was wondering whether to lock for the whole putAll or loop and lock
per entry and then forgot to supply either! I'll do the former for now.
> Binary compatibility issue for GroovyClassLoader between 2.4 vs later branches
> --
>
> Key: GROOVY-8525
> URL: https://issues.apache.org/jira/browse/GROOVY-8525
> Project: Groovy
> Issue Type: Task
>Reporter: Paul King
>Priority: Major
>
> Protected fields {{classCache}} and {{sourceCache}} have type
> {{EvictableCache}} instead of {{Map}} in {{java.lang.GroovyClassLoader}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8525) Binary compatibility issue for GroovyClassLoader between 2.4 vs later branches
[
https://issues.apache.org/jira/browse/GROOVY-8525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16421151#comment-16421151
]
ASF GitHub Bot commented on GROOVY-8525:
Github user danielsun1106 commented on a diff in the pull request:
https://github.com/apache/groovy/pull/679#discussion_r178421232
--- Diff:
src/main/java/org/codehaus/groovy/runtime/memoize/StampedCommonCache.java ---
@@ -175,6 +174,11 @@ private V compute(K key, ValueProvider valueProvider, bo
return doWithReadLock(c -> c.values());
}
+@Override
+public Set> entrySet() {
+return commonCache.entrySet();
--- End diff --
Implementing an interface and throwing `UnsupportedOperationException` does
not look elegant...
> Binary compatibility issue for GroovyClassLoader between 2.4 vs later branches
> --
>
> Key: GROOVY-8525
> URL: https://issues.apache.org/jira/browse/GROOVY-8525
> Project: Groovy
> Issue Type: Task
>Reporter: Paul King
>Priority: Major
>
> Protected fields {{classCache}} and {{sourceCache}} have type
> {{EvictableCache}} instead of {{Map}} in {{java.lang.GroovyClassLoader}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8525) Binary compatibility issue for GroovyClassLoader between 2.4 vs later branches
[
https://issues.apache.org/jira/browse/GROOVY-8525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16421167#comment-16421167
]
ASF GitHub Bot commented on GROOVY-8525:
Github user paulk-asert commented on a diff in the pull request:
https://github.com/apache/groovy/pull/679#discussion_r178422137
--- Diff:
src/main/java/org/codehaus/groovy/runtime/memoize/StampedCommonCache.java ---
@@ -175,6 +174,11 @@ private V compute(K key, ValueProvider valueProvider, bo
return doWithReadLock(c -> c.values());
}
+@Override
+public Set> entrySet() {
+return commonCache.entrySet();
--- End diff --
Inelegant but the Java collections way! ;-) Better to look inelegant rather
than provide an apparently good looking but buggy implementation! In any case,
I have implemented entrySet() in the same way as keys() and values() are
implemented. The concern though is that if you look at ConcurrentHashMap,
keySet(), entrySet() and values() are backed by views using iterators and
spliterators that guarantee "weak consistency". It doesn't seem like we are
making any such considerations for StampedCommonCache? I will leave that as a
future exercise - we can always create such views or throw
UnsupportedOperationException if we deem there is no other way to be safe.
> Binary compatibility issue for GroovyClassLoader between 2.4 vs later branches
> --
>
> Key: GROOVY-8525
> URL: https://issues.apache.org/jira/browse/GROOVY-8525
> Project: Groovy
> Issue Type: Task
>Reporter: Paul King
>Priority: Major
>
> Protected fields {{classCache}} and {{sourceCache}} have type
> {{EvictableCache}} instead of {{Map}} in {{java.lang.GroovyClassLoader}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8525) Binary compatibility issue for GroovyClassLoader between 2.4 vs later branches
[
https://issues.apache.org/jira/browse/GROOVY-8525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16421173#comment-16421173
]
ASF GitHub Bot commented on GROOVY-8525:
Github user danielsun1106 commented on a diff in the pull request:
https://github.com/apache/groovy/pull/679#discussion_r178422703
--- Diff:
src/main/java/org/codehaus/groovy/runtime/memoize/StampedCommonCache.java ---
@@ -175,6 +174,11 @@ private V compute(K key, ValueProvider valueProvider, bo
return doWithReadLock(c -> c.values());
}
+@Override
+public Set> entrySet() {
+return commonCache.entrySet();
--- End diff --
I will set aside some time to complete the exercise 😉
> Binary compatibility issue for GroovyClassLoader between 2.4 vs later branches
> --
>
> Key: GROOVY-8525
> URL: https://issues.apache.org/jira/browse/GROOVY-8525
> Project: Groovy
> Issue Type: Task
>Reporter: Paul King
>Priority: Major
>
> Protected fields {{classCache}} and {{sourceCache}} have type
> {{EvictableCache}} instead of {{Map}} in {{java.lang.GroovyClassLoader}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8525) Binary compatibility issue for GroovyClassLoader between 2.4 vs later branches
[
https://issues.apache.org/jira/browse/GROOVY-8525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16421182#comment-16421182
]
ASF GitHub Bot commented on GROOVY-8525:
Github user asfgit closed the pull request at:
https://github.com/apache/groovy/pull/679
> Binary compatibility issue for GroovyClassLoader between 2.4 vs later branches
> --
>
> Key: GROOVY-8525
> URL: https://issues.apache.org/jira/browse/GROOVY-8525
> Project: Groovy
> Issue Type: Task
>Reporter: Paul King
>Priority: Major
>
> Protected fields {{classCache}} and {{sourceCache}} have type
> {{EvictableCache}} instead of {{Map}} in {{java.lang.GroovyClassLoader}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8525) Binary compatibility issue for GroovyClassLoader between 2.4 vs later branches
[
https://issues.apache.org/jira/browse/GROOVY-8525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16421197#comment-16421197
]
ASF GitHub Bot commented on GROOVY-8525:
Github user paulk-asert closed the pull request at:
https://github.com/apache/groovy/pull/678
> Binary compatibility issue for GroovyClassLoader between 2.4 vs later branches
> --
>
> Key: GROOVY-8525
> URL: https://issues.apache.org/jira/browse/GROOVY-8525
> Project: Groovy
> Issue Type: Task
>Reporter: Paul King
>Priority: Major
>
> Protected fields {{classCache}} and {{sourceCache}} have type
> {{EvictableCache}} instead of {{Map}} in {{java.lang.GroovyClassLoader}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8514) NullPointerException in class MissingMethodException
[
https://issues.apache.org/jira/browse/GROOVY-8514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16421293#comment-16421293
]
ASF GitHub Bot commented on GROOVY-8514:
Github user asfgit closed the pull request at:
https://github.com/apache/groovy/pull/675
> NullPointerException in class MissingMethodException
>
>
> Key: GROOVY-8514
> URL: https://issues.apache.org/jira/browse/GROOVY-8514
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.14
>Reporter: Dennis K
>Assignee: Paul King
>Priority: Major
> Fix For: 2.4.15
>
>
> The class {{MissingMethodException}} throws an {{NullPointerException}} on
> {{getMessage()}} if {{arguments}} are null.
> This can happen, if the someone calls {{GroovyScriptEngineImpl.getInterface}}
> and invokes a method without arguments on that interface. And the method is
> not defined in the groovy script.
> The {{InvocationHandler}} calls the method {{invokeImpl}} with {{null}} as
> arguments, because the interface method has no arguments. If the Method is
> not defined in the groovy script. A {{MissingMethodException}} is thrown and
> catched. Than the following {{NoSuchMethodException(var5.getMessage());}} is
> thrown. But {{getMessage()}} itself throws an NPE due to {{arguments}} is
> null.
> From the Java Documentation
> [InvocationHandler|https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/InvocationHandler.html]
> {quote}args - an array of objects containing the values of the arguments
> passed in the method invocation on the proxy instance, or null if interface
> method takes no arguments. Arguments of primitive types are wrapped in
> instances of the appropriate primitive wrapper class, such as
> java.lang.Integer or java.lang.Boolean.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8523) Static type checking instanceof
[
https://issues.apache.org/jira/browse/GROOVY-8523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16421941#comment-16421941
]
ASF GitHub Bot commented on GROOVY-8523:
GitHub user nikchugunov opened a pull request:
https://github.com/apache/groovy/pull/680
GROOVY-8523 Static type checking instanceof_not
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/nikchugunov/groovy master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/680.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #680
commit ada5660cea287e19543de2133b270272d0c9b329
Author: venkato
Date: 2018-04-01T20:13:23Z
GROOVY-8523 Static type checking instanceof
commit e63447e6c75754bef21507264703993d6496c16d
Author: venkato
Date: 2018-04-01T20:17:06Z
GROOVY-8523 Static type checking instanceof
commit 250bc0d3e4606f3e3ebcc3f1231ddcf4b5c89dee
Author: venkato
Date: 2018-04-02T05:58:00Z
GROOVY-8523 Static type checking instanceof
commit 1c220beb02fc5be3626f961e311a1dece82636bf
Author: venkato
Date: 2018-04-02T06:18:06Z
GROOVY-8523 Static type checking instanceof
> Static type checking instanceof
> ---
>
> Key: GROOVY-8523
> URL: https://issues.apache.org/jira/browse/GROOVY-8523
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.13
>Reporter: Nikolay Chugunov
>Priority: Minor
>
> Now following code failed to compile :
> {code}
> @CompileStatic
> class Gr {
> void f1(Object obj) {
> if (!(obj instanceof Runnable)) {
> return
> }
> f3(obj) // failed compiled here : Cannot find matching method
> Gr#f3(java.lang.Object).
> }
> void f3(Runnable r) { }
> }
> {code}
> I have implemented fix and can submit fix, if needed.
> Idea doesn't highlight this code as error, but groovy compiler failed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8523) Static type checking instanceof
[
https://issues.apache.org/jira/browse/GROOVY-8523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16423274#comment-16423274
]
ASF GitHub Bot commented on GROOVY-8523:
Github user asfgit closed the pull request at:
https://github.com/apache/groovy/pull/680
> Static type checking instanceof
> ---
>
> Key: GROOVY-8523
> URL: https://issues.apache.org/jira/browse/GROOVY-8523
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.13
>Reporter: Nikolay Chugunov
>Priority: Minor
>
> Now following code failed to compile :
> {code}
> @CompileStatic
> class Gr {
> void f1(Object obj) {
> if (!(obj instanceof Runnable)) {
> return
> }
> f3(obj) // failed compiled here : Cannot find matching method
> Gr#f3(java.lang.Object).
> }
> void f3(Runnable r) { }
> }
> {code}
> I have implemented fix and can submit fix, if needed.
> Idea doesn't highlight this code as error, but groovy compiler failed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-4585) backslash can not be escaped by `SimpleTemplateEngine`
[
https://issues.apache.org/jira/browse/GROOVY-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16428345#comment-16428345
]
ASF GitHub Bot commented on GROOVY-4585:
GitHub user danielsun1106 opened a pull request:
https://github.com/apache/groovy/pull/681
GROOVY-4585: backslash can not be escaped by `SimpleTemplateEngine`
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/danielsun1106/groovy GROOVY-4585
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/681.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #681
commit 4b44cb1a78e7cfc512f69f2cdc4ba9d0359d99d9
Author: Daniel Sun
Date: 2018-04-06T13:44:49Z
GROOVY-4585: backslash can not be escaped by `SimpleTemplateEngine`
> backslash can not be escaped by `SimpleTemplateEngine`
> --
>
> Key: GROOVY-4585
> URL: https://issues.apache.org/jira/browse/GROOVY-4585
> Project: Groovy
> Issue Type: Improvement
> Components: Templating
>Affects Versions: 1.8-beta-2
> Environment: jdk1.6u16, windows xp
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 1.8-beta-4
>
> Attachments: SimpleTemplateEngine.java.patch,
> SimpleTemplateEngine.java.v2.patch, TEST_for_GROOVY-4585.groovy,
> testcase.v2.zip
>
>
> 1, bug:fail to escape back slash
> If a back slash(\) in the template, SimpleTemplateEngine can not escape it,
> as a result, an exception throwed.
> 2, new feature: add support to escape dollar char
> Now we can escape dollar char with dollar char, for example: $$
> Enjoy the patch ;)
> {code}
> import groovy.text.*
> String templateContent = new
> File(/D:\_APPS\groovy_apps\TemplateEnginTest\echo.xml/).text
> def engineForBuildXml = new SimpleTemplateEngine()
> def templateForBuildXml = engineForBuildXml.createTemplate(templateContent)
> String buildXmlContent = templateForBuildXml.make([names:['a', 'b',
> 'c']]).toString()
> println buildXmlContent
> {code}
> {code}
>
>
>
>
> <%for (int i = 0; i < names.size(); i++) {%>
>
>
>
> <%}%>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-4585) backslash can not be escaped by `SimpleTemplateEngine`
[
https://issues.apache.org/jira/browse/GROOVY-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16428385#comment-16428385
]
ASF GitHub Bot commented on GROOVY-4585:
Github user asfgit closed the pull request at:
https://github.com/apache/groovy/pull/681
> backslash can not be escaped by `SimpleTemplateEngine`
> --
>
> Key: GROOVY-4585
> URL: https://issues.apache.org/jira/browse/GROOVY-4585
> Project: Groovy
> Issue Type: Improvement
> Components: Templating
>Affects Versions: 3.0.0-alpha-1, 2.6.0-alpha-3, 2.5.0-rc-1, 2.4.15
> Environment: jdk1.6u16, windows xp
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 3.0.0-alpha-2, 2.6.0-alpha-4, 2.4.16, 2.5.0-rc-2
>
> Attachments: SimpleTemplateEngine.java.patch,
> SimpleTemplateEngine.java.v2.patch, TEST_for_GROOVY-4585.groovy,
> testcase.v2.zip
>
>
> 1, bug:fail to escape back slash
> If a back slash(\) in the template, SimpleTemplateEngine can not escape it,
> as a result, an exception throwed.
> 2, new feature: add support to escape dollar char
> Now we can escape dollar char with dollar char, for example: $$
> Enjoy the patch ;)
> {code}
> import groovy.text.*
> String templateContent = new
> File(/D:\_APPS\groovy_apps\TemplateEnginTest\echo.xml/).text
> def engineForBuildXml = new SimpleTemplateEngine()
> def templateForBuildXml = engineForBuildXml.createTemplate(templateContent)
> String buildXmlContent = templateForBuildXml.make([names:['a', 'b',
> 'c']]).toString()
> println buildXmlContent
> {code}
> {code}
>
>
>
>
> <%for (int i = 0; i < names.size(); i++) {%>
>
>
>
> <%}%>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8537) GroovyCollections.combinations(Iterable) exhibits incorrect (asymmetric) behavior
[
https://issues.apache.org/jira/browse/GROOVY-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16429825#comment-16429825
]
ASF GitHub Bot commented on GROOVY-8537:
GitHub user rvprasad opened a pull request:
https://github.com/apache/groovy/pull/682
GroovyCollections.combinations(Iterable) exhibits incorrect (asymmetric)
behavior.
The fix ensures no combination is returned if any of the input iterables to
GroovyCollections.combinations() is empty.
https://issues.apache.org/jira/browse/GROOVY-8537
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/rvprasad/groovy GROOVY-8537
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/682.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #682
commit 8e6d955f7a519dbeac737b77930d7007d9681912
Author: Venkatesh-Prasad Ranganath
Date: 2018-04-08T17:45:18Z
Fixes issue GROOVY-8537
Ensures no combination is returned if any of the input iterables to
GroovyCollections.combinations() is empty.
> GroovyCollections.combinations(Iterable) exhibits incorrect (asymmetric)
> behavior
> -
>
> Key: GROOVY-8537
> URL: https://issues.apache.org/jira/browse/GROOVY-8537
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Affects Versions: 2.4.15
>Reporter: Venkatesh-Prasad Ranganath
>Priority: Major
> Labels: easyfix
>
> h4. *Issue*
> When GroovyCollections.combinations() is invoked on a collection of iterables
> with at least one empty iterable, the expected return value is an empty list
> of combinations.
> Instead, in version 2.4.15 (and I am guessing in earlier versions at least
> since 2.2.0), the return value of combinations() is sensitive to the order of
> iterables in the input collection. Here are two instances of such behavior.
> h4. Repro
> {{groovy:000> assert [[1,3], []].combinations() == [[],
> [1,3]].combinations()}}
> {{ERROR org.codehaus.groovy.runtime.powerassert.PowerAssertionError:}}
> {{assert [[1,3], []].combinations() == [[], [1,3]].combinations()}}
> {{ | | |}}
> {{ [] false [[1], [3]]}}
>
> {{groovy:000> assert [[1,3], [2], []].combinations() == [[1,3], [],
> [2]].combinations()}}
> {{ERROR org.codehaus.groovy.runtime.powerassert.PowerAssertionError:}}
> {{assert [[1,3], [2], []].combinations() == [[1,3], [], [2]].combinations()}}
> {{ | | |}}
> {{ [] false [[2]]}}
> h4. *Fix*
> Add a short-circuiting check at the start of combinations(Iterable) method to
> return an empty list of combination if any of the input iterables are empty.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8539) Groovy fails to compile assignment operators on boolean array
[ https://issues.apache.org/jira/browse/GROOVY-8539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16433456#comment-16433456 ] ASF GitHub Bot commented on GROOVY-8539: GitHub user paulk-asert opened a pull request: https://github.com/apache/groovy/pull/683 GROOVY-8539: Groovy fails to compile assignment operators on boolean … …array You can merge this pull request into a Git repository by running: $ git pull https://github.com/paulk-asert/groovy groovy8539 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/683.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #683 commit f8a0c55bb9bd69c298bcbcf763a43e6031e24b34 Author: Paul King Date: 2018-04-11T06:12:59Z GROOVY-8539: Groovy fails to compile assignment operators on boolean array > Groovy fails to compile assignment operators on boolean array > - > > Key: GROOVY-8539 > URL: https://issues.apache.org/jira/browse/GROOVY-8539 > Project: Groovy > Issue Type: Bug > Components: class generator >Affects Versions: 3.0.0-alpha-1, 2.4.15 >Reporter: Tony Yoshicedo >Priority: Major > > Groovy fails to compile: > boolean[] b = [true]; b[0] &= false; > with an error: > Caught: BUG! exception in phase 'class generation' in source unit > 'script_from_command_line' should not reach here > BUG! exception in phase 'class generation' in source unit > 'script_from_command_line' should not reach here > when running: > groovy -e "boolean[] b = [true]; b[0] &= false;" > Alternative formats work fine, such as: > groovy -e "boolean[] b = [true]; b[0] = false && b[0];" > Similarly affects |= and ^= operators. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8537) GroovyCollections.combinations(Iterable) exhibits incorrect (asymmetric) behavior
[
https://issues.apache.org/jira/browse/GROOVY-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16433474#comment-16433474
]
ASF GitHub Bot commented on GROOVY-8537:
Github user asfgit closed the pull request at:
https://github.com/apache/groovy/pull/682
> GroovyCollections.combinations(Iterable) exhibits incorrect (asymmetric)
> behavior
> -
>
> Key: GROOVY-8537
> URL: https://issues.apache.org/jira/browse/GROOVY-8537
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Affects Versions: 2.4.15
>Reporter: Venkatesh-Prasad Ranganath
>Priority: Major
> Labels: easyfix
>
> h4. *Issue*
> When GroovyCollections.combinations() is invoked on a collection of iterables
> with at least one empty iterable, the expected return value is an empty list
> of combinations.
> Instead, in version 2.4.15 (and I am guessing in earlier versions at least
> since 2.2.0), the return value of combinations() is sensitive to the order of
> iterables in the input collection. Here are two instances of such behavior.
> h4. Repro
> {{groovy:000> assert [[1,3], []].combinations() == [[],
> [1,3]].combinations()}}
> {{ERROR org.codehaus.groovy.runtime.powerassert.PowerAssertionError:}}
> {{assert [[1,3], []].combinations() == [[], [1,3]].combinations()}}
> {{ | | |}}
> {{ [] false [[1], [3]]}}
>
> {{groovy:000> assert [[1,3], [2], []].combinations() == [[1,3], [],
> [2]].combinations()}}
> {{ERROR org.codehaus.groovy.runtime.powerassert.PowerAssertionError:}}
> {{assert [[1,3], [2], []].combinations() == [[1,3], [], [2]].combinations()}}
> {{ | | |}}
> {{ [] false [[2]]}}
> h4. *Fix*
> Add a short-circuiting check at the start of combinations(Iterable) method to
> return an empty list of combination if any of the input iterables are empty.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8539) Groovy fails to compile assignment operators on boolean array
[ https://issues.apache.org/jira/browse/GROOVY-8539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16436004#comment-16436004 ] ASF GitHub Bot commented on GROOVY-8539: Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/683 > Groovy fails to compile assignment operators on boolean array > - > > Key: GROOVY-8539 > URL: https://issues.apache.org/jira/browse/GROOVY-8539 > Project: Groovy > Issue Type: Bug > Components: class generator >Affects Versions: 3.0.0-alpha-1, 2.4.15 >Reporter: Tony Yoshicedo >Priority: Major > > Groovy fails to compile: > boolean[] b = [true]; b[0] &= false; > with an error: > Caught: BUG! exception in phase 'class generation' in source unit > 'script_from_command_line' should not reach here > BUG! exception in phase 'class generation' in source unit > 'script_from_command_line' should not reach here > when running: > groovy -e "boolean[] b = [true]; b[0] &= false;" > Alternative formats work fine, such as: > groovy -e "boolean[] b = [true]; b[0] = false && b[0];" > Similarly affects |= and ^= operators. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8520) Replace commons-cli with picocli in CliBuilder
[ https://issues.apache.org/jira/browse/GROOVY-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16443429#comment-16443429 ] ASF GitHub Bot commented on GROOVY-8520: GitHub user remkop opened a pull request: https://github.com/apache/groovy/pull/687 Groovy-8520 picocli-based CliBuilder Details are in the JIRA: https://issues.apache.org/jira/browse/GROOVY-8520 You can merge this pull request into a Git repository by running: $ git pull https://github.com/remkop/groovy GROOVY_2_5_X Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/687.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #687 commit ecd3060e0b3943feacb1d575f6e78b2e5c5fade0 Author: Remko Popma Date: 2018-04-03T12:05:54Z GROOVY-8520 initial version of migrating CliBuilder from commons-cli to picocli commit 16645af5c8f49cb190b72166e1ee2b59fa1fcdf1 Author: Remko Popma Date: 2018-04-03T12:07:53Z Merge remote-tracking branch 'upstream/GROOVY_2_5_X' into GROOVY_2_5_X commit 979d2f974b958b109a2e3ea4562a8666de7406c0 Author: Remko Popma Date: 2018-04-04T14:53:08Z GROOVY-8520 fix failing test CliBuilderTest.testConvertClass commit c42284afefeff6586e5afe51b3367b84c90fabcf Author: Remko Popma Date: 2018-04-04T14:57:49Z GROOVY-8520 fix failing test CliBuilderTest.testParseFromInstance: method invocation parameters must be an array commit b9e5ca6c5c1ac0047284812650637435cd462f6e Author: Remko Popma Date: 2018-04-04T15:37:25Z GROOVY-8520 cleanup: remove unused code (TypedOption not used any more) commit 261181a841f6be85b18f54b2cbb31137aaf548ab Author: Remko Popma Date: 2018-04-04T16:10:03Z GROOVY-8520 for multi-value options, cli.optionName should return the first element in the list commit 69f2660bef3d24a120a64846d1eaa50e3335fc58 Author: Remko Popma Date: 2018-04-04T16:33:45Z GROOVY-8520 fix failing CliBuilderTest.testMixedBurstingAndLongOptions: to be backwards compatible, longOpt names should be registered with both a single hyphen and with two hyphens in picocli. commit c405cfdd3198e1be73081a5ec6b2395c4149d474 Author: Remko Popma Date: 2018-04-04T16:38:01Z GROOVY-8520 fix CliBuilderTest.testMixedBurstingAndLongOptions: if you reuse the same CliBuilder instance multiple times, the previous parse result interacts with the next parse result (e.g., boolean flags are toggled, collections are added to, etc) commit bc0005254a50184a24fef337eabae896375787ac Author: Remko Popma Date: 2018-04-04T17:25:00Z GROOVY-8520 add back methods to OptionAccessor commit 5ea2733adf80ef48335d20e99cfe68c846287afd Author: Remko Popma Date: 2018-04-04T18:04:13Z GROOVY-8520 remove dependency on commons-cli from CliBuilderTest commit 7c1530e7d873bfce9e8b3d549f18a2b20a2c1776 Author: Remko Popma Date: 2018-04-05T23:19:55Z GROOVY-8520 bugfixes, revert TypedOption, support name property, suppress trace output commit 29dab5f62abb8f1ad67e31e52ca422002d3c9024 Author: Remko Popma Date: 2018-04-05T23:21:11Z GROOVY-8520 expected output of usage help message is different with picocli commit d0cf7a2035524ea13249ac1ae2379ee949aaa77c Author: Remko Popma Date: 2018-04-06T14:35:02Z GROOVY-8520 replace Unmatched with PositionalParams to support strongly typed @Unparsed fields/methods commit 1821e98fb85432bd8fa7ff144105782e62b3113f Author: Remko Popma Date: 2018-04-06T14:37:30Z GROOVY-8520 Fix test: should not reuse CliBuilder instance for new input commit 7668333c8010e2a9d2866a92ad2c75e9b13c820b Author: Remko Popma Date: 2018-04-06T17:02:17Z Merge remote-tracking branch 'upstream/GROOVY_2_5_X' into GROOVY_2_5_X commit c342b2ea9a9a63649415a8b373d62b10fae4d474 Author: Remko Popma Date: 2018-04-10T13:08:26Z GROOVY-8520 use new picocli-3.0.0-alpha-5 API, fix many bugs commit e6652b9acdbf049fae1ef91a013db371d27bfee5 Author: Remko Popma Date: 2018-04-10T18:25:34Z GROOVY-8520 fix failing test commit 6a913e0dec8adbaf72b1a7836599be51061d2b1a Author: Remko Popma Date: 2018-04-10T18:27:38Z GROOVY-8520 create new CliBuilder instance before parsing commit 699521b019527b38bf1914949d8d8da211ec28af Author: Remko Popma Date: 2018-04-10T18:28:38Z GROOVY-8520 create new CliBuilder instance before parsing commit eb5aab2b0bdbe3b125f5b19573f631554c430891 Author: Remko Popma Date: 2018-04-10T18:33:18Z Merge remote-tracking branch 'upstream/GROOVY_2_5_X' into GROOVY_2_5_X commit 98dbd9108d1f543a56ef573af8ea4c175121f2f2 Author: Remko Popma Date: 2018-04-10T18:34:06Z GROOVY-8520 bump picocliVersion to v3.0.0-alpha-5 commit 29174a7c0bc99a7d0491aa68f1d0e1f0c91dc5a2 Author: Remko Popma Date: 2018-04-12T13:52:59Z GROOVY-8520 no need to create n
[jira] [Commented] (GROOVY-8520) Replace commons-cli with picocli in CliBuilder
[
https://issues.apache.org/jira/browse/GROOVY-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16446913#comment-16446913
]
ASF GitHub Bot commented on GROOVY-8520:
GitHub user remkop opened a pull request:
https://github.com/apache/groovy/pull/688
GROOVY-8520 add picocli-based CliBuilder
Rebased on the GROOVY_2_5_X branch with all commits squashed.
Requires picocli 3.0.0-beta-2.
Renamed package to {{groovy.cli.picocli}}.
{{groovy.cli.picocli.CliBuilder}} is now fully compatible with the
commons-cli based {{groovy.util.CliBuilder}}.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/remkop/groovy GROOVY_2_5_X_squashed
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/688.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #688
commit f11195d554932b75d583383b80ba79ed271d95a9
Author: Remko Popma
Date: 2018-04-20T23:01:02Z
GROOVY-8520 add picocli-based CliBuilder
> Replace commons-cli with picocli in CliBuilder
> --
>
> Key: GROOVY-8520
> URL: https://issues.apache.org/jira/browse/GROOVY-8520
> Project: Groovy
> Issue Type: Improvement
> Components: command line processing
>Reporter: Remko Popma
>Priority: Major
>
> This ticket proposes to replace commons-cli with picocli in
> {{groovy.util.CliBuilder}}.
> See [discussion on the mailing
> list|https://lists.apache.org/thread.html/d60b6d5d4411e9ba0d7dc209cde8a9bb4abb00f0b9c0322f068c322e@%3Cdev.groovy.apache.org%3E]
> for the original proposal and comparison with other CLI libraries.
> Goals for the initial implementation:
> * preserve the current CliBuilder behaviour as much as possible
> * deliver an implementation, tests and documentation in time to be included
> in the 2.5 GA release
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8520) Replace commons-cli with picocli in CliBuilder
[
https://issues.apache.org/jira/browse/GROOVY-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16446915#comment-16446915
]
ASF GitHub Bot commented on GROOVY-8520:
Github user remkop closed the pull request at:
https://github.com/apache/groovy/pull/687
> Replace commons-cli with picocli in CliBuilder
> --
>
> Key: GROOVY-8520
> URL: https://issues.apache.org/jira/browse/GROOVY-8520
> Project: Groovy
> Issue Type: Improvement
> Components: command line processing
>Reporter: Remko Popma
>Priority: Major
>
> This ticket proposes to replace commons-cli with picocli in
> {{groovy.util.CliBuilder}}.
> See [discussion on the mailing
> list|https://lists.apache.org/thread.html/d60b6d5d4411e9ba0d7dc209cde8a9bb4abb00f0b9c0322f068c322e@%3Cdev.groovy.apache.org%3E]
> for the original proposal and comparison with other CLI libraries.
> Goals for the initial implementation:
> * preserve the current CliBuilder behaviour as much as possible
> * deliver an implementation, tests and documentation in time to be included
> in the 2.5 GA release
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8558) Add DGM `whichJar` to get the url of the jar containing the specified class
[ https://issues.apache.org/jira/browse/GROOVY-8558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16449388#comment-16449388 ] ASF GitHub Bot commented on GROOVY-8558: Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/690 > Add DGM `whichJar` to get the url of the jar containing the specified class > --- > > Key: GROOVY-8558 > URL: https://issues.apache.org/jira/browse/GROOVY-8558 > Project: Groovy > Issue Type: New Feature >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Minor > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8520) Replace commons-cli with picocli in CliBuilder
[
https://issues.apache.org/jira/browse/GROOVY-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16457180#comment-16457180
]
ASF GitHub Bot commented on GROOVY-8520:
Github user asfgit closed the pull request at:
https://github.com/apache/groovy/pull/688
> Replace commons-cli with picocli in CliBuilder
> --
>
> Key: GROOVY-8520
> URL: https://issues.apache.org/jira/browse/GROOVY-8520
> Project: Groovy
> Issue Type: Improvement
> Components: command line processing
>Reporter: Remko Popma
>Priority: Major
>
> This ticket proposes to replace commons-cli with picocli in
> {{groovy.util.CliBuilder}}.
> See [discussion on the mailing
> list|https://lists.apache.org/thread.html/d60b6d5d4411e9ba0d7dc209cde8a9bb4abb00f0b9c0322f068c322e@%3Cdev.groovy.apache.org%3E]
> for the original proposal and comparison with other CLI libraries.
> Goals for the initial implementation:
> * preserve the current CliBuilder behaviour as much as possible
> * deliver an implementation, tests and documentation in time to be included
> in the 2.5 GA release
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8520) Replace commons-cli with picocli in CliBuilder
[
https://issues.apache.org/jira/browse/GROOVY-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16458243#comment-16458243
]
ASF GitHub Bot commented on GROOVY-8520:
GitHub user remkop opened a pull request:
https://github.com/apache/groovy/pull/692
GROOVY-8520 CliBuilder groovydoc improvements
Groovy-doc improvements for CliBuilder.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/remkop/groovy master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/692.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #692
commit f115ef292b859f3035a2894d438679e1d39268ad
Author: Remko Popma
Date: 2018-04-29T23:39:40Z
GROOVY-8520 CliBuilder groovydoc improvements
> Replace commons-cli with picocli in CliBuilder
> --
>
> Key: GROOVY-8520
> URL: https://issues.apache.org/jira/browse/GROOVY-8520
> Project: Groovy
> Issue Type: Improvement
> Components: command line processing
>Reporter: Remko Popma
>Priority: Major
>
> This ticket proposes to replace commons-cli with picocli in
> {{groovy.util.CliBuilder}}.
> See [discussion on the mailing
> list|https://lists.apache.org/thread.html/d60b6d5d4411e9ba0d7dc209cde8a9bb4abb00f0b9c0322f068c322e@%3Cdev.groovy.apache.org%3E]
> for the original proposal and comparison with other CLI libraries.
> Goals for the initial implementation:
> * preserve the current CliBuilder behaviour as much as possible
> * deliver an implementation, tests and documentation in time to be included
> in the 2.5 GA release
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8520) Replace commons-cli with picocli in CliBuilder
[
https://issues.apache.org/jira/browse/GROOVY-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16459561#comment-16459561
]
ASF GitHub Bot commented on GROOVY-8520:
Github user asfgit closed the pull request at:
https://github.com/apache/groovy/pull/692
> Replace commons-cli with picocli in CliBuilder
> --
>
> Key: GROOVY-8520
> URL: https://issues.apache.org/jira/browse/GROOVY-8520
> Project: Groovy
> Issue Type: Improvement
> Components: command line processing
>Reporter: Remko Popma
>Priority: Major
>
> This ticket proposes to replace commons-cli with picocli in
> {{groovy.util.CliBuilder}}.
> See [discussion on the mailing
> list|https://lists.apache.org/thread.html/d60b6d5d4411e9ba0d7dc209cde8a9bb4abb00f0b9c0322f068c322e@%3Cdev.groovy.apache.org%3E]
> for the original proposal and comparison with other CLI libraries.
> Goals for the initial implementation:
> * preserve the current CliBuilder behaviour as much as possible
> * deliver an implementation, tests and documentation in time to be included
> in the 2.5 GA release
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-3867) Allow methodMissing/propertyMissing to be defined through category
[ https://issues.apache.org/jira/browse/GROOVY-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16462038#comment-16462038 ] ASF GitHub Bot commented on GROOVY-3867: GitHub user ecerulm opened a pull request: https://github.com/apache/groovy/pull/693 Allow methodMissing/propertyMissing to be defined through category Resolves GROOVY-3867 You can merge this pull request into a Git repository by running: $ git pull https://github.com/ecerulm/groovy GROOVY-3867-pq Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/693.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #693 commit 8d6af73c53d0f0ad8c2e7b72d214ba732b14e8ee Author: Ruben Laguna Date: 2018-05-01T10:07:54Z Allow methodMissing/propertyMissing to be defined through category Resolves GROOVY-3867 > Allow methodMissing/propertyMissing to be defined through category > -- > > Key: GROOVY-3867 > URL: https://issues.apache.org/jira/browse/GROOVY-3867 > Project: Groovy > Issue Type: Improvement > Components: groovy-runtime >Affects Versions: 1.6.5 >Reporter: Kohsuke Kawaguchi >Priority: Major > Attachments: categoryAndMissingMethodFailingTest.patch > > > When integrating a library defined by a 3rd party into Groovy, it's often > convenient to be able to define missing method/property receiver. Since I > can't modify the library directly, it would be great if this can be achieved > via category. > In the current MetaClassImpl implementation, category isn't searched for a > missing method/property receiver. > Note that the generic "Object get(String name)" serves as a replacement for > propertyMissing, but there's nothing like that for methods. Plus the get > method isn't invoked for "foo.someMethod(...)" even though it works for > "(foo.someMethod)(...)" due to the difference in the property look up and > method invocation handling. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-3867) Allow methodMissing/propertyMissing to be defined through category
[ https://issues.apache.org/jira/browse/GROOVY-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16463204#comment-16463204 ] ASF GitHub Bot commented on GROOVY-3867: Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/693 > Allow methodMissing/propertyMissing to be defined through category > -- > > Key: GROOVY-3867 > URL: https://issues.apache.org/jira/browse/GROOVY-3867 > Project: Groovy > Issue Type: Improvement > Components: groovy-runtime >Affects Versions: 1.6.5 >Reporter: Kohsuke Kawaguchi >Priority: Major > Attachments: categoryAndMissingMethodFailingTest.patch > > > When integrating a library defined by a 3rd party into Groovy, it's often > convenient to be able to define missing method/property receiver. Since I > can't modify the library directly, it would be great if this can be achieved > via category. > In the current MetaClassImpl implementation, category isn't searched for a > missing method/property receiver. > Note that the generic "Object get(String name)" serves as a replacement for > propertyMissing, but there's nothing like that for methods. Plus the get > method isn't invoked for "foo.someMethod(...)" even though it works for > "(foo.someMethod)(...)" due to the difference in the property look up and > method invocation handling. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8567) Migrate Groovyc to picocli
[
https://issues.apache.org/jira/browse/GROOVY-8567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16463499#comment-16463499
]
ASF GitHub Bot commented on GROOVY-8567:
GitHub user remkop opened a pull request:
https://github.com/apache/groovy/pull/694
GROOVY-8567 Migrate Groovyc to picocli
GROOVY-8567 Migrate Groovyc to picocli
See comments in the JIRA ticket.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/remkop/groovy master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/694.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #694
commit f115ef292b859f3035a2894d438679e1d39268ad
Author: Remko Popma
Date: 2018-04-29T23:39:40Z
GROOVY-8520 CliBuilder groovydoc improvements
commit 10a7a3c6dc8a4974a4ed7fd1b35adabcd079eaa9
Author: Remko Popma
Date: 2018-05-01T21:33:42Z
Merge remote-tracking branch 'upstream/master'
commit de3c3a8bcd04a4c05cbf605100f1a029417ccb17
Author: Remko Popma
Date: 2018-05-03T13:53:26Z
Merge remote-tracking branch 'upstream/master'
commit c1fd6cf55b5c59cf08a5efdaabc91b9656296690
Author: Remko Popma
Date: 2018-05-04T07:35:05Z
Merge remote-tracking branch 'upstream/master'
commit 4679fc5ee2ec823e22c3d5375f651c255dbd0bed
Author: Remko Popma
Date: 2018-05-04T07:35:42Z
GROOVY-8567 Migrate Groovyc to picocli
> Migrate Groovyc to picocli
> --
>
> Key: GROOVY-8567
> URL: https://issues.apache.org/jira/browse/GROOVY-8567
> Project: Groovy
> Issue Type: Task
> Components: command line processing
>Reporter: Remko Popma
>Priority: Major
> Fix For: 2.5.x
>
>
> Migrate {{org.codehaus.groovy.ant.Groovyc}} from commons-cli to picocli.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8567) Migrate Groovyc to picocli
[
https://issues.apache.org/jira/browse/GROOVY-8567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16463544#comment-16463544
]
ASF GitHub Bot commented on GROOVY-8567:
Github user paulk-asert commented on a diff in the pull request:
https://github.com/apache/groovy/pull/694#discussion_r186015291
--- Diff: src/main/java/org/codehaus/groovy/tools/FileSystemCompiler.java
---
@@ -77,18 +73,6 @@ public void compile(File[] files) throws Exception {
unit.compile();
}
-public static void displayHelp(final Options options) {
-final HelpFormatter formatter = new HelpFormatter();
-formatter.printHelp(80, "groovyc [options] ",
"options:", options, "");
-}
-
-public static void displayVersion() {
--- End diff --
For binary compatibility we'd want to keep but deprecate this method.
Ideally, you'd change implementation to point to new details. If that's not
possible you can throw a DeprecationException.
> Migrate Groovyc to picocli
> --
>
> Key: GROOVY-8567
> URL: https://issues.apache.org/jira/browse/GROOVY-8567
> Project: Groovy
> Issue Type: Task
> Components: command line processing
>Reporter: Remko Popma
>Priority: Major
> Fix For: 2.5.x
>
>
> Migrate {{org.codehaus.groovy.ant.Groovyc}} from commons-cli to picocli.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8567) Migrate Groovyc to picocli
[
https://issues.apache.org/jira/browse/GROOVY-8567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16463546#comment-16463546
]
ASF GitHub Bot commented on GROOVY-8567:
Github user paulk-asert commented on a diff in the pull request:
https://github.com/apache/groovy/pull/694#discussion_r186015829
--- Diff: src/main/java/org/codehaus/groovy/tools/FileSystemCompiler.java
---
@@ -77,18 +73,6 @@ public void compile(File[] files) throws Exception {
unit.compile();
}
-public static void displayHelp(final Options options) {
--- End diff --
Not 100% sure on this one. I think we might need to keep it and mark as
deprecated in 2_5_X and then remove in 2_6_X and master. That means we won't be
able to remove commons cli fully just yet.
> Migrate Groovyc to picocli
> --
>
> Key: GROOVY-8567
> URL: https://issues.apache.org/jira/browse/GROOVY-8567
> Project: Groovy
> Issue Type: Task
> Components: command line processing
>Reporter: Remko Popma
>Priority: Major
> Fix For: 2.5.x
>
>
> Migrate {{org.codehaus.groovy.ant.Groovyc}} from commons-cli to picocli.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8567) Migrate Groovyc to picocli
[
https://issues.apache.org/jira/browse/GROOVY-8567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16463633#comment-16463633
]
ASF GitHub Bot commented on GROOVY-8567:
Github user remkop commented on a diff in the pull request:
https://github.com/apache/groovy/pull/694#discussion_r186035195
--- Diff: src/main/java/org/codehaus/groovy/tools/FileSystemCompiler.java
---
@@ -77,18 +73,6 @@ public void compile(File[] files) throws Exception {
unit.compile();
}
-public static void displayHelp(final Options options) {
-final HelpFormatter formatter = new HelpFormatter();
-formatter.printHelp(80, "groovyc [options] ",
"options:", options, "");
-}
-
-public static void displayVersion() {
--- End diff --
Done in commit 3900e3b.
> Migrate Groovyc to picocli
> --
>
> Key: GROOVY-8567
> URL: https://issues.apache.org/jira/browse/GROOVY-8567
> Project: Groovy
> Issue Type: Task
> Components: command line processing
>Reporter: Remko Popma
>Priority: Major
> Fix For: 2.5.x
>
>
> Migrate {{org.codehaus.groovy.ant.Groovyc}} from commons-cli to picocli.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8567) Migrate Groovyc to picocli
[
https://issues.apache.org/jira/browse/GROOVY-8567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16463638#comment-16463638
]
ASF GitHub Bot commented on GROOVY-8567:
Github user remkop commented on a diff in the pull request:
https://github.com/apache/groovy/pull/694#discussion_r186035996
--- Diff: src/main/java/org/codehaus/groovy/tools/FileSystemCompiler.java
---
@@ -77,18 +73,6 @@ public void compile(File[] files) throws Exception {
unit.compile();
}
-public static void displayHelp(final Options options) {
--- End diff --
Okay. Note that the Options class is no longer used anywhere in
`FileSystemCompiler` so this would be purely for binary compatibility.
How do you want to do this? I'm working on master, so the method is removed
in the PR. Do you want a separate PR for 2_5_X with the method reinstated or
will you manually reinstate on the 2_5_X branch when cherrypicking?
> Migrate Groovyc to picocli
> --
>
> Key: GROOVY-8567
> URL: https://issues.apache.org/jira/browse/GROOVY-8567
> Project: Groovy
> Issue Type: Task
> Components: command line processing
>Reporter: Remko Popma
>Priority: Major
> Fix For: 2.5.x
>
>
> Migrate {{org.codehaus.groovy.ant.Groovyc}} from commons-cli to picocli.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8567) Migrate Groovyc to picocli
[
https://issues.apache.org/jira/browse/GROOVY-8567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16465148#comment-16465148
]
ASF GitHub Bot commented on GROOVY-8567:
Github user remkop commented on a diff in the pull request:
https://github.com/apache/groovy/pull/694#discussion_r186292414
--- Diff: src/main/java/org/codehaus/groovy/tools/FileSystemCompiler.java
---
@@ -77,18 +73,6 @@ public void compile(File[] files) throws Exception {
unit.compile();
}
-public static void displayHelp(final Options options) {
--- End diff --
I've reinstated the `displayHelp(org.apache.commons.cli.Options)` method
and made it deprecated. This can be merged with the 2_5_X branch as is, and the
method (and associated imports) can be removed for 2_6_X and master.
> Migrate Groovyc to picocli
> --
>
> Key: GROOVY-8567
> URL: https://issues.apache.org/jira/browse/GROOVY-8567
> Project: Groovy
> Issue Type: Task
> Components: command line processing
>Reporter: Remko Popma
>Priority: Major
> Fix For: 2.5.x
>
>
> Migrate {{org.codehaus.groovy.ant.Groovyc}} from commons-cli to picocli.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8520) Replace commons-cli with picocli in CliBuilder
[
https://issues.apache.org/jira/browse/GROOVY-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16465311#comment-16465311
]
ASF GitHub Bot commented on GROOVY-8520:
GitHub user remkop opened a pull request:
https://github.com/apache/groovy/pull/695
GROOVY-8520 fixes
* add CliBuilder.setParser and setFormatter methods that ignore the
specified values and print a warning to stderr to easy the transition for
existing applications
* bugfix: @Unparsed annotation description attribute was ignored
* add @since tag to acceptLongOptionsWithSingleHyphen property
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/remkop/groovy GROOVY-8520-fixes
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/695.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #695
commit f115ef292b859f3035a2894d438679e1d39268ad
Author: Remko Popma
Date: 2018-04-29T23:39:40Z
GROOVY-8520 CliBuilder groovydoc improvements
commit 10a7a3c6dc8a4974a4ed7fd1b35adabcd079eaa9
Author: Remko Popma
Date: 2018-05-01T21:33:42Z
Merge remote-tracking branch 'upstream/master'
commit de3c3a8bcd04a4c05cbf605100f1a029417ccb17
Author: Remko Popma
Date: 2018-05-03T13:53:26Z
Merge remote-tracking branch 'upstream/master'
commit c1fd6cf55b5c59cf08a5efdaabc91b9656296690
Author: Remko Popma
Date: 2018-05-04T07:35:05Z
Merge remote-tracking branch 'upstream/master'
commit 4679fc5ee2ec823e22c3d5375f651c255dbd0bed
Author: Remko Popma
Date: 2018-05-04T07:35:42Z
GROOVY-8567 Migrate Groovyc to picocli
commit 3900e3b3f7a60cf420a766f7fa7c5f3882cc0c62
Author: Remko Popma
Date: 2018-05-04T09:45:12Z
GROOVY-8567 Migrate Groovyc to picocli: reinstate method
`FileSystemCompiler::displayVersion`
commit 66c7e6751fca1f0e28db1f9475f3acfe9f96e344
Author: Remko Popma
Date: 2018-05-04T22:39:49Z
GROOVY-8556 embed jarjar'd picocli for internal Groovy usage of picocli
commit 28cca36ebb597623ea7c95cf125d2bd673d60fae
Author: Remko Popma
Date: 2018-05-06T07:08:46Z
GROOVY-8567 Migrate Groovyc to picocli: fix usage help message and add
implementation note
commit 659bbf8d3ee95d0544cbf490b6813b4e3c84a7db
Author: Remko Popma
Date: 2018-05-06T09:21:54Z
GROOVY-8567 ensure standard help options appear last in the usage help
message
commit bd57d459feda8c227019a8dd276417e2bf267208
Author: Remko Popma
Date: 2018-05-06T14:21:17Z
GROOVY-8567 reinstate method
`FileSystemCompiler::displayHelp(org.apache.commons.cli.Options)`, add picocli
equivalent
commit 5311b85d28d4565386e5fa19d8efb804e600c5b6
Author: Remko Popma
Date: 2018-05-06T22:07:35Z
GROOVY-8520 bugfix: @Unparsed annotation description attribute was ignored
commit 39dc96ad52c77e1e0b8787e0a6bf28721689d3f6
Author: Remko Popma
Date: 2018-05-06T23:18:38Z
GROOVY-8520 add CliBuilder.setParser and setFormatter methods that ignore
the specified values and print a warning to stderr to easy the transition for
existing applications
commit adb807fddd104b69c9fedad940e526bdea7b5076
Author: Remko Popma
Date: 2018-05-06T23:19:19Z
GROOVY-8520 add @since tag to acceptLongOptionsWithSingleHyphen property
> Replace commons-cli with picocli in CliBuilder
> --
>
> Key: GROOVY-8520
> URL: https://issues.apache.org/jira/browse/GROOVY-8520
> Project: Groovy
> Issue Type: Improvement
> Components: command line processing
>Reporter: Remko Popma
>Assignee: Paul King
>Priority: Major
> Fix For: 2.5.0-rc-2
>
>
> This ticket proposes to replace commons-cli with picocli in
> {{groovy.util.CliBuilder}}.
> See [discussion on the mailing
> list|https://lists.apache.org/thread.html/d60b6d5d4411e9ba0d7dc209cde8a9bb4abb00f0b9c0322f068c322e@%3Cdev.groovy.apache.org%3E]
> for the original proposal and comparison with other CLI libraries.
> Goals for the initial implementation:
> * preserve the current CliBuilder behaviour as much as possible
> * deliver an implementation, tests and documentation in time to be included
> in the 2.5 GA release
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8520) Replace commons-cli with picocli in CliBuilder
[
https://issues.apache.org/jira/browse/GROOVY-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16465312#comment-16465312
]
ASF GitHub Bot commented on GROOVY-8520:
Github user remkop closed the pull request at:
https://github.com/apache/groovy/pull/695
> Replace commons-cli with picocli in CliBuilder
> --
>
> Key: GROOVY-8520
> URL: https://issues.apache.org/jira/browse/GROOVY-8520
> Project: Groovy
> Issue Type: Improvement
> Components: command line processing
>Reporter: Remko Popma
>Assignee: Paul King
>Priority: Major
> Fix For: 2.5.0-rc-2
>
>
> This ticket proposes to replace commons-cli with picocli in
> {{groovy.util.CliBuilder}}.
> See [discussion on the mailing
> list|https://lists.apache.org/thread.html/d60b6d5d4411e9ba0d7dc209cde8a9bb4abb00f0b9c0322f068c322e@%3Cdev.groovy.apache.org%3E]
> for the original proposal and comparison with other CLI libraries.
> Goals for the initial implementation:
> * preserve the current CliBuilder behaviour as much as possible
> * deliver an implementation, tests and documentation in time to be included
> in the 2.5 GA release
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8520) Replace commons-cli with picocli in CliBuilder
[
https://issues.apache.org/jira/browse/GROOVY-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16465315#comment-16465315
]
ASF GitHub Bot commented on GROOVY-8520:
GitHub user remkop opened a pull request:
https://github.com/apache/groovy/pull/696
GROOVY-8520 fixes (attempt 2)
* add CliBuilder.setParser and setFormatter methods that ignore the
specified values and print a warning to stderr to easy the transition for
existing applications
* bugfix: @Unparsed annotation description attribute was ignored
* add @since tag to acceptLongOptionsWithSingleHyphen property
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/remkop/groovy GROOVY-8520-fixes(attempt2)
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/696.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #696
commit f115ef292b859f3035a2894d438679e1d39268ad
Author: Remko Popma
Date: 2018-04-29T23:39:40Z
GROOVY-8520 CliBuilder groovydoc improvements
commit 10a7a3c6dc8a4974a4ed7fd1b35adabcd079eaa9
Author: Remko Popma
Date: 2018-05-01T21:33:42Z
Merge remote-tracking branch 'upstream/master'
commit de3c3a8bcd04a4c05cbf605100f1a029417ccb17
Author: Remko Popma
Date: 2018-05-03T13:53:26Z
Merge remote-tracking branch 'upstream/master'
commit c1fd6cf55b5c59cf08a5efdaabc91b9656296690
Author: Remko Popma
Date: 2018-05-04T07:35:05Z
Merge remote-tracking branch 'upstream/master'
commit e64b40faa48b792509d8a150c1b1b22c5118f93b
Author: Remko Popma
Date: 2018-05-06T22:07:35Z
GROOVY-8520 bugfix: @Unparsed annotation description attribute was ignored
commit 007040e5849af5d98eb6a0e8b4f5ec85248ae4ab
Author: Remko Popma
Date: 2018-05-06T23:18:38Z
GROOVY-8520 add CliBuilder.setParser and setFormatter methods that ignore
the specified values and print a warning to stderr to easy the transition for
existing applications
commit 2896071b43ddbf9d3796cdf3b6a7292b3de1f0ff
Author: Remko Popma
Date: 2018-05-06T23:19:19Z
GROOVY-8520 add @since tag to acceptLongOptionsWithSingleHyphen property
> Replace commons-cli with picocli in CliBuilder
> --
>
> Key: GROOVY-8520
> URL: https://issues.apache.org/jira/browse/GROOVY-8520
> Project: Groovy
> Issue Type: Improvement
> Components: command line processing
>Reporter: Remko Popma
>Assignee: Paul King
>Priority: Major
> Fix For: 2.5.0-rc-2
>
>
> This ticket proposes to replace commons-cli with picocli in
> {{groovy.util.CliBuilder}}.
> See [discussion on the mailing
> list|https://lists.apache.org/thread.html/d60b6d5d4411e9ba0d7dc209cde8a9bb4abb00f0b9c0322f068c322e@%3Cdev.groovy.apache.org%3E]
> for the original proposal and comparison with other CLI libraries.
> Goals for the initial implementation:
> * preserve the current CliBuilder behaviour as much as possible
> * deliver an implementation, tests and documentation in time to be included
> in the 2.5 GA release
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8569) Migrate groovy.ui.GroovyMain to picocli
[ https://issues.apache.org/jira/browse/GROOVY-8569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16465321#comment-16465321 ] ASF GitHub Bot commented on GROOVY-8569: GitHub user remkop opened a pull request: https://github.com/apache/groovy/pull/697 GROOVY-8569 GroovyMain picocli migration Migrate `groovy.ui.GroovyMain` from commons-cli to picocli. You can merge this pull request into a Git repository by running: $ git pull https://github.com/remkop/groovy GROOVY-8569-GroovyMain-picocli-migration Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/697.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #697 commit f115ef292b859f3035a2894d438679e1d39268ad Author: Remko Popma Date: 2018-04-29T23:39:40Z GROOVY-8520 CliBuilder groovydoc improvements commit 10a7a3c6dc8a4974a4ed7fd1b35adabcd079eaa9 Author: Remko Popma Date: 2018-05-01T21:33:42Z Merge remote-tracking branch 'upstream/master' commit de3c3a8bcd04a4c05cbf605100f1a029417ccb17 Author: Remko Popma Date: 2018-05-03T13:53:26Z Merge remote-tracking branch 'upstream/master' commit c1fd6cf55b5c59cf08a5efdaabc91b9656296690 Author: Remko Popma Date: 2018-05-04T07:35:05Z Merge remote-tracking branch 'upstream/master' commit 0573ce1922735ef371a8e0c89b036d8fabb573bc Author: Remko Popma Date: 2018-05-06T18:20:03Z GROOVY-8569 Migrate groovy.ui.GroovyMain to picocli > Migrate groovy.ui.GroovyMain to picocli > --- > > Key: GROOVY-8569 > URL: https://issues.apache.org/jira/browse/GROOVY-8569 > Project: Groovy > Issue Type: Task > Components: command line processing >Reporter: Remko Popma >Priority: Major > Fix For: 2.5.x > > > Migrate groovy.ui.GroovyMain from commons-cli to picocli. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-7204) Static type checking and compilation fail when multiple generics in use
[
https://issues.apache.org/jira/browse/GROOVY-7204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16469179#comment-16469179
]
ASF GitHub Bot commented on GROOVY-7204:
GitHub user danielsun1106 opened a pull request:
https://github.com/apache/groovy/pull/699
GROOVY-7204: Static type checking and compilation fail when multiple …
…generics in use
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/danielsun1106/groovy GROOVY-7204
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/699.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #699
commit 1adb32dc73f13f07cc61124711d3bba92dd6ec82
Author: Daniel Sun
Date: 2018-05-09T17:38:30Z
GROOVY-7204: Static type checking and compilation fail when multiple
generics in use
> Static type checking and compilation fail when multiple generics in use
> ---
>
> Key: GROOVY-7204
> URL: https://issues.apache.org/jira/browse/GROOVY-7204
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.3.8
>Reporter: Mauro Molinari
>Priority: Critical
>
> Consider the following interfaces:
> {code:title=CrudRepository.java}
> package f;
> import java.io.Serializable;
> public interface CrudRepository {
> void delete(S arg);
> void delete(T arg);
> }
> {code}
> {code:title=MyRepository.java}
> package f;
> public interface MyRepository extends CrudRepository {
> }
> {code}
> The following implementation class:
> {code:title=MyRepositoryImpl.java}
> package f;
> public class MyRepositoryImpl implements MyRepository {
> @Override
> public void delete(String arg) {
> System.out.println("String");
> }
> @Override
> public void delete(Long arg) {
> System.out.println("Long");
> }
> }
> {code}
> And the following Groovy class:
> {code:title=MyClass.groovy}
> package f
> import groovy.transform.CompileStatic;
> import groovy.transform.TypeChecked;
> @TypeChecked
> class MyClass {
> static MyRepository factory() {
> return new MyRepositoryImpl()
> }
>
> static void main(String[] args) {
> MyRepository r = factory()
> r.delete('foo')
> }
> }
> {code}
> Static type checking returns the following error:
> {noformat}
> MyClass.groovy: 15: [Static type checking] - Cannot call
> f.MyRepository#delete(S) with arguments [java.lang.String]
> {noformat}
> The same applies if you use {{@CompileStatic}} instead of {{@TypeChecked}}.
> Note that if, In the previous code, you change the method {{main}} by
> replacing:
> {code}
> MyRepository r = factory()
> {code}
> with:
> {code}
> MyRepository r = new MyRepositoryImpl()
> {code}
> compilation succeeds. However in real code this might not be possible (the
> {{MyRepository}} instance may be injected and auto-generated, think of Spring
> Data for instance).
> The only workaround is (yet again...) to disable static type checking and
> static compilation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-7204) Static type checking and compilation fail when multiple generics in use
[
https://issues.apache.org/jira/browse/GROOVY-7204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16470028#comment-16470028
]
ASF GitHub Bot commented on GROOVY-7204:
Github user asfgit closed the pull request at:
https://github.com/apache/groovy/pull/699
> Static type checking and compilation fail when multiple generics in use
> ---
>
> Key: GROOVY-7204
> URL: https://issues.apache.org/jira/browse/GROOVY-7204
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.3.8
>Reporter: Mauro Molinari
>Priority: Critical
>
> Consider the following interfaces:
> {code:title=CrudRepository.java}
> package f;
> import java.io.Serializable;
> public interface CrudRepository {
> void delete(S arg);
> void delete(T arg);
> }
> {code}
> {code:title=MyRepository.java}
> package f;
> public interface MyRepository extends CrudRepository {
> }
> {code}
> The following implementation class:
> {code:title=MyRepositoryImpl.java}
> package f;
> public class MyRepositoryImpl implements MyRepository {
> @Override
> public void delete(String arg) {
> System.out.println("String");
> }
> @Override
> public void delete(Long arg) {
> System.out.println("Long");
> }
> }
> {code}
> And the following Groovy class:
> {code:title=MyClass.groovy}
> package f
> import groovy.transform.CompileStatic;
> import groovy.transform.TypeChecked;
> @TypeChecked
> class MyClass {
> static MyRepository factory() {
> return new MyRepositoryImpl()
> }
>
> static void main(String[] args) {
> MyRepository r = factory()
> r.delete('foo')
> }
> }
> {code}
> Static type checking returns the following error:
> {noformat}
> MyClass.groovy: 15: [Static type checking] - Cannot call
> f.MyRepository#delete(S) with arguments [java.lang.String]
> {noformat}
> The same applies if you use {{@CompileStatic}} instead of {{@TypeChecked}}.
> Note that if, In the previous code, you change the method {{main}} by
> replacing:
> {code}
> MyRepository r = factory()
> {code}
> with:
> {code}
> MyRepository r = new MyRepositoryImpl()
> {code}
> compilation succeeds. However in real code this might not be possible (the
> {{MyRepository}} instance may be injected and auto-generated, think of Spring
> Data for instance).
> The only workaround is (yet again...) to disable static type checking and
> static compilation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8576) Remove Java2GroovyMain dependency on commons-cli
[
https://issues.apache.org/jira/browse/GROOVY-8576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16470457#comment-16470457
]
ASF GitHub Bot commented on GROOVY-8576:
GitHub user remkop opened a pull request:
https://github.com/apache/groovy/pull/700
GROOVY-8576 Remove Java2GroovyMain dependency on commons-cli
`org.codehaus.groovy.antlr.java.Java2GroovyMain` can be simplified by
removing its dependency on commons-cli: it does not have any options or print a
usage help message.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/remkop/groovy GROOVY-8576-Java2GroovyMain
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/700.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #700
commit f115ef292b859f3035a2894d438679e1d39268ad
Author: Remko Popma
Date: 2018-04-29T23:39:40Z
GROOVY-8520 CliBuilder groovydoc improvements
commit 10a7a3c6dc8a4974a4ed7fd1b35adabcd079eaa9
Author: Remko Popma
Date: 2018-05-01T21:33:42Z
Merge remote-tracking branch 'upstream/master'
commit de3c3a8bcd04a4c05cbf605100f1a029417ccb17
Author: Remko Popma
Date: 2018-05-03T13:53:26Z
Merge remote-tracking branch 'upstream/master'
commit c1fd6cf55b5c59cf08a5efdaabc91b9656296690
Author: Remko Popma
Date: 2018-05-04T07:35:05Z
Merge remote-tracking branch 'upstream/master'
commit a0ff55e15fa420443e71fb1067828da67ed59ce8
Author: Remko Popma
Date: 2018-05-10T14:25:07Z
GROOVY-8576 Remove Java2GroovyMain dependency on commons-cli
> Remove Java2GroovyMain dependency on commons-cli
>
>
> Key: GROOVY-8576
> URL: https://issues.apache.org/jira/browse/GROOVY-8576
> Project: Groovy
> Issue Type: Task
> Components: command line processing
>Reporter: Remko Popma
>Priority: Major
> Fix For: 2.5.0-rc-3
>
>
> {{org.codehaus.groovy.antlr.java.Java2GroovyMain}} could be simplified by
> removing its dependency on commons-cli: it does not have any options or print
> usage help message.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8520) Replace commons-cli with picocli in CliBuilder
[
https://issues.apache.org/jira/browse/GROOVY-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16470707#comment-16470707
]
ASF GitHub Bot commented on GROOVY-8520:
GitHub user remkop opened a pull request:
https://github.com/apache/groovy/pull/701
GROOVY-8520 fixes (attempt 3)
Rebased on master, replaces PR #696
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/remkop/groovy GROOVY-8520-fixes(attempt3)
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/701.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #701
commit ce8cd8fcf287d4a66600bd21348b54d01770797e
Author: Remko Popma
Date: 2018-05-06T22:07:35Z
GROOVY-8520 bugfix: @Unparsed annotation description attribute was ignored
commit abdc7ae402732a8078790d5d3b99405d6f801311
Author: Remko Popma
Date: 2018-05-06T23:18:38Z
GROOVY-8520 add CliBuilder.setParser and setFormatter methods that ignore
the specified values and print a warning to stderr to easy the transition for
existing applications
commit e510419fc131251478a7658f97c48dfeea90
Author: Remko Popma
Date: 2018-05-06T23:19:19Z
GROOVY-8520 add @since tag to acceptLongOptionsWithSingleHyphen property
commit fa77970a61ff777bbf6d54f87a71712afdf35b72
Author: Remko Popma
Date: 2018-05-10T14:42:19Z
GROOVY-8520 change `setPosix` signature to accept Boolean parameter instead
of boolean; handle null values
> Replace commons-cli with picocli in CliBuilder
> --
>
> Key: GROOVY-8520
> URL: https://issues.apache.org/jira/browse/GROOVY-8520
> Project: Groovy
> Issue Type: Improvement
> Components: command line processing
>Reporter: Remko Popma
>Assignee: Paul King
>Priority: Major
> Fix For: 2.5.0-rc-2
>
>
> This ticket proposes to replace commons-cli with picocli in
> {{groovy.util.CliBuilder}}.
> See [discussion on the mailing
> list|https://lists.apache.org/thread.html/d60b6d5d4411e9ba0d7dc209cde8a9bb4abb00f0b9c0322f068c322e@%3Cdev.groovy.apache.org%3E]
> for the original proposal and comparison with other CLI libraries.
> Goals for the initial implementation:
> * preserve the current CliBuilder behaviour as much as possible
> * deliver an implementation, tests and documentation in time to be included
> in the 2.5 GA release
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8520) Replace commons-cli with picocli in CliBuilder
[
https://issues.apache.org/jira/browse/GROOVY-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16470709#comment-16470709
]
ASF GitHub Bot commented on GROOVY-8520:
Github user remkop closed the pull request at:
https://github.com/apache/groovy/pull/696
> Replace commons-cli with picocli in CliBuilder
> --
>
> Key: GROOVY-8520
> URL: https://issues.apache.org/jira/browse/GROOVY-8520
> Project: Groovy
> Issue Type: Improvement
> Components: command line processing
>Reporter: Remko Popma
>Assignee: Paul King
>Priority: Major
> Fix For: 2.5.0-rc-2
>
>
> This ticket proposes to replace commons-cli with picocli in
> {{groovy.util.CliBuilder}}.
> See [discussion on the mailing
> list|https://lists.apache.org/thread.html/d60b6d5d4411e9ba0d7dc209cde8a9bb4abb00f0b9c0322f068c322e@%3Cdev.groovy.apache.org%3E]
> for the original proposal and comparison with other CLI libraries.
> Goals for the initial implementation:
> * preserve the current CliBuilder behaviour as much as possible
> * deliver an implementation, tests and documentation in time to be included
> in the 2.5 GA release
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8569) Migrate groovy.ui.GroovyMain to picocli
[ https://issues.apache.org/jira/browse/GROOVY-8569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16470742#comment-16470742 ] ASF GitHub Bot commented on GROOVY-8569: GitHub user remkop opened a pull request: https://github.com/apache/groovy/pull/702 GROOVY-8569 GroovyMain picocli migration Migrate `groovy.ui.GroovyMain` from commons-cli to picocli. Replaces PR #697 You can merge this pull request into a Git repository by running: $ git pull https://github.com/remkop/groovy GROOVY-8569-GroovyMain-attempt2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/702.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #702 commit 1502bff7ed5fa9c41d906b8edaae7cdaf9f341a9 Author: Remko Popma Date: 2018-05-06T11:20:03Z GROOVY-8569 Migrate groovy.ui.GroovyMain to picocli > Migrate groovy.ui.GroovyMain to picocli > --- > > Key: GROOVY-8569 > URL: https://issues.apache.org/jira/browse/GROOVY-8569 > Project: Groovy > Issue Type: Task > Components: command line processing >Reporter: Remko Popma >Priority: Major > Fix For: 2.5.x > > > Migrate groovy.ui.GroovyMain from commons-cli to picocli. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8569) Migrate groovy.ui.GroovyMain to picocli
[ https://issues.apache.org/jira/browse/GROOVY-8569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16470744#comment-16470744 ] ASF GitHub Bot commented on GROOVY-8569: Github user remkop closed the pull request at: https://github.com/apache/groovy/pull/697 > Migrate groovy.ui.GroovyMain to picocli > --- > > Key: GROOVY-8569 > URL: https://issues.apache.org/jira/browse/GROOVY-8569 > Project: Groovy > Issue Type: Task > Components: command line processing >Reporter: Remko Popma >Priority: Major > Fix For: 2.5.x > > > Migrate groovy.ui.GroovyMain from commons-cli to picocli. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8567) Migrate Groovyc to picocli
[
https://issues.apache.org/jira/browse/GROOVY-8567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16470765#comment-16470765
]
ASF GitHub Bot commented on GROOVY-8567:
GitHub user remkop opened a pull request:
https://github.com/apache/groovy/pull/703
GROOVY-8567 Migrate Groovyc to picocli
Migrate groovyc to picocli.
Rebased and squashed commits. This PR replaces #694.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/remkop/groovy GROOVY-8567-Groovyc-attempt2
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/703.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #703
commit b9c7824b6d3dc1ef614bc4013b65ff4d3d1a9a37
Author: Remko Popma
Date: 2018-05-06T07:21:17Z
GROOVY-8567 Migrate Groovyc to picocli
> Migrate Groovyc to picocli
> --
>
> Key: GROOVY-8567
> URL: https://issues.apache.org/jira/browse/GROOVY-8567
> Project: Groovy
> Issue Type: Task
> Components: command line processing
>Reporter: Remko Popma
>Priority: Major
> Fix For: 2.5.x
>
>
> Migrate {{org.codehaus.groovy.ant.Groovyc}} from commons-cli to picocli.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8567) Migrate Groovyc to picocli
[
https://issues.apache.org/jira/browse/GROOVY-8567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16470767#comment-16470767
]
ASF GitHub Bot commented on GROOVY-8567:
Github user remkop closed the pull request at:
https://github.com/apache/groovy/pull/694
> Migrate Groovyc to picocli
> --
>
> Key: GROOVY-8567
> URL: https://issues.apache.org/jira/browse/GROOVY-8567
> Project: Groovy
> Issue Type: Task
> Components: command line processing
>Reporter: Remko Popma
>Priority: Major
> Fix For: 2.5.x
>
>
> Migrate {{org.codehaus.groovy.ant.Groovyc}} from commons-cli to picocli.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8576) Remove Java2GroovyMain dependency on commons-cli
[
https://issues.apache.org/jira/browse/GROOVY-8576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16471439#comment-16471439
]
ASF GitHub Bot commented on GROOVY-8576:
Github user remkop closed the pull request at:
https://github.com/apache/groovy/pull/700
> Remove Java2GroovyMain dependency on commons-cli
>
>
> Key: GROOVY-8576
> URL: https://issues.apache.org/jira/browse/GROOVY-8576
> Project: Groovy
> Issue Type: Task
> Components: command line processing
>Reporter: Remko Popma
>Priority: Major
> Fix For: 2.5.0-rc-3
>
>
> {{org.codehaus.groovy.antlr.java.Java2GroovyMain}} could be simplified by
> removing its dependency on commons-cli: it does not have any options or print
> usage help message.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8577) Migrate org.codehaus.groovy.tools.GrapeMain.groovy to picocli
[ https://issues.apache.org/jira/browse/GROOVY-8577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472510#comment-16472510 ] ASF GitHub Bot commented on GROOVY-8577: GitHub user remkop opened a pull request: https://github.com/apache/groovy/pull/704 GROOVY-8577 Migrate org.codehaus.groovy.tools.GrapeMain.groovy to picocli GROOVY-8577 Migrate org.codehaus.groovy.tools.GrapeMain.groovy to picocli You can merge this pull request into a Git repository by running: $ git pull https://github.com/remkop/groovy GROOVY-8577-GrapeMain(attempt2) Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/704.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #704 commit 92d40dbb0305a901fcbacf6a313f1e5776889a70 Author: Remko Popma Date: 2018-05-10T16:27:36Z GROOVY-8577 Migrate org.codehaus.groovy.tools.GrapeMain.groovy to picocli > Migrate org.codehaus.groovy.tools.GrapeMain.groovy to picocli > - > > Key: GROOVY-8577 > URL: https://issues.apache.org/jira/browse/GROOVY-8577 > Project: Groovy > Issue Type: Task >Reporter: Remko Popma >Priority: Major > > Migrate org.codehaus.groovy.tools.GrapeMain.groovy to picocli as part of > GROOVY-8556. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-7883) Static compiler prefers private constructor over public if private matches better
[
https://issues.apache.org/jira/browse/GROOVY-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472909#comment-16472909
]
ASF GitHub Bot commented on GROOVY-7883:
GitHub user danielsun1106 opened a pull request:
https://github.com/apache/groovy/pull/705
GROOVY-7883 Static compiler prefers private constructor over public …
…if private matches be
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/danielsun1106/groovy GROOVY-7883
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/705.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #705
commit 394db983d51446f849205efc4f9cca21601cc47c
Author: Daniel Sun
Date: 2018-05-12T04:35:01Z
GROOVY-7883 Static compiler prefers private constructor over public if
private matches be
> Static compiler prefers private constructor over public if private matches
> better
> -
>
> Key: GROOVY-7883
> URL: https://issues.apache.org/jira/browse/GROOVY-7883
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.7
>Reporter: Jason Winnebeck
>Priority: Major
>
> When constructing an AssertionError for example, it has a public constructor
> taking Object and a private constructor taking String. The static compiler
> "chooses" the private constructor over the public one and this results in a
> compile error.
> {code}
> @groovy.transform.CompileStatic
> void doIt() {
> //Cannot call private constructor for java.lang.AssertionError. However, it
> should call AssertionError(Object)
> throw new AssertionError("abc")
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-7883) Static compiler prefers private constructor over public if private matches better
[
https://issues.apache.org/jira/browse/GROOVY-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472911#comment-16472911
]
ASF GitHub Bot commented on GROOVY-7883:
Github user danielsun1106 commented on a diff in the pull request:
https://github.com/apache/groovy/pull/705#discussion_r187764707
--- Diff: subprojects/groovy-sql/src/main/java/groovy/sql/Sql.java ---
@@ -3973,7 +3973,7 @@ protected final ResultSet executePreparedQuery(String
sql, List params)
* @return the resulting list of rows
* @throws SQLException if a database error occurs
*/
-protected List asList(String sql, ResultSet rs,
+public List asList(String sql, ResultSet rs,
--- End diff --
The test accesses the `protected` method `asList`, which is not allowed. so
I change its visibility to `public`.
groovy.sql.SqlSTCTest#testAsList
```
void testAsList() {
shell.evaluate '''
def test(groovy.sql.Sql sql, java.sql.ResultSet rs) {
sql.asList('SELECT * FROM FOO', rs) { println
it.columnCount }
}
'''
}
```
> Static compiler prefers private constructor over public if private matches
> better
> -
>
> Key: GROOVY-7883
> URL: https://issues.apache.org/jira/browse/GROOVY-7883
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.7
>Reporter: Jason Winnebeck
>Priority: Major
>
> When constructing an AssertionError for example, it has a public constructor
> taking Object and a private constructor taking String. The static compiler
> "chooses" the private constructor over the public one and this results in a
> compile error.
> {code}
> @groovy.transform.CompileStatic
> void doIt() {
> //Cannot call private constructor for java.lang.AssertionError. However, it
> should call AssertionError(Object)
> throw new AssertionError("abc")
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-7883) Static compiler prefers private constructor over public if private matches better
[
https://issues.apache.org/jira/browse/GROOVY-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472928#comment-16472928
]
ASF GitHub Bot commented on GROOVY-7883:
Github user asfgit closed the pull request at:
https://github.com/apache/groovy/pull/705
> Static compiler prefers private constructor over public if private matches
> better
> -
>
> Key: GROOVY-7883
> URL: https://issues.apache.org/jira/browse/GROOVY-7883
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.7
>Reporter: Jason Winnebeck
>Priority: Major
>
> When constructing an AssertionError for example, it has a public constructor
> taking Object and a private constructor taking String. The static compiler
> "chooses" the private constructor over the public one and this results in a
> compile error.
> {code}
> @groovy.transform.CompileStatic
> void doIt() {
> //Cannot call private constructor for java.lang.AssertionError. However, it
> should call AssertionError(Object)
> throw new AssertionError("abc")
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8577) Migrate org.codehaus.groovy.tools.GrapeMain.groovy to picocli
[
https://issues.apache.org/jira/browse/GROOVY-8577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475145#comment-16475145
]
ASF GitHub Bot commented on GROOVY-8577:
Github user remkop commented on a diff in the pull request:
https://github.com/apache/groovy/pull/704#discussion_r188142573
--- Diff: src/main/groovy/org/codehaus/groovy/tools/GrapeMain.groovy ---
@@ -19,290 +19,323 @@
package org.codehaus.groovy.tools
import groovy.grape.Grape
-import groovy.transform.Field
-import org.apache.commons.cli.CommandLine
-import org.apache.commons.cli.DefaultParser
-import org.apache.commons.cli.HelpFormatter
-import org.apache.commons.cli.Option
-import org.apache.commons.cli.OptionGroup
-import org.apache.commons.cli.Options
import org.apache.ivy.util.DefaultMessageLogger
import org.apache.ivy.util.Message
-
-//commands
-
-@Field install = {arg, cmd ->
-if (arg.size() > 5 || arg.size() < 3) {
-println 'install requires two to four arguments:
[ []]'
-return
-}
-def ver = '*'
-if (arg.size() >= 4) {
-ver = arg[3]
-}
-def classifier = null
-if (arg.size() >= 5) {
-classifier = arg[4]
+import picocli.CommandLine
+import picocli.CommandLine.Command
+import picocli.CommandLine.Option
+import picocli.CommandLine.Parameters
+import picocli.CommandLine.ParentCommand
+import picocli.CommandLine.RunLast
+import picocli.CommandLine.Unmatched
+
+@Command(name = "grape", description = "Allows for the inspection and
management of the local grape cache.",
+subcommands = [
+Install.class,
+Uninstall.class,
+ListCommand.class,
+Resolve.class,
+picocli.CommandLine.HelpCommand.class])
+class GrapeMain implements Runnable {
+@Option(names = ["-D", "--define"], description = "define a system
property", paramLabel = "")
+private Map properties = new LinkedHashMap()
+
+@Option(names = ["-r", "--resolver"], description = "define a grab
resolver (for install)", paramLabel = "")
+private List resolvers = new ArrayList()
+
+@Option(names = ["-q", "--quiet"], description = "Log level 0 - only
errors")
+private boolean quiet
+
+@Option(names = ["-w", "--warn"], description = "Log level 1 - errors
and warnings")
+private boolean warn
+
+@Option(names = ["-i", "--info"], description = "Log level 2 - info")
+private boolean info
+
+@Option(names = ["-V", "--verbose"], description = "Log level 3 -
verbose")
+private boolean verbose
+
+@Option(names = ["-d", "--debug"], description = "Log level 4 - debug")
+private boolean debug
+
+@Unmatched List unmatched = new ArrayList()
+
+private CommandLine parser
+
+public static void main(String[] args) {
+GrapeMain grape = new GrapeMain()
+def parser = new CommandLine(grape)
+parser.addMixin("helpOptions", new HelpOptionsMixin())
+parser.subcommands.findAll { k, v -> k != 'help' }.each { k, v ->
v.addMixin("helpOptions", new HelpOptionsMixin()) }
+
+grape.parser = parser
+parser.parseWithHandler(new RunLast(), args)
}
-// set the instance so we can re-set the logger
-Grape.getInstance()
-setupLogging()
+void run() {
+if (unmatched) {
+System.err.println "grape: '${unmatched[0]}' is not a grape
command. See 'grape --help'"
+} else {
+parser.usage(System.out) // if no subcommand was specified
+}
+}
-cmd.getOptionValues('r')?.each { String url ->
-Grape.addResolver(name:url, root:url)
+private void init() {
+properties.each { k, v ->
+System.setProperty(k, v)
+}
}
-try {
-Grape.grab(autoDownload: true, group: arg[1], module: arg[2],
version: ver, classifier: classifier, noExceptions: true)
-} catch (Exception e) {
-println "An error occured : $ex"
+private void setupLogging(int defaultLevel = 2) { // =
Message.MSG_INFO -> some parsing error :(
+if (quiet) {
+Message.setDefaultLogger(new
DefaultMessageLogger(Message.MSG_ERR))
+} else if (warn) {
+Message.setDefaultLogger(new
DefaultMessageLogger(Message.MSG_WARN))
+} else if (info) {
+Message.setDefaultLogger(new
DefaultMessageLogger(Message.MSG_INFO))
+} else if (verbose) {
+Message.setDefaultLogger(new
D
[jira] [Commented] (GROOVY-8355) Instanceof inference does not work on field assigning
[
https://issues.apache.org/jira/browse/GROOVY-8355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475689#comment-16475689
]
ASF GitHub Bot commented on GROOVY-8355:
GitHub user danielsun1106 opened a pull request:
https://github.com/apache/groovy/pull/706
GROOVY-8355: Instanceof inference does not work on field assigning
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/danielsun1106/groovy GROOVY-8355
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/706.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #706
commit cdf254c3814415bebba622da43f2e5243cfdbcf5
Author: Daniel Sun
Date: 2018-05-15T11:34:24Z
GROOVY-8355: Instanceof inference does not work on field assigning
> Instanceof inference does not work on field assigning
> -
>
> Key: GROOVY-8355
> URL: https://issues.apache.org/jira/browse/GROOVY-8355
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Reporter: Alexey Afanasiev
>Priority: Major
>
> If instanceof inference works as expected
> [https://issues.apache.org/jira/browse/GROOVY-8293] So probably this code
> should work to:
> {code}
> import groovy.transform.CompileStatic
> @CompileStatic
> class Foo {
> Object str = new Object()
> def bar() {
> str = "str"
> str.toUpperCase() // here compile error
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8355) Instanceof inference does not work on field assigning
[
https://issues.apache.org/jira/browse/GROOVY-8355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475876#comment-16475876
]
ASF GitHub Bot commented on GROOVY-8355:
Github user asfgit closed the pull request at:
https://github.com/apache/groovy/pull/706
> Instanceof inference does not work on field assigning
> -
>
> Key: GROOVY-8355
> URL: https://issues.apache.org/jira/browse/GROOVY-8355
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Reporter: Alexey Afanasiev
>Priority: Major
>
> If instanceof inference works as expected
> [https://issues.apache.org/jira/browse/GROOVY-8293] So probably this code
> should work to:
> {code}
> import groovy.transform.CompileStatic
> @CompileStatic
> class Foo {
> Object str = new Object()
> def bar() {
> str = "str"
> str.toUpperCase() // here compile error
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8509) SC: error for call to protected method from same package
[ https://issues.apache.org/jira/browse/GROOVY-8509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16477858#comment-16477858 ] ASF GitHub Bot commented on GROOVY-8509: GitHub user jwagenleitner opened a pull request: https://github.com/apache/groovy/pull/707 GROOVY-8509: SC error call to protected method from same package Because they were closely related, this PR also includes the following: 1. A change to the fix introduced by GROOVY-7883 (b1d1232770aa) to prevent filtering protected methods in the `StaticTypeCheckingVisitor` if caller is in the same package. From the same commit, removes the test `Groovy7883Bug#test3` because it should compile and the new test introduced for GROOVY-8509 in `MethodCallsStaticCompilation` takes it place. 1. A change to revert groovy.sql.Sql#asList (b1d1232770aa) back to `protected`. Fix for GROOVY-7883 enforced visibility for method calls in `TypedChecked` and `CompileStatic` modes. Test was originally put in place to verify the added ClosureParams, so changed test to access method via subclass so that the access modifier for the method can remain protected. I think the spirit of the test is preserved in this case without having to open access to the method under test. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jwagenleitner/groovy 8509-SC-protected-same-package Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/707.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #707 commit c76783966f4f9198498abdf6f4696dc36e449cd5 Author: John Wagenleitner Date: 2018-05-16T14:58:23Z Revert change to groovy.sql.Sql#asList in commit b1d1232770aa Fix for GROOVY-7883 enforced visibility for method calls in TypedChecked and CompileStatic modes. Test was originally put in place to verify the added ClosureParams, so changed test to access method via subclass so that the access modifier for the method can remain protected. commit 8821e8406adeec4d69894b739a2d941c51266c87 Author: John Wagenleitner Date: 2018-05-16T15:34:48Z GROOVY-8509: SC error call to protected method from same package Also includes a change to the fix introduced by GROOVY-7883 (b1d1232770aa) to prevent filtering protected methods in the StaticTypeCheckingVisitor if caller is in the same package. From the same commit, removes the test Groovy7883Bug#test3 because it should compile and the new test introduced for GROOVY-8509 in MethodCallsStaticCompilation takes it place. > SC: error for call to protected method from same package > > > Key: GROOVY-8509 > URL: https://issues.apache.org/jira/browse/GROOVY-8509 > Project: Groovy > Issue Type: Bug >Affects Versions: 2.5.0-beta-2, 2.6.0-alpha-3 >Reporter: Eric Milles >Priority: Major > > Groovy 2.5+ is producing compilation errors for @CompileStatic test class > calling a protected method of class under test (in same package). This > should be allowed as protected is "package-private" plus subtypes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-6668) Static compiler doesn't coerce GString for getAt() call
[
https://issues.apache.org/jira/browse/GROOVY-6668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16478371#comment-16478371
]
ASF GitHub Bot commented on GROOVY-6668:
GitHub user danielsun1106 opened a pull request:
https://github.com/apache/groovy/pull/708
GROOVY-6668: Static compiler doesn't coerce GString for getAt() call
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/danielsun1106/groovy GROOVY-6668
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/708.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #708
commit f3c3939b473c33acf0de5d95074bc2eb8bd61555
Author: Daniel Sun
Date: 2018-05-17T01:49:00Z
GROOVY-6668: Static compiler doesn't coerce GString for getAt() call
> Static compiler doesn't coerce GString for getAt() call
> ---
>
> Key: GROOVY-6668
> URL: https://issues.apache.org/jira/browse/GROOVY-6668
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.3.0-beta-1, 2.4.0-rc-1
>Reporter: Luke Daley
>Priority: Major
>
> This might not be a bug, but it's a behaviour change from 2.2.
> {code}
> @groovy.transform.CompileStatic
> class OtherThing {
> OtherThing() {
> Map m = [:]
> def k = "foo"
> m["$k"].toUpperCase() // fails, no method toUpperCase() on object
> m[k].toUpperCase() // works
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-6668) Static compiler doesn't coerce GString for getAt() call
[
https://issues.apache.org/jira/browse/GROOVY-6668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16478380#comment-16478380
]
ASF GitHub Bot commented on GROOVY-6668:
Github user blackdrag commented on a diff in the pull request:
https://github.com/apache/groovy/pull/708#discussion_r188821671
--- Diff:
src/main/java/org/codehaus/groovy/classgen/asm/sc/StaticInvocationWriter.java
---
@@ -468,7 +469,11 @@ protected void loadArguments(List
argumentList, Parameter[] para) {
expression.putNodeMetaData(PARAMETER_TYPE,
para[i].getType());
expression.visit(acg);
if (!isNullConstant(expression)) {
-operandStack.doGroovyCast(para[i].getType());
+if (expression instanceof GStringExpression) {
+operandStack.doGroovyCast(ClassHelper.STRING_TYPE);
--- End diff --
what if the method has a GString parameter? Converting to string is then
wrong. You should add a test for this
> Static compiler doesn't coerce GString for getAt() call
> ---
>
> Key: GROOVY-6668
> URL: https://issues.apache.org/jira/browse/GROOVY-6668
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.3.0-beta-1, 2.4.0-rc-1
>Reporter: Luke Daley
>Priority: Major
>
> This might not be a bug, but it's a behaviour change from 2.2.
> {code}
> @groovy.transform.CompileStatic
> class OtherThing {
> OtherThing() {
> Map m = [:]
> def k = "foo"
> m["$k"].toUpperCase() // fails, no method toUpperCase() on object
> m[k].toUpperCase() // works
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-6668) Static compiler doesn't coerce GString for getAt() call
[
https://issues.apache.org/jira/browse/GROOVY-6668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16478382#comment-16478382
]
ASF GitHub Bot commented on GROOVY-6668:
Github user blackdrag commented on a diff in the pull request:
https://github.com/apache/groovy/pull/708#discussion_r188821809
--- Diff:
src/main/java/org/codehaus/groovy/transform/stc/StaticTypeCheckingVisitor.java
---
@@ -4101,13 +4101,17 @@ protected static ClassNode
getGroupOperationResultType(ClassNode a, ClassNode b)
return Number_TYPE;
}
-protected ClassNode inferComponentType(final ClassNode containerType,
final ClassNode indexType) {
+private static ClassNode convertGStringToStringType(ClassNode cn) {
+return GSTRING_TYPE.equals(cn) ? STRING_TYPE : cn;
+}
+
+protected ClassNode inferComponentType(final ClassNode containerType,
ClassNode indexType) {
final ClassNode componentType = containerType.getComponentType();
if (componentType == null) {
// GROOVY-5521
// try to identify a getAt method
typeCheckingContext.pushErrorCollector();
-MethodCallExpression vcall = callX(varX("_hash_",
containerType), "getAt", varX("_index_", indexType));
+MethodCallExpression vcall = callX(varX("_hash_",
containerType), "getAt", varX("_index_",
convertGStringToStringType(indexType)));
--- End diff --
what if I add a DGM getAt(GString) for Map? This code looks like I would no
longer be able to call it
> Static compiler doesn't coerce GString for getAt() call
> ---
>
> Key: GROOVY-6668
> URL: https://issues.apache.org/jira/browse/GROOVY-6668
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.3.0-beta-1, 2.4.0-rc-1
>Reporter: Luke Daley
>Priority: Major
>
> This might not be a bug, but it's a behaviour change from 2.2.
> {code}
> @groovy.transform.CompileStatic
> class OtherThing {
> OtherThing() {
> Map m = [:]
> def k = "foo"
> m["$k"].toUpperCase() // fails, no method toUpperCase() on object
> m[k].toUpperCase() // works
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-6668) Static compiler doesn't coerce GString for getAt() call
[
https://issues.apache.org/jira/browse/GROOVY-6668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16478388#comment-16478388
]
ASF GitHub Bot commented on GROOVY-6668:
Github user blackdrag commented on a diff in the pull request:
https://github.com/apache/groovy/pull/708#discussion_r188822722
--- Diff: src/test/groovy/bugs/Groovy6668Bug.groovy ---
@@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ *http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package groovy.bugs
+
+class Groovy6668Bug extends GroovyTestCase{
+void testGroovy6668() {
+assertScript '''
+@groovy.transform.CompileStatic
+class OtherThing {
+OtherThing() {
+Map m = [:]
+def k = "foo"
+m["$k"].toUpperCase()
+}
+}
+
+OtherThing
--- End diff --
new OtherThing()?
> Static compiler doesn't coerce GString for getAt() call
> ---
>
> Key: GROOVY-6668
> URL: https://issues.apache.org/jira/browse/GROOVY-6668
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.3.0-beta-1, 2.4.0-rc-1
>Reporter: Luke Daley
>Priority: Major
>
> This might not be a bug, but it's a behaviour change from 2.2.
> {code}
> @groovy.transform.CompileStatic
> class OtherThing {
> OtherThing() {
> Map m = [:]
> def k = "foo"
> m["$k"].toUpperCase() // fails, no method toUpperCase() on object
> m[k].toUpperCase() // works
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-6668) Static compiler doesn't coerce GString for getAt() call
[
https://issues.apache.org/jira/browse/GROOVY-6668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16478412#comment-16478412
]
ASF GitHub Bot commented on GROOVY-6668:
Github user danielsun1106 commented on a diff in the pull request:
https://github.com/apache/groovy/pull/708#discussion_r188825988
--- Diff:
src/main/java/org/codehaus/groovy/transform/stc/StaticTypeCheckingVisitor.java
---
@@ -4101,13 +4101,17 @@ protected static ClassNode
getGroupOperationResultType(ClassNode a, ClassNode b)
return Number_TYPE;
}
-protected ClassNode inferComponentType(final ClassNode containerType,
final ClassNode indexType) {
+private static ClassNode convertGStringToStringType(ClassNode cn) {
+return GSTRING_TYPE.equals(cn) ? STRING_TYPE : cn;
+}
+
+protected ClassNode inferComponentType(final ClassNode containerType,
ClassNode indexType) {
final ClassNode componentType = containerType.getComponentType();
if (componentType == null) {
// GROOVY-5521
// try to identify a getAt method
typeCheckingContext.pushErrorCollector();
-MethodCallExpression vcall = callX(varX("_hash_",
containerType), "getAt", varX("_index_", indexType));
+MethodCallExpression vcall = callX(varX("_hash_",
containerType), "getAt", varX("_index_",
convertGStringToStringType(indexType)));
--- End diff --
Good idea!
```groovy
/**
* Get the value via the string value of the key
* See GROOVY-6668 and the PR#708
(https://github.com/apache/groovy/pull/708)
*
* @param self a map
* @param key a key
* @param value type
* @return the value
*/
public static V getAt(Map self, GString key) {
if (null == key) {
return null;
}
return self.get(key.toString());
}
```
but I wonder why we should not treat GString as String?
As a groovy user, I won't write code like `GString str =
"${'someString'}"`, and I just write `String str = "${'someString'}"` or `def
str = "${'someString'}"` then treat `str` as a `String`...
> Static compiler doesn't coerce GString for getAt() call
> ---
>
> Key: GROOVY-6668
> URL: https://issues.apache.org/jira/browse/GROOVY-6668
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.3.0-beta-1, 2.4.0-rc-1
>Reporter: Luke Daley
>Priority: Major
>
> This might not be a bug, but it's a behaviour change from 2.2.
> {code}
> @groovy.transform.CompileStatic
> class OtherThing {
> OtherThing() {
> Map m = [:]
> def k = "foo"
> m["$k"].toUpperCase() // fails, no method toUpperCase() on object
> m[k].toUpperCase() // works
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-6668) Static compiler doesn't coerce GString for getAt() call
[
https://issues.apache.org/jira/browse/GROOVY-6668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16478416#comment-16478416
]
ASF GitHub Bot commented on GROOVY-6668:
Github user danielsun1106 commented on a diff in the pull request:
https://github.com/apache/groovy/pull/708#discussion_r188826337
--- Diff: src/test/groovy/bugs/Groovy6668Bug.groovy ---
@@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ *http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package groovy.bugs
+
+class Groovy6668Bug extends GroovyTestCase{
+void testGroovy6668() {
+assertScript '''
+@groovy.transform.CompileStatic
+class OtherThing {
+OtherThing() {
+Map m = [:]
+def k = "foo"
+m["$k"].toUpperCase()
+}
+}
+
+OtherThing
--- End diff --
I just keep the code of the issue as it is. the `new OtherThing()` version
is `testGroovy6668WithData` ;-)
> Static compiler doesn't coerce GString for getAt() call
> ---
>
> Key: GROOVY-6668
> URL: https://issues.apache.org/jira/browse/GROOVY-6668
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.3.0-beta-1, 2.4.0-rc-1
>Reporter: Luke Daley
>Priority: Major
>
> This might not be a bug, but it's a behaviour change from 2.2.
> {code}
> @groovy.transform.CompileStatic
> class OtherThing {
> OtherThing() {
> Map m = [:]
> def k = "foo"
> m["$k"].toUpperCase() // fails, no method toUpperCase() on object
> m[k].toUpperCase() // works
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-6668) Static compiler doesn't coerce GString for getAt() call
[
https://issues.apache.org/jira/browse/GROOVY-6668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16478474#comment-16478474
]
ASF GitHub Bot commented on GROOVY-6668:
Github user paulk-asert commented on a diff in the pull request:
https://github.com/apache/groovy/pull/708#discussion_r188832656
--- Diff: src/test/groovy/bugs/Groovy6668Bug.groovy ---
@@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ *http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package groovy.bugs
+
+class Groovy6668Bug extends GroovyTestCase{
+void testGroovy6668() {
+assertScript '''
+@groovy.transform.CompileStatic
+class OtherThing {
+OtherThing() {
+Map m = [:]
+def k = "foo"
+m["$k"].toUpperCase()
+}
+}
+
+OtherThing
--- End diff --
why not just shouldCompile then?
> Static compiler doesn't coerce GString for getAt() call
> ---
>
> Key: GROOVY-6668
> URL: https://issues.apache.org/jira/browse/GROOVY-6668
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.3.0-beta-1, 2.4.0-rc-1
>Reporter: Luke Daley
>Priority: Major
>
> This might not be a bug, but it's a behaviour change from 2.2.
> {code}
> @groovy.transform.CompileStatic
> class OtherThing {
> OtherThing() {
> Map m = [:]
> def k = "foo"
> m["$k"].toUpperCase() // fails, no method toUpperCase() on object
> m[k].toUpperCase() // works
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-6668) Static compiler doesn't coerce GString for getAt() call
[
https://issues.apache.org/jira/browse/GROOVY-6668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16478502#comment-16478502
]
ASF GitHub Bot commented on GROOVY-6668:
Github user danielsun1106 commented on a diff in the pull request:
https://github.com/apache/groovy/pull/708#discussion_r188837462
--- Diff: src/test/groovy/bugs/Groovy6668Bug.groovy ---
@@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ *http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package groovy.bugs
+
+class Groovy6668Bug extends GroovyTestCase{
+void testGroovy6668() {
+assertScript '''
+@groovy.transform.CompileStatic
+class OtherThing {
+OtherThing() {
+Map m = [:]
+def k = "foo"
+m["$k"].toUpperCase()
+}
+}
+
+OtherThing
--- End diff --
I've fixed that according your suggestion :-)
> Static compiler doesn't coerce GString for getAt() call
> ---
>
> Key: GROOVY-6668
> URL: https://issues.apache.org/jira/browse/GROOVY-6668
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.3.0-beta-1, 2.4.0-rc-1
>Reporter: Luke Daley
>Priority: Major
>
> This might not be a bug, but it's a behaviour change from 2.2.
> {code}
> @groovy.transform.CompileStatic
> class OtherThing {
> OtherThing() {
> Map m = [:]
> def k = "foo"
> m["$k"].toUpperCase() // fails, no method toUpperCase() on object
> m[k].toUpperCase() // works
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
