[jira] [Commented] (GROOVY-8467) IOGroovyMethods class readLine method works unexpected in

2018-02-06 Thread zhuxiaobing (JIRA) 

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

zhuxiaobing commented on GROOVY-8467:
-

[~blackdrag] yes, you are correct, this is what i want to say. 

> IOGroovyMethods class readLine method works unexpected in  
> ---
>
> Key: GROOVY-8467
> URL: https://issues.apache.org/jira/browse/GROOVY-8467
> Project: Groovy
>  Issue Type: Bug
> Environment: windows 7
>Reporter: zhuxiaobing
>Priority: Major
> Attachments: Screenshot from 2018-02-05 13-30-03.png, 
> groovy_test_linux.zip, groovy_test_win.zip
>
>
> i have a android aapt dump file
> i try to read the file use the code below:
>  
> {code:java}
> InputStreamReader inputReader = new InputStreamReader(dumpFile)
> String line = null
> while ((line = inputReader.readLine()) != null){
> println(line)
> }
> {code}
> the dumpfile uses \r\n to start a new line, while the IOGroovyMethods
> readLineFromReaderWithoutMark method which called by readLine  method  is : 
> {code:java}
>  private static String readLineFromReaderWithoutMark(Reader input) throws 
> IOException {
> int c = input.read();
> if(c == -1) {
> return null;
> } else {
> StringBuilder line;
> for(line = new StringBuilder(expectedLineLength); c != EOF && c != 10 
> && c != 13; c = input.read()) {
> char ch = (char)c;
> line.append(ch);
> }
> return line.toString();
> }
> }{code}
>  this casues an extra empty line read.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8472) Final variable analysis doesn't account for early exit

2018-02-06 Thread Paul King (JIRA) 

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

Paul King updated GROOVY-8472:
--
Description: 
An example with early return from a method:
{code}
def method(String foo) {
def str
try {
str = foo.trim()
}
catch(e) {
println e
return null
}
int exitCode = str.isInteger() ? str.toInteger() : null
exitCode
//str.isInteger() ? str.toInteger() : null // this doesn't trigger the error
}

println method(null)
{code}
And a slight rearrangement of above:
{code}
def method(String foo) {
def str
try {
return foo.trim()
}
catch(e) {
str = '-1'
}
int exitCode = str.toInteger() // The variable [str] may be uninitialized
exitCode
}

println method(null)
{code}
Another example with a while loop:
{code}
int index
def result = -1
int val = 2
while(true) {
try {
index = 12/val--
}
catch(e) {
break
}
println index // okay
result = index // The variable [index] may be uninitialized
}
println result // should be found but isn't if -1 above is commented out
{code}

  was:
An example with early return from a method:
{code}
def method(String foo) {
def str
try {
str = foo.trim()
}
catch(e) {
println e
return null
}
int exitCode = str.isInteger() ? str.toInteger() : null
exitCode
//str.isInteger() ? str.toInteger() : null // this doesn't trigger the error
}

println method(null)
{code}
Another example with a while loop:
{code}
int index
def result = -1
int val = 2
while(true) {
try {
index = 12/val--
}
catch(e) {
break
}
println index // okay
result = index // The variable [index] may be uninitialized
}
println result // should be found but isn't if -1 above is commented out
{code}


> Final variable analysis doesn't account for early exit
> --
>
> Key: GROOVY-8472
> URL: https://issues.apache.org/jira/browse/GROOVY-8472
> Project: Groovy
>  Issue Type: Improvement
>Reporter: Paul King
>Priority: Major
>
> An example with early return from a method:
> {code}
> def method(String foo) {
> def str
> try {
> str = foo.trim()
> }
> catch(e) {
> println e
> return null
> }
> int exitCode = str.isInteger() ? str.toInteger() : null
> exitCode
> //str.isInteger() ? str.toInteger() : null // this doesn't trigger the 
> error
> }
> println method(null)
> {code}
> And a slight rearrangement of above:
> {code}
> def method(String foo) {
> def str
> try {
> return foo.trim()
> }
> catch(e) {
> str = '-1'
> }
> int exitCode = str.toInteger() // The variable [str] may be uninitialized
> exitCode
> }
> println method(null)
> {code}
> Another example with a while loop:
> {code}
> int index
> def result = -1
> int val = 2
> while(true) {
> try {
> index = 12/val--
> }
> catch(e) {
> break
> }
> println index // okay
> result = index // The variable [index] may be uninitialized
> }
> println result // should be found but isn't if -1 above is commented out
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8469) org.codehaus.groovy.runtime.typehandling.GroovyCastException:

