[GitHub] groovy pull request: GROOVY-7747: Generated Java stub for enum wit...

2016-02-05 Thread paulk-asert
GitHub user paulk-asert opened a pull request:

https://github.com/apache/groovy/pull/254

GROOVY-7747: Generated Java stub for enum with abstract method is inv…

…alid (closes #254)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/paulk-asert/incubator-groovy groovy7747

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/groovy/pull/254.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 #254


commit ae606a540a36fa4bda465e42d880595e52e0feec
Author: paulk 
Date:   2016-02-05T11:07:05Z

GROOVY-7747: Generated Java stub for enum with abstract method is invalid 
(closes #254)




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (GROOVY-7747) Generated Java stub for enum with abstract method is invalid

2016-02-05 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-7747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15134016#comment-15134016
 ] 

ASF GitHub Bot commented on GROOVY-7747:


GitHub user paulk-asert opened a pull request:

https://github.com/apache/groovy/pull/254

GROOVY-7747: Generated Java stub for enum with abstract method is inv…

…alid (closes #254)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/paulk-asert/incubator-groovy groovy7747

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/groovy/pull/254.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 #254


commit ae606a540a36fa4bda465e42d880595e52e0feec
Author: paulk 
Date:   2016-02-05T11:07:05Z

GROOVY-7747: Generated Java stub for enum with abstract method is invalid 
(closes #254)




> Generated Java stub for enum with abstract method is invalid
> 
>
> Key: GROOVY-7747
> URL: https://issues.apache.org/jira/browse/GROOVY-7747
> Project: Groovy
>  Issue Type: Bug
> Environment: Groovy 2.4.5
>Reporter: Jonathan Peterson
>Priority: Minor
>
> When generating Java stub for enum with an abstract method results in invalid 
> Java source. The generated source class is defined as "abstract enum".
> {code:title=EnumWithAbstractMethod.groovy}
> enum EnumWithAbstractMethod {
> ONE {
> @Override
> int getInt() {
> return 1
> }
> },
> TWO {
> @Override
> int getInt() {
> return 2
> }
> }
> abstract int getInt()
> }
> {code}
> {code:title=Driver.groovy}
> class Driver {
> public static void main(String[] args) {
> def stubCompiler = new JavaStubCompilationUnit(
> new CompilerConfiguration(),
> new GroovyClassLoader(),
> new File('tmp')
> )
> stubCompiler.addSource(new File('EnumWithAbstractMethod.groovy'))
> stubCompiler.compile()
> }
> }
> {code}
> {code:title=EnumWithAbstractMethod.java}
> public abstract enum EnumWithAbstractMethod
>   implements
> groovy.lang.GroovyObject {
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (GROOVY-7747) Generated Java stub for enum with abstract method is invalid

2016-02-05 Thread Paul King (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-7747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15134019#comment-15134019
 ] 

Paul King edited comment on GROOVY-7747 at 2/5/16 11:11 AM:


I can confirm this is a bug. Proposed fix as per above PR.

Cheers, Paul.


was (Author: paulk):
I can confirm this is a bug. Proposed fix above.

Cheers, Paul.

> Generated Java stub for enum with abstract method is invalid
> 
>
> Key: GROOVY-7747
> URL: https://issues.apache.org/jira/browse/GROOVY-7747
> Project: Groovy
>  Issue Type: Bug
> Environment: Groovy 2.4.5
>Reporter: Jonathan Peterson
>Priority: Minor
>
> When generating Java stub for enum with an abstract method results in invalid 
> Java source. The generated source class is defined as "abstract enum".
> {code:title=EnumWithAbstractMethod.groovy}
> enum EnumWithAbstractMethod {
> ONE {
> @Override
> int getInt() {
> return 1
> }
> },
> TWO {
> @Override
> int getInt() {
> return 2
> }
> }
> abstract int getInt()
> }
> {code}
> {code:title=Driver.groovy}
> class Driver {
> public static void main(String[] args) {
> def stubCompiler = new JavaStubCompilationUnit(
> new CompilerConfiguration(),
> new GroovyClassLoader(),
> new File('tmp')
> )
> stubCompiler.addSource(new File('EnumWithAbstractMethod.groovy'))
> stubCompiler.compile()
> }
> }
> {code}
> {code:title=EnumWithAbstractMethod.java}
> public abstract enum EnumWithAbstractMethod
>   implements
> groovy.lang.GroovyObject {
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (GROOVY-7747) Generated Java stub for enum with abstract method is invalid

2016-02-05 Thread Paul King (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-7747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15134019#comment-15134019
 ] 

Paul King commented on GROOVY-7747:
---

I can confirm this is a bug. Proposed fix above.

Cheers, Paul.

> Generated Java stub for enum with abstract method is invalid
> 
>
> Key: GROOVY-7747
> URL: https://issues.apache.org/jira/browse/GROOVY-7747
> Project: Groovy
>  Issue Type: Bug
> Environment: Groovy 2.4.5
>Reporter: Jonathan Peterson
>Priority: Minor
>
> When generating Java stub for enum with an abstract method results in invalid 
> Java source. The generated source class is defined as "abstract enum".
> {code:title=EnumWithAbstractMethod.groovy}
> enum EnumWithAbstractMethod {
> ONE {
> @Override
> int getInt() {
> return 1
> }
> },
> TWO {
> @Override
> int getInt() {
> return 2
> }
> }
> abstract int getInt()
> }
> {code}
> {code:title=Driver.groovy}
> class Driver {
> public static void main(String[] args) {
> def stubCompiler = new JavaStubCompilationUnit(
> new CompilerConfiguration(),
> new GroovyClassLoader(),
> new File('tmp')
> )
> stubCompiler.addSource(new File('EnumWithAbstractMethod.groovy'))
> stubCompiler.compile()
> }
> }
> {code}
> {code:title=EnumWithAbstractMethod.java}
> public abstract enum EnumWithAbstractMethod
>   implements
> groovy.lang.GroovyObject {
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (GROOVY-7747) Generated Java stub for enum with abstract method is invalid

2016-02-05 Thread Paul King (JIRA)

 [ 
https://issues.apache.org/jira/browse/GROOVY-7747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul King reassigned GROOVY-7747:
-

Assignee: Paul King

> Generated Java stub for enum with abstract method is invalid
> 
>
> Key: GROOVY-7747
> URL: https://issues.apache.org/jira/browse/GROOVY-7747
> Project: Groovy
>  Issue Type: Bug
> Environment: Groovy 2.4.5
>Reporter: Jonathan Peterson
>Assignee: Paul King
>Priority: Minor
>
> When generating Java stub for enum with an abstract method results in invalid 
> Java source. The generated source class is defined as "abstract enum".
> {code:title=EnumWithAbstractMethod.groovy}
> enum EnumWithAbstractMethod {
> ONE {
> @Override
> int getInt() {
> return 1
> }
> },
> TWO {
> @Override
> int getInt() {
> return 2
> }
> }
> abstract int getInt()
> }
> {code}
> {code:title=Driver.groovy}
> class Driver {
> public static void main(String[] args) {
> def stubCompiler = new JavaStubCompilationUnit(
> new CompilerConfiguration(),
> new GroovyClassLoader(),
> new File('tmp')
> )
> stubCompiler.addSource(new File('EnumWithAbstractMethod.groovy'))
> stubCompiler.compile()
> }
> }
> {code}
> {code:title=EnumWithAbstractMethod.java}
> public abstract enum EnumWithAbstractMethod
>   implements
> groovy.lang.GroovyObject {
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (GROOVY-6754) groovysh positional argument terminates groovysh after evaluation

2016-02-05 Thread Crazy Gambler (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-6754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15134614#comment-15134614
 ] 

Crazy Gambler commented on GROOVY-6754:
---

Updating on the basis of: 
http://groovy.329449.n5.nabble.com/Groovysh-in-non-interactive-mode-td5731004.html

The changes for this improvement introduced the following regressions: groovysh 
no longer works in non-interactive mode.

1) Before Groovy 2.4, you could run groovysh in non-interactive mode. It would 
execute the action and then quit. This made it useful when embedding in shell 
scripts etc.
2) Before Groovy 2.4, you could pass arguments to groovysh in non-interactive 
mode. For example, I had some custom commands which I could execute not only 
from within the shell, but also outside of the shell.

Both these features seem to be gone in latest Groovy 2.4.5 release. They were 
useful and a lot of code depended on them. 

Before (groovy 2.3.9):
user@machine:~$ groovysh :show all
No variables defined
No classes have been loaded
No custom imports have been defined
Preferences:
verbose=false
===> [null, null, null, null]
user@machine:~$

After (groovy 2.4.5):
user@machine:~/opt/groovy-2.4.5/bin$ ./groovysh :show all
Groovy Shell (2.4.5, JVM: 1.8.0_51)
Type ':help' or ':h' for help.

groovy:000> :load :show
File not found: ":show"
groovy:000> :load all
File not found: "all"
groovy:000>

> groovysh positional argument terminates groovysh after evaluation
> -
>
> Key: GROOVY-6754
> URL: https://issues.apache.org/jira/browse/GROOVY-6754
> Project: Groovy
>  Issue Type: Improvement
>  Components: Groovysh
>Reporter: Thibault Kruse
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 2.4.0-beta-1
>
>
> groovy can be invoked passing a script via the -e param, e.g.
> {quote}$ groovy -e 'print 1+1'
> 2 {quote}
> groovy can also run a script file that is passed as positional argument:
> {quote}$ groovy foo.groovy
> Hello World{quote}
> For some reason, groovysh has no -e option, but allos passing a script as 
> positional argument. However, when passing this, groovysh evaluates and then 
> shuts down, seemingly without benefit over the groovy -e command.
> Also see this discussion (from 2010): 
> http://groovy.329449.n5.nabble.com/groovy-equivalent-to-quot-python-i-lt-script-py-gt-quot-td372587.html
> So i suggest to make groovysh parameters consistent with the groovy command, 
> but that groovysh does not terminate after evaluation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (GROOVY-6754) groovysh positional argument terminates groovysh after evaluation

2016-02-05 Thread Crazy Gambler (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-6754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15134614#comment-15134614
 ] 

Crazy Gambler edited comment on GROOVY-6754 at 2/5/16 6:20 PM:
---

Updating on the basis of: 
http://groovy.329449.n5.nabble.com/Groovysh-in-non-interactive-mode-td5731004.html

The changes for this improvement introduced the following regressions: groovysh 
no longer works in non-interactive mode.

# Before Groovy 2.4, you could run groovysh in non-interactive mode. It would 
execute the action and then quit. This made it useful when embedding in shell 
scripts etc.
# Before Groovy 2.4, you could pass arguments to groovysh in non-interactive 
mode. For example, I had some custom commands which I could execute not only 
from within the shell, but also outside of the shell.

Both these features seem to be gone in latest Groovy 2.4.5 release. They were 
useful and a lot of code depended on them. 

Before (groovy 2.3.9):
{noformat}user@machine:~$ groovysh :show all
No variables defined
No classes have been loaded
No custom imports have been defined
Preferences:
verbose=false
===> [null, null, null, null]
user@machine:~${noformat}

After (groovy 2.4.5):
{noformat}user@machine:~/opt/groovy-2.4.5/bin$ ./groovysh :show all
Groovy Shell (2.4.5, JVM: 1.8.0_51)
Type ':help' or ':h' for help.

groovy:000> :load :show
File not found: ":show"
groovy:000> :load all
File not found: "all"
groovy:000>{noformat}


was (Author: crazygambler):
Updating on the basis of: 
http://groovy.329449.n5.nabble.com/Groovysh-in-non-interactive-mode-td5731004.html

The changes for this improvement introduced the following regressions: groovysh 
no longer works in non-interactive mode.

1) Before Groovy 2.4, you could run groovysh in non-interactive mode. It would 
execute the action and then quit. This made it useful when embedding in shell 
scripts etc.
2) Before Groovy 2.4, you could pass arguments to groovysh in non-interactive 
mode. For example, I had some custom commands which I could execute not only 
from within the shell, but also outside of the shell.

Both these features seem to be gone in latest Groovy 2.4.5 release. They were 
useful and a lot of code depended on them. 

Before (groovy 2.3.9):
user@machine:~$ groovysh :show all
No variables defined
No classes have been loaded
No custom imports have been defined
Preferences:
verbose=false
===> [null, null, null, null]
user@machine:~$

After (groovy 2.4.5):
user@machine:~/opt/groovy-2.4.5/bin$ ./groovysh :show all
Groovy Shell (2.4.5, JVM: 1.8.0_51)
Type ':help' or ':h' for help.

groovy:000> :load :show
File not found: ":show"
groovy:000> :load all
File not found: "all"
groovy:000>

> groovysh positional argument terminates groovysh after evaluation
> -
>
> Key: GROOVY-6754
> URL: https://issues.apache.org/jira/browse/GROOVY-6754
> Project: Groovy
>  Issue Type: Improvement
>  Components: Groovysh
>Reporter: Thibault Kruse
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 2.4.0-beta-1
>
>
> groovy can be invoked passing a script via the -e param, e.g.
> {quote}$ groovy -e 'print 1+1'
> 2 {quote}
> groovy can also run a script file that is passed as positional argument:
> {quote}$ groovy foo.groovy
> Hello World{quote}
> For some reason, groovysh has no -e option, but allos passing a script as 
> positional argument. However, when passing this, groovysh evaluates and then 
> shuts down, seemingly without benefit over the groovy -e command.
> Also see this discussion (from 2010): 
> http://groovy.329449.n5.nabble.com/groovy-equivalent-to-quot-python-i-lt-script-py-gt-quot-td372587.html
> So i suggest to make groovysh parameters consistent with the groovy command, 
> but that groovysh does not terminate after evaluation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (GROOVY-6754) groovysh positional argument terminates groovysh after evaluation

2016-02-05 Thread Crazy Gambler (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-6754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15134614#comment-15134614
 ] 

Crazy Gambler edited comment on GROOVY-6754 at 2/5/16 6:21 PM:
---

Updating on the basis of: 
http://groovy.329449.n5.nabble.com/Groovysh-in-non-interactive-mode-td5731004.html

The changes for this improvement introduced the following regressions: groovysh 
no longer works in non-interactive mode.

# Before Groovy 2.4, you could run groovysh in non-interactive mode. It would 
execute the action and then quit. This made it useful when embedding in shell 
scripts etc.
# Before Groovy 2.4, you could pass arguments to groovysh in non-interactive 
mode. For example, I had some custom commands which I could execute not only 
from within the shell, but also outside of the shell.

Both these features seem to be gone in latest Groovy 2.4.5 release. They were 
useful and a lot of code depended on them. 

Before (groovy 2.3.9):
{noformat}user@machine:~$ groovysh :show all
No variables defined
No classes have been loaded
No custom imports have been defined
Preferences:
verbose=false
===> [null, null, null, null]
user@machine:~${noformat}

After (groovy 2.4.5):
{noformat}user@machine:~/opt/groovy-2.4.5/bin$ ./groovysh :show all
Groovy Shell (2.4.5, JVM: 1.8.0_51)
Type ':help' or ':h' for help.

groovy:000> :load :show
File not found: ":show"
groovy:000> :load all
File not found: "all"
groovy:000>{noformat}


was (Author: crazygambler):
Updating on the basis of: 
http://groovy.329449.n5.nabble.com/Groovysh-in-non-interactive-mode-td5731004.html

The changes for this improvement introduced the following regressions: groovysh 
no longer works in non-interactive mode.

# Before Groovy 2.4, you could run groovysh in non-interactive mode. It would 
execute the action and then quit. This made it useful when embedding in shell 
scripts etc.
# Before Groovy 2.4, you could pass arguments to groovysh in non-interactive 
mode. For example, I had some custom commands which I could execute not only 
from within the shell, but also outside of the shell.

Both these features seem to be gone in latest Groovy 2.4.5 release. They were 
useful and a lot of code depended on them. 

Before (groovy 2.3.9):
{noformat}user@machine:~$ groovysh :show all
No variables defined
No classes have been loaded
No custom imports have been defined
Preferences:
verbose=false
===> [null, null, null, null]
user@machine:~${noformat}

After (groovy 2.4.5):
{noformat}user@machine:~/opt/groovy-2.4.5/bin$ ./groovysh :show all
Groovy Shell (2.4.5, JVM: 1.8.0_51)
Type ':help' or ':h' for help.

groovy:000> :load :show
File not found: ":show"
groovy:000> :load all
File not found: "all"
groovy:000>{noformat}

> groovysh positional argument terminates groovysh after evaluation
> -
>
> Key: GROOVY-6754
> URL: https://issues.apache.org/jira/browse/GROOVY-6754
> Project: Groovy
>  Issue Type: Improvement
>  Components: Groovysh
>Reporter: Thibault Kruse
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 2.4.0-beta-1
>
>
> groovy can be invoked passing a script via the -e param, e.g.
> {quote}$ groovy -e 'print 1+1'
> 2 {quote}
> groovy can also run a script file that is passed as positional argument:
> {quote}$ groovy foo.groovy
> Hello World{quote}
> For some reason, groovysh has no -e option, but allos passing a script as 
> positional argument. However, when passing this, groovysh evaluates and then 
> shuts down, seemingly without benefit over the groovy -e command.
> Also see this discussion (from 2010): 
> http://groovy.329449.n5.nabble.com/groovy-equivalent-to-quot-python-i-lt-script-py-gt-quot-td372587.html
> So i suggest to make groovysh parameters consistent with the groovy command, 
> but that groovysh does not terminate after evaluation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (GROOVY-7627) Property calls are not correctly type checked if the setter parameter type or getter return type are not the field type

2016-02-05 Thread Shil Sinha (JIRA)

 [ 
https://issues.apache.org/jira/browse/GROOVY-7627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shil Sinha updated GROOVY-7627:
---
Fix Version/s: (was: 2.5.0-beta-1)
   2.4.6

> Property calls are not correctly type checked if the setter parameter type or 
> getter return type are not the field type
> ---
>
> Key: GROOVY-7627
> URL: https://issues.apache.org/jira/browse/GROOVY-7627
> Project: Groovy
>  Issue Type: Bug
>  Components: Static Type Checker
>Affects Versions: 2.4.5
> Environment: JDK 1.8.0_60
>Reporter: Shil Sinha
>Assignee: Shil Sinha
> Fix For: 2.4.6
>
>
> If a class defines a property but also explicitly provides a getter or 
> setter, property style get/set calls are type checked using the underlying 
> field type rather than the getter return type/setter parameter type.
> Setter example:
> {code}
> class Foo {
> Bar bar;
> void setBar(int x) {
> this.bar = new Bar(x: x)
> }
> }
> class Bar {
> int x
> }
> @groovy.transform.TypeChecked
> void test() {
> Foo foo = new Foo()
> foo.bar = new Bar()
> }
> test()
> {code}
> The code above will pass STC and throw a GroovyCastException at runtime. 
> Conversely, code like {{foo.bar = 1}} will not pass STC.  The case for 
> getters with return type different from the field type is similar.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (GROOVY-6754) groovysh positional argument terminates groovysh after evaluation

2016-02-05 Thread Thibault Kruse (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-6754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15134838#comment-15134838
 ] 

Thibault Kruse commented on GROOVY-6754:


Until I get back home to confirm, you can try the following. It could still
be possible to pass a command to groovysh in startup, but maybe in hyphens.
Also it may be possible to pass a command to groovysh that exits groovysh
at the end. Something like groovysh -x ':show all \n:exit'

Something along these lines, anyway.




> groovysh positional argument terminates groovysh after evaluation
> -
>
> Key: GROOVY-6754
> URL: https://issues.apache.org/jira/browse/GROOVY-6754
> Project: Groovy
>  Issue Type: Improvement
>  Components: Groovysh
>Reporter: Thibault Kruse
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 2.4.0-beta-1
>
>
> groovy can be invoked passing a script via the -e param, e.g.
> {quote}$ groovy -e 'print 1+1'
> 2 {quote}
> groovy can also run a script file that is passed as positional argument:
> {quote}$ groovy foo.groovy
> Hello World{quote}
> For some reason, groovysh has no -e option, but allos passing a script as 
> positional argument. However, when passing this, groovysh evaluates and then 
> shuts down, seemingly without benefit over the groovy -e command.
> Also see this discussion (from 2010): 
> http://groovy.329449.n5.nabble.com/groovy-equivalent-to-quot-python-i-lt-script-py-gt-quot-td372587.html
> So i suggest to make groovysh parameters consistent with the groovy command, 
> but that groovysh does not terminate after evaluation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (GROOVY-7705) CompileStatic closure accessing "thisObject" private field: setProperty instead of synthetic method

2016-02-05 Thread Shil Sinha (JIRA)

 [ 
https://issues.apache.org/jira/browse/GROOVY-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shil Sinha updated GROOVY-7705:
---
Fix Version/s: (was: 2.5.0-beta-1)
   2.4.6

> CompileStatic closure accessing "thisObject" private field: setProperty 
> instead of synthetic method
> ---
>
> Key: GROOVY-7705
> URL: https://issues.apache.org/jira/browse/GROOVY-7705
> Project: Groovy
>  Issue Type: Bug
>  Components: Static compilation
>Affects Versions: 2.4.5
>Reporter: Jason Winnebeck
>Assignee: Shil Sinha
> Fix For: 2.4.6
>
>
> When a closure sets the private field of a class, it does it via a 
> ScriptBytecodeAdapter.setGroovyObjectProperty on the closure object itself, 
> whereas when getting a private field of the class it uses a synthetic 
> "pfaccess$0" method.
> Source:
> {code:title=Source}
> @CompileStatic
> class SetFromClosure {
>   private int x
>   void doIt() {
>   def closure = {
>   x = 5
>   println x
>   }
>   closure()
>   }
> }
> {code}
> Decompiled result of closure class (via Fernflower in IntelliJ):
> {code}
> class SetFromClosure$_doIt_closure1 extends Closure implements 
> GeneratedClosure {
>   public SetFromClosure$_doIt_closure1(Object _outerInstance, Object 
> _thisObject) {
> super(_outerInstance, _thisObject);
>   }
>   public Object doCall(Object it) {
> byte var2 = 5;
> ScriptBytecodeAdapter.setGroovyObjectProperty(Integer.valueOf(var2), 
> SetFromClosure$_doIt_closure1.class, this, (String)"x");
> DefaultGroovyMethods.println((SetFromClosure)this.getThisObject(), 
> Integer.valueOf(SetFromClosure.pfaccess$0((SetFromClosure)this.getThisObject(;
> return null;
>   }
>   public Object call(Object args) {
> return this.doCall(args);
>   }
>   public Object call() {
> return this.doCall((Object)null);
>   }
>   public Object doCall() {
> return this.doCall((Object)null);
>   }
> }
> {code}
> Workaround is to remove "private" keyword on the variable declaration, which 
> causes Groovy to generate public getter and setter. In that mode, the static 
> compiler does generate direct calls to both the getter and the setter. In one 
> example within my project the performance speedup was 10x with this 
> workaround. The only thing I notice in the workaround that is odd is that 
> instead of normal Java casts used, ScriptBytecodeAdapter.castToType is used 
> on "getThisObject" before calling the getters or setters.
> This issue could possibly related to GROOVY-6825, but in that case it's an 
> inner class, and the issue description (currently) is not clear enough to see 
> if it's also generating a setProperty call.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (GROOVY-7705) CompileStatic closure accessing "thisObject" private field: setProperty instead of synthetic method

2016-02-05 Thread Shil Sinha (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15135017#comment-15135017
 ] 

Shil Sinha commented on GROOVY-7705:


[~gillius] This fix will be in 2.4.6.

> CompileStatic closure accessing "thisObject" private field: setProperty 
> instead of synthetic method
> ---
>
> Key: GROOVY-7705
> URL: https://issues.apache.org/jira/browse/GROOVY-7705
> Project: Groovy
>  Issue Type: Bug
>  Components: Static compilation
>Affects Versions: 2.4.5
>Reporter: Jason Winnebeck
>Assignee: Shil Sinha
> Fix For: 2.4.6
>
>
> When a closure sets the private field of a class, it does it via a 
> ScriptBytecodeAdapter.setGroovyObjectProperty on the closure object itself, 
> whereas when getting a private field of the class it uses a synthetic 
> "pfaccess$0" method.
> Source:
> {code:title=Source}
> @CompileStatic
> class SetFromClosure {
>   private int x
>   void doIt() {
>   def closure = {
>   x = 5
>   println x
>   }
>   closure()
>   }
> }
> {code}
> Decompiled result of closure class (via Fernflower in IntelliJ):
> {code}
> class SetFromClosure$_doIt_closure1 extends Closure implements 
> GeneratedClosure {
>   public SetFromClosure$_doIt_closure1(Object _outerInstance, Object 
> _thisObject) {
> super(_outerInstance, _thisObject);
>   }
>   public Object doCall(Object it) {
> byte var2 = 5;
> ScriptBytecodeAdapter.setGroovyObjectProperty(Integer.valueOf(var2), 
> SetFromClosure$_doIt_closure1.class, this, (String)"x");
> DefaultGroovyMethods.println((SetFromClosure)this.getThisObject(), 
> Integer.valueOf(SetFromClosure.pfaccess$0((SetFromClosure)this.getThisObject(;
> return null;
>   }
>   public Object call(Object args) {
> return this.doCall(args);
>   }
>   public Object call() {
> return this.doCall((Object)null);
>   }
>   public Object doCall() {
> return this.doCall((Object)null);
>   }
> }
> {code}
> Workaround is to remove "private" keyword on the variable declaration, which 
> causes Groovy to generate public getter and setter. In that mode, the static 
> compiler does generate direct calls to both the getter and the setter. In one 
> example within my project the performance speedup was 10x with this 
> workaround. The only thing I notice in the workaround that is odd is that 
> instead of normal Java casts used, ScriptBytecodeAdapter.castToType is used 
> on "getThisObject" before calling the getters or setters.
> This issue could possibly related to GROOVY-6825, but in that case it's an 
> inner class, and the issue description (currently) is not clear enough to see 
> if it's also generating a setProperty call.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (GROOVY-7741) StackoverflowError with Closure and CompileStatic

2016-02-05 Thread Shil Sinha (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-7741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15135035#comment-15135035
 ] 

Shil Sinha commented on GROOVY-7741:


The closure passed to nodes.each calls itself instead of addTextClosure.

> StackoverflowError with Closure and CompileStatic
> -
>
> Key: GROOVY-7741
> URL: https://issues.apache.org/jira/browse/GROOVY-7741
> Project: Groovy
>  Issue Type: Bug
>  Components: Static compilation
>Affects Versions: 2.4.5
>Reporter: Gerhard Langs
>
> run the code below - it fails with a stackoverflow:
> {code}
> $ groovy ClosureStackOverflow.groovy
> Caught: java.lang.StackOverflowError
> java.lang.StackOverflowError
> at ClosureStackOverflow$_f_closure2.call(ClosureStackOverflow.groovy)
> at 
> ClosureStackOverflow$_f_closure2.doCall(ClosureStackOverflow.groovy:17)
> at ClosureStackOverflow$_f_closure2.call(ClosureStackOverflow.groovy)
> at 
> ClosureStackOverflow$_f_closure2.doCall(ClosureStackOverflow.groovy:17)
> at ClosureStackOverflow$_f_closure2.call(ClosureStackOverflow.groovy)
> at 
> ClosureStackOverflow$_f_closure2.doCall(ClosureStackOverflow.groovy:17)
> {code}
> {code}
> import groovy.transform.CompileStatic
> @CompileStatic
> class ClosureStackOverflow {
> Closure addTextClosure = { "xx" }
> void f()
> {
> List nodes = [ "sth" ]
> nodes.each {
> // here we get the overflow:
> addTextClosure()
> }
> }
> static void main(String[] args) {
> new ClosureStackOverflow().f()
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (GROOVY-7741) StackoverflowError with Closure and CompileStatic

2016-02-05 Thread Shil Sinha (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-7741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15135035#comment-15135035
 ] 

Shil Sinha edited comment on GROOVY-7741 at 2/5/16 9:27 PM:


The closure passed to nodes.each calls itself in its doCall method instead of 
calling addTextClosure. 


was (Author: shils):
The closure passed to nodes.each calls itself instead of addTextClosure.

> StackoverflowError with Closure and CompileStatic
> -
>
> Key: GROOVY-7741
> URL: https://issues.apache.org/jira/browse/GROOVY-7741
> Project: Groovy
>  Issue Type: Bug
>  Components: Static compilation
>Affects Versions: 2.4.5
>Reporter: Gerhard Langs
>
> run the code below - it fails with a stackoverflow:
> {code}
> $ groovy ClosureStackOverflow.groovy
> Caught: java.lang.StackOverflowError
> java.lang.StackOverflowError
> at ClosureStackOverflow$_f_closure2.call(ClosureStackOverflow.groovy)
> at 
> ClosureStackOverflow$_f_closure2.doCall(ClosureStackOverflow.groovy:17)
> at ClosureStackOverflow$_f_closure2.call(ClosureStackOverflow.groovy)
> at 
> ClosureStackOverflow$_f_closure2.doCall(ClosureStackOverflow.groovy:17)
> at ClosureStackOverflow$_f_closure2.call(ClosureStackOverflow.groovy)
> at 
> ClosureStackOverflow$_f_closure2.doCall(ClosureStackOverflow.groovy:17)
> {code}
> {code}
> import groovy.transform.CompileStatic
> @CompileStatic
> class ClosureStackOverflow {
> Closure addTextClosure = { "xx" }
> void f()
> {
> List nodes = [ "sth" ]
> nodes.each {
> // here we get the overflow:
> addTextClosure()
> }
> }
> static void main(String[] args) {
> new ClosureStackOverflow().f()
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (GROOVY-7741) StackoverflowError with Closure and CompileStatic

2016-02-05 Thread Shil Sinha (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-7741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15135035#comment-15135035
 ] 

Shil Sinha edited comment on GROOVY-7741 at 2/5/16 9:29 PM:


The closure passed to nodes.each calls itself in its doCall method instead of 
calling addTextClosure:

{code}
  public doCall(Ljava/lang/Object;)Ljava/lang/Object;
   L0
LINENUMBER 11 L0
ALOAD 0
CHECKCAST ClosureStackOverflow$_f_closure2
INVOKEVIRTUAL ClosureStackOverflow$_f_closure2.call ()Ljava/lang/Object;
ARETURN
   L1
{code}


was (Author: shils):
The closure passed to nodes.each calls itself in its doCall method instead of 
calling addTextClosure. 

> StackoverflowError with Closure and CompileStatic
> -
>
> Key: GROOVY-7741
> URL: https://issues.apache.org/jira/browse/GROOVY-7741
> Project: Groovy
>  Issue Type: Bug
>  Components: Static compilation
>Affects Versions: 2.4.5
>Reporter: Gerhard Langs
>
> run the code below - it fails with a stackoverflow:
> {code}
> $ groovy ClosureStackOverflow.groovy
> Caught: java.lang.StackOverflowError
> java.lang.StackOverflowError
> at ClosureStackOverflow$_f_closure2.call(ClosureStackOverflow.groovy)
> at 
> ClosureStackOverflow$_f_closure2.doCall(ClosureStackOverflow.groovy:17)
> at ClosureStackOverflow$_f_closure2.call(ClosureStackOverflow.groovy)
> at 
> ClosureStackOverflow$_f_closure2.doCall(ClosureStackOverflow.groovy:17)
> at ClosureStackOverflow$_f_closure2.call(ClosureStackOverflow.groovy)
> at 
> ClosureStackOverflow$_f_closure2.doCall(ClosureStackOverflow.groovy:17)
> {code}
> {code}
> import groovy.transform.CompileStatic
> @CompileStatic
> class ClosureStackOverflow {
> Closure addTextClosure = { "xx" }
> void f()
> {
> List nodes = [ "sth" ]
> nodes.each {
> // here we get the overflow:
> addTextClosure()
> }
> }
> static void main(String[] args) {
> new ClosureStackOverflow().f()
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (GROOVY-7741) StackoverflowError with Closure and CompileStatic

2016-02-05 Thread Shil Sinha (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-7741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15135035#comment-15135035
 ] 

Shil Sinha edited comment on GROOVY-7741 at 2/5/16 9:31 PM:


The closure passed to nodes.each calls itself in its doCall method instead of 
calling addTextClosure:

{code}
  public doCall(Ljava/lang/Object;)Ljava/lang/Object;
   L0
LINENUMBER 11 L0
ALOAD 0
CHECKCAST ClosureStackOverflow$_f_closure2
INVOKEVIRTUAL ClosureStackOverflow$_f_closure2.call ()Ljava/lang/Object;
ARETURN
   L1
{code}

The exception does not occur if addTextClosure is called explicitly like 
{{addTextClosure.call()}}.


was (Author: shils):
The closure passed to nodes.each calls itself in its doCall method instead of 
calling addTextClosure:

{code}
  public doCall(Ljava/lang/Object;)Ljava/lang/Object;
   L0
LINENUMBER 11 L0
ALOAD 0
CHECKCAST ClosureStackOverflow$_f_closure2
INVOKEVIRTUAL ClosureStackOverflow$_f_closure2.call ()Ljava/lang/Object;
ARETURN
   L1
{code}

> StackoverflowError with Closure and CompileStatic
> -
>
> Key: GROOVY-7741
> URL: https://issues.apache.org/jira/browse/GROOVY-7741
> Project: Groovy
>  Issue Type: Bug
>  Components: Static compilation
>Affects Versions: 2.4.5
>Reporter: Gerhard Langs
>
> run the code below - it fails with a stackoverflow:
> {code}
> $ groovy ClosureStackOverflow.groovy
> Caught: java.lang.StackOverflowError
> java.lang.StackOverflowError
> at ClosureStackOverflow$_f_closure2.call(ClosureStackOverflow.groovy)
> at 
> ClosureStackOverflow$_f_closure2.doCall(ClosureStackOverflow.groovy:17)
> at ClosureStackOverflow$_f_closure2.call(ClosureStackOverflow.groovy)
> at 
> ClosureStackOverflow$_f_closure2.doCall(ClosureStackOverflow.groovy:17)
> at ClosureStackOverflow$_f_closure2.call(ClosureStackOverflow.groovy)
> at 
> ClosureStackOverflow$_f_closure2.doCall(ClosureStackOverflow.groovy:17)
> {code}
> {code}
> import groovy.transform.CompileStatic
> @CompileStatic
> class ClosureStackOverflow {
> Closure addTextClosure = { "xx" }
> void f()
> {
> List nodes = [ "sth" ]
> nodes.each {
> // here we get the overflow:
> addTextClosure()
> }
> }
> static void main(String[] args) {
> new ClosureStackOverflow().f()
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (GROOVY-6754) groovysh positional argument terminates groovysh after evaluation

2016-02-05 Thread Crazy Gambler (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-6754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15135461#comment-15135461
 ] 

Crazy Gambler commented on GROOVY-6754:
---

Thanks [~tkruse]! I have found a workaround described below. Here is what I 
tried:
# {{./groovysh -e ":show all \r\n :exit"}} 
I could not find a way to delimit the two commands, shell interprets it as one 
command 
{noformat}user@machine:~/opt/groovy-2.4.5/bin$ ./groovysh -e ":show all \r\n 
:exit"
Groovy Shell (2.4.5, JVM: 1.8.0_51)
Type ':help' or ':h' for help.
-
groovy:000> :show all \r\n :exit
No variables defined
No classes have been loaded
No custom imports have been defined
Preferences:
verbose=false
===> [null, null, null, null]
groovy:000> 
{noformat}
# {{./groovysh -e ":show all" ":exit"}}
Groovysh interpreted second argument as a filename to load, not as initial 
script to execute.
{noformat}user@machine:~/opt/groovy-2.4.5/bin$ ./groovysh -e ":show all" ":exit"
Groovy Shell (2.4.5, JVM: 1.8.0_51)
Type ':help' or ':h' for help.
-
groovy:000> :show all
No variables defined
No classes have been loaded
No custom imports have been defined
Preferences:
verbose=false
===> [null, null, null, null]
groovy:000> :load :exit
File not found: ":exit"
groovy:000> 
{noformat}
# {{./groovysh -e ":show all" exitConsole.groovy}}
I created a simple script exitConsole.groovy which contains {{:exit}}. This 
worked.
{noformat}user@machine:~/opt/groovy-2.4.5/bin$ ./groovysh -e ":show all" 
exitConsole.groovy
Groovy Shell (2.4.5, JVM: 1.8.0_51)
Type ':help' or ':h' for help.
-
groovy:000> :show all
No variables defined
No classes have been loaded
No custom imports have been defined
Preferences:
verbose=false
===> [null, null, null, null]
groovy:000> :load exitConsole.groovy
user@machine:~/opt/groovy-2.4.5/bin$ 
{noformat}

> groovysh positional argument terminates groovysh after evaluation
> -
>
> Key: GROOVY-6754
> URL: https://issues.apache.org/jira/browse/GROOVY-6754
> Project: Groovy
>  Issue Type: Improvement
>  Components: Groovysh
>Reporter: Thibault Kruse
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 2.4.0-beta-1
>
>
> groovy can be invoked passing a script via the -e param, e.g.
> {quote}$ groovy -e 'print 1+1'
> 2 {quote}
> groovy can also run a script file that is passed as positional argument:
> {quote}$ groovy foo.groovy
> Hello World{quote}
> For some reason, groovysh has no -e option, but allos passing a script as 
> positional argument. However, when passing this, groovysh evaluates and then 
> shuts down, seemingly without benefit over the groovy -e command.
> Also see this discussion (from 2010): 
> http://groovy.329449.n5.nabble.com/groovy-equivalent-to-quot-python-i-lt-script-py-gt-quot-td372587.html
> So i suggest to make groovysh parameters consistent with the groovy command, 
> but that groovysh does not terminate after evaluation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[GitHub] groovy pull request: GROOVY-7747: Generated Java stub for enum wit...

2016-02-05 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/groovy/pull/254


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] groovy pull request: GROOVY-7747: Generated Java stub for enum wit...

2016-02-05 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/groovy/pull/254


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (GROOVY-7747) Generated Java stub for enum with abstract method is invalid

2016-02-05 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-7747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15135640#comment-15135640
 ] 

ASF GitHub Bot commented on GROOVY-7747:


Github user asfgit closed the pull request at:

https://github.com/apache/groovy/pull/254


> Generated Java stub for enum with abstract method is invalid
> 
>
> Key: GROOVY-7747
> URL: https://issues.apache.org/jira/browse/GROOVY-7747
> Project: Groovy
>  Issue Type: Bug
> Environment: Groovy 2.4.5
>Reporter: Jonathan Peterson
>Assignee: Paul King
>Priority: Minor
>
> When generating Java stub for enum with an abstract method results in invalid 
> Java source. The generated source class is defined as "abstract enum".
> {code:title=EnumWithAbstractMethod.groovy}
> enum EnumWithAbstractMethod {
> ONE {
> @Override
> int getInt() {
> return 1
> }
> },
> TWO {
> @Override
> int getInt() {
> return 2
> }
> }
> abstract int getInt()
> }
> {code}
> {code:title=Driver.groovy}
> class Driver {
> public static void main(String[] args) {
> def stubCompiler = new JavaStubCompilationUnit(
> new CompilerConfiguration(),
> new GroovyClassLoader(),
> new File('tmp')
> )
> stubCompiler.addSource(new File('EnumWithAbstractMethod.groovy'))
> stubCompiler.compile()
> }
> }
> {code}
> {code:title=EnumWithAbstractMethod.java}
> public abstract enum EnumWithAbstractMethod
>   implements
> groovy.lang.GroovyObject {
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (GROOVY-7747) Generated Java stub for enum with abstract method is invalid

2016-02-05 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/GROOVY-7747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15135639#comment-15135639
 ] 

ASF GitHub Bot commented on GROOVY-7747:


Github user asfgit closed the pull request at:

https://github.com/apache/groovy/pull/254


> Generated Java stub for enum with abstract method is invalid
> 
>
> Key: GROOVY-7747
> URL: https://issues.apache.org/jira/browse/GROOVY-7747
> Project: Groovy
>  Issue Type: Bug
> Environment: Groovy 2.4.5
>Reporter: Jonathan Peterson
>Assignee: Paul King
>Priority: Minor
>
> When generating Java stub for enum with an abstract method results in invalid 
> Java source. The generated source class is defined as "abstract enum".
> {code:title=EnumWithAbstractMethod.groovy}
> enum EnumWithAbstractMethod {
> ONE {
> @Override
> int getInt() {
> return 1
> }
> },
> TWO {
> @Override
> int getInt() {
> return 2
> }
> }
> abstract int getInt()
> }
> {code}
> {code:title=Driver.groovy}
> class Driver {
> public static void main(String[] args) {
> def stubCompiler = new JavaStubCompilationUnit(
> new CompilerConfiguration(),
> new GroovyClassLoader(),
> new File('tmp')
> )
> stubCompiler.addSource(new File('EnumWithAbstractMethod.groovy'))
> stubCompiler.compile()
> }
> }
> {code}
> {code:title=EnumWithAbstractMethod.java}
> public abstract enum EnumWithAbstractMethod
>   implements
> groovy.lang.GroovyObject {
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (GROOVY-7747) Generated Java stub for enum with abstract method is invalid

2016-02-05 Thread Paul King (JIRA)

 [ 
https://issues.apache.org/jira/browse/GROOVY-7747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul King resolved GROOVY-7747.
---
   Resolution: Fixed
Fix Version/s: 2.4.6

PR merged.

> Generated Java stub for enum with abstract method is invalid
> 
>
> Key: GROOVY-7747
> URL: https://issues.apache.org/jira/browse/GROOVY-7747
> Project: Groovy
>  Issue Type: Bug
> Environment: Groovy 2.4.5
>Reporter: Jonathan Peterson
>Assignee: Paul King
>Priority: Minor
> Fix For: 2.4.6
>
>
> When generating Java stub for enum with an abstract method results in invalid 
> Java source. The generated source class is defined as "abstract enum".
> {code:title=EnumWithAbstractMethod.groovy}
> enum EnumWithAbstractMethod {
> ONE {
> @Override
> int getInt() {
> return 1
> }
> },
> TWO {
> @Override
> int getInt() {
> return 2
> }
> }
> abstract int getInt()
> }
> {code}
> {code:title=Driver.groovy}
> class Driver {
> public static void main(String[] args) {
> def stubCompiler = new JavaStubCompilationUnit(
> new CompilerConfiguration(),
> new GroovyClassLoader(),
> new File('tmp')
> )
> stubCompiler.addSource(new File('EnumWithAbstractMethod.groovy'))
> stubCompiler.compile()
> }
> }
> {code}
> {code:title=EnumWithAbstractMethod.java}
> public abstract enum EnumWithAbstractMethod
>   implements
> groovy.lang.GroovyObject {
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)