[jira] [Comment Edited] (GROOVY-11459) weak hashing algorithm (使用弱哈希算法)
[ https://issues.apache.org/jira/browse/GROOVY-11459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881922#comment-17881922 ] Paul King edited comment on GROOVY-11459 at 9/16/24 5:56 AM: - Current status: hashing algorithm is now configurable thanks. Default is still md5. Plan is to test more on master and if further testing shows sha256 to be as fast as md5, swap the default on master (for Groovy 5). If testing isn't finished before we make the next release, I'll clone the issue and split out that work. was (Author: paulk): Current status: hashing algorithm is now configurable thanks. Default is still md5. Plan is to test more on master and if further testing shows sha256 to be as fast as md5, swap the default on master (for Groovy 5). > weak hashing algorithm (使用弱哈希算法) > > > Key: GROOVY-11459 > URL: https://issues.apache.org/jira/browse/GROOVY-11459 > Project: Groovy > Issue Type: Bug >Affects Versions: 4.0.22 >Reporter: wellchang >Assignee: Paul King >Priority: Major > > 通过iast扫描发现groovy中使用了md5来生成缓存键名，路径为groovy.lang.GroovyClassLoader.getSourceCacheKey > 建议使用常见的安全的哈希算法，如SHA-256,SHA-384,SHA-512等 > Google Translate gives: > Through iast scanning, it was found that md5 is used in groovy to generate > the cache key name, and the path is > groovy.lang.GroovyClassLoader.getSourceCacheKey > It is recommended to use common secure hash algorithms, such as SHA-256, > SHA-384, SHA-512, etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11459) weak hashing algorithm (使用弱哈希算法)
[ https://issues.apache.org/jira/browse/GROOVY-11459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881922#comment-17881922 ] Paul King commented on GROOVY-11459: Current status: hashing algorithm is now configurable thanks. Default is still md5. Plan is to test more on master and if further testing shows sha256 to be as fast as md5, swap the default on master (for Groovy 5). > weak hashing algorithm (使用弱哈希算法) > > > Key: GROOVY-11459 > URL: https://issues.apache.org/jira/browse/GROOVY-11459 > Project: Groovy > Issue Type: Bug >Affects Versions: 4.0.22 >Reporter: wellchang >Assignee: Paul King >Priority: Major > > 通过iast扫描发现groovy中使用了md5来生成缓存键名，路径为groovy.lang.GroovyClassLoader.getSourceCacheKey > 建议使用常见的安全的哈希算法，如SHA-256,SHA-384,SHA-512等 > Google Translate gives: > Through iast scanning, it was found that md5 is used in groovy to generate > the cache key name, and the path is > groovy.lang.GroovyClassLoader.getSourceCacheKey > It is recommended to use common secure hash algorithms, such as SHA-256, > SHA-384, SHA-512, etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11478) Enable GroovyClassLoader to be ParallelCapable
Paul King created GROOVY-11478:
--
Summary: Enable GroovyClassLoader to be ParallelCapable
Key: GROOVY-11478
URL: https://issues.apache.org/jira/browse/GROOVY-11478
Project: Groovy
Issue Type: Improvement
Affects Versions: 5.0.0-alpha-10, 4.0.23, 3.0.22
Reporter: Paul King
Assignee: Paul King
GroovyClassLoader is parallel capable but we do not declare it as such by
calling the {{registerAsParallelCapable}} method as per recommended
guidelines[1]. Some frameworks have worked around this using reflection but as
JDK restrictions have tightened in later JDK versions, this has become not
possible. Other workarounds[2] for frameworks to work with non-parallel capable
classloaders have also been deprecated and removed in recent JDK
versions[3][4][5]. See also [6].
[1] https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html
[2] https://openjdk.org/groups/core-libs/ClassLoaderProposal.html
[3] https://bugs.openjdk.org/browse/JDK-8296446
[4] https://bugs.openjdk.org/browse/JDK-8303967
[5] https://bugs.openjdk.org/browse/JDK-8295848
[6] https://inside.java/2022/11/14/quality-heads-up/
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-11459) weak hashing algorithm (使用弱哈希算法)
[ https://issues.apache.org/jira/browse/GROOVY-11459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881009#comment-17881009 ] Paul King edited comment on GROOVY-11459 at 9/11/24 3:24 PM: - I'll send an email to the dev list shortly. Short answer is I like the idea of making it configurable and maybe sha256 isn't that bad performance-wise but I think we'd need more testing to know for sure. It puzzles me why the 5.0.0-alpha-9 test is quite a bit faster than the current_md5 version when there is really only a switch statement extra in that case and a one-off system property read. was (Author: paulk): I'll send an email to the dev list shortly. > weak hashing algorithm (使用弱哈希算法) > > > Key: GROOVY-11459 > URL: https://issues.apache.org/jira/browse/GROOVY-11459 > Project: Groovy > Issue Type: Bug >Affects Versions: 4.0.22 >Reporter: wellchang >Assignee: Paul King >Priority: Major > > 通过iast扫描发现groovy中使用了md5来生成缓存键名，路径为groovy.lang.GroovyClassLoader.getSourceCacheKey > 建议使用常见的安全的哈希算法，如SHA-256,SHA-384,SHA-512等 > Google Translate gives: > Through iast scanning, it was found that md5 is used in groovy to generate > the cache key name, and the path is > groovy.lang.GroovyClassLoader.getSourceCacheKey > It is recommended to use common secure hash algorithms, such as SHA-256, > SHA-384, SHA-512, etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11459) weak hashing algorithm (使用弱哈希算法)
[ https://issues.apache.org/jira/browse/GROOVY-11459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881009#comment-17881009 ] Paul King commented on GROOVY-11459: I'll send an email to the dev list shortly. > weak hashing algorithm (使用弱哈希算法) > > > Key: GROOVY-11459 > URL: https://issues.apache.org/jira/browse/GROOVY-11459 > Project: Groovy > Issue Type: Bug >Affects Versions: 4.0.22 >Reporter: wellchang >Assignee: Paul King >Priority: Major > > 通过iast扫描发现groovy中使用了md5来生成缓存键名，路径为groovy.lang.GroovyClassLoader.getSourceCacheKey > 建议使用常见的安全的哈希算法，如SHA-256,SHA-384,SHA-512等 > Google Translate gives: > Through iast scanning, it was found that md5 is used in groovy to generate > the cache key name, and the path is > groovy.lang.GroovyClassLoader.getSourceCacheKey > It is recommended to use common secure hash algorithms, such as SHA-256, > SHA-384, SHA-512, etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-11459) weak hashing algorithm (使用弱哈希算法)
[
https://issues.apache.org/jira/browse/GROOVY-11459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880970#comment-17880970
]
Paul King edited comment on GROOVY-11459 at 9/11/24 2:16 PM:
-
I created a temporary branch to play with hashing algorithms:
[https://github.com/paulk-asert/groovy/tree/groovy11459]
Some parts are definitely not intended to be committed. When running
`perf:perfTests` gives results like this:
{noformat}
> Task :performance:performanceTests (Linux JDK21)
Groovy 5_0_0-alpha-9Average 593.9ms ± 70.56ms
Groovy current_md5 Average 634.54ms ± 88.25ms (6.84% slower)
Groovy current_xx128Average 635.98ms ± 85.95ms (7.08% slower)
Groovy current_sha256 Average 636.03ms ± 83.15ms (7.09% slower)
Groovy current_murmur3_128B Average 640.67ms ± 78.06ms (7.87% slower)
Groovy current_murmur3_128A Average 654.14ms ± 73.55ms (10.14% slower)
Groovy 4_0_22 Average 738.33ms ± 216.17ms (24.32% slower)
{noformat}
The ordering wasn't consistent, e.g. here was one of the runs on Windows:
{noformat}
> Task :performance:performanceTests (Windows JDK17)
Groovy current_murmur3_128B Average 957.75ms ± 16.2ms
Groovy current_murmur3_128A Average 962.23ms ± 21.11ms (0.47% slower)
Groovy current_sha256 Average 969.51ms ± 26.66ms (1.23% slower)
Groovy current_xx128Average 970.76ms ± 29.18ms (1.36% slower)
Groovy current_md5 Average 975.36ms ± 24.39ms (1.84% slower)
{noformat}
The murmur3_128A was from Apache commons code:
.https://github.com/apache/commons-codec
The murmur3_128B and xx128 were from:
https://github.com/OpenHFT/Zero-Allocation-Hashing
Trying out those algorithms was just to check whether there were better or
faster 128-bit algorithms. The results don't indicate that we'd want to
consider also supporting those.
was (Author: paulk):
I created a temporary branch to play with hashing algorithms:
[https://github.com/paulk-asert/groovy/tree/groovy11459]
Some parts are definitely not intended to be committed. When running
`perf:perfTests` gives results like this:
{noformat}
> Task :performance:performanceTests (Linux JDK21)
Groovy 5_0_0-alpha-9Average 593.9ms ± 70.56ms
Groovy current_md5 Average 634.54ms ± 88.25ms (6.84% slower)
Groovy current_xx128Average 635.98ms ± 85.95ms (7.08% slower)
Groovy current_sha256 Average 636.03ms ± 83.15ms (7.09% slower)
Groovy current_murmur3_128B Average 640.67ms ± 78.06ms (7.87% slower)
Groovy current_murmur3_128A Average 654.14ms ± 73.55ms (10.14% slower)
Groovy 4_0_22 Average 738.33ms ± 216.17ms (24.32% slower)
{noformat}
The ordering wasn't consistent, e.g. here was one of the runs on Windows:
{noformat}
> Task :performance:performanceTests (Windows JDK17)
Groovy current_murmur3_128B Average 957.75ms ± 16.2ms
Groovy current_murmur3_128A Average 962.23ms ± 21.11ms (0.47% slower)
Groovy current_sha256 Average 969.51ms ± 26.66ms (1.23% slower)
Groovy current_xx128Average 970.76ms ± 29.18ms (1.36% slower)
Groovy current_md5 Average 975.36ms ± 24.39ms (1.84% slower)
{noformat}
> weak hashing algorithm (使用弱哈希算法)
>
>
> Key: GROOVY-11459
> URL: https://issues.apache.org/jira/browse/GROOVY-11459
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.22
>Reporter: wellchang
>Assignee: Paul King
>Priority: Major
>
> 通过iast扫描发现groovy中使用了md5来生成缓存键名，路径为groovy.lang.GroovyClassLoader.getSourceCacheKey
> 建议使用常见的安全的哈希算法，如SHA-256,SHA-384,SHA-512等
> Google Translate gives:
> Through iast scanning, it was found that md5 is used in groovy to generate
> the cache key name, and the path is
> groovy.lang.GroovyClassLoader.getSourceCacheKey
> It is recommended to use common secure hash algorithms, such as SHA-256,
> SHA-384, SHA-512, etc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-11459) weak hashing algorithm (使用弱哈希算法)
[
https://issues.apache.org/jira/browse/GROOVY-11459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880970#comment-17880970
]
Paul King edited comment on GROOVY-11459 at 9/11/24 1:50 PM:
-
I created a temporary branch to play with hashing algorithms:
[https://github.com/paulk-asert/groovy/tree/groovy11459]
Some parts are definitely not intended to be committed. When running
`perf:perfTests` gives results like this:
{noformat}
> Task :performance:performanceTests (Linux JDK21)
Groovy 5_0_0-alpha-9Average 593.9ms ± 70.56ms
Groovy current_md5 Average 634.54ms ± 88.25ms (6.84% slower)
Groovy current_xx128Average 635.98ms ± 85.95ms (7.08% slower)
Groovy current_sha256 Average 636.03ms ± 83.15ms (7.09% slower)
Groovy current_murmur3_128B Average 640.67ms ± 78.06ms (7.87% slower)
Groovy current_murmur3_128A Average 654.14ms ± 73.55ms (10.14% slower)
Groovy 4_0_22 Average 738.33ms ± 216.17ms (24.32% slower)
{noformat}
The ordering wasn't consistent, e.g. here was one of the runs on Windows:
{noformat}
> Task :performance:performanceTests (Windows JDK17)
Groovy current_murmur3_128B Average 957.75ms ± 16.2ms
Groovy current_murmur3_128A Average 962.23ms ± 21.11ms (0.47% slower)
Groovy current_sha256 Average 969.51ms ± 26.66ms (1.23% slower)
Groovy current_xx128Average 970.76ms ± 29.18ms (1.36% slower)
Groovy current_md5 Average 975.36ms ± 24.39ms (1.84% slower)
{noformat}
was (Author: paulk):
I created a temporary branch to play with hashing algorithms:
https://github.com/paulk-asert/groovy/tree/groovy11459
Some parts are definitely not intended to be committed. When running
`perf:perfTests` gives results like this:
{noformat}
> Task :performance:performanceTests (Linux JDK21)
Groovy 5_0_0-alpha-9Average 593.9ms ± 70.56ms
Groovy current_md5 Average 634.54ms ± 88.25ms (6.84% slower)
Groovy current_xx128Average 635.98ms ± 85.95ms (7.08% slower)
Groovy current_sha256 Average 636.03ms ± 83.15ms (7.09% slower)
Groovy current_murmur3_128B Average 640.67ms ± 78.06ms (7.87% slower)
Groovy current_murmur3_128A Average 654.14ms ± 73.55ms (10.14% slower)
Groovy 4_0_22 Average 738.33ms ± 216.17ms (24.32% slower)
{noformat}
The ordering wasn't consistent, e.g. here was one of the runs on Windows:
{noformat}
> Task :performance:performanceTests (Windows JDK17)
Groovy current_murmur3_128B Average 957.75ms ± 16.2ms
Groovy current_murmur3_128A Average 962.23ms ± 21.11ms (0.47% slower)
Groovy current_sha256 Average 969.51ms ± 26.66ms (1.23% slower)
Groovy current_xx128 Average 970.76ms ± 29.18ms (1.36% slower)
Groovy current_md5 Average 975.36ms ± 24.39ms (1.84% slower)
{noformat}
> weak hashing algorithm (使用弱哈希算法)
>
>
> Key: GROOVY-11459
> URL: https://issues.apache.org/jira/browse/GROOVY-11459
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.22
>Reporter: wellchang
>Assignee: Paul King
>Priority: Major
>
> 通过iast扫描发现groovy中使用了md5来生成缓存键名，路径为groovy.lang.GroovyClassLoader.getSourceCacheKey
> 建议使用常见的安全的哈希算法，如SHA-256,SHA-384,SHA-512等
> Google Translate gives:
> Through iast scanning, it was found that md5 is used in groovy to generate
> the cache key name, and the path is
> groovy.lang.GroovyClassLoader.getSourceCacheKey
> It is recommended to use common secure hash algorithms, such as SHA-256,
> SHA-384, SHA-512, etc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-11459) weak hashing algorithm (使用弱哈希算法)
[
https://issues.apache.org/jira/browse/GROOVY-11459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880970#comment-17880970
]
Paul King edited comment on GROOVY-11459 at 9/11/24 1:47 PM:
-
I created a temporary branch to play with hashing algorithms:
https://github.com/paulk-asert/groovy/tree/groovy11459
Some parts are definitely not intended to be committed. When running
`perf:perfTests` gives results like this:
{noformat}
> Task :performance:performanceTests (Linux JDK21)
Groovy 5_0_0-alpha-9Average 593.9ms ± 70.56ms
Groovy current_md5 Average 634.54ms ± 88.25ms (6.84% slower)
Groovy current_xx128Average 635.98ms ± 85.95ms (7.08% slower)
Groovy current_sha256 Average 636.03ms ± 83.15ms (7.09% slower)
Groovy current_murmur3_128B Average 640.67ms ± 78.06ms (7.87% slower)
Groovy current_murmur3_128A Average 654.14ms ± 73.55ms (10.14% slower)
Groovy 4_0_22 Average 738.33ms ± 216.17ms (24.32% slower)
{noformat}
The ordering wasn't consistent, e.g. here was one of the runs on Windows:
{noformat}
> Task :performance:performanceTests (Windows JDK17)
Groovy current_murmur3_128B Average 957.75ms ± 16.2ms
Groovy current_murmur3_128A Average 962.23ms ± 21.11ms (0.47% slower)
Groovy current_sha256 Average 969.51ms ± 26.66ms (1.23% slower)
Groovy current_xx128 Average 970.76ms ± 29.18ms (1.36% slower)
Groovy current_md5 Average 975.36ms ± 24.39ms (1.84% slower)
{noformat}
was (Author: paulk):
I created a temporary branch to play with hashing algorithms:
https://github.com/paulk-asert/groovy/tree/groovy11459
Some parts are definitely not intended to be committed. When running
`perf:perfTests` gives results like this:
{noformat}
> Task :performance:performanceTests
Groovy 5_0_0-alpha-9Average 593.9ms ± 70.56ms
Groovy current_md5 Average 634.54ms ± 88.25ms (6.84% slower)
Groovy current_xx128Average 635.98ms ± 85.95ms (7.08% slower)
Groovy current_sha256 Average 636.03ms ± 83.15ms (7.09% slower)
Groovy current_murmur3_128B Average 640.67ms ± 78.06ms (7.87% slower)
Groovy current_murmur3_128A Average 654.14ms ± 73.55ms (10.14% slower)
Groovy 4_0_22 Average 738.33ms ± 216.17ms (24.32% slower)
{noformat}
> weak hashing algorithm (使用弱哈希算法)
>
>
> Key: GROOVY-11459
> URL: https://issues.apache.org/jira/browse/GROOVY-11459
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.22
>Reporter: wellchang
>Assignee: Paul King
>Priority: Major
>
> 通过iast扫描发现groovy中使用了md5来生成缓存键名，路径为groovy.lang.GroovyClassLoader.getSourceCacheKey
> 建议使用常见的安全的哈希算法，如SHA-256,SHA-384,SHA-512等
> Google Translate gives:
> Through iast scanning, it was found that md5 is used in groovy to generate
> the cache key name, and the path is
> groovy.lang.GroovyClassLoader.getSourceCacheKey
> It is recommended to use common secure hash algorithms, such as SHA-256,
> SHA-384, SHA-512, etc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11459) weak hashing algorithm (使用弱哈希算法)
[
https://issues.apache.org/jira/browse/GROOVY-11459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880970#comment-17880970
]
Paul King commented on GROOVY-11459:
I created a temporary branch to play with hashing algorithms:
https://github.com/paulk-asert/groovy/tree/groovy11459
Some parts are definitely not intended to be committed. When running
`perf:perfTests` gives results like this:
{noformat}
> Task :performance:performanceTests
Groovy 5_0_0-alpha-9Average 593.9ms ± 70.56ms
Groovy current_md5 Average 634.54ms ± 88.25ms (6.84% slower)
Groovy current_xx128Average 635.98ms ± 85.95ms (7.08% slower)
Groovy current_sha256 Average 636.03ms ± 83.15ms (7.09% slower)
Groovy current_murmur3_128B Average 640.67ms ± 78.06ms (7.87% slower)
Groovy current_murmur3_128A Average 654.14ms ± 73.55ms (10.14% slower)
Groovy 4_0_22 Average 738.33ms ± 216.17ms (24.32% slower)
{noformat}
> weak hashing algorithm (使用弱哈希算法)
>
>
> Key: GROOVY-11459
> URL: https://issues.apache.org/jira/browse/GROOVY-11459
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.22
>Reporter: wellchang
>Assignee: Paul King
>Priority: Major
>
> 通过iast扫描发现groovy中使用了md5来生成缓存键名，路径为groovy.lang.GroovyClassLoader.getSourceCacheKey
> 建议使用常见的安全的哈希算法，如SHA-256,SHA-384,SHA-512等
> Google Translate gives:
> Through iast scanning, it was found that md5 is used in groovy to generate
> the cache key name, and the path is
> groovy.lang.GroovyClassLoader.getSourceCacheKey
> It is recommended to use common secure hash algorithms, such as SHA-256,
> SHA-384, SHA-512, etc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-11472) Bump logback-classic to 1.5.8 (test dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-11472. Resolution: Fixed > Bump logback-classic to 1.5.8 (test dependency) > --- > > Key: GROOVY-11472 > URL: https://issues.apache.org/jira/browse/GROOVY-11472 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-10 > > > For Groovy 5+ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11473) Bump log4j2 version to 2.24.0 (test dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-11473. Fix Version/s: 5.0.0-alpha-10 4.0.23 Resolution: Fixed > Bump log4j2 version to 2.24.0 (test dependency) > --- > > Key: GROOVY-11473 > URL: https://issues.apache.org/jira/browse/GROOVY-11473 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-10, 4.0.23 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11473) Bump log4j2 version to 2.24.0 (test dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11473: --- Fix Version/s: (was: 5.0.0-alpha-8) (was: 4.0.21) > Bump log4j2 version to 2.24.0 (test dependency) > --- > > Key: GROOVY-11473 > URL: https://issues.apache.org/jira/browse/GROOVY-11473 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11473) Bump log4j2 version to 2.24.0 (test dependency)
Paul King created GROOVY-11473: -- Summary: Bump log4j2 version to 2.24.0 (test dependency) Key: GROOVY-11473 URL: https://issues.apache.org/jira/browse/GROOVY-11473 Project: Groovy Issue Type: Dependency upgrade Reporter: Paul King Assignee: Paul King Fix For: 5.0.0-alpha-8, 4.0.21 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GROOVY-11469) Empty execute method in groovy.sql.Sql
[ https://issues.apache.org/jira/browse/GROOVY-11469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King reassigned GROOVY-11469: -- Assignee: Paul King > Empty execute method in groovy.sql.Sql > -- > > Key: GROOVY-11469 > URL: https://issues.apache.org/jira/browse/GROOVY-11469 > Project: Groovy > Issue Type: Bug > Components: SQL processing >Affects Versions: 4.0.22 >Reporter: Henrique Mota >Assignee: Paul King >Priority: Major > Attachments: image-2024-09-04-12-56-27-527.png > > > !image-2024-09-04-12-56-27-527.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11463) Bump ant version to 1.10.15
[ https://issues.apache.org/jira/browse/GROOVY-11463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-11463. Fix Version/s: 4.0.23 5.0.0-alpha-10 Resolution: Fixed > Bump ant version to 1.10.15 > --- > > Key: GROOVY-11463 > URL: https://issues.apache.org/jira/browse/GROOVY-11463 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 4.0.23, 5.0.0-alpha-10 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11460) Bump slf4j to 2.0.16 (test and standard install dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-11460. Fix Version/s: 4.0.23 5.0.0-alpha-10 Resolution: Fixed > Bump slf4j to 2.0.16 (test and standard install dependency) > --- > > Key: GROOVY-11460 > URL: https://issues.apache.org/jira/browse/GROOVY-11460 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 4.0.23, 5.0.0-alpha-10 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11462) Bump Codenarc to 3.5.0-groovy-4.0 (build dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-11462. Fix Version/s: 4.0.23 5.0.0-alpha-10 Resolution: Fixed > Bump Codenarc to 3.5.0-groovy-4.0 (build dependency) > > > Key: GROOVY-11462 > URL: https://issues.apache.org/jira/browse/GROOVY-11462 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 4.0.23, 5.0.0-alpha-10 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11465) Bump jqwik to 1.9.0 (test dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-11465. Fix Version/s: 4.0.23 5.0.0-alpha-10 Resolution: Fixed > Bump jqwik to 1.9.0 (test dependency) > - > > Key: GROOVY-11465 > URL: https://issues.apache.org/jira/browse/GROOVY-11465 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 4.0.23, 5.0.0-alpha-10 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11464) Bump commons-cli to 1.9.0
[ https://issues.apache.org/jira/browse/GROOVY-11464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-11464. Resolution: Fixed > Bump commons-cli to 1.9.0 > - > > Key: GROOVY-11464 > URL: https://issues.apache.org/jira/browse/GROOVY-11464 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-10 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11464) Bump commons-cli to 1.9.0
[ https://issues.apache.org/jira/browse/GROOVY-11464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11464: --- Fix Version/s: 5.0.0-alpha-10 > Bump commons-cli to 1.9.0 > - > > Key: GROOVY-11464 > URL: https://issues.apache.org/jira/browse/GROOVY-11464 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-10 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11466) Bump checkstyle to 10.18.1 (build dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-11466. Fix Version/s: 5.0.0-alpha-10 Resolution: Fixed > Bump checkstyle to 10.18.1 (build dependency) > - > > Key: GROOVY-11466 > URL: https://issues.apache.org/jira/browse/GROOVY-11466 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-10 > > > For Groovy 5+. > > See: > https://checkstyle.org/releasenotes.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11461) Bump logback-classic to 1.5.7 (test dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-11461. Fix Version/s: 5.0.0-alpha-10 Resolution: Fixed > Bump logback-classic to 1.5.7 (test dependency) > --- > > Key: GROOVY-11461 > URL: https://issues.apache.org/jira/browse/GROOVY-11461 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-10 > > > For Groovy 5+ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11466) Bump checkstyle to 10.18.1 (build dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11466: --- Description: For Groovy 5+. See: https://checkstyle.org/releasenotes.html was: For Groovy 5+. See: https://checkstyle.org/releasenotes.html#Release_10.14.2 > Bump checkstyle to 10.18.1 (build dependency) > - > > Key: GROOVY-11466 > URL: https://issues.apache.org/jira/browse/GROOVY-11466 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > > For Groovy 5+. > > See: > https://checkstyle.org/releasenotes.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11423) Bump checkstyle to 10.17.0 (build dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11423: --- Description: For Groovy 5+. See: https://checkstyle.org/releasenotes.html was: For Groovy 5+. See: https://checkstyle.org/releasenotes.html#Release_10.14.2 > Bump checkstyle to 10.17.0 (build dependency) > - > > Key: GROOVY-11423 > URL: https://issues.apache.org/jira/browse/GROOVY-11423 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-9 > > > For Groovy 5+. > > See: > https://checkstyle.org/releasenotes.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11466) Bump checkstyle to 10.18.1 (build dependency)
Paul King created GROOVY-11466: -- Summary: Bump checkstyle to 10.18.1 (build dependency) Key: GROOVY-11466 URL: https://issues.apache.org/jira/browse/GROOVY-11466 Project: Groovy Issue Type: Dependency upgrade Reporter: Paul King Assignee: Paul King Fix For: 5.0.0-alpha-9 For Groovy 5+. See: https://checkstyle.org/releasenotes.html#Release_10.14.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11466) Bump checkstyle to 10.18.1 (build dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11466: --- Fix Version/s: (was: 5.0.0-alpha-9) > Bump checkstyle to 10.18.1 (build dependency) > - > > Key: GROOVY-11466 > URL: https://issues.apache.org/jira/browse/GROOVY-11466 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > > For Groovy 5+. > > See: > https://checkstyle.org/releasenotes.html#Release_10.14.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11465) Bump jqwik to 1.9.0 (test dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11465: --- Fix Version/s: (was: 5.0.0-alpha-9) (was: 4.0.22) > Bump jqwik to 1.9.0 (test dependency) > - > > Key: GROOVY-11465 > URL: https://issues.apache.org/jira/browse/GROOVY-11465 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11465) Bump jqwik to 1.9.0 (test dependency)
Paul King created GROOVY-11465: -- Summary: Bump jqwik to 1.9.0 (test dependency) Key: GROOVY-11465 URL: https://issues.apache.org/jira/browse/GROOVY-11465 Project: Groovy Issue Type: Dependency upgrade Reporter: Paul King Assignee: Paul King Fix For: 5.0.0-alpha-9, 4.0.22 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11464) Bump commons-cli to 1.9.0
[ https://issues.apache.org/jira/browse/GROOVY-11464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11464: --- Fix Version/s: (was: 5.0.0-alpha-9) > Bump commons-cli to 1.9.0 > - > > Key: GROOVY-11464 > URL: https://issues.apache.org/jira/browse/GROOVY-11464 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GROOVY-11464) Bump commons-cli to 1.9.0
[ https://issues.apache.org/jira/browse/GROOVY-11464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King reassigned GROOVY-11464: -- Assignee: Paul King (was: Daniel Sun) > Bump commons-cli to 1.9.0 > - > > Key: GROOVY-11464 > URL: https://issues.apache.org/jira/browse/GROOVY-11464 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Paul King >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11464) Bump commons-cli to 1.9.0
Paul King created GROOVY-11464: -- Summary: Bump commons-cli to 1.9.0 Key: GROOVY-11464 URL: https://issues.apache.org/jira/browse/GROOVY-11464 Project: Groovy Issue Type: Dependency upgrade Reporter: Daniel Sun Assignee: Daniel Sun Fix For: 5.0.0-alpha-9 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11461) Bump logback-classic to 1.5.7 (test dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11461: --- Fix Version/s: (was: 5.0.0-alpha-9) > Bump logback-classic to 1.5.7 (test dependency) > --- > > Key: GROOVY-11461 > URL: https://issues.apache.org/jira/browse/GROOVY-11461 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > > For Groovy 5+ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11463) Bump ant version to 1.10.15
[ https://issues.apache.org/jira/browse/GROOVY-11463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11463: --- Fix Version/s: (was: 5.0.0-alpha-2) (was: 4.0.15) (was: 3.0.20) > Bump ant version to 1.10.15 > --- > > Key: GROOVY-11463 > URL: https://issues.apache.org/jira/browse/GROOVY-11463 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11462) Bump Codenarc to 3.5.0-groovy-4.0 (build dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11462: --- Fix Version/s: (was: 4.0.19) (was: 5.0.0-alpha-6) > Bump Codenarc to 3.5.0-groovy-4.0 (build dependency) > > > Key: GROOVY-11462 > URL: https://issues.apache.org/jira/browse/GROOVY-11462 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11463) Bump ant version to 1.10.15
Paul King created GROOVY-11463: -- Summary: Bump ant version to 1.10.15 Key: GROOVY-11463 URL: https://issues.apache.org/jira/browse/GROOVY-11463 Project: Groovy Issue Type: Dependency upgrade Reporter: Paul King Assignee: Paul King Fix For: 5.0.0-alpha-2, 4.0.15, 3.0.20 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11462) Bump Codenarc to 3.5.0-groovy-4.0 (build dependency)
Paul King created GROOVY-11462: -- Summary: Bump Codenarc to 3.5.0-groovy-4.0 (build dependency) Key: GROOVY-11462 URL: https://issues.apache.org/jira/browse/GROOVY-11462 Project: Groovy Issue Type: Dependency upgrade Reporter: Paul King Assignee: Paul King Fix For: 4.0.19, 5.0.0-alpha-6 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11461) Bump logback-classic to 1.5.7 (test dependency)
Paul King created GROOVY-11461: -- Summary: Bump logback-classic to 1.5.7 (test dependency) Key: GROOVY-11461 URL: https://issues.apache.org/jira/browse/GROOVY-11461 Project: Groovy Issue Type: Dependency upgrade Reporter: Paul King Assignee: Paul King Fix For: 5.0.0-alpha-9 For Groovy 5+ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11460) Bump slf4j to 2.0.16 (test and standard install dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11460: --- Summary: Bump slf4j to 2.0.16 (test and standard install dependency) (was: CLONE - Bump slf4j to 2.0.16 (test and standard install dependency)) > Bump slf4j to 2.0.16 (test and standard install dependency) > --- > > Key: GROOVY-11460 > URL: https://issues.apache.org/jira/browse/GROOVY-11460 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11460) CLONE - Bump slf4j to 2.0.16 (test and standard install dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11460: --- Fix Version/s: (was: 5.0.0-alpha-9) (was: 4.0.22) > CLONE - Bump slf4j to 2.0.16 (test and standard install dependency) > --- > > Key: GROOVY-11460 > URL: https://issues.apache.org/jira/browse/GROOVY-11460 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11460) CLONE - Bump slf4j to 2.0.16 (test and standard install dependency)
Paul King created GROOVY-11460: -- Summary: CLONE - Bump slf4j to 2.0.16 (test and standard install dependency) Key: GROOVY-11460 URL: https://issues.apache.org/jira/browse/GROOVY-11460 Project: Groovy Issue Type: Dependency upgrade Reporter: Paul King Assignee: Paul King Fix For: 5.0.0-alpha-9, 4.0.22 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GROOVY-11459) weak hashing algorithm (使用弱哈希算法)
[ https://issues.apache.org/jira/browse/GROOVY-11459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King reassigned GROOVY-11459: -- Assignee: Paul King > weak hashing algorithm (使用弱哈希算法) > > > Key: GROOVY-11459 > URL: https://issues.apache.org/jira/browse/GROOVY-11459 > Project: Groovy > Issue Type: Bug >Affects Versions: 4.0.22 >Reporter: wellchang >Assignee: Paul King >Priority: Major > > 通过iast扫描发现groovy中使用了md5来生成缓存键名，路径为groovy.lang.GroovyClassLoader.getSourceCacheKey > 建议使用常见的安全的哈希算法，如SHA-256,SHA-384,SHA-512等 > Google Translate gives: > Through iast scanning, it was found that md5 is used in groovy to generate > the cache key name, and the path is > groovy.lang.GroovyClassLoader.getSourceCacheKey > It is recommended to use common secure hash algorithms, such as SHA-256, > SHA-384, SHA-512, etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11459) weak hashing algorithm (使用弱哈希算法)
[ https://issues.apache.org/jira/browse/GROOVY-11459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11459: --- Summary: weak hashing algorithm (使用弱哈希算法) (was: 使用弱哈希算法) > weak hashing algorithm (使用弱哈希算法) > > > Key: GROOVY-11459 > URL: https://issues.apache.org/jira/browse/GROOVY-11459 > Project: Groovy > Issue Type: Bug >Affects Versions: 4.0.22 >Reporter: wellchang >Priority: Major > > 通过iast扫描发现groovy中使用了md5来生成缓存键名，路径为groovy.lang.GroovyClassLoader.getSourceCacheKey > 建议使用常见的安全的哈希算法，如SHA-256,SHA-384,SHA-512等 > Google Translate gives: > Through iast scanning, it was found that md5 is used in groovy to generate > the cache key name, and the path is > groovy.lang.GroovyClassLoader.getSourceCacheKey > It is recommended to use common secure hash algorithms, such as SHA-256, > SHA-384, SHA-512, etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11459) weak hashing algorithm (使用弱哈希算法)
[ https://issues.apache.org/jira/browse/GROOVY-11459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878707#comment-17878707 ] Paul King commented on GROOVY-11459: Hi, I translated to English using Google Translate. Can you confirm that it still captures your intent? Thanks. > weak hashing algorithm (使用弱哈希算法) > > > Key: GROOVY-11459 > URL: https://issues.apache.org/jira/browse/GROOVY-11459 > Project: Groovy > Issue Type: Bug >Affects Versions: 4.0.22 >Reporter: wellchang >Priority: Major > > 通过iast扫描发现groovy中使用了md5来生成缓存键名，路径为groovy.lang.GroovyClassLoader.getSourceCacheKey > 建议使用常见的安全的哈希算法，如SHA-256,SHA-384,SHA-512等 > Google Translate gives: > Through iast scanning, it was found that md5 is used in groovy to generate > the cache key name, and the path is > groovy.lang.GroovyClassLoader.getSourceCacheKey > It is recommended to use common secure hash algorithms, such as SHA-256, > SHA-384, SHA-512, etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11459) 使用弱哈希算法
[ https://issues.apache.org/jira/browse/GROOVY-11459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11459: --- Description: 通过iast扫描发现groovy中使用了md5来生成缓存键名，路径为groovy.lang.GroovyClassLoader.getSourceCacheKey 建议使用常见的安全的哈希算法，如SHA-256,SHA-384,SHA-512等 Google Translate gives: Through iast scanning, it was found that md5 is used in groovy to generate the cache key name, and the path is groovy.lang.GroovyClassLoader.getSourceCacheKey It is recommended to use common secure hash algorithms, such as SHA-256, SHA-384, SHA-512, etc. was: 通过iast扫描发现groovy中使用了md5来生成缓存键名，路径为groovy.lang.GroovyClassLoader.getSourceCacheKey 建议使用常见的安全的哈希算法，如SHA-256,SHA-384,SHA-512等 > 使用弱哈希算法 > --- > > Key: GROOVY-11459 > URL: https://issues.apache.org/jira/browse/GROOVY-11459 > Project: Groovy > Issue Type: Bug >Affects Versions: 4.0.22 >Reporter: wellchang >Priority: Major > > 通过iast扫描发现groovy中使用了md5来生成缓存键名，路径为groovy.lang.GroovyClassLoader.getSourceCacheKey > 建议使用常见的安全的哈希算法，如SHA-256,SHA-384,SHA-512等 > Google Translate gives: > Through iast scanning, it was found that md5 is used in groovy to generate > the cache key name, and the path is > groovy.lang.GroovyClassLoader.getSourceCacheKey > It is recommended to use common secure hash algorithms, such as SHA-256, > SHA-384, SHA-512, etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11045) Bump testng to 7.5.1
[ https://issues.apache.org/jira/browse/GROOVY-11045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875465#comment-17875465 ] Paul King commented on GROOVY-11045: Are you using a Groovy installation or using Groovy via build dependencies? I haven't tried recently but there is a good chance that you can just use a later testng version in your build file. There may be some breaking changes in later testng versions, but I would guess that most of the classes we use haven't changed. But please do let us know if try this and it doesn't work. If you are using a Groovy installation, you'd need to delete the relevant testng jars from the lib directory and replace with newer ones. > Bump testng to 7.5.1 > > > Key: GROOVY-11045 > URL: https://issues.apache.org/jira/browse/GROOVY-11045 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 4.0.12 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11449) Improve documentation on Named Method Parameters
[
https://issues.apache.org/jira/browse/GROOVY-11449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17872339#comment-17872339
]
Paul King commented on GROOVY-11449:
Indeed, if there are no named arguments, Groovy would look for a `foo(Integer
number)` method to call. You can explicitly create such a method and call the
Map-based method with an empty Map. Using a default empty Map will generate
such a method for you.
Did you want to create a PR for this (much appreciated)? Or are you happy for
me to make a change?
> Improve documentation on Named Method Parameters
>
>
> Key: GROOVY-11449
> URL: https://issues.apache.org/jira/browse/GROOVY-11449
> Project: Groovy
> Issue Type: Improvement
> Components: Documentation
>Reporter: Holger Austinat
>Priority: Minor
>
> Section 3.2.2 of the _Groovy Object Orientation_ documentation describes
> named method parameters
> ([http://groovy-lang.org/objectorientation.html#_named_parameters_2]).
> All name parameters are collected in a map, and passed in as first parameter
> to the called method. One corner case is not mentioned, though: when you call
> the method without any named parameter, the map is not created and not passed
> in. Thus, one should make the map optional:
> {code:groovy}
> def foo(Map args=[:], Integer number)
> {code}
> If not optional, one gets a {{{}groovy.lang.MissingMethodException: No
> signature of method{}}}.
> This is a tricky, unintuitive case which should be explicitly mentioned in
> the documentation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GROOVY-11449) Improve documentation on Named Method Parameters
[
https://issues.apache.org/jira/browse/GROOVY-11449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King reassigned GROOVY-11449:
--
Assignee: Paul King
> Improve documentation on Named Method Parameters
>
>
> Key: GROOVY-11449
> URL: https://issues.apache.org/jira/browse/GROOVY-11449
> Project: Groovy
> Issue Type: Improvement
> Components: Documentation
>Reporter: Holger Austinat
>Assignee: Paul King
>Priority: Minor
>
> Section 3.2.2 of the _Groovy Object Orientation_ documentation describes
> named method parameters
> ([http://groovy-lang.org/objectorientation.html#_named_parameters_2]).
> All name parameters are collected in a map, and passed in as first parameter
> to the called method. One corner case is not mentioned, though: when you call
> the method without any named parameter, the map is not created and not passed
> in. Thus, one should make the map optional:
> {code:groovy}
> def foo(Map args=[:], Integer number)
> {code}
> If not optional, one gets a {{{}groovy.lang.MissingMethodException: No
> signature of method{}}}.
> This is a tricky, unintuitive case which should be explicitly mentioned in
> the documentation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-11432) Support method references/method pointers in annotations
[
https://issues.apache.org/jira/browse/GROOVY-11432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-11432.
Fix Version/s: 5.0.0-alpha-10
Resolution: Fixed
> Support method references/method pointers in annotations
>
>
> Key: GROOVY-11432
> URL: https://issues.apache.org/jira/browse/GROOVY-11432
> Project: Groovy
> Issue Type: Improvement
>Reporter: Paul King
>Assignee: Paul King
>Priority: Major
> Fix For: 5.0.0-alpha-10
>
>
> The topic (for Java) appeared on social media recently:
> https://twitter.com/GeoffreyDeSmet/status/1808216150867861896
> Java thought it might be a good idea a while back but thought it would be
> hard to implement:
> https://mail.openjdk.org/pipermail/core-libs-dev/2018-November/056596.html
> For us we could use a Class typed annotation attribute and do like we
> currently do for closures, e.g.:
> {code}
> @interface UIColorAnnotation {
> Class method()
> }
> @UIColorAnnotation(method = Person::getAgeColor)
> public int getAge() {
> }
> ...
> {code}
> Since we already support closures, my thinking is to make the above exactly
> equivalent to:
> {code}
> @UIColorAnnotation(method = { with(Person::getAgeColor) })
> public int getAge() {
> }
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-11443) Support multiple Requires/Ensures/Invariant annotations in groovy-contracts
[
https://issues.apache.org/jira/browse/GROOVY-11443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-11443.
Fix Version/s: 5.0.0-alpha-10
Resolution: Fixed
> Support multiple Requires/Ensures/Invariant annotations in groovy-contracts
> ---
>
> Key: GROOVY-11443
> URL: https://issues.apache.org/jira/browse/GROOVY-11443
> Project: Groovy
> Issue Type: Improvement
>Reporter: Paul King
>Assignee: Paul King
>Priority: Major
> Fix For: 5.0.0-alpha-10
>
>
> Languages like Dafny support having multiple pre/post condition clauses. They
> are just and'd together.
> A contrived example (with boring constants as the conditions - but you'll get
> the idea):
> {code}
> import groovy.contracts.*
> @Invariant({ 1 })
> @Invariant({ 2 })
> interface F {
> @Ensures({ 1 })
> @Ensures({ 2 })
> @Requires({ 1 })
> @Requires({ 2 })
> def foo()
> }
> @Invariant({ 3 })
> @Invariant({ 4 })
> abstract class P {
> @Requires({ 3 })
> @Requires({ 4 })
> @Ensures({ 3 })
> @Ensures({ 4 })
> abstract def foo()
> }
> @Invariant({ 5 })
> @Invariant({ 6 })
> class C extends P implements F {
>def d() { println new Date() }
> @Requires({ 5 })
> @Requires({ 6 })
> @Ensures({ 5 })
> @Ensures({ 6 })
> def foo() { println true }
> }
> new C().d()
> {code}
> The invariant for class C is "1 && 2 && 3 && 4 && 5 && 6" as is the
> postcondition.
> The precondition is "(1 && 2) || (3 && 4) || (5 && 6)". Preconditions are
> typically or'd like this to handle the weaker pre rule - no change in
> behavior was made, just and'ing together the terms in the one class/interface.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GROOVY-11432) Explore whether we should add method references to annotations
[
https://issues.apache.org/jira/browse/GROOVY-11432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King reassigned GROOVY-11432:
--
Assignee: Paul King
> Explore whether we should add method references to annotations
> --
>
> Key: GROOVY-11432
> URL: https://issues.apache.org/jira/browse/GROOVY-11432
> Project: Groovy
> Issue Type: Improvement
>Reporter: Paul King
>Assignee: Paul King
>Priority: Major
>
> The topic (for Java) appeared on social media recently:
> https://twitter.com/GeoffreyDeSmet/status/1808216150867861896
> Java thought it might be a good idea a while back but thought it would be
> hard to implement:
> https://mail.openjdk.org/pipermail/core-libs-dev/2018-November/056596.html
> For us we could use a Class typed annotation attribute and do like we
> currently do for closures, e.g.:
> {code}
> @interface UIColorAnnotation {
> Class method()
> }
> @UIColorAnnotation(method = Person::getAgeColor)
> public int getAge() {
> }
> ...
> {code}
> Since we already support closures, my thinking is to make the above exactly
> equivalent to:
> {code}
> @UIColorAnnotation(method = { with(Person::getAgeColor) })
> public int getAge() {
> }
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11432) Support method references/method pointers in annotations
[
https://issues.apache.org/jira/browse/GROOVY-11432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-11432:
---
Summary: Support method references/method pointers in annotations (was:
Explore whether we should add method references to annotations)
> Support method references/method pointers in annotations
>
>
> Key: GROOVY-11432
> URL: https://issues.apache.org/jira/browse/GROOVY-11432
> Project: Groovy
> Issue Type: Improvement
>Reporter: Paul King
>Assignee: Paul King
>Priority: Major
>
> The topic (for Java) appeared on social media recently:
> https://twitter.com/GeoffreyDeSmet/status/1808216150867861896
> Java thought it might be a good idea a while back but thought it would be
> hard to implement:
> https://mail.openjdk.org/pipermail/core-libs-dev/2018-November/056596.html
> For us we could use a Class typed annotation attribute and do like we
> currently do for closures, e.g.:
> {code}
> @interface UIColorAnnotation {
> Class method()
> }
> @UIColorAnnotation(method = Person::getAgeColor)
> public int getAge() {
> }
> ...
> {code}
> Since we already support closures, my thinking is to make the above exactly
> equivalent to:
> {code}
> @UIColorAnnotation(method = { with(Person::getAgeColor) })
> public int getAge() {
> }
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11443) Support multiple Requires/Ensures/Invariant annotations in groovy-contracts
[
https://issues.apache.org/jira/browse/GROOVY-11443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-11443:
---
Description:
Languages like Dafny support having multiple pre/post condition clauses. They
are just and'd together.
A contrived example (with boring constants as the conditions - but you'll get
the idea):
{code}
import groovy.contracts.*
@Invariant({ 1 })
@Invariant({ 2 })
interface F {
@Ensures({ 1 })
@Ensures({ 2 })
@Requires({ 1 })
@Requires({ 2 })
def foo()
}
@Invariant({ 3 })
@Invariant({ 4 })
abstract class P {
@Requires({ 3 })
@Requires({ 4 })
@Ensures({ 3 })
@Ensures({ 4 })
abstract def foo()
}
@Invariant({ 5 })
@Invariant({ 6 })
class C extends P implements F {
def d() { println new Date() }
@Requires({ 5 })
@Requires({ 6 })
@Ensures({ 5 })
@Ensures({ 6 })
def foo() { println true }
}
new C().d()
{code}
The invariant for class C is "1 && 2 && 3 && 4 && 5 && 6" as is the
postcondition.
The precondition is "(1 && 2) || (3 && 4) || (5 && 6)". Preconditions are
typically or'd like this to handle the weaker pre rule - no change in behavior
was made, just and'ing together the terms in the one class/interface.
was:
Languages like Dafny support having multiple pre/post condition clauses. They
are just and'ed together.
A contrived example (with boring constants as the conditions - but you'll get
the idea):
{code}
import groovy.contracts.*
@Invariant({ 1 })
@Invariant({ 2 })
interface F {
@Ensures({ 1 })
@Ensures({ 2 })
@Requires({ 1 })
@Requires({ 2 })
def foo()
}
@Invariant({ 3 })
@Invariant({ 4 })
abstract class P {
@Requires({ 3 })
@Requires({ 4 })
@Ensures({ 3 })
@Ensures({ 4 })
abstract def foo()
}
@Invariant({ 5 })
@Invariant({ 6 })
class C extends P implements F {
def d() { println new Date() }
@Requires({ 5 })
@Requires({ 6 })
@Ensures({ 5 })
@Ensures({ 6 })
def foo() { println true }
}
new C().d()
{code}
> Support multiple Requires/Ensures/Invariant annotations in groovy-contracts
> ---
>
> Key: GROOVY-11443
> URL: https://issues.apache.org/jira/browse/GROOVY-11443
> Project: Groovy
> Issue Type: Improvement
>Reporter: Paul King
>Assignee: Paul King
>Priority: Major
>
> Languages like Dafny support having multiple pre/post condition clauses. They
> are just and'd together.
> A contrived example (with boring constants as the conditions - but you'll get
> the idea):
> {code}
> import groovy.contracts.*
> @Invariant({ 1 })
> @Invariant({ 2 })
> interface F {
> @Ensures({ 1 })
> @Ensures({ 2 })
> @Requires({ 1 })
> @Requires({ 2 })
> def foo()
> }
> @Invariant({ 3 })
> @Invariant({ 4 })
> abstract class P {
> @Requires({ 3 })
> @Requires({ 4 })
> @Ensures({ 3 })
> @Ensures({ 4 })
> abstract def foo()
> }
> @Invariant({ 5 })
> @Invariant({ 6 })
> class C extends P implements F {
>def d() { println new Date() }
> @Requires({ 5 })
> @Requires({ 6 })
> @Ensures({ 5 })
> @Ensures({ 6 })
> def foo() { println true }
> }
> new C().d()
> {code}
> The invariant for class C is "1 && 2 && 3 && 4 && 5 && 6" as is the
> postcondition.
> The precondition is "(1 && 2) || (3 && 4) || (5 && 6)". Preconditions are
> typically or'd like this to handle the weaker pre rule - no change in
> behavior was made, just and'ing together the terms in the one class/interface.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11443) Support multiple Requires/Ensures/Invariant annotations in groovy-contracts
[
https://issues.apache.org/jira/browse/GROOVY-11443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-11443:
---
Description:
Languages like Dafny support having multiple pre/post condition clauses. They
are just and'ed together.
A contrived example (with boring constants as the conditions - but you'll get
the idea):
{code}
import groovy.contracts.*
@Invariant({ 1 })
@Invariant({ 2 })
interface F {
@Ensures({ 1 })
@Ensures({ 2 })
@Requires({ 1 })
@Requires({ 2 })
def foo()
}
@Invariant({ 3 })
@Invariant({ 4 })
abstract class P {
@Requires({ 3 })
@Requires({ 4 })
@Ensures({ 3 })
@Ensures({ 4 })
abstract def foo()
}
@Invariant({ 5 })
@Invariant({ 6 })
class C extends P implements F {
def d() { println new Date() }
@Requires({ 5 })
@Requires({ 6 })
@Ensures({ 5 })
@Ensures({ 6 })
def foo() { println true }
}
new C().d()
{code}
was:Languages like Dafny support having multiple pre/post condition clauses.
They are just and'ed together.
> Support multiple Requires/Ensures/Invariant annotations in groovy-contracts
> ---
>
> Key: GROOVY-11443
> URL: https://issues.apache.org/jira/browse/GROOVY-11443
> Project: Groovy
> Issue Type: Improvement
>Reporter: Paul King
>Assignee: Paul King
>Priority: Major
>
> Languages like Dafny support having multiple pre/post condition clauses. They
> are just and'ed together.
> A contrived example (with boring constants as the conditions - but you'll get
> the idea):
> {code}
> import groovy.contracts.*
> @Invariant({ 1 })
> @Invariant({ 2 })
> interface F {
> @Ensures({ 1 })
> @Ensures({ 2 })
> @Requires({ 1 })
> @Requires({ 2 })
> def foo()
> }
> @Invariant({ 3 })
> @Invariant({ 4 })
> abstract class P {
> @Requires({ 3 })
> @Requires({ 4 })
> @Ensures({ 3 })
> @Ensures({ 4 })
> abstract def foo()
> }
> @Invariant({ 5 })
> @Invariant({ 6 })
> class C extends P implements F {
>def d() { println new Date() }
> @Requires({ 5 })
> @Requires({ 6 })
> @Ensures({ 5 })
> @Ensures({ 6 })
> def foo() { println true }
> }
> new C().d()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GROOVY-11443) Support multiple Requires/Ensures/Invariant annotations in groovy-contracts
[ https://issues.apache.org/jira/browse/GROOVY-11443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King reassigned GROOVY-11443: -- Assignee: Paul King > Support multiple Requires/Ensures/Invariant annotations in groovy-contracts > --- > > Key: GROOVY-11443 > URL: https://issues.apache.org/jira/browse/GROOVY-11443 > Project: Groovy > Issue Type: Improvement >Reporter: Paul King >Assignee: Paul King >Priority: Major > > Languages like Dafny support having multiple pre/post condition clauses. They > are just and'ed together. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11443) Support multiple Requires/Ensures/Invariant annotations in groovy-contracts
Paul King created GROOVY-11443: -- Summary: Support multiple Requires/Ensures/Invariant annotations in groovy-contracts Key: GROOVY-11443 URL: https://issues.apache.org/jira/browse/GROOVY-11443 Project: Groovy Issue Type: Improvement Reporter: Paul King Languages like Dafny support having multiple pre/post condition clauses. They are just and'ed together. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-10993) Produce and publish CycloneDX SBOM artifacts
[ https://issues.apache.org/jira/browse/GROOVY-10993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-10993: --- Summary: Produce and publish CycloneDX SBOM artifacts (was: Add CycloneDX SBOM files) > Produce and publish CycloneDX SBOM artifacts > > > Key: GROOVY-10993 > URL: https://issues.apache.org/jira/browse/GROOVY-10993 > Project: Groovy > Issue Type: Improvement >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-9 > > > We should consider adding SBOM file(s) into our releases. SBOM files capture > dependency metadata somewhat like pom or bom files but focus on security. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-10993) Add CycloneDX SBOM files
[ https://issues.apache.org/jira/browse/GROOVY-10993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-10993: --- Summary: Add CycloneDX SBOM files (was: Consider adding CycloneDX SBOM files) > Add CycloneDX SBOM files > > > Key: GROOVY-10993 > URL: https://issues.apache.org/jira/browse/GROOVY-10993 > Project: Groovy > Issue Type: Improvement >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-9 > > > We should consider adding SBOM file(s) into our releases. SBOM files capture > dependency metadata somewhat like pom or bom files but focus on security. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11432) Explore whether we should add method references to annotations
[
https://issues.apache.org/jira/browse/GROOVY-11432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-11432:
---
Description:
The topic (for Java) appeared on social media recently:
https://twitter.com/GeoffreyDeSmet/status/1808216150867861896
Java thought it might be a good idea a while back but thought it would be hard
to implement:
https://mail.openjdk.org/pipermail/core-libs-dev/2018-November/056596.html
For us we could use a Class typed annotation attribute and do like we currently
do for closures, e.g.:
{code}
@interface UIColorAnnotation {
Class method()
}
@UIColorAnnotation(method = Person::getAgeColor)
public int getAge() {
}
...
{code}
Since we already support closures, my thinking is to make the above exactly
equivalent to:
{code}
@UIColorAnnotation(method = { with(Person::getAgeColor) })
public int getAge() {
}
...
{code}
was:
The topic (for Java) appeared on social media recently:
https://twitter.com/GeoffreyDeSmet/status/1808216150867861896
Java thought it might be a good idea a while back but thought it would be hard
to implement:
https://mail.openjdk.org/pipermail/core-libs-dev/2018-November/056596.html
For us we could use a Class typed annotation attribute and do like we currently
do for closures, e.g.:
{code}
@interface UIColorAnnotation {
Class method()
}
@UIColorAnnotation(method = Person::getAgeColor)
public int getAge() {
}
...
{code}
> Explore whether we should add method references to annotations
> --
>
> Key: GROOVY-11432
> URL: https://issues.apache.org/jira/browse/GROOVY-11432
> Project: Groovy
> Issue Type: Improvement
>Reporter: Paul King
>Priority: Major
>
> The topic (for Java) appeared on social media recently:
> https://twitter.com/GeoffreyDeSmet/status/1808216150867861896
> Java thought it might be a good idea a while back but thought it would be
> hard to implement:
> https://mail.openjdk.org/pipermail/core-libs-dev/2018-November/056596.html
> For us we could use a Class typed annotation attribute and do like we
> currently do for closures, e.g.:
> {code}
> @interface UIColorAnnotation {
> Class method()
> }
> @UIColorAnnotation(method = Person::getAgeColor)
> public int getAge() {
> }
> ...
> {code}
> Since we already support closures, my thinking is to make the above exactly
> equivalent to:
> {code}
> @UIColorAnnotation(method = { with(Person::getAgeColor) })
> public int getAge() {
> }
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GROOVY-11432) Explore whether we should add method references to annotations
Paul King created GROOVY-11432:
--
Summary: Explore whether we should add method references to
annotations
Key: GROOVY-11432
URL: https://issues.apache.org/jira/browse/GROOVY-11432
Project: Groovy
Issue Type: Improvement
Reporter: Paul King
The topic (for Java) appeared on social media recently:
https://twitter.com/GeoffreyDeSmet/status/1808216150867861896
Java thought it might be a good idea a while back but thought it would be hard
to implement:
https://mail.openjdk.org/pipermail/core-libs-dev/2018-November/056596.html
For us we could use a Class typed annotation attribute and do like we currently
do for closures, e.g.:
{code}
@interface UIColorAnnotation {
Class method()
}
@UIColorAnnotation(method = Person::getAgeColor)
public int getAge() {
}
...
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11428) WARNING: An illegal reflective access operation has occurred
[ https://issues.apache.org/jira/browse/GROOVY-11428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17860653#comment-17860653 ] Paul King commented on GROOVY-11428: [~tombensve] Can you add the JDK version? > WARNING: An illegal reflective access operation has occurred > > > Key: GROOVY-11428 > URL: https://issues.apache.org/jira/browse/GROOVY-11428 > Project: Groovy > Issue Type: Bug > Environment: Mac OS X Version 17.5 (19618.2.12.11.6) >Reporter: Tommy Svensson >Priority: Critical > > Now I have debugged over and over and over to finally find this: >Map map = [:] > ... > LinkedHashMap resMap = new LinkedHashMap() > resMap.putAll( map ) <=== This is the one producing: > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by org.codehaus.groovy.vmplugin.v9.Java9 > (file:/Users/tommy/.m2/repository/org/apache/groovy/groovy/4.0.21/groovy-4.0.21.jar) > to field java.lang.reflect.Proxy.h > WARNING: Please consider reporting this to the maintainers of > org.codehaus.groovy.vmplugin.v9.Java9 > WARNING: Use --illegal-access=warn to enable warnings of further illegal > reflective access operations > WARNING: All illegal access operations will be denied in a future release > This seems like very legal code to me! > I can also add that when single-stepping through the code in debugger (IDEA) > the above does not occur! No warning displayed! > This makes me believe that the problem occur if run to fast! Since there is a > Groovy specific plugin involved here I'd say this is a Groovy problem! > I can also add that I'm working on an Apple M1 Pro (I think Apple call it). > 64 GB memory and 10 core processor. It is really fast! I believe that this is > relevant due to working fine when run slower in debug mode. > I do consider this a Groovy issue! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GROOVY-9761) Upgrade build from deprecated maven plugin to maven-publish
[
https://issues.apache.org/jira/browse/GROOVY-9761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-9761.
-
Resolution: Fixed
I'll close this. We haven't done this in our older builds but it is in 4 and 5
versions.
> Upgrade build from deprecated maven plugin to maven-publish
> ---
>
> Key: GROOVY-9761
> URL: https://issues.apache.org/jira/browse/GROOVY-9761
> Project: Groovy
> Issue Type: Task
>Reporter: Paul King
>Priority: Major
> Labels: contrib
>
> For bonus points, leverage Gradle Module Metadata to represent
> {{org.codehaus.groovy}} to {{org.apache.groovy}} change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11426) Bump javaparser to 3.26.1
[ https://issues.apache.org/jira/browse/GROOVY-11426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11426: --- Fix Version/s: 4.0.22 > Bump javaparser to 3.26.1 > - > > Key: GROOVY-11426 > URL: https://issues.apache.org/jira/browse/GROOVY-11426 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 5.0.0-alpha-9, 4.0.22 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11424) Bump spotbugs to 4.8.6
[ https://issues.apache.org/jira/browse/GROOVY-11424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-11424. Fix Version/s: 5.0.0-alpha-9 4.0.22 Assignee: Paul King (was: Daniel Sun) Resolution: Fixed > Bump spotbugs to 4.8.6 > -- > > Key: GROOVY-11424 > URL: https://issues.apache.org/jira/browse/GROOVY-11424 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-9, 4.0.22 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11421) Bump logback-classic to 1.5.6 (test dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-11421. Fix Version/s: 5.0.0-alpha-9 Resolution: Fixed > Bump logback-classic to 1.5.6 (test dependency) > --- > > Key: GROOVY-11421 > URL: https://issues.apache.org/jira/browse/GROOVY-11421 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-9 > > > For Groovy 5+ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11423) Bump checkstyle to 10.17.0 (build dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-11423. Fix Version/s: 5.0.0-alpha-9 Resolution: Fixed > Bump checkstyle to 10.17.0 (build dependency) > - > > Key: GROOVY-11423 > URL: https://issues.apache.org/jira/browse/GROOVY-11423 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-9 > > > For Groovy 5+. > > See: > https://checkstyle.org/releasenotes.html#Release_10.14.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11422) Bump testng to 7.10.2
[ https://issues.apache.org/jira/browse/GROOVY-11422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-11422. Fix Version/s: 5.0.0-alpha-9 Resolution: Fixed > Bump testng to 7.10.2 > - > > Key: GROOVY-11422 > URL: https://issues.apache.org/jira/browse/GROOVY-11422 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-9 > > > This includes fixes for Groovy: > [https://github.com/cbeust/testng/releases/tag/7.7.1] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11420) Bump jqwik to 1.8.5 (test dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-11420. Fix Version/s: 5.0.0-alpha-9 4.0.22 Resolution: Fixed > Bump jqwik to 1.8.5 (test dependency) > - > > Key: GROOVY-11420 > URL: https://issues.apache.org/jira/browse/GROOVY-11420 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-9, 4.0.22 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11419) Bump slf4j to 2.0.13 (test and standard install dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-11419. Fix Version/s: 5.0.0-alpha-9 4.0.22 Resolution: Fixed > Bump slf4j to 2.0.13 (test and standard install dependency) > --- > > Key: GROOVY-11419 > URL: https://issues.apache.org/jira/browse/GROOVY-11419 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-9, 4.0.22 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11418) Bump hsqldb to 2.7.3 (test dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-11418. Fix Version/s: 5.0.0-alpha-9 4.0.22 Resolution: Fixed > Bump hsqldb to 2.7.3 (test dependency) > -- > > Key: GROOVY-11418 > URL: https://issues.apache.org/jira/browse/GROOVY-11418 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-9, 4.0.22 > > > Groovy 4 uses the "jdk8" classifier for this dependency so that the test > suite can still run on JDK8. > The jdk8 classifier isn't needed for Groovy 4 if you are running on a higher > JDK. > Groovy 5 doesn't use an classifier (which currently uses JDK11 class version). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11425) Bump gson to 2.11.0 (test dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-11425. Fix Version/s: 5.0.0-alpha-9 4.0.22 Resolution: Fixed > Bump gson to 2.11.0 (test dependency) > - > > Key: GROOVY-11425 > URL: https://issues.apache.org/jira/browse/GROOVY-11425 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-9, 4.0.22 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11425) Bump gson to 2.11.0 (test dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11425: --- Fix Version/s: (was: 4.0.10) > Bump gson to 2.11.0 (test dependency) > - > > Key: GROOVY-11425 > URL: https://issues.apache.org/jira/browse/GROOVY-11425 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11425) Bump gson to 2.11.0 (test dependency)
Paul King created GROOVY-11425: -- Summary: Bump gson to 2.11.0 (test dependency) Key: GROOVY-11425 URL: https://issues.apache.org/jira/browse/GROOVY-11425 Project: Groovy Issue Type: Dependency upgrade Reporter: Paul King Assignee: Paul King Fix For: 4.0.10 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11424) Bump spotbugs to 4.8.6
Paul King created GROOVY-11424: -- Summary: Bump spotbugs to 4.8.6 Key: GROOVY-11424 URL: https://issues.apache.org/jira/browse/GROOVY-11424 Project: Groovy Issue Type: Dependency upgrade Reporter: Daniel Sun Assignee: Daniel Sun Fix For: 5.0.0-alpha-9 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11424) Bump spotbugs to 4.8.6
[ https://issues.apache.org/jira/browse/GROOVY-11424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11424: --- Fix Version/s: (was: 5.0.0-alpha-9) > Bump spotbugs to 4.8.6 > -- > > Key: GROOVY-11424 > URL: https://issues.apache.org/jira/browse/GROOVY-11424 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11423) Bump checkstyle to 10.17.0 (build dependency)
Paul King created GROOVY-11423: -- Summary: Bump checkstyle to 10.17.0 (build dependency) Key: GROOVY-11423 URL: https://issues.apache.org/jira/browse/GROOVY-11423 Project: Groovy Issue Type: Dependency upgrade Reporter: Paul King Assignee: Paul King Fix For: 5.0.0-alpha-8 For Groovy 5+. See: https://checkstyle.org/releasenotes.html#Release_10.14.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11423) Bump checkstyle to 10.17.0 (build dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11423: --- Fix Version/s: (was: 5.0.0-alpha-8) > Bump checkstyle to 10.17.0 (build dependency) > - > > Key: GROOVY-11423 > URL: https://issues.apache.org/jira/browse/GROOVY-11423 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > > For Groovy 5+. > > See: > https://checkstyle.org/releasenotes.html#Release_10.14.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11422) Bump testng to 7.10.2
Paul King created GROOVY-11422: -- Summary: Bump testng to 7.10.2 Key: GROOVY-11422 URL: https://issues.apache.org/jira/browse/GROOVY-11422 Project: Groovy Issue Type: Dependency upgrade Reporter: Paul King Assignee: Paul King Fix For: 5.0.0-alpha-5 This includes fixes for Groovy: [https://github.com/cbeust/testng/releases/tag/7.7.1] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11422) Bump testng to 7.10.2
[ https://issues.apache.org/jira/browse/GROOVY-11422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11422: --- Fix Version/s: (was: 5.0.0-alpha-5) > Bump testng to 7.10.2 > - > > Key: GROOVY-11422 > URL: https://issues.apache.org/jira/browse/GROOVY-11422 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > > This includes fixes for Groovy: > [https://github.com/cbeust/testng/releases/tag/7.7.1] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11421) Bump logback-classic to 1.5.6 (test dependency)
Paul King created GROOVY-11421: -- Summary: Bump logback-classic to 1.5.6 (test dependency) Key: GROOVY-11421 URL: https://issues.apache.org/jira/browse/GROOVY-11421 Project: Groovy Issue Type: Dependency upgrade Reporter: Paul King Assignee: Paul King Fix For: 5.0.0-alpha-7 For Groovy 5+ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11421) Bump logback-classic to 1.5.6 (test dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11421: --- Fix Version/s: (was: 5.0.0-alpha-7) > Bump logback-classic to 1.5.6 (test dependency) > --- > > Key: GROOVY-11421 > URL: https://issues.apache.org/jira/browse/GROOVY-11421 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > > For Groovy 5+ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11420) Bump jqwik to 1.8.5 (test dependency)
Paul King created GROOVY-11420: -- Summary: Bump jqwik to 1.8.5 (test dependency) Key: GROOVY-11420 URL: https://issues.apache.org/jira/browse/GROOVY-11420 Project: Groovy Issue Type: Dependency upgrade Reporter: Paul King Assignee: Paul King Fix For: 5.0.0-alpha-8, 4.0.21 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11420) Bump jqwik to 1.8.5 (test dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11420: --- Fix Version/s: (was: 5.0.0-alpha-8) (was: 4.0.21) > Bump jqwik to 1.8.5 (test dependency) > - > > Key: GROOVY-11420 > URL: https://issues.apache.org/jira/browse/GROOVY-11420 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11418) Bump hsqldb to 2.7.3 (test dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11418: --- Fix Version/s: (was: 4.0.7) > Bump hsqldb to 2.7.3 (test dependency) > -- > > Key: GROOVY-11418 > URL: https://issues.apache.org/jira/browse/GROOVY-11418 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > > Groovy 4 uses the "jdk8" classifier for this dependency so that the test > suite can still run on JDK8. > The jdk8 classifier isn't needed for Groovy 4 if you are running on a higher > JDK. > Groovy 5 doesn't use an classifier (which currently uses JDK11 class version). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11419) CLONE - Bump slf4j to 2.0.13 (test and standard install dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11419: --- Fix Version/s: (was: 4.0.19) (was: 5.0.0-alpha-6) > CLONE - Bump slf4j to 2.0.13 (test and standard install dependency) > --- > > Key: GROOVY-11419 > URL: https://issues.apache.org/jira/browse/GROOVY-11419 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11419) CLONE - Bump slf4j to 2.0.13 (test and standard install dependency)
Paul King created GROOVY-11419: -- Summary: CLONE - Bump slf4j to 2.0.13 (test and standard install dependency) Key: GROOVY-11419 URL: https://issues.apache.org/jira/browse/GROOVY-11419 Project: Groovy Issue Type: Dependency upgrade Reporter: Paul King Assignee: Paul King Fix For: 4.0.19, 5.0.0-alpha-6 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11419) Bump slf4j to 2.0.13 (test and standard install dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11419: --- Summary: Bump slf4j to 2.0.13 (test and standard install dependency) (was: CLONE - Bump slf4j to 2.0.13 (test and standard install dependency)) > Bump slf4j to 2.0.13 (test and standard install dependency) > --- > > Key: GROOVY-11419 > URL: https://issues.apache.org/jira/browse/GROOVY-11419 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11418) Bump hsqldb to 2.7.3 (test dependency)
Paul King created GROOVY-11418: -- Summary: Bump hsqldb to 2.7.3 (test dependency) Key: GROOVY-11418 URL: https://issues.apache.org/jira/browse/GROOVY-11418 Project: Groovy Issue Type: Dependency upgrade Reporter: Paul King Assignee: Paul King Fix For: 4.0.7 Groovy 4 uses the "jdk8" classifier for this dependency so that the test suite can still run on JDK8. The jdk8 classifier isn't needed for Groovy 4 if you are running on a higher JDK. Groovy 5 doesn't use an classifier (which currently uses JDK11 class version). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11411) Static Compilation fails for Grails domain class method getAll()
[
https://issues.apache.org/jira/browse/GROOVY-11411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856357#comment-17856357
]
Paul King commented on GROOVY-11411:
[~emilles] You are correct. I updated the earlier comment.
> Static Compilation fails for Grails domain class method getAll()
>
>
> Key: GROOVY-11411
> URL: https://issues.apache.org/jira/browse/GROOVY-11411
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 3.0.21
>Reporter: Tyler VanZanten
>Priority: Minor
>
> Hello,
>
> The following code results in a static compilation error after upgrading from
> Grails 6.1.2 (which uses Groovy 3.0.11) to Grails 6.2.0 (which uses Groovy
> 3.0.21):
>
>
> {code:java}
> import grails.compiler.GrailsCompileStatic
> import static org.springframework.http.HttpStatus.NO_CONTENT
> @GrailsCompileStatic
> class SessionItemGroupController {
> def deleteMultiple() {
> List longIds = ((String) params.ids)?.split(',')?.collect {
> String id -> id.toLong() }
> List sessionItemGroups =
> SessionItemGroup.getAll(longIds as Iterable) // This line
> causes the error
> response.status = NO_CONTENT.value()
> }
> }{code}
>
>
> SessionItemGroup is a Grails domain class and this is the error I'm getting
> when trying to run a Gradle task such as `bootRun` or `build`:
>
> ```
> > Task :compileGroovy FAILED
> startup failed:
> grails-app/controllers/myapp/sessionitem/SessionItemGroupController.groovy:
> 57: [Static type checking] - Cannot call
> myapp.sessionitem.SessionItemGroup#getAll(java.lang.Iterable
> ) with arguments [java.util.List ]
> @ line 41, column 56.
> temGroup> sessionItemGroups = SessionIte
> ```
>
> I have created a sample application repository which reproduces the issue:
> https://github.com/tylervz/grails620-groovy-bug-compile-static
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-11411) Static Compilation fails for Grails domain class method getAll()
[
https://issues.apache.org/jira/browse/GROOVY-11411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856345#comment-17856345
]
Paul King edited comment on GROOVY-11411 at 6/19/24 9:52 PM:
-
Here is what I get with a standalone reproducer for Groovy 3.0.21 and 4.0.21:
{code}
def getAll(Iterable items) { }
@groovy.transform.CompileStatic
def method() {
List longIds = '3,4'.split(',')*.toLong()
getAll(longIds as Iterable) // Okay
getAll(longIds) // Okay
}
method()
{code}
was (Author: paulk):
Here is what I get with a standalone reproducer for Groovy 3.0.21 and 4.0.21:
{code}
def getAll(Iterable items) { }
@groovy.transform.CompileStatic
def method() {
List longIds = '3,4'.split(',')*.toLong()
getAll(longIds as Iterable) // Okay
getAll(longIds) // Cannot call
ConsoleScript22#getAll(java.lang.Iterable) with arguments
[java.util.List]
}
method()
{code}
Are you saying that the first {{getAll}} isn't working?
> Static Compilation fails for Grails domain class method getAll()
>
>
> Key: GROOVY-11411
> URL: https://issues.apache.org/jira/browse/GROOVY-11411
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 3.0.21
>Reporter: Tyler VanZanten
>Priority: Minor
>
> Hello,
>
> The following code results in a static compilation error after upgrading from
> Grails 6.1.2 (which uses Groovy 3.0.11) to Grails 6.2.0 (which uses Groovy
> 3.0.21):
>
>
> {code:java}
> import grails.compiler.GrailsCompileStatic
> import static org.springframework.http.HttpStatus.NO_CONTENT
> @GrailsCompileStatic
> class SessionItemGroupController {
> def deleteMultiple() {
> List longIds = ((String) params.ids)?.split(',')?.collect {
> String id -> id.toLong() }
> List sessionItemGroups =
> SessionItemGroup.getAll(longIds as Iterable) // This line
> causes the error
> response.status = NO_CONTENT.value()
> }
> }{code}
>
>
> SessionItemGroup is a Grails domain class and this is the error I'm getting
> when trying to run a Gradle task such as `bootRun` or `build`:
>
> ```
> > Task :compileGroovy FAILED
> startup failed:
> grails-app/controllers/myapp/sessionitem/SessionItemGroupController.groovy:
> 57: [Static type checking] - Cannot call
> myapp.sessionitem.SessionItemGroup#getAll(java.lang.Iterable
> ) with arguments [java.util.List ]
> @ line 41, column 56.
> temGroup> sessionItemGroups = SessionIte
> ```
>
> I have created a sample application repository which reproduces the issue:
> https://github.com/tylervz/grails620-groovy-bug-compile-static
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-11411) Static Compilation fails for Grails domain class method getAll()
[
https://issues.apache.org/jira/browse/GROOVY-11411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856345#comment-17856345
]
Paul King edited comment on GROOVY-11411 at 6/19/24 8:37 PM:
-
Here is what I get with a standalone reproducer for Groovy 3.0.21 and 4.0.21:
{code}
def getAll(Iterable items) { }
@groovy.transform.CompileStatic
def method() {
List longIds = '3,4'.split(',')*.toLong()
getAll(longIds as Iterable) // Okay
getAll(longIds) // Cannot call
ConsoleScript22#getAll(java.lang.Iterable) with arguments
[java.util.List]
}
method()
{code}
Are you saying that the first {{getAll}} isn't working?
was (Author: paulk):
Here is what I get with a standalone reproducer for Groovy 3.0.21 and 4.0.21:
{code}
def getAll(Iterable items) { }
@groovy.transform.CompileStatic
def method() {
List longIds = '3,4'.split(',')?.collect { String id -> id.toLong() }
getAll(longIds as Iterable) // Okay
getAll(longIds) // Cannot call
ConsoleScript22#getAll(java.lang.Iterable) with arguments
[java.util.List]
}
method()
{code}
Are you saying that the first {{getAll}} isn't working?
> Static Compilation fails for Grails domain class method getAll()
>
>
> Key: GROOVY-11411
> URL: https://issues.apache.org/jira/browse/GROOVY-11411
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 3.0.21
>Reporter: Tyler VanZanten
>Priority: Minor
>
> Hello,
>
> The following code results in a static compilation error after upgrading from
> Grails 6.1.2 (which uses Groovy 3.0.11) to Grails 6.2.0 (which uses Groovy
> 3.0.21):
>
>
> {code:java}
> import grails.compiler.GrailsCompileStatic
> import static org.springframework.http.HttpStatus.NO_CONTENT
> @GrailsCompileStatic
> class SessionItemGroupController {
> def deleteMultiple() {
> List longIds = ((String) params.ids)?.split(',')?.collect {
> String id -> id.toLong() }
> List sessionItemGroups =
> SessionItemGroup.getAll(longIds as Iterable) // This line
> causes the error
> response.status = NO_CONTENT.value()
> }
> }{code}
>
>
> SessionItemGroup is a Grails domain class and this is the error I'm getting
> when trying to run a Gradle task such as `bootRun` or `build`:
>
> ```
> > Task :compileGroovy FAILED
> startup failed:
> grails-app/controllers/myapp/sessionitem/SessionItemGroupController.groovy:
> 57: [Static type checking] - Cannot call
> myapp.sessionitem.SessionItemGroup#getAll(java.lang.Iterable
> ) with arguments [java.util.List ]
> @ line 41, column 56.
> temGroup> sessionItemGroups = SessionIte
> ```
>
> I have created a sample application repository which reproduces the issue:
> https://github.com/tylervz/grails620-groovy-bug-compile-static
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11411) Static Compilation fails for Grails domain class method getAll()
[
https://issues.apache.org/jira/browse/GROOVY-11411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856345#comment-17856345
]
Paul King commented on GROOVY-11411:
Here is what I get with a standalone reproducer for Groovy 3.0.21 and 4.0.21:
{code}
def getAll(Iterable items) { }
@groovy.transform.CompileStatic
def method() {
List longIds = '3,4'.split(',')?.collect { String id -> id.toLong() }
getAll(longIds as Iterable) // Okay
getAll(longIds) // Cannot call
ConsoleScript22#getAll(java.lang.Iterable) with arguments
[java.util.List]
}
method()
{code}
Are you saying that the first {{getAll}} isn't working?
> Static Compilation fails for Grails domain class method getAll()
>
>
> Key: GROOVY-11411
> URL: https://issues.apache.org/jira/browse/GROOVY-11411
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 3.0.21
>Reporter: Tyler VanZanten
>Priority: Minor
>
> Hello,
>
> The following code results in a static compilation error after upgrading from
> Grails 6.1.2 (which uses Groovy 3.0.11) to Grails 6.2.0 (which uses Groovy
> 3.0.21):
>
>
> {code:java}
> import grails.compiler.GrailsCompileStatic
> import static org.springframework.http.HttpStatus.NO_CONTENT
> @GrailsCompileStatic
> class SessionItemGroupController {
> def deleteMultiple() {
> List longIds = ((String) params.ids)?.split(',')?.collect {
> String id -> id.toLong() }
> List sessionItemGroups =
> SessionItemGroup.getAll(longIds as Iterable) // This line
> causes the error
> response.status = NO_CONTENT.value()
> }
> }{code}
>
>
> SessionItemGroup is a Grails domain class and this is the error I'm getting
> when trying to run a Gradle task such as `bootRun` or `build`:
>
> ```
> > Task :compileGroovy FAILED
> startup failed:
> grails-app/controllers/myapp/sessionitem/SessionItemGroupController.groovy:
> 57: [Static type checking] - Cannot call
> myapp.sessionitem.SessionItemGroup#getAll(java.lang.Iterable
> ) with arguments [java.util.List ]
> @ line 41, column 56.
> temGroup> sessionItemGroups = SessionIte
> ```
>
> I have created a sample application repository which reproduces the issue:
> https://github.com/tylervz/grails620-groovy-bug-compile-static
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11144) MissingPropertyEx when accessing private static field in closure of same class
[
https://issues.apache.org/jira/browse/GROOVY-11144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17853523#comment-17853523
]
Paul King commented on GROOVY-11144:
You want to look at:
https://groovy.apache.org/snapshots.html
> MissingPropertyEx when accessing private static field in closure of same class
> --
>
> Key: GROOVY-11144
> URL: https://issues.apache.org/jira/browse/GROOVY-11144
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 4.0.13
> Environment: Windows 10, Groovy 4.0.13, Java 17.0.8
>Reporter: Andreas Turban
>Assignee: Eric Milles
>Priority: Major
> Fix For: 5.0.0-alpha-1, 4.0.22
>
> Attachments: Test.groovy
>
>
> When accessing a private static final field from a Closure within the same
> class Groovy 4 throws a MissingPropertyException. The code works in Groovy
> 2.5.22 & 3.0.18.
> The real instance of the object needs to be a subtype of the class containing
> the constant.
> See attached code to reproduce.
> *Expected behavior:*
> The code runs without error
> *Actual behavior:*
> Groovy 4 throws:
> {{groovy.lang.MissingPropertyException: No such property: field for class:
> FirstEvent}}
> {{ at BaseEvent$_init_closure1.doCall(Test.groovy:7)}}
> {{ at BaseEvent.init(Test.groovy:7)}}
> {{ at Test.run(Test.groovy:15)}}
> *Notes:*
> Interestingly if you remove the static keyword from {color:#0033b3}private
> static final {color}{color:#00}String {color}{color:#871094}field
> {color}= {color:#067d17}"name"{color}
> it fails in all three versions 2.5.22, 3.0.18 & 4.0.13 with a
> {{{}MissingPropertyException{}}}.
> I would expect that the code should also work for these cases.
>
> The problem came up in a discussion about a Spock issue
> [#1544|https://github.com/spockframework/spock/issues/1544].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11389) Groovy @Delegate issue with Java 21
[
https://issues.apache.org/jira/browse/GROOVY-11389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850966#comment-17850966
]
Paul King commented on GROOVY-11389:
The "default" part of your description is I think not helpful to understanding
the problem. The delegate generated code is calling via invokeInterface, a
method from the delegate implementation class. It could end up being an
explicit method in the implementation class or a "default" method
implementation if no concrete implementations exist in the supplied delegate.
If we didn't create methods for cases where a "default" is supplied, then if
the concrete delegate implementation did override such a method, we would no
longer pick up the override.
> Groovy @Delegate issue with Java 21
> ---
>
> Key: GROOVY-11389
> URL: https://issues.apache.org/jira/browse/GROOVY-11389
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 4.0.21
>Reporter: paolo di tommaso
>Priority: Major
>
> Context: Java 21 introduces a new interface SequencedCollection
> as super-interface for `List` and other interfaces.
> This causes an issue in Groovy when the following conditions are met:
> 1. Using a `@Delegate List someAttribute` in a class
> 2. Compile with Java 21
> 3. Run with Java 20 or earlier the resulting app.
> *Replicate the issue*
>
> 0. Clone this repository
> [https://github.com/pditommaso/groovy-java21-poc]
>
> 1. Compile and run
>
> {code:java}
> ./gradlew run {code}
> Output:
> {code:java}
> Runtime: Groovy 4.0.21 on OpenJDK 64-Bit Server VM 21.0.3+9-LTS
> Plain list sub-class: [1, 2, 3]
> Delegate list class : [1, 2, 3] {code}
> 2. Setup Java 11
> {code:java}
> sdk use java 11.0.14-zulu {code}
> 3. Run the app with Java 11
> {code:java}
> bash run.sh {code}
> Output:
> {code:java}
> Runtime: Groovy 4.0.21 on OpenJDK 64-Bit Server VM 11.0.14+9-LTS
> Plain list sub-class: [1, 2, 3]
> Exception in thread "main" java.lang.NoClassDefFoundError:
> java/util/SequencedCollection
> at org.example.App.run(App.groovy:18)
> at org.example.App.main(App.groovy:22)
> Caused by: java.lang.ClassNotFoundException: java.util.SequencedCollection
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
> ... 2 more {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11389) Groovy @Delegate issue with Java 21
[
https://issues.apache.org/jira/browse/GROOVY-11389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850618#comment-17850618
]
Paul King commented on GROOVY-11389:
Currently we are delegating to the "reversed" method from List:
{noformat}
public java.util.List reversed();
descriptor: ()Ljava/util/List;
flags: (0x0001) ACC_PUBLIC
{noformat}
As well as providing the "reversed" bridge method from SequencedCollection.
Only the latter is causing the NoClassDefFoundError but both would cause
NoSuchMethodError if compiled on JDK21 and run on earlier JDKs.
> Groovy @Delegate issue with Java 21
> ---
>
> Key: GROOVY-11389
> URL: https://issues.apache.org/jira/browse/GROOVY-11389
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 4.0.21
>Reporter: paolo di tommaso
>Priority: Major
>
> Context: Java 21 introduces a new interface SequencedCollection
> as super-interface for `List` and other interfaces.
> This causes an issue in Groovy when the following conditions are met:
> 1. Using a `@Delegate List someAttribute` in a class
> 2. Compile with Java 21
> 3. Run with Java 20 or earlier the resulting app.
> *Replicate the issue*
>
> 0. Clone this repository
> [https://github.com/pditommaso/groovy-java21-poc]
>
> 1. Compile and run
>
> {code:java}
> ./gradlew run {code}
> Output:
> {code:java}
> Runtime: Groovy 4.0.21 on OpenJDK 64-Bit Server VM 21.0.3+9-LTS
> Plain list sub-class: [1, 2, 3]
> Delegate list class : [1, 2, 3] {code}
> 2. Setup Java 11
> {code:java}
> sdk use java 11.0.14-zulu {code}
> 3. Run the app with Java 11
> {code:java}
> bash run.sh {code}
> Output:
> {code:java}
> Runtime: Groovy 4.0.21 on OpenJDK 64-Bit Server VM 11.0.14+9-LTS
> Plain list sub-class: [1, 2, 3]
> Exception in thread "main" java.lang.NoClassDefFoundError:
> java/util/SequencedCollection
> at org.example.App.run(App.groovy:18)
> at org.example.App.main(App.groovy:22)
> Caused by: java.lang.ClassNotFoundException: java.util.SequencedCollection
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
> ... 2 more {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-11389) Groovy @Delegate issue with Java 21
[
https://issues.apache.org/jira/browse/GROOVY-11389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850586#comment-17850586
]
Paul King edited comment on GROOVY-11389 at 5/30/24 6:07 AM:
-
You can get rid of the ClassNotFound exception by excluding the JDK21
"reversed" method.
If I was compiling on 21 and wanted it to work on earlier versions, I'd
probably exclude all of the about 7 methods added by JEP 431. Even excluding
"reversed", if you went and called "addFirst" for instance, you'd get a
NoSuchMethodError.
Having said that, I am not sure whether copying over a synthetic bridge method
is a bug or feature:
{noformat}
public java.util.SequencedCollection reversed();
descriptor: ()Ljava/util/SequencedCollection;
flags: (0x1041) ACC_PUBLIC, ACC_BRIDGE, ACC_SYNTHETIC
{noformat}
If the bridge method wasn't copied, you wouldn't get NoClassDefFoundError but
you'd still get NoSuchMethodError for the list's version of the "reversed"
method.
was (Author: paulk):
You can get rid of the ClassNotFound exception by excluding the JDK21
"reversed" method.
If I was compiling on 21 and wanted it to work on earlier versions, I probably
exclude all of the about 7 methods added by JEP 431. Even excluding "reversed",
if you went and called "addFirst" for instance, you'd get a NoSuchMethodError.
Having said that, I am not sure whether copying over a synthetic bridge method
is a bug or feature:
{noformat}
public java.util.SequencedCollection reversed();
descriptor: ()Ljava/util/SequencedCollection;
flags: (0x1041) ACC_PUBLIC, ACC_BRIDGE, ACC_SYNTHETIC
{noformat}
If the bridge method wasn't copied, you wouldn't get NoClassDefFoundError but
you'd still get NoSuchMethodError for the list's version of the "reversed"
method.
> Groovy @Delegate issue with Java 21
> ---
>
> Key: GROOVY-11389
> URL: https://issues.apache.org/jira/browse/GROOVY-11389
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 4.0.21
>Reporter: paolo di tommaso
>Priority: Major
>
> Context: Java 21 introduces a new interface SequencedCollection
> as super-interface for `List` and other interfaces.
> This causes an issue in Groovy when the following conditions are met:
> 1. Using a `@Delegate List someAttribute` in a class
> 2. Compile with Java 21
> 3. Run with Java 20 or earlier the resulting app.
> *Replicate the issue*
>
> 0. Clone this repository
> [https://github.com/pditommaso/groovy-java21-poc]
>
> 1. Compile and run
>
> {code:java}
> ./gradlew run {code}
> Output:
> {code:java}
> Runtime: Groovy 4.0.21 on OpenJDK 64-Bit Server VM 21.0.3+9-LTS
> Plain list sub-class: [1, 2, 3]
> Delegate list class : [1, 2, 3] {code}
> 2. Setup Java 11
> {code:java}
> sdk use java 11.0.14-zulu {code}
> 3. Run the app with Java 11
> {code:java}
> bash run.sh {code}
> Output:
> {code:java}
> Runtime: Groovy 4.0.21 on OpenJDK 64-Bit Server VM 11.0.14+9-LTS
> Plain list sub-class: [1, 2, 3]
> Exception in thread "main" java.lang.NoClassDefFoundError:
> java/util/SequencedCollection
> at org.example.App.run(App.groovy:18)
> at org.example.App.main(App.groovy:22)
> Caused by: java.lang.ClassNotFoundException: java.util.SequencedCollection
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
> ... 2 more {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11389) Groovy @Delegate issue with Java 21
[
https://issues.apache.org/jira/browse/GROOVY-11389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850586#comment-17850586
]
Paul King commented on GROOVY-11389:
You can get rid of the ClassNotFound exception by excluding the JDK21
"reversed" method.
If I was compiling on 21 and wanted it to work on earlier versions, I probably
exclude all of the about 7 methods added by JEP 431. Even excluding "reversed",
if you went and called "addFirst" for instance, you'd get a NoSuchMethodError.
Having said that, I am not sure whether copying over a synthetic bridge method
is a bug or feature:
{noformat}
public java.util.SequencedCollection reversed();
descriptor: ()Ljava/util/SequencedCollection;
flags: (0x1041) ACC_PUBLIC, ACC_BRIDGE, ACC_SYNTHETIC
{noformat}
If the bridge method wasn't copied, you wouldn't get NoClassDefFoundError but
you'd still get NoSuchMethodError for the list's version of the "reversed"
method.
> Groovy @Delegate issue with Java 21
> ---
>
> Key: GROOVY-11389
> URL: https://issues.apache.org/jira/browse/GROOVY-11389
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 4.0.21
>Reporter: paolo di tommaso
>Priority: Major
>
> Context: Java 21 introduces a new interface SequencedCollection
> as super-interface for `List` and other interfaces.
> This causes an issue in Groovy when the following conditions are met:
> 1. Using a `@Delegate List someAttribute` in a class
> 2. Compile with Java 21
> 3. Run with Java 20 or earlier the resulting app.
> *Replicate the issue*
>
> 0. Clone this repository
> [https://github.com/pditommaso/groovy-java21-poc]
>
> 1. Compile and run
>
> {code:java}
> ./gradlew run {code}
> Output:
> {code:java}
> Runtime: Groovy 4.0.21 on OpenJDK 64-Bit Server VM 21.0.3+9-LTS
> Plain list sub-class: [1, 2, 3]
> Delegate list class : [1, 2, 3] {code}
> 2. Setup Java 11
> {code:java}
> sdk use java 11.0.14-zulu {code}
> 3. Run the app with Java 11
> {code:java}
> bash run.sh {code}
> Output:
> {code:java}
> Runtime: Groovy 4.0.21 on OpenJDK 64-Bit Server VM 11.0.14+9-LTS
> Plain list sub-class: [1, 2, 3]
> Exception in thread "main" java.lang.NoClassDefFoundError:
> java/util/SequencedCollection
> at org.example.App.run(App.groovy:18)
> at org.example.App.main(App.groovy:22)
> Caused by: java.lang.ClassNotFoundException: java.util.SequencedCollection
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
> ... 2 more {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11388) Does Groovy support Java Anntotation Processors?
[
https://issues.apache.org/jira/browse/GROOVY-11388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850374#comment-17850374
]
Paul King commented on GROOVY-11388:
In mixed Java/Groovy codebases, Annotation processors can be used on the Java
files but not on the Groovy files. In general, Groovy's AST transforms are more
powerful that annotation processors. Most Lombok annotations have Groovy
transform equivalents. Certainly, if you think there is some commonly used
Lombok feature that you don't believe has an equivalent in Groovy, let us know.
It may be possible to have some annotation processor integration with Groovy
but it wouldn't be straight forward - except perhaps for some special edge
cases like perhaps Java stub files. We'd certainly be keen if anyone has time
to look into this further.
> Does Groovy support Java Anntotation Processors?
> -
>
> Key: GROOVY-11388
> URL: https://issues.apache.org/jira/browse/GROOVY-11388
> Project: Groovy
> Issue Type: Question
>Reporter: Christoph Henrici
>Priority: Major
>
> My question is simple : Does Groovy support Annotation Processors, like
> Mapstruct , Lombok or even custom Processors :
> [https://docs.oracle.com/javase/8/docs/api/javax/annotation/processing/Processor.html]
> ?
> Something like:
>
> {code:java}
> import lombok.Builder
> import lombok.NonNull
> import lombok.Value
> @Value
> @Builder
> class TestE {
> …
> {code}
>
> Please, no opionated answers, just facts and fact based explanations. There
> are many confuseing, strongly subjective and optinated posts in the web
> (Stacktrace and such, and even here), which trend towards no, you don‘t need
> it, i don't recommend, Lombok is a hack etc etc, but nothing really
> conclusive, substantial and objective.
> My Testcase does seems to indicate that at least the Lombok Annotation
> Processor is not supported , see :
> [https://github.com/chhex/groovylombok/tree/main]
> But it also may well be, that i am missing something in the Gradle Build.
> The enviroment i tested in:
> {code:java}
> $ ./gradlew -versionGradle 7.3.3Build time: 2021-12-22 12:37:54 UTC
> Revision: 6f556c80f945dc54b50e0be633da6c62dbe8dc71Kotlin: 1.5.31
> Groovy: 3.0.9
> Ant: Apache Ant(TM) version 1.10.11 compiled on July 10 2021
> JVM: 17.0.3 (Eclipse Adoptium 17.0.3+7)
> OS: Mac OS X 13.2.1 aarch64{code}
>
> Where the Groovy Version used by gradle is the same for the application.
> If this is a redundant post, sorry! I really like Groovy and am using it
> frequently, it would be just great to have good understanding of it‘s
> limitations, if that is the case.
> Best thanks for any help.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11379) Use of findAll produces NoSuchMethodError when compiling with Groovy 3.0.21 and running on an older version
[
https://issues.apache.org/jira/browse/GROOVY-11379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847117#comment-17847117
]
Paul King commented on GROOVY-11379:
As a general rule, we strive for backward compatibility not forward
compatibility, but the breakage wasn't really needed/intended for a minor
release. Another workaround would be to use dynamic mode.
At the moment, Groovy 4 and 5 contain the "backward compatibility" bridge
methods - so 3.0.20 statically compiled code would still work (give or take a
small performance penalty if not inlined by the JIT). We may decide to remove
the bridge methods in Groovy 5 before it goes GA in which case only 3.0.21 CS
code would run with 5.
> Use of findAll produces NoSuchMethodError when compiling with Groovy 3.0.21
> and running on an older version
> ---
>
> Key: GROOVY-11379
> URL: https://issues.apache.org/jira/browse/GROOVY-11379
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 3.0.12
>Reporter: Sterling Greene
>Priority: Major
>
> This was reported as a regression in Gradle, but I've reduced it down to
> something in Groovy.
> Given this class:
> {code}
> @groovy.transform.CompileStatic
> class Main {
> static void main(String[] args) {
> println "example".split("m").findAll { true }.collect()
> }
> }
> {code}
> If this is compiled with Groovy 3.0.21 and then run with Groovy before 3.0.21
> (tried 3.0.17 and 3.0.20), you'll get a NoSuchMethodError:
> {quote}
> java.lang.NoSuchMethodError: 'java.util.List
> org.codehaus.groovy.runtime.DefaultGroovyMethods.findAll(java.lang.Object[],
> groovy.lang.Closure)'
> at Main.main(Main.groovy:4)
> {quote}
> This might be related to the backport of GROOVY-7001:
> https://github.com/apache/groovy/commit/d9fbe95b47c16502952c1844febd11e789ab8bb4
> I'm not sure if findAll is the only method affected. Compiling with 3.0.20
> and running with 3.0.21 works.
> The bytecode produced with 3.0.21 definitely has a reference to the missing
> method:
> {noformat}
> public static void main(java.lang.String...);
> Code:
>0: ldc #2 // class Main
>2: ldc #30 // String example
>4: ldc #32 // String m
>6: invokevirtual #38 // Method
> java/lang/String.split:(Ljava/lang/String;)[Ljava/lang/String;
>9: new #40 // class Main$_main_closure1
> 12: dup
> 13: ldc #2 // class Main
> 15: ldc #2 // class Main
> 17: invokespecial #43 // Method
> Main$_main_closure1."":(Ljava/lang/Object;Ljava/lang/Object;)V
> 20: invokestatic #49 // Method
> org/codehaus/groovy/runtime/DefaultGroovyMethods.findAll:([Ljava/lang/Object;Lgroovy/lang/Closure;)Ljava/util/List;
> 23: invokestatic #53 // Method
> org/codehaus/groovy/runtime/DefaultGroovyMethods.collect:(Ljava/lang/Iterable;)Ljava/util/List;
> 26: invokestatic #56 // Method
> org/codehaus/groovy/runtime/DefaultGroovyMethods.println:(Ljava/lang/Object;Ljava/lang/Object;)V
> 29: aconst_null
> 30: pop
> 31: return
> {noformat}
> The same code built with 3.0.20 produces:
> {noformat}
> public static void main(java.lang.String...);
> Code:
>0: ldc #2 // class Main
>2: ldc #30 // String example
>4: ldc #32 // String m
>6: invokevirtual #38 // Method
> java/lang/String.split:(Ljava/lang/String;)[Ljava/lang/String;
>9: ldc #40 // class "[Ljava/lang/Object;"
> 11: invokestatic #46 // Method
> org/codehaus/groovy/runtime/ScriptBytecodeAdapter.castToType:(Ljava/lang/Object;Ljava/lang/Class;)Ljava/lang/Object;
> 14: checkcast #40 // class "[Ljava/lang/Object;"
> 17: new #48 // class Main$_main_closure1
> 20: dup
> 21: ldc #2 // class Main
> 23: ldc #2 // class Main
> 25: invokespecial #51 // Method
> Main$_main_closure1."":(Ljava/lang/Object;Ljava/lang/Object;)V
> 28: invokestatic #57 // Method
> org/codehaus/groovy/runtime/DefaultGroovyMethods.findAll:([Ljava/lang/Object;Lgroovy/lang/Closure;)Ljava/util/Collection;
> 31: invokestatic #61 // Method
> org/codehaus/groovy/runtime/DefaultGroovyMethods.collect:(Ljava/lang/Iterable;)Ljava/u
[jira] [Updated] (GROOVY-11375) Power binary expression finds incorrect type - currently uses declaration inferred type
[
https://issues.apache.org/jira/browse/GROOVY-11375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-11375:
---
Description:
For this code:
{code}
@groovy.transform.CompileStatic
def method() {
var temp = 'foo'
temp = temp.size()
assert temp ** temp == 27
}
method()
{code}
The compiler gives this error:
{noformat}
BUG! exception in phase 'class generation' in source unit 'ConsoleScript3' At
line 10 column 8
On receiver: temp with message: power and arguments: temp
This method should not have been called. Please try to create a simple example
reproducing
this error and file a bug report at https://issues.apache.org/jira/browse/GROOVY
at
org.codehaus.groovy.classgen.asm.sc.StaticTypesCallSiteWriter.makeSingleArgumentCall(StaticTypesCallSiteWriter.java:582)
at
org.codehaus.groovy.classgen.asm.InvocationWriter.makeSingleArgumentCall(InvocationWriter.java:626)
at
org.codehaus.groovy.classgen.asm.BinaryExpressionHelper.evaluateBinaryExpression(BinaryExpressionHelper.java:602)
at
org.codehaus.groovy.classgen.asm.BinaryExpressionMultiTypeDispatcher.evaluateBinaryExpression(BinaryExpressionMultiTypeDispatcher.java:242)
at
org.codehaus.groovy.classgen.asm.BinaryExpressionHelper.eval(BinaryExpressionHelper.java:264)
at
org.codehaus.groovy.classgen.AsmClassGenerator.visitBinaryExpression(AsmClassGenerator.java:849)
...
{noformat}
We apply flow typing for the receiver but not the argument type. This looks
like a case that should be handled where we currently have "TODO: more cases
..." in StaticTypesCallSiteWriter.
The same situation occurs for the shift operators and plus etc., e.g.:
{code}
assert temp << temp == 24
assert temp + temp == 6
{code}
was:
For this code:
{code}
@groovy.transform.CompileStatic
def method() {
var temp = new Date()
temp = temp.format('')[-3..-1].capitalize()
assert temp == 'Day'
temp = temp.size()
assert temp ** temp == 27
}
method()
{code}
The compiler gives this error:
{noformat}
BUG! exception in phase 'class generation' in source unit 'ConsoleScript3' At
line 10 column 8
On receiver: temp with message: power and arguments: temp
This method should not have been called. Please try to create a simple example
reproducing
this error and file a bug report at https://issues.apache.org/jira/browse/GROOVY
at
org.codehaus.groovy.classgen.asm.sc.StaticTypesCallSiteWriter.makeSingleArgumentCall(StaticTypesCallSiteWriter.java:582)
at
org.codehaus.groovy.classgen.asm.InvocationWriter.makeSingleArgumentCall(InvocationWriter.java:626)
at
org.codehaus.groovy.classgen.asm.BinaryExpressionHelper.evaluateBinaryExpression(BinaryExpressionHelper.java:602)
at
org.codehaus.groovy.classgen.asm.BinaryExpressionMultiTypeDispatcher.evaluateBinaryExpression(BinaryExpressionMultiTypeDispatcher.java:242)
at
org.codehaus.groovy.classgen.asm.BinaryExpressionHelper.eval(BinaryExpressionHelper.java:264)
at
org.codehaus.groovy.classgen.AsmClassGenerator.visitBinaryExpression(AsmClassGenerator.java:849)
...
{noformat}
We apply flow typing for the receiver but not the argument type. This looks
like a case that should be handled where we currently have "TODO: more cases
..." in StaticTypesCallSiteWriter.
The same situation occurs for the shift operators and plus etc., e.g.:
{code}
assert temp << temp == 24
assert temp + temp == 6
{code}
> Power binary expression finds incorrect type - currently uses declaration
> inferred type
> ---
>
> Key: GROOVY-11375
> URL: https://issues.apache.org/jira/browse/GROOVY-11375
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 5.0.0-alpha-8, 4.0.21
>Reporter: Paul King
>Priority: Major
> Labels: CompileStatic
>
> For this code:
> {code}
> @groovy.transform.CompileStatic
> def method() {
> var temp = 'foo'
> temp = temp.size()
> assert temp ** temp == 27
> }
> method()
> {code}
> The compiler gives this error:
> {noformat}
> BUG! exception in phase 'class generation' in source unit 'ConsoleScript3' At
> line 10 column 8
> On receiver: temp with message: power and arguments: temp
> This method should not have been called. Please try to create a simple
> example reproducing
> this error and file a bug report at
> https://issues.apache.org/jira/browse/GROOVY
> at
> org.codehaus.groovy.classgen.asm.sc.StaticTypesCallSiteWriter.makeSingleArgumentCall(StaticTypesCallSiteWriter.java:582)
> at
> org.codehaus.groovy.classgen.asm.InvocationWriter.makeSingleArgumentCall(InvocationWriter.java:626)
> at
> org.codehaus.groovy.classgen.asm.BinaryExpressionHelper.evaluateBinaryExpression(BinaryExpressionHelper.java:602)
> at
> org.codehaus
[jira] [Updated] (GROOVY-11375) Power binary expression finds incorrect type - currently uses declaration inferred type
[
https://issues.apache.org/jira/browse/GROOVY-11375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-11375:
---
Description:
For this code:
{code}
@groovy.transform.CompileStatic
def method() {
var temp = new Date()
temp = temp.format('')[-3..-1].capitalize()
assert temp == 'Day'
temp = temp.size()
assert temp ** temp == 27
}
method()
{code}
The compiler gives this error:
{noformat}
BUG! exception in phase 'class generation' in source unit 'ConsoleScript3' At
line 10 column 8
On receiver: temp with message: power and arguments: temp
This method should not have been called. Please try to create a simple example
reproducing
this error and file a bug report at https://issues.apache.org/jira/browse/GROOVY
at
org.codehaus.groovy.classgen.asm.sc.StaticTypesCallSiteWriter.makeSingleArgumentCall(StaticTypesCallSiteWriter.java:582)
at
org.codehaus.groovy.classgen.asm.InvocationWriter.makeSingleArgumentCall(InvocationWriter.java:626)
at
org.codehaus.groovy.classgen.asm.BinaryExpressionHelper.evaluateBinaryExpression(BinaryExpressionHelper.java:602)
at
org.codehaus.groovy.classgen.asm.BinaryExpressionMultiTypeDispatcher.evaluateBinaryExpression(BinaryExpressionMultiTypeDispatcher.java:242)
at
org.codehaus.groovy.classgen.asm.BinaryExpressionHelper.eval(BinaryExpressionHelper.java:264)
at
org.codehaus.groovy.classgen.AsmClassGenerator.visitBinaryExpression(AsmClassGenerator.java:849)
...
{noformat}
We apply flow typing for the receiver but not the argument type. This looks
like a case that should be handled where we currently have "TODO: more cases
..." in StaticTypesCallSiteWriter.
The same situation occurs for the shift operators and plus etc., e.g.:
{code}
assert temp << temp == 24
assert temp + temp == 6
{code}
was:
For this code:
{code}
@groovy.transform.CompileStatic
def method() {
var temp = new Date()
temp = temp.format('')[-3..-1].capitalize()
assert temp == 'Day'
temp = temp.size()
assert temp ** temp == 27
}
method()
{code}
The compiler gives this error:
{noformat}
BUG! exception in phase 'class generation' in source unit 'ConsoleScript3' At
line 10 column 8
On receiver: temp with message: power and arguments: temp
This method should not have been called. Please try to create a simple example
reproducing
this error and file a bug report at https://issues.apache.org/jira/browse/GROOVY
at
org.codehaus.groovy.classgen.asm.sc.StaticTypesCallSiteWriter.makeSingleArgumentCall(StaticTypesCallSiteWriter.java:582)
at
org.codehaus.groovy.classgen.asm.InvocationWriter.makeSingleArgumentCall(InvocationWriter.java:626)
at
org.codehaus.groovy.classgen.asm.BinaryExpressionHelper.evaluateBinaryExpression(BinaryExpressionHelper.java:602)
at
org.codehaus.groovy.classgen.asm.BinaryExpressionMultiTypeDispatcher.evaluateBinaryExpression(BinaryExpressionMultiTypeDispatcher.java:242)
at
org.codehaus.groovy.classgen.asm.BinaryExpressionHelper.eval(BinaryExpressionHelper.java:264)
at
org.codehaus.groovy.classgen.AsmClassGenerator.visitBinaryExpression(AsmClassGenerator.java:849)
...
{noformat}
We apply flow typing for the receiver but not the argument type. This looks
like a case that should be handled where we currently have "TODO: more cases
..." in StaticTypesCallSiteWriter.
The same situation occurs for the shift operators, e.g.:
{code}
assert temp << temp == 24
{code}
> Power binary expression finds incorrect type - currently uses declaration
> inferred type
> ---
>
> Key: GROOVY-11375
> URL: https://issues.apache.org/jira/browse/GROOVY-11375
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 5.0.0-alpha-8, 4.0.21
>Reporter: Paul King
>Priority: Major
> Labels: CompileStatic
>
> For this code:
> {code}
> @groovy.transform.CompileStatic
> def method() {
> var temp = new Date()
> temp = temp.format('')[-3..-1].capitalize()
> assert temp == 'Day'
> temp = temp.size()
> assert temp ** temp == 27
> }
> method()
> {code}
> The compiler gives this error:
> {noformat}
> BUG! exception in phase 'class generation' in source unit 'ConsoleScript3' At
> line 10 column 8
> On receiver: temp with message: power and arguments: temp
> This method should not have been called. Please try to create a simple
> example reproducing
> this error and file a bug report at
> https://issues.apache.org/jira/browse/GROOVY
> at
> org.codehaus.groovy.classgen.asm.sc.StaticTypesCallSiteWriter.makeSingleArgumentCall(StaticTypesCallSiteWriter.java:582)
> at
> org.codehaus.groovy.classgen.asm.InvocationWriter.makeSingleArgumentCall(InvocationWriter.java:626)
> at
> org.codehaus.groovy.classgen.a