2018-02-06 Thread Jochen Theodorou (JIRA) 

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

Jochen Theodorou commented on GROOVY-8469:
--

Most likely the classloader setup was different for the later runs. The issue 
does not really contain any information that allows a bug to be recognized or 
even analysed.

> org.codehaus.groovy.runtime.typehandling.GroovyCastException:
> -
>
> Key: GROOVY-8469
> URL: https://issues.apache.org/jira/browse/GROOVY-8469
> Project: Groovy
>  Issue Type: Bug
>Reporter: Anna
>Priority: Major
>
> After trying to run a script i have the following message:
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast 
> object 
> 'com.onresolve.scriptrunner.canned.jira.utils.ConditionCustomScriptDelegate@78719b2a'
>  with class 
> 'com.onresolve.scriptrunner.canned.jira.utils.ConditionCustomScriptDelegate' 
> to class 'com.onresolve.scriptrunner.canned.jira.utils.CustomScriptDelegate'
> Later it run successfuI, i don't changed the script 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8472) Final variable analysis doesn't account for early exit

2018-02-06 Thread Jochen Theodorou (JIRA) 

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

Jochen Theodorou commented on GROOVY-8472:
--

to bad that the issue does not really describe the error and what is expected. 
So there is plenty room for misunderstanding things here... but in general... 
isn't it good enough for our cases to know if a variable is quasi-final from a 
certain point on? The issue shines through that initialization is required for 
that. I think it is actually not. If we define final as "we allow one single 
assignment per code path after the default value", then we have a much more 
easy life imho.  So in your first example let me totally ignore the return in 
the catch, but let us assume, that there is a caught exception... then yes str 
will be of the default value. But the value is still final after the try block 
has been handled. In your second example I see index, val and result as final 
after the while block. The much more difficult to answer question is if we 
ignore that we have a while here and assume the while is actually a method call 
with attached block, how do we then handle the final states? Nothing guarantees 
the block will actually be executed and the value be initialized at all. The 
execution might be even asynchronously. Java prevents the problem by requiring 
the final state before such blocks (anonymous inner classes and lambdas). We do 
not enforce this and I think we really need a different understanding of final 
than Java here.

> Final variable analysis doesn't account for early exit
> --
>
> Key: GROOVY-8472
> URL: https://issues.apache.org/jira/browse/GROOVY-8472
> Project: Groovy
>  Issue Type: Improvement
>Reporter: Paul King
>Priority: Major
>
> An example with early return from a method:
> {code}
> def method(String foo) {
> def str
> try {
> str = foo.trim()
> }
> catch(e) {
> println e
> return null
> }
> int exitCode = str.isInteger() ? str.toInteger() : null
> exitCode
> //str.isInteger() ? str.toInteger() : null // this doesn't trigger the 
> error
> }
> println method(null)
> {code}
> Another example with a while loop:
> {code}
> int index
> def result = -1
> int val = 2
> while(true) {
> try {
> index = 12/val--
> }
> catch(e) {
> break
> }
> println index // okay
> result = index // The variable [index] may be uninitialized
> }
> println result // should be found but isn't if -1 above is commented out
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8472) Final variable analysis doesn't account for early exit

2018-02-06 Thread Paul King (JIRA) 

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

Paul King updated GROOVY-8472:
--
Description: 
An example with early return from a method:
{code}
def method(String foo) {
def str
try {
str = foo.trim()
}
catch(e) {
println e
return null
}
int exitCode = str.isInteger() ? str.toInteger() : null
exitCode
//str.isInteger() ? str.toInteger() : null // this doesn't trigger the error
}

println method(null)
{code}
Another example with a while loop:
{code}
int index
def result = -1
int val = 2
while(true) {
try {
index = 12/val--
}
catch(e) {
break
}
println index // okay
result = index // The variable [index] may be uninitialized
}
println result // should be found but isn't if -1 above is commented out
{code}

  was:
An example with early return from a method:
{code}
def method(String foo) {
def str
try {
str = foo.trim()
}
catch(e) {
println e
return null
}
int exitCode = str.isInteger() ? str.toInteger() : null
exitCode
//str.isInteger() ? str.toInteger() : null // this doesn't trigger the error
}

println method(null)
{code}
Another example with a while loop:
{code}
int index
def result
int val = 2
while(true) {
try {
index = 12/val--
}
catch(e) {
break
}
println index // okay
result = index // The variable [index] may be uninitialized
}
println result
{code}


> Final variable analysis doesn't account for early exit
> --
>
> Key: GROOVY-8472
> URL: https://issues.apache.org/jira/browse/GROOVY-8472
> Project: Groovy
>  Issue Type: Improvement
>Reporter: Paul King
>Priority: Major
>
> An example with early return from a method:
> {code}
> def method(String foo) {
> def str
> try {
> str = foo.trim()
> }
> catch(e) {
> println e
> return null
> }
> int exitCode = str.isInteger() ? str.toInteger() : null
> exitCode
> //str.isInteger() ? str.toInteger() : null // this doesn't trigger the 
> error
> }
> println method(null)
> {code}
> Another example with a while loop:
> {code}
> int index
> def result = -1
> int val = 2
> while(true) {
> try {
> index = 12/val--
> }
> catch(e) {
> break
> }
> println index // okay
> result = index // The variable [index] may be uninitialized
> }
> println result // should be found but isn't if -1 above is commented out
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8473) Bump asm version to 6.1-beta2

2018-02-06 Thread Daniel Sun (JIRA) 
Daniel Sun created GROOVY-8473:
--

 Summary: Bump asm version to 6.1-beta2
 Key: GROOVY-8473
 URL: https://issues.apache.org/jira/browse/GROOVY-8473
 Project: Groovy
  Issue Type: Improvement
Reporter: Daniel Sun
Assignee: Daniel Sun
 Fix For: 2.6.0-alpha-3, 3.0.0-alpha-2






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8472) Final variable analysis doesn't account for early exit

2018-02-06 Thread Paul King (JIRA) 

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

Paul King updated GROOVY-8472:
--
Description: 
An example with early return from a method:
{code}
def method(String foo) {
def str
try {
str = foo.trim()
}
catch(e) {
println e
return null
}
int exitCode = str.isInteger() ? str.toInteger() : null
exitCode
//str.isInteger() ? str.toInteger() : null // this doesn't trigger the error
}

println method(null)
{code}
Another example with a while loop:
{code}
int index
def result
int val = 2
while(true) {
try {
index = 12/val--
}
catch(e) {
break
}
println index // okay
result = index // The variable [index] may be uninitialized
}
println result
{code}

  was:
{code}
def method(String foo) {
def str
try {
str = foo.trim()
}
catch(e) {
println e
return null
}
int exitCode = str.isInteger() ? str.toInteger() : null
exitCode
//str.isInteger() ? str.toInteger() : null // this doesn't trigger the error
}

println method(null)
{code}



> Final variable analysis doesn't account for early exit
> --
>
> Key: GROOVY-8472
> URL: https://issues.apache.org/jira/browse/GROOVY-8472
> Project: Groovy
>  Issue Type: Improvement
>Reporter: Paul King
>Priority: Major
>
> An example with early return from a method:
> {code}
> def method(String foo) {
> def str
> try {
> str = foo.trim()
> }
> catch(e) {
> println e
> return null
> }
> int exitCode = str.isInteger() ? str.toInteger() : null
> exitCode
> //str.isInteger() ? str.toInteger() : null // this doesn't trigger the 
> error
> }
> println method(null)
> {code}
> Another example with a while loop:
> {code}
> int index
> def result
> int val = 2
> while(true) {
> try {
> index = 12/val--
> }
> catch(e) {
> break
> }
> println index // okay
> result = index // The variable [index] may be uninitialized
> }
> println result
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GROOVY-8472) Final variable analysis doesn't account for early exit

2018-02-06 Thread Paul King (JIRA) 
Paul King created GROOVY-8472:
-

 Summary: Final variable analysis doesn't account for early exit
 Key: GROOVY-8472
 URL: https://issues.apache.org/jira/browse/GROOVY-8472
 Project: Groovy
  Issue Type: Improvement
Reporter: Paul King


{code}
def method(String foo) {
def str
try {
str = foo.trim()
}
catch(e) {
println e
return null
}
int exitCode = str.isInteger() ? str.toInteger() : null
exitCode
//str.isInteger() ? str.toInteger() : null // this doesn't trigger the error
}

println method(null)
{code}




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (GROOVY-8093) Final variable analysis broken within closure fields

2018-02-06 Thread Paul King (JIRA) 

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

Paul King resolved GROOVY-8093.
---
   Resolution: Fixed
 Assignee: Paul King
Fix Version/s: 2.5.0-beta-3

Proposed PR merged.

> 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
>Assignee: Paul King
>Priority: Major
> Fix For: 2.5.0-beta-3
>
>
> 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

2018-02-06 Thread ASF GitHub Bot (JIRA) 

[ 
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)

[GitHub] groovy pull request #659: GROOVY-8093: Final variable analysis broken within...

2018-02-06 Thread asfgit 
Github user asfgit closed the pull request at:

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


---

[jira] [Created] (GROOVY-8471) Contents of META-INF/services/org.codehaus.groovy.source.Extensions conflict with Maven/Jisaw

2018-02-06 Thread JIRA 
Ceki Gülcü created GROOVY-8471:
--

 Summary: 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: 2.4.13, 3.0.0-alpha-1
Reporter: Ceki Gülcü


>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] [Comment Edited] (GROOVY-8467) IOGroovyMethods class readLine method works unexpected in

2018-02-06 Thread Paul King (JIRA) 

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

Paul King edited comment on GROOVY-8467 at 2/6/18 1:04 PM:
---

Workaround: use readLines() or eachLine \{ ... } (but they won't give you the 
same level of streaming capability) or a reader with mark supported. The 
comment on that method indicates that this is a known design limitation:
{code:java}
/*
* This method reads without a buffer.
* It returns too many empty lines if \r\n combinations
* are used. Nothing can be done because we can't push
* back the character we have just read.
*/
private static String readLineFromReaderWithoutMark(Reader input)
{code}
I guess it should read "... nothing simple can be done ...".


was (Author: paulk):
Workaround: use readLines() or eachLine \{ ... } (but they won't give you the 
same level of streaming capability) or a reader with mark supported. The 
comment on that method indicates that this is a known design limitation:
{code:java}
/*
* This method reads without a buffer.
* It returns too many empty lines if \r\n combinations
* are used. Nothing can be done because we can't push
* back the character we have just read.
*/
private static String readLineFromReaderWithoutMark(Reader input)
{code}

> IOGroovyMethods class readLine method works unexpected in  
> ---
>
> Key: GROOVY-8467
> URL: https://issues.apache.org/jira/browse/GROOVY-8467
> Project: Groovy
>  Issue Type: Bug
> Environment: windows 7
>Reporter: zhuxiaobing
>Priority: Major
> Attachments: Screenshot from 2018-02-05 13-30-03.png, 
> groovy_test_linux.zip, groovy_test_win.zip
>
>
> i have a android aapt dump file
> i try to read the file use the code below:
>  
> {code:java}
> InputStreamReader inputReader = new InputStreamReader(dumpFile)
> String line = null
> while ((line = inputReader.readLine()) != null){
> println(line)
> }
> {code}
> the dumpfile uses \r\n to start a new line, while the IOGroovyMethods
> readLineFromReaderWithoutMark method which called by readLine  method  is : 
> {code:java}
>  private static String readLineFromReaderWithoutMark(Reader input) throws 
> IOException {
> int c = input.read();
> if(c == -1) {
> return null;
> } else {
> StringBuilder line;
> for(line = new StringBuilder(expectedLineLength); c != EOF && c != 10 
> && c != 13; c = input.read()) {
> char ch = (char)c;
> line.append(ch);
> }
> return line.toString();
> }
> }{code}
>  this casues an extra empty line read.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (GROOVY-8467) IOGroovyMethods class readLine method works unexpected in

2018-02-06 Thread Paul King (JIRA) 

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

Paul King edited comment on GROOVY-8467 at 2/6/18 1:03 PM:
---

Workaround: use readLines() or eachLine \{ ... } (but they won't give you the 
same level of streaming capability) or a reader with mark supported. The 
comment on that method indicates that this is a known design limitation:
{code:java}
/*
* This method reads without a buffer.
* It returns too many empty lines if \r\n combinations
* are used. Nothing can be done because we can't push
* back the character we have just read.
*/
private static String readLineFromReaderWithoutMark(Reader input)
{code}


was (Author: paulk):
Workaround: use readLines() or eachLine {{{ ... } }}(but they won't give you 
the same level of streaming capability) or a reader with mark supported. The 
comment on that method indicates that this is a known design limitation:
{code:java}
/*
* This method reads without a buffer.
* It returns too many empty lines if \r\n combinations
* are used. Nothing can be done because we can't push
* back the character we have just read.
*/
private static String readLineFromReaderWithoutMark(Reader input)
{code}

> IOGroovyMethods class readLine method works unexpected in  
> ---
>
> Key: GROOVY-8467
> URL: https://issues.apache.org/jira/browse/GROOVY-8467
> Project: Groovy
>  Issue Type: Bug
> Environment: windows 7
>Reporter: zhuxiaobing
>Priority: Major
> Attachments: Screenshot from 2018-02-05 13-30-03.png, 
> groovy_test_linux.zip, groovy_test_win.zip
>
>
> i have a android aapt dump file
> i try to read the file use the code below:
>  
> {code:java}
> InputStreamReader inputReader = new InputStreamReader(dumpFile)
> String line = null
> while ((line = inputReader.readLine()) != null){
> println(line)
> }
> {code}
> the dumpfile uses \r\n to start a new line, while the IOGroovyMethods
> readLineFromReaderWithoutMark method which called by readLine  method  is : 
> {code:java}
>  private static String readLineFromReaderWithoutMark(Reader input) throws 
> IOException {
> int c = input.read();
> if(c == -1) {
> return null;
> } else {
> StringBuilder line;
> for(line = new StringBuilder(expectedLineLength); c != EOF && c != 10 
> && c != 13; c = input.read()) {
> char ch = (char)c;
> line.append(ch);
> }
> return line.toString();
> }
> }{code}
>  this casues an extra empty line read.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (GROOVY-8467) IOGroovyMethods class readLine method works unexpected in

2018-02-06 Thread Paul King (JIRA) 

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

Paul King edited comment on GROOVY-8467 at 2/6/18 1:02 PM:
---

Workaround: use readLines() or eachLine {{{ ... } }}(but they won't give you 
the same level of streaming capability) or a reader with mark supported. The 
comment on that method indicates that this is a known design limitation:
{code:java}
/*
* This method reads without a buffer.
* It returns too many empty lines if \r\n combinations
* are used. Nothing can be done because we can't push
* back the character we have just read.
*/
private static String readLineFromReaderWithoutMark(Reader input)
{code}


was (Author: paulk):
Workaround: use readLines() or eachLine{ ... } (but they won't give you the 
same level of streaming capability) or a reader with mark supported. The 
comment on that method indicates that this is a known design limitation:
{code}
/*
* This method reads without a buffer.
* It returns too many empty lines if \r\n combinations
* are used. Nothing can be done because we can't push
* back the character we have just read.
*/
private static String readLineFromReaderWithoutMark(Reader input)
{code}

> IOGroovyMethods class readLine method works unexpected in  
> ---
>
> Key: GROOVY-8467
> URL: https://issues.apache.org/jira/browse/GROOVY-8467
> Project: Groovy
>  Issue Type: Bug
> Environment: windows 7
>Reporter: zhuxiaobing
>Priority: Major
> Attachments: Screenshot from 2018-02-05 13-30-03.png, 
> groovy_test_linux.zip, groovy_test_win.zip
>
>
> i have a android aapt dump file
> i try to read the file use the code below:
>  
> {code:java}
> InputStreamReader inputReader = new InputStreamReader(dumpFile)
> String line = null
> while ((line = inputReader.readLine()) != null){
> println(line)
> }
> {code}
> the dumpfile uses \r\n to start a new line, while the IOGroovyMethods
> readLineFromReaderWithoutMark method which called by readLine  method  is : 
> {code:java}
>  private static String readLineFromReaderWithoutMark(Reader input) throws 
> IOException {
> int c = input.read();
> if(c == -1) {
> return null;
> } else {
> StringBuilder line;
> for(line = new StringBuilder(expectedLineLength); c != EOF && c != 10 
> && c != 13; c = input.read()) {
> char ch = (char)c;
> line.append(ch);
> }
> return line.toString();
> }
> }{code}
>  this casues an extra empty line read.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8467) IOGroovyMethods class readLine method works unexpected in

2018-02-06 Thread Paul King (JIRA) 

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

Paul King commented on GROOVY-8467:
---

Workaround: use readLines() or eachLine{ ... } (but they won't give you the 
same level of streaming capability) or a reader with mark supported. The 
comment on that method indicates that this is a known design limitation:
{code}
/*
* This method reads without a buffer.
* It returns too many empty lines if \r\n combinations
* are used. Nothing can be done because we can't push
* back the character we have just read.
*/
private static String readLineFromReaderWithoutMark(Reader input)
{code}

> IOGroovyMethods class readLine method works unexpected in  
> ---
>
> Key: GROOVY-8467
> URL: https://issues.apache.org/jira/browse/GROOVY-8467
> Project: Groovy
>  Issue Type: Bug
> Environment: windows 7
>Reporter: zhuxiaobing
>Priority: Major
> Attachments: Screenshot from 2018-02-05 13-30-03.png, 
> groovy_test_linux.zip, groovy_test_win.zip
>
>
> i have a android aapt dump file
> i try to read the file use the code below:
>  
> {code:java}
> InputStreamReader inputReader = new InputStreamReader(dumpFile)
> String line = null
> while ((line = inputReader.readLine()) != null){
> println(line)
> }
> {code}
> the dumpfile uses \r\n to start a new line, while the IOGroovyMethods
> readLineFromReaderWithoutMark method which called by readLine  method  is : 
> {code:java}
>  private static String readLineFromReaderWithoutMark(Reader input) throws 
> IOException {
> int c = input.read();
> if(c == -1) {
> return null;
> } else {
> StringBuilder line;
> for(line = new StringBuilder(expectedLineLength); c != EOF && c != 10 
> && c != 13; c = input.read()) {
> char ch = (char)c;
> line.append(ch);
> }
> return line.toString();
> }
> }{code}
>  this casues an extra empty line read.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8467) IOGroovyMethods class readLine method works unexpected in

2018-02-06 Thread Jochen Theodorou (JIRA) 

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

Jochen Theodorou commented on GROOVY-8467:
--

I think I see the problem now. If we read A\r\nB\r\n, then readLine will make 
first a line for A and then the expectation is to have the next line for B. The 
loop up there will only consume the \r, not the \n. And this leads to an empty 
line. So reading all lines will produce A, empty, B empty. Is that correct?

> IOGroovyMethods class readLine method works unexpected in  
> ---
>
> Key: GROOVY-8467
> URL: https://issues.apache.org/jira/browse/GROOVY-8467
> Project: Groovy
>  Issue Type: Bug
> Environment: windows 7
>Reporter: zhuxiaobing
>Priority: Major
> Attachments: Screenshot from 2018-02-05 13-30-03.png, 
> groovy_test_linux.zip, groovy_test_win.zip
>
>
> i have a android aapt dump file
> i try to read the file use the code below:
>  
> {code:java}
> InputStreamReader inputReader = new InputStreamReader(dumpFile)
> String line = null
> while ((line = inputReader.readLine()) != null){
> println(line)
> }
> {code}
> the dumpfile uses \r\n to start a new line, while the IOGroovyMethods
> readLineFromReaderWithoutMark method which called by readLine  method  is : 
> {code:java}
>  private static String readLineFromReaderWithoutMark(Reader input) throws 
> IOException {
> int c = input.read();
> if(c == -1) {
> return null;
> } else {
> StringBuilder line;
> for(line = new StringBuilder(expectedLineLength); c != EOF && c != 10 
> && c != 13; c = input.read()) {
> char ch = (char)c;
> line.append(ch);
> }
> return line.toString();
> }
> }{code}
>  this casues an extra empty line read.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-4105) List Comprehensions are Missing from Groovy

2018-02-06 Thread Mario Garcia (JIRA) 

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

Mario Garcia commented on GROOVY-4105:
--

At the time I started to implement list comprehensions applying AST 
transformation to list syntax in Groovy. I did a first attempt to see how they 
could look like, and this is what I got:
{code:java}
assert [ x  | x << (1..2)]  == [1,2]
assert [ [x,y]  | x << (1..2), y << (1..2)] == [[1,1], [1,2], [2,1], 
[2,2]]
assert [ { x + y }  | x << (1..2), y << (1..2)] == [2, 3, 3, 4]
assert [ i  | i << [ j | j << (1..10)]] == [1, 2, 3, 4, 5, 6, 7, 8, 
9, 10]
assert [[x + y , x - y] | x << (1..2), y << (1..2)] == [[2, 0], [3, -1], [3, 
1], [4, 0]]
{code}
 
 Things I didn't do:
 - *guards*: filtering elements
 - *lazyness*: take, takeWhile, skip

Although it's amazing how many things can be done with Groovy syntax + AST 
transformations, it's also true, that this kind of implementation it's far from 
being trivial, and it should need a more concrete proposal.
 - *What can be considered a generator*
{code:java}
x << generateValues() // a method call returning a collection of values
x << (1..20) // a range
x << [y | y << (1..10)]  // another comprehension
{code}

 - *The different expressions allowed in the value generated*

{code:java}
x // simple value
[x] // a list
{x + 1} // some value calculated in a closure
{code}

 - *What can be considered a guard*
{code:java}
{ x % 2 == 0} // a closure returning a boolean
filter(x) // a method call returning a boolean
{code}

 - *What expressions can be used to limit of elements generated*
{code:java}
[x | x << (1..10)].take(10) // following current Groovy/list method calls
[x | x << (1..10), take(10)] // methods inside the comprehension
{code}

 - *How static compilation should behave over a list comprehension*

Those are a few questions that sprang to mind but there could be other 
important ones that I could have forgotten. I guess once the path is clear is a 
matter of time and motivation.

Another point of view, is that such feature, could be delivered by an external 
library so that if it is really worth it then could be added as part of the 
language.

> List Comprehensions are Missing from Groovy
> ---
>
> Key: GROOVY-4105
> URL: https://issues.apache.org/jira/browse/GROOVY-4105
> Project: Groovy
>  Issue Type: Improvement
>  Components: Compiler
>Reporter: Russel Winder
>Priority: Critical
> Attachments: collectMany.patch
>
>
> List comprehensions are present in C#, Clojure, Common Lisp, Erlang, Haskell, 
> JavaScript, Boo, OCaml, Perl, Python, Scala, Scheme and other languages.  
> They are obviously missing from Groovy.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-5249) Avoid unnecessary locking in ClassInfo.getMetaClass

2018-02-06 Thread Jochen Theodorou (JIRA) 

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

Jochen Theodorou commented on GROOVY-5249:
--

I think just cherry-picking them and not having conflicts will not work. If it 
is save or not... well.. 1.7.5 is 8 years old. I can understand that you are 
maybe stuck with Grails 1.3.5, but if applying those commits will solve your 
issue and not produce new ones is something nobody here can really answer I 
think. Did you every try using a new Groovy with that Grails version? It may 
just work (once you rename the jar). But even in the 1.7 line we have a lot of 
fixes newer than 1.7.5

> Avoid unnecessary locking in ClassInfo.getMetaClass
> ---
>
> Key: GROOVY-5249
> URL: https://issues.apache.org/jira/browse/GROOVY-5249
> Project: Groovy
>  Issue Type: Bug
>  Components: groovy-runtime
> Environment: Linux 64-bit, Java 1.6, Tomcat, Grails
>Reporter: Serge P. Nekoval
>Assignee: Jochen Theodorou
>Priority: Critical
> Fix For: 2.3.0-beta-1, 2.2.3
>
> Attachments: mc.patch, mc.patch
>
>
> We have a Grails application serving hundreds of requests per second and this 
> seems to be the most critical hot spot for us. Under high load, most threads 
> are blocked in the following call stack:
> {code}
> "http-apr-8080"-exec-144
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:842)
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1178)
> org.codehaus.groovy.util.LockableObject.lock(LockableObject.java:34)
> org.codehaus.groovy.reflection.ClassInfo.lock(ClassInfo.java:268)
> org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:193)
> org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.getMetaClass(MetaClassRegistryImpl.java:214)
> org.codehaus.groovy.runtime.InvokerHelper.getMetaClass(InvokerHelper.java:747)
> org.codehaus.groovy.runtime.InvokerHelper.invokePojoMethod(InvokerHelper.java:780)
> org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:772)
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToBoolean(DefaultTypeTransformation.java:156)
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.booleanUnbox(DefaultTypeTransformation.java:65)
> {code}
> Grails uses {{InvokerHelper}} a lot, which calls {{ClassInfo.getMetaClass}} 
> which uses locking. This is stop-the-world lock affecting all threads (they 
> all hit the same {{ClassInfo}} instance). Note that 99,999% of time the 
> locking is useless as nothing is modified (typically all metaclasses getting 
> modified on startup). 
> There are several related tickets: GROOVY-3557 and GROOVY-5059, not really 
> solving the issue.
> The solution could be to use more fine-grained locks (ReadWriteLock) or 
> Atomics. Should be easy to implement, but need to isolate modification part 
> from read-only parts.
> Doing so can be a good boost to overall Grails performance.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] groovy pull request #566: Added IgnoreDefaultEqualsAndToString

2018-02-06 Thread melix 
Github user melix commented on a diff in the pull request:

https://github.com/apache/groovy/pull/566#discussion_r166253411
  
--- Diff: src/main/org/codehaus/groovy/runtime/DefaultGroovyMethods.java ---
@@ -12026,6 +12026,9 @@ public static boolean equals(List left, List right) 
{
 if (left == right) {
 return true;
 }
+if( 
left.getClass().getAnnotation(IgnoreDefaultEqualsAndToString.class)!=null && 
right.getClass().getAnnotation(IgnoreDefaultEqualsAndToString.class)!=null ) {
--- End diff --

I have nothing particular in mind at this point, but it involves this 
method being called with different kind of objects, and comparing with the 
baseline without the change.


---

[GitHub] groovy pull request #566: Added IgnoreDefaultEqualsAndToString

2018-02-06 Thread pditommaso 
Github user pditommaso commented on a diff in the pull request:

https://github.com/apache/groovy/pull/566#discussion_r166250753
  
--- Diff: src/main/org/codehaus/groovy/runtime/DefaultGroovyMethods.java ---
@@ -12026,6 +12026,9 @@ public static boolean equals(List left, List right) 
{
 if (left == right) {
 return true;
 }
+if( 
left.getClass().getAnnotation(IgnoreDefaultEqualsAndToString.class)!=null && 
right.getClass().getAnnotation(IgnoreDefaultEqualsAndToString.class)!=null ) {
--- End diff --

Could you suggest a possible metrics/benchmark ?


---

[GitHub] groovy pull request #566: Added IgnoreDefaultEqualsAndToString

2018-02-06 Thread melix 
Github user melix commented on a diff in the pull request:

https://github.com/apache/groovy/pull/566#discussion_r166246347
  
--- Diff: src/main/org/codehaus/groovy/runtime/DefaultGroovyMethods.java ---
@@ -12026,6 +12026,9 @@ public static boolean equals(List left, List right) 
{
 if (left == right) {
 return true;
 }
+if( 
left.getClass().getAnnotation(IgnoreDefaultEqualsAndToString.class)!=null && 
right.getClass().getAnnotation(IgnoreDefaultEqualsAndToString.class)!=null ) {
--- End diff --

-1 to this until we have a better idea on the impact on performance. 
Calling `getClass().getAnnotation(...)` is **very** expensive.


---

[GitHub] groovy pull request #659: GROOVY-8093: Final variable analysis broken within...

2018-02-06 Thread paulk-asert 
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






---

[jira] [Commented] (GROOVY-8093) Final variable analysis broken within closure fields

2018-02-06 Thread ASF GitHub Bot (JIRA) 

[ 
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)