[jira] [Resolved] (GROOVY-11517) Bump checkstyle to 10.20.0
[ https://issues.apache.org/jira/browse/GROOVY-11517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-11517. Resolution: Fixed > Bump checkstyle to 10.20.0 > -- > > Key: GROOVY-11517 > URL: https://issues.apache.org/jira/browse/GROOVY-11517 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11518) Support Java 23 through ASM 9.7
[
https://issues.apache.org/jira/browse/GROOVY-11518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17896120#comment-17896120
]
Paul King commented on GROOVY-11518:
No problems Herve, never hurts to ask.
> Support Java 23 through ASM 9.7
> ---
>
> Key: GROOVY-11518
> URL: https://issues.apache.org/jira/browse/GROOVY-11518
> Project: Groovy
> Issue Type: New Feature
> Components: Compiler
>Affects Versions: 4.0.16
>Reporter: Herve Girod
>Priority: Major
>
> Groovy uses ASM 9.6, which support up to Java 22. Using ASM 9.7 would allow
> to support Java 23. I have the following Stack Trace:
> {code:java}
> BUG! exception in phase 'semantic analysis' in source unit
> 'Script_83d220891ea7c7d06c78121cd044992a.groovy' Unsupported class file major
> version 67
> at
> org.codehaus.groovy.control.CompilationUnit$ISourceUnitOperation.doPhaseOperation(CompilationUnit.java:901)
> at
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:692)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:666)
> at
> groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:373)
> {code}
> I uses Groovy 4.0.16 but looking on the logs for versions it appears that the
> ASM version has not be upgraed since this version.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11518) Support Java 23 through ASM 9.7
[
https://issues.apache.org/jira/browse/GROOVY-11518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17895798#comment-17895798
]
Paul King commented on GROOVY-11518:
{noformat}
$ git log --oneline -200 | grep -i asm
75c9ac944e GROOVY-11497: Bump asm to 9.7.1
f0079da7bf GROOVY-11343: Bump asm to 9.7
{noformat}
ASM was bumped to 4.7 for Groovy 4.0.21 and 4.7.1 for 4.0.24 (currently under
voting for release).
> Support Java 23 through ASM 9.7
> ---
>
> Key: GROOVY-11518
> URL: https://issues.apache.org/jira/browse/GROOVY-11518
> Project: Groovy
> Issue Type: New Feature
> Components: Compiler
>Affects Versions: 4.0.16
>Reporter: Herve Girod
>Priority: Major
>
> Groovy uses ASM 9.6, which support up to Java 22. Using ASM 9.7 would allow
> to support Java 23. I have the following Stack Trace:
> {code:java}
> BUG! exception in phase 'semantic analysis' in source unit
> 'Script_83d220891ea7c7d06c78121cd044992a.groovy' Unsupported class file major
> version 67
> at
> org.codehaus.groovy.control.CompilationUnit$ISourceUnitOperation.doPhaseOperation(CompilationUnit.java:901)
> at
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:692)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:666)
> at
> groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:373)
> {code}
> I uses Groovy 4.0.16 but looking on the logs for versions it appears that the
> ASM version has not be upgraed since this version.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-11518) Support Java 23 through ASM 9.7
[
https://issues.apache.org/jira/browse/GROOVY-11518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-11518.
Resolution: Not A Problem
> Support Java 23 through ASM 9.7
> ---
>
> Key: GROOVY-11518
> URL: https://issues.apache.org/jira/browse/GROOVY-11518
> Project: Groovy
> Issue Type: New Feature
> Components: Compiler
>Affects Versions: 4.0.16
>Reporter: Herve Girod
>Priority: Major
>
> Groovy uses ASM 9.6, which support up to Java 22. Using ASM 9.7 would allow
> to support Java 23. I have the following Stack Trace:
> {code:java}
> BUG! exception in phase 'semantic analysis' in source unit
> 'Script_83d220891ea7c7d06c78121cd044992a.groovy' Unsupported class file major
> version 67
> at
> org.codehaus.groovy.control.CompilationUnit$ISourceUnitOperation.doPhaseOperation(CompilationUnit.java:901)
> at
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:692)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:666)
> at
> groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:373)
> {code}
> I uses Groovy 4.0.16 but looking on the logs for versions it appears that the
> ASM version has not be upgraed since this version.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11478) Enable GroovyClassLoader to be ParallelCapable
[
https://issues.apache.org/jira/browse/GROOVY-11478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-11478:
---
Fix Version/s: 3.0.23
> Enable GroovyClassLoader to be ParallelCapable
> --
>
> Key: GROOVY-11478
> URL: https://issues.apache.org/jira/browse/GROOVY-11478
> Project: Groovy
> Issue Type: Improvement
>Affects Versions: 3.0.22, 4.0.23, 5.0.0-alpha-10
>Reporter: Paul King
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.23, 5.0.0-alpha-11, 4.0.24
>
>
> 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] [Updated] (GROOVY-11517) Bump checkstyle to 10.20.0
[ https://issues.apache.org/jira/browse/GROOVY-11517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11517: --- Fix Version/s: (was: 4.0.24) > Bump checkstyle to 10.20.0 > -- > > Key: GROOVY-11517 > URL: https://issues.apache.org/jira/browse/GROOVY-11517 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-11516) Improve consistency of treatment for internal properties
[
https://issues.apache.org/jira/browse/GROOVY-11516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17895282#comment-17895282
]
Paul King edited comment on GROOVY-11516 at 11/4/24 1:09 PM:
-
[~blackdrag] That would be one of the cases I'd like to make more consistent:
{code}
import groovy.json.JsonOutput
import groovy.transform.ToString
@ToString(includeFields=true, includeNames=true)
class Foo {
public int amountIn$ = 10
public int amountInDollars = 20
}
def foo = new Foo()
assert foo.toString() == 'Foo(amountInDollars:20)' // in 4/5
assert JsonOutput.toJson(foo) == '{"amountIn$":10,"amountInDollars":20}' //
currently in 4
assert JsonOutput.toJson(foo) == '{"amountInDollars":20}' // planned for 5
{code}
The slightly tricky thing is that we have an easier opt-out using allNames for
AST transforms, e.g.:
{code}
@ToString(includeFields=true, includeNames=true, allNames=true)
class Foo {
public int amountIn$ = 10
public int amountInDollars = 20
}
def foo = new Foo()
assert foo.toString() == 'Foo(amountIn$:10, amountInDollars:20)'
{code}
I'll also note that the PR covers methods and fields with "$" but I think we
only cover fields for AST transforms. Perhaps that is safer to start with. I
also haven't added tests in the PR yet since we should agree on intended
behavior first.
was (Author: paulk):
[~blackdrag] That would be one of the cases I'd like to make more consistent:
{code}
import groovy.json.JsonOutput
import groovy.transform.ToString
@ToString(includeFields=true, includeNames=true)
class Foo {
public int amountIn$ = 10
public int amountInDollars = 20
}
def foo = new Foo()
assert foo.toString() == 'Foo(amountInDollars:20)' // in 4/5
assert JsonOutput.toJson(foo) == '{"amountIn$":10,"amountInDollars":20}' //
currently in 4
assert JsonOutput.toJson(foo) == '{"amountInDollars":20}' // planned for 5
{code}
The slightly tricky thing is that we have an easier opt-out using allNames for
AST transforms, e.g.:
{code}
@ToString(includeFields=true, includeNames=true, allNames=true)
class Foo {
public int amountIn$ = 10
public int amountInDollars = 20
}
def foo = new Foo()
assert foo.toString() == 'Foo(amountIn$:10, amountInDollars:20)'
{code}
I'll also note that the PR covers methods and fields with "$" but I think we
only cover fields for AST transforms. Perhaps that is safer to start with.
> Improve consistency of treatment for internal properties
>
>
> Key: GROOVY-11516
> URL: https://issues.apache.org/jira/browse/GROOVY-11516
> Project: Groovy
> Issue Type: Improvement
>Reporter: Paul King
>Assignee: Paul King
>Priority: Major
> Labels: breaking
>
> In numerous places, property names containing a "$" are deemed internal but
> not MetaClassImpl#getProperties. This means for instance that
> JsonOutput.toJson() currently outputs such internal properties.
> After this change, such properties would not normally be returned. No test
> fails after such a change indicating that this is an edge case we haven't
> covered previously.
> This would be a breaking change if anyone is really on the existing edge case
> behavior. If necessary, we could use a system property to re-enable the
> system behavior. We already have a system property
> "groovy.permissive.property.access". We could use
> "groovy.dollar.property.access" as well but I wasn't planning to add this
> unless we get feedback that some folks need it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-11516) Improve consistency of treatment for internal properties
[
https://issues.apache.org/jira/browse/GROOVY-11516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17895282#comment-17895282
]
Paul King edited comment on GROOVY-11516 at 11/4/24 1:08 PM:
-
[~blackdrag] That would be one of the cases I'd like to make more consistent:
{code}
import groovy.json.JsonOutput
import groovy.transform.ToString
@ToString(includeFields=true, includeNames=true)
class Foo {
public int amountIn$ = 10
public int amountInDollars = 20
}
def foo = new Foo()
assert foo.toString() == 'Foo(amountInDollars:20)' // in 4/5
assert JsonOutput.toJson(foo) == '{"amountIn$":10,"amountInDollars":20}' //
currently in 4
assert JsonOutput.toJson(foo) == '{"amountInDollars":20}' // planned for 5
{code}
The slightly tricky thing is that we have an easier opt-out using allNames for
AST transforms, e.g.:
{code}
@ToString(includeFields=true, includeNames=true, allNames=true)
class Foo {
public int amountIn$ = 10
public int amountInDollars = 20
}
def foo = new Foo()
assert foo.toString() == 'Foo(amountIn$:10, amountInDollars:20)'
{code}
I'll also note that the PR covers methods and fields with "$" but I think we
only cover fields for AST transforms. Perhaps that is safer to start with.
was (Author: paulk):
[~blackdrag] That would be one of the cases I'd like to make more consistent:
{code}
import groovy.json.JsonOutput
import groovy.transform.ToString
@ToString(includeFields=true, includeNames=true)
class Foo {
public int amountIn$ = 10
public int amountInDollars = 20
}
def foo = new Foo()
assert foo.toString() == 'Foo(amountInDollars:20)' // in 4/5
assert JsonOutput.toJson(foo) == '{"amountIn$":10,"amountInDollars":20}' //
currently in 4
assert JsonOutput.toJson(foo) == '{"amountInDollars":20}' // planned for 5
{code}
The slightly tricky thing is that we have an easier opt-out using allNames for
AST transforms, e.g.:
{code}
@ToString(includeFields=true, includeNames=true, allNames=true)
class Foo {
public int amountIn$ = 10
public int amountInDollars = 20
}
def foo = new Foo()
assert foo.toString() == 'Foo(amountIn$:10, amountInDollars:20)'
{code}
> Improve consistency of treatment for internal properties
>
>
> Key: GROOVY-11516
> URL: https://issues.apache.org/jira/browse/GROOVY-11516
> Project: Groovy
> Issue Type: Improvement
>Reporter: Paul King
>Assignee: Paul King
>Priority: Major
> Labels: breaking
>
> In numerous places, property names containing a "$" are deemed internal but
> not MetaClassImpl#getProperties. This means for instance that
> JsonOutput.toJson() currently outputs such internal properties.
> After this change, such properties would not normally be returned. No test
> fails after such a change indicating that this is an edge case we haven't
> covered previously.
> This would be a breaking change if anyone is really on the existing edge case
> behavior. If necessary, we could use a system property to re-enable the
> system behavior. We already have a system property
> "groovy.permissive.property.access". We could use
> "groovy.dollar.property.access" as well but I wasn't planning to add this
> unless we get feedback that some folks need it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GROOVY-11516) Improve consistency of treatment for internal properties
[ https://issues.apache.org/jira/browse/GROOVY-11516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King reassigned GROOVY-11516: -- Assignee: Paul King > Improve consistency of treatment for internal properties > > > Key: GROOVY-11516 > URL: https://issues.apache.org/jira/browse/GROOVY-11516 > Project: Groovy > Issue Type: Improvement >Reporter: Paul King >Assignee: Paul King >Priority: Major > Labels: breaking > > In numerous places, property names containing a "$" are deemed internal but > not MetaClassImpl#getProperties. This means for instance that > JsonOutput.toJson() currently outputs such internal properties. > After this change, such properties would not normally be returned. No test > fails after such a change indicating that this is an edge case we haven't > covered previously. > This would be a breaking change if anyone is really on the existing edge case > behavior. If necessary, we could use a system property to re-enable the > system behavior. We already have a system property > "groovy.permissive.property.access". We could use > "groovy.dollar.property.access" as well but I wasn't planning to add this > unless we get feedback that some folks need it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11516) Improve consistency of treatment for internal properties
[
https://issues.apache.org/jira/browse/GROOVY-11516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17895282#comment-17895282
]
Paul King commented on GROOVY-11516:
[~blackdrag] That would be one of the cases I'd like to make more consistent:
{code}
import groovy.json.JsonOutput
import groovy.transform.ToString
@ToString(includeFields=true, includeNames=true)
class Foo {
public int amountIn$ = 10
public int amountInDollars = 20
}
def foo = new Foo()
assert foo.toString() == 'Foo(amountInDollars:20)' // in 4/5
assert JsonOutput.toJson(foo) == '{"amountIn$":10,"amountInDollars":20}' //
currently in 4
assert JsonOutput.toJson(foo) == '{"amountInDollars":20}' // planned for 5
{code}
The slightly tricky thing is that we have an easier opt-out using allNames for
AST transforms, e.g.:
{code}
@ToString(includeFields=true, includeNames=true, allNames=true)
class Foo {
public int amountIn$ = 10
public int amountInDollars = 20
}
def foo = new Foo()
assert foo.toString() == 'Foo(amountIn$:10, amountInDollars:20)'
{code}
> Improve consistency of treatment for internal properties
>
>
> Key: GROOVY-11516
> URL: https://issues.apache.org/jira/browse/GROOVY-11516
> Project: Groovy
> Issue Type: Improvement
>Reporter: Paul King
>Priority: Major
> Labels: breaking
>
> In numerous places, property names containing a "$" are deemed internal but
> not MetaClassImpl#getProperties. This means for instance that
> JsonOutput.toJson() currently outputs such internal properties.
> After this change, such properties would not normally be returned. No test
> fails after such a change indicating that this is an edge case we haven't
> covered previously.
> This would be a breaking change if anyone is really on the existing edge case
> behavior. If necessary, we could use a system property to re-enable the
> system behavior. We already have a system property
> "groovy.permissive.property.access". We could use
> "groovy.dollar.property.access" as well but I wasn't planning to add this
> unless we get feedback that some folks need it.
--
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=17895270#comment-17895270 ] Paul King commented on GROOVY-11459: This has been backported to Groovy 4. Please note though that if we change the default, we'll likely only do that 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 > Fix For: 5.0.0-alpha-11, 4.0.24 > > > 通过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-11459) weak hashing algorithm (使用弱哈希算法)
[ https://issues.apache.org/jira/browse/GROOVY-11459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-11459. Resolution: Fixed > 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 > Fix For: 5.0.0-alpha-11, 4.0.24 > > > 通过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: --- Fix Version/s: 5.0.0-alpha-11 4.0.24 (was: 4.x) > 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 > Fix For: 5.0.0-alpha-11, 4.0.24 > > > 通过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-11517) Bump checkstyle to 10.20.0
Paul King created GROOVY-11517: -- Summary: Bump checkstyle to 10.20.0 Key: GROOVY-11517 URL: https://issues.apache.org/jira/browse/GROOVY-11517 Project: Groovy Issue Type: Dependency upgrade Reporter: Daniel Sun Assignee: Daniel Sun Fix For: 5.0.0-alpha-11, 4.0.24 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GROOVY-11517) Bump checkstyle to 10.20.0
[ https://issues.apache.org/jira/browse/GROOVY-11517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King reassigned GROOVY-11517: -- Assignee: Paul King (was: Daniel Sun) > Bump checkstyle to 10.20.0 > -- > > Key: GROOVY-11517 > URL: https://issues.apache.org/jira/browse/GROOVY-11517 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-11, 4.0.24 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11516) Improve consistency of treatment for internal properties
Paul King created GROOVY-11516: -- Summary: Improve consistency of treatment for internal properties Key: GROOVY-11516 URL: https://issues.apache.org/jira/browse/GROOVY-11516 Project: Groovy Issue Type: Improvement Reporter: Paul King In numerous places, property names containing a "$" are deemed internal but not MetaClassImpl#getProperties. This means for instance that JsonOutput.toJson() currently outputs such internal properties. After this change, such properties would not normally be returned. No test fails after such a change indicating that this is an edge case we haven't covered previously. This would be a breaking change if anyone is really on the existing edge case behavior. If necessary, we could use a system property to re-enable the system behavior. We already have a system property "groovy.permissive.property.access". We could use "groovy.dollar.property.access" as well but I wasn't planning to add this unless we get feedback that some folks need it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11515) configurable hashing algorithm
[ https://issues.apache.org/jira/browse/GROOVY-11515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11515: --- Description: bq. 通过iast扫描发现groovy中使用了md5来生成缓存键名，路径为groovy.lang.GroovyClassLoader.getSourceCacheKey bq. bq. 建议使用常见的安全的哈希算法，如SHA-256,SHA-384,SHA-512等 bq. bq. Google Translate gives: bq. 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 bq. bq. It is recommended to use common secure hash algorithms, such as SHA-256, SHA-384, SHA-512, etc. In GROOVY-11459, it was made possible to configure the hashing algorithm. This issue is to explore whether there is a significant performance degradation making SHA256 the default. Initial tests, albeit on a small sample size, indicates no. We need to do further testing though. The default would only be changed for Groovy 5+. was: 通过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. In GROOVY-11459, it was made possible to configure the hashing algorithm. This issue is to explore whether there is a significant performance degradation making SHA256 the default. Initial tests, albeit on a small sample size, indicates no. We need to do further testing though. The default would only be changed for Groovy 5+. > configurable hashing algorithm > -- > > Key: GROOVY-11515 > URL: https://issues.apache.org/jira/browse/GROOVY-11515 > Project: Groovy > Issue Type: Bug >Affects Versions: 4.0.22 >Reporter: wellchang >Assignee: Paul King >Priority: Major > Fix For: 5.x > > > bq. > 通过iast扫描发现groovy中使用了md5来生成缓存键名，路径为groovy.lang.GroovyClassLoader.getSourceCacheKey > bq. > bq. 建议使用常见的安全的哈希算法，如SHA-256,SHA-384,SHA-512等 > bq. > bq. Google Translate gives: > bq. 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 > bq. > bq. It is recommended to use common secure hash algorithms, such as SHA-256, > SHA-384, SHA-512, etc. > In GROOVY-11459, it was made possible to configure the hashing algorithm. > This issue is to explore whether there is a significant performance > degradation making SHA256 the default. Initial tests, albeit on a small > sample size, indicates no. We need to do further testing though. The default > would only be changed for Groovy 5+. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11515) configurable hashing algorithm
[ https://issues.apache.org/jira/browse/GROOVY-11515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11515: --- 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. In GROOVY-11459, it was made possible to configure the hashing algorithm. This issue is to explore whether there is a significant performance degradation making SHA256 the default. Initial tests, albeit on a small sample size, indicates no. We need to do further testing though. The default would only be changed for Groovy 5+. was: 通过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. In GROOVY-11459, it was made possible > configurable hashing algorithm > -- > > Key: GROOVY-11515 > URL: https://issues.apache.org/jira/browse/GROOVY-11515 > Project: Groovy > Issue Type: Bug >Affects Versions: 4.0.22 >Reporter: wellchang >Assignee: Paul King >Priority: Major > Fix For: 5.x > > > 通过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. > In GROOVY-11459, it was made possible to configure the hashing algorithm. > This issue is to explore whether there is a significant performance > degradation making SHA256 the default. Initial tests, albeit on a small > sample size, indicates no. We need to do further testing though. The default > would only be changed for Groovy 5+. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11515) configurable hashing algorithm
Paul King created GROOVY-11515: -- Summary: configurable hashing algorithm Key: GROOVY-11515 URL: https://issues.apache.org/jira/browse/GROOVY-11515 Project: Groovy Issue Type: Bug Affects Versions: 4.0.22 Reporter: wellchang Assignee: Paul King Fix For: 4.x 通过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-11515) configurable hashing algorithm
[ https://issues.apache.org/jira/browse/GROOVY-11515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11515: --- 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. In GROOVY-11459, it was made possible was: 通过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. > configurable hashing algorithm > -- > > Key: GROOVY-11515 > URL: https://issues.apache.org/jira/browse/GROOVY-11515 > Project: Groovy > Issue Type: Bug >Affects Versions: 4.0.22 >Reporter: wellchang >Assignee: Paul King >Priority: Major > Fix For: 4.x > > > 通过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. > In GROOVY-11459, it was made possible -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11515) configurable hashing algorithm
[ https://issues.apache.org/jira/browse/GROOVY-11515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11515: --- Fix Version/s: 5.x (was: 4.x) > configurable hashing algorithm > -- > > Key: GROOVY-11515 > URL: https://issues.apache.org/jira/browse/GROOVY-11515 > Project: Groovy > Issue Type: Bug >Affects Versions: 4.0.22 >Reporter: wellchang >Assignee: Paul King >Priority: Major > Fix For: 5.x > > > 通过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. > In GROOVY-11459, it was made possible -- 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: --- Fix Version/s: 4.x > 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 > Fix For: 4.x > > > 通过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-11166) JEP 445 compatibility
[
https://issues.apache.org/jira/browse/GROOVY-11166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-11166.
Resolution: Done
The subtasks are all delivered. JEP 445 wasn't finalized at the time, so I left
this ticket open. Also, we could probably improve documentation. But, let's
close for now and we can add additional specific issues later if needed.
> JEP 445 compatibility
> -
>
> Key: GROOVY-11166
> URL: https://issues.apache.org/jira/browse/GROOVY-11166
> Project: Groovy
> Issue Type: New Feature
>Reporter: Paul King
>Assignee: Paul King
>Priority: Major
> Labels: GEP, breaking
>
> [JEP 445: Unnamed Classes and Instance Main
> Methods|https://openjdk.org/jeps/445] provides features that improve using
> Java for scripting purposes. While these features offer a subset of the
> features offered by Groovy for scripting, it would be nice to offer some
> interworking for cut-n-paste compatibility and leveraging the updated launch
> protocol.
> (i) This description will contain the most update-to-date proposal for the
> design but may undergo change during discussions. If needed, a separate GEP
> section in the wiki will capture the final design.
> h2. Scripting semantics
> ||Source file characteristics||Semantics determined||
> |Contains only a class declaration|Compiled as a class|
> |Contains class declaration(s) and uncontained statements|Class definitions
> elevated to top-level, uncontained statements treated like a normal script|
> |Contains only a class declaration|Compiled as a class|
> |Contains an instance main method, and possibly field and other method
> declarations|*NEW*: Compiled as a JEP 445 compatible class|
> |Contains a static main method, and possibly field and other method
> declarations|*CHANGED*: Compiled like a JEP 445 compatible class but method
> signature "promoted" to public static void main with String[] argument|
> |Contains uncontained non-declaration statements or a no-arg instance {{run}}
> method|*NEW*: Compiled as a Groovy script|
> Groovy scripts are wrapped into an encompassing class that extends
> {{groovy.lang.Script}}.
> Such classes have a {{public static void main}} added which (summarising)
> creates a class instance and calls its {{run}} method.
> Uncontained statements within the script can be thought of as belonging
> within the {{run}} method.
> Declaration statements within the script are treated as local variable
> definitions (also within the {{run}} method).
> Field definitions can be obtained by annotating declaration statements with
> the {{@Field}} annotation.
> JEP 445 scripts do not extend {{Script}} and do not have any methods added.
> Declaration statements within the script are treated as field definitions.
> h2. Script runner
> Groovy's runner mechanism will be extended to follow a similar protocol to
> Java's revised launch protocol. This should be available for JDK11+ and a
> JEP-445 compatible class could be invoked using JDK21+ with preview enabled
> (with Groovy on the classpath unless a POJO class is created).
> h2. Breaking changes
> * Previously, if a script had a single instance {{main}} method not taking a
> {{String[]}} parameter and no loose statements, that was previously accepted
> as a normal Groovy script (and nothing would execute). Now if the method has
> an Object parameter, that is treated as a JEP-445 script and its contents
> executed.
> * Previously, if a script had a static main method and no other loose
> statements, the main method's contents were moved into the run method and the
> script class extended Script. Now, creating a no-arg {{run}} method is
> supported for this scenario. If a static {{main}} method is created, it is
> treated as a JEP 445 compatible script.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11453) Spread-safe operator differences and efficiencies
[
https://issues.apache.org/jira/browse/GROOVY-11453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886024#comment-17886024
]
Paul King commented on GROOVY-11453:
Yes, I see the difference now. I mustn't have done a clean in previous testing.
I've added the breaking label to this issue, though I'll note that it is only
breaking if folks were relying on the specific empty list for that one edge
case.
> Spread-safe operator differences and efficiencies
> -
>
> Key: GROOVY-11453
> URL: https://issues.apache.org/jira/browse/GROOVY-11453
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Labels: breaking
> Fix For: 5.0.0-alpha-11
>
>
> The spread-safe operator -- aka {{a*.b}} or {{a*.b(c)}} -- has some
> differences and inefficiencies.
> # When the receiver is null, the expression produces null for dynamic mode
> and an empty list for static compilation. Can this difference be safely
> resolved?
> # When the method return type is {{void}}, there is no need for a list to
> collect up nulls. This is producing "Useless object stored in variable
> var$1" warnings from SpotBugs. The only benefit of this is the ability to
> detect the number of elements.
> # The SC bytecode has a redundant null test in it. Since a for loop is also
> null-safe, guarding the loop bytecode by a null check is producing "Redundant
> check for null" warnings from SpotBugs. *NOTE:* If (1) above is changed in
> the SC classgen, the null check may not be redundant as it would guard list
> construction.
> For reference, {{object*.method(arguments)}} is written by the static
> compiler like this:
> {code:groovy}
> def result = new ArrayList()
> if (object != null) {
> for (Inferred element : object) { // also null-safe
> result.add(element?.method(arguments)
> }
> }
> result
> {code}
> And the dynamic impl:
> https://github.com/apache/groovy/blob/f46103d31b7574ce883ff3b6c01fa8a412f225be/src/main/java/org/codehaus/groovy/runtime/ScriptBytecodeAdapter.java#L189
> GROOVY-7177
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11453) Spread-safe operator differences and efficiencies
[
https://issues.apache.org/jira/browse/GROOVY-11453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-11453:
---
Labels: breaking (was: )
> Spread-safe operator differences and efficiencies
> -
>
> Key: GROOVY-11453
> URL: https://issues.apache.org/jira/browse/GROOVY-11453
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Labels: breaking
> Fix For: 5.0.0-alpha-11
>
>
> The spread-safe operator -- aka {{a*.b}} or {{a*.b(c)}} -- has some
> differences and inefficiencies.
> # When the receiver is null, the expression produces null for dynamic mode
> and an empty list for static compilation. Can this difference be safely
> resolved?
> # When the method return type is {{void}}, there is no need for a list to
> collect up nulls. This is producing "Useless object stored in variable
> var$1" warnings from SpotBugs. The only benefit of this is the ability to
> detect the number of elements.
> # The SC bytecode has a redundant null test in it. Since a for loop is also
> null-safe, guarding the loop bytecode by a null check is producing "Redundant
> check for null" warnings from SpotBugs. *NOTE:* If (1) above is changed in
> the SC classgen, the null check may not be redundant as it would guard list
> construction.
> For reference, {{object*.method(arguments)}} is written by the static
> compiler like this:
> {code:groovy}
> def result = new ArrayList()
> if (object != null) {
> for (Inferred element : object) { // also null-safe
> result.add(element?.method(arguments)
> }
> }
> result
> {code}
> And the dynamic impl:
> https://github.com/apache/groovy/blob/f46103d31b7574ce883ff3b6c01fa8a412f225be/src/main/java/org/codehaus/groovy/runtime/ScriptBytecodeAdapter.java#L189
> GROOVY-7177
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11453) Spread-safe operator differences and efficiencies
[
https://issues.apache.org/jira/browse/GROOVY-11453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885871#comment-17885871
]
Paul King commented on GROOVY-11453:
[~emilles] So generated bytecode didn't change but inference was improved?
> Spread-safe operator differences and efficiencies
> -
>
> Key: GROOVY-11453
> URL: https://issues.apache.org/jira/browse/GROOVY-11453
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Fix For: 5.0.0-alpha-11
>
>
> The spread-safe operator -- aka {{a*.b}} or {{a*.b(c)}} -- has some
> differences and inefficiencies.
> # When the receiver is null, the expression produces null for dynamic mode
> and an empty list for static compilation. Can this difference be safely
> resolved?
> # When the method return type is {{void}}, there is no need for a list to
> collect up nulls. This is producing "Useless object stored in variable
> var$1" warnings from SpotBugs. The only benefit of this is the ability to
> detect the number of elements.
> # The SC bytecode has a redundant null test in it. Since a for loop is also
> null-safe, guarding the loop bytecode by a null check is producing "Redundant
> check for null" warnings from SpotBugs. *NOTE:* If (1) above is changed in
> the SC classgen, the null check may not be redundant as it would guard list
> construction.
> For reference, {{object*.method(arguments)}} is written by the static
> compiler like this:
> {code:groovy}
> def result = new ArrayList()
> if (object != null) {
> for (Inferred element : object) { // also null-safe
> result.add(element?.method(arguments)
> }
> }
> result
> {code}
> And the dynamic impl:
> https://github.com/apache/groovy/blob/f46103d31b7574ce883ff3b6c01fa8a412f225be/src/main/java/org/codehaus/groovy/runtime/ScriptBytecodeAdapter.java#L189
> GROOVY-7177
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11478) Enable GroovyClassLoader to be ParallelCapable
[
https://issues.apache.org/jira/browse/GROOVY-11478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-11478:
---
Fix Version/s: 4.0.24
> Enable GroovyClassLoader to be ParallelCapable
> --
>
> Key: GROOVY-11478
> URL: https://issues.apache.org/jira/browse/GROOVY-11478
> Project: Groovy
> Issue Type: Improvement
>Affects Versions: 3.0.22, 4.0.23, 5.0.0-alpha-10
>Reporter: Paul King
>Assignee: Paul King
>Priority: Major
> Fix For: 5.0.0-alpha-11, 4.0.24
>
>
> 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] [Updated] (GROOVY-11484) Downgrade asciidoctorj-diagram to 2.2.10 due to errors
[ https://issues.apache.org/jira/browse/GROOVY-11484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11484: --- Description: This seemed to break at least 2 of our diagrams, e.g. Strategy Method UML diagram and Template Method UML diagram. Current broken URL (but should autocorrect with the next release): https://groovy-lang.org/design-patterns.html#_strategy_pattern Version specific broken URL: https://docs.groovy-lang.org/docs/groovy-4.0.23/html/documentation/design-patterns-in-groovy.html#_strategy_pattern Workaround is to go back to previous version specific file: https://docs.groovy-lang.org/docs/groovy-4.0.22/html/documentation/design-patterns-in-groovy.html#_strategy_pattern For now I don't plan to manually try to fix the images. They will be automatically corrected when we next release and the workaround is mentioned above. There are issues raised on the upstream projects website already. was: This seemed to break at least 2 of our diagrams, e.g. Strategy Method UML diagram and Template Method UML diagram. Current broken URL (but should autocorrect with the next release): https://groovy-lang.org/design-patterns.html#_strategy_pattern Version specific broken URL: https://docs.groovy-lang.org/docs/groovy-4.0.23/html/documentation/design-patterns-in-groovy.html#_strategy_pattern Workaround is to go back to previous version specific file: https://docs.groovy-lang.org/docs/groovy-4.0.22/html/documentation/design-patterns-in-groovy.html#_strategy_pattern > Downgrade asciidoctorj-diagram to 2.2.10 due to errors > --- > > Key: GROOVY-11484 > URL: https://issues.apache.org/jira/browse/GROOVY-11484 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-11, 4.0.24 > > > This seemed to break at least 2 of our diagrams, e.g. Strategy Method UML > diagram and Template Method UML diagram. > Current broken URL (but should autocorrect with the next release): > https://groovy-lang.org/design-patterns.html#_strategy_pattern > Version specific broken URL: > https://docs.groovy-lang.org/docs/groovy-4.0.23/html/documentation/design-patterns-in-groovy.html#_strategy_pattern > Workaround is to go back to previous version specific file: > https://docs.groovy-lang.org/docs/groovy-4.0.22/html/documentation/design-patterns-in-groovy.html#_strategy_pattern > For now I don't plan to manually try to fix the images. They will be > automatically corrected when we next release and the workaround is mentioned > above. There are issues raised on the upstream projects website already. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11484) Downgrade asciidoctorj-diagram to 2.2.10 due to errors
[ https://issues.apache.org/jira/browse/GROOVY-11484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-11484. Resolution: Fixed > Downgrade asciidoctorj-diagram to 2.2.10 due to errors > --- > > Key: GROOVY-11484 > URL: https://issues.apache.org/jira/browse/GROOVY-11484 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-11, 4.0.24 > > > This seemed to break at least 2 of our diagrams, e.g. Strategy Method UML > diagram and Template Method UML diagram. > Current broken URL (but should autocorrect with the next release): > https://groovy-lang.org/design-patterns.html#_strategy_pattern > Version specific broken URL: > https://docs.groovy-lang.org/docs/groovy-4.0.23/html/documentation/design-patterns-in-groovy.html#_strategy_pattern > Workaround is to go back to previous version specific file: > https://docs.groovy-lang.org/docs/groovy-4.0.22/html/documentation/design-patterns-in-groovy.html#_strategy_pattern > For now I don't plan to manually try to fix the images. They will be > automatically corrected when we next release and the workaround is mentioned > above. There are issues raised on the upstream projects website already. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11484) Downgrade asciidoctorj-diagram to 2.2.10 due to errors
[ https://issues.apache.org/jira/browse/GROOVY-11484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11484: --- Description: This seemed to break at least 2 of our diagrams, e.g. Strategy Method UML diagram and Template Method UML diagram. Current broken URL (but should autocorrect with the next release): https://groovy-lang.org/design-patterns.html#_strategy_pattern Version specific broken URL: https://docs.groovy-lang.org/docs/groovy-4.0.23/html/documentation/design-patterns-in-groovy.html#_strategy_pattern Workaround is to go back to previous version specific file: https://docs.groovy-lang.org/docs/groovy-4.0.22/html/documentation/design-patterns-in-groovy.html#_strategy_pattern > Downgrade asciidoctorj-diagram to 2.2.10 due to errors > --- > > Key: GROOVY-11484 > URL: https://issues.apache.org/jira/browse/GROOVY-11484 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-11, 4.0.24 > > > This seemed to break at least 2 of our diagrams, e.g. Strategy Method UML > diagram and Template Method UML diagram. > Current broken URL (but should autocorrect with the next release): > https://groovy-lang.org/design-patterns.html#_strategy_pattern > Version specific broken URL: > https://docs.groovy-lang.org/docs/groovy-4.0.23/html/documentation/design-patterns-in-groovy.html#_strategy_pattern > Workaround is to go back to previous version specific file: > https://docs.groovy-lang.org/docs/groovy-4.0.22/html/documentation/design-patterns-in-groovy.html#_strategy_pattern -- 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=17884247#comment-17884247 ] Paul King commented on GROOVY-11045: I backported to the GROOVY_3_0_X branch. Thanks for providing and testing out the workaround. > 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, 3.0.23 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11045) Bump testng to 7.5.1
[ https://issues.apache.org/jira/browse/GROOVY-11045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11045: --- Fix Version/s: 3.0.23 > 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, 3.0.23 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11484) Downgrade asciidoctorj-diagram to 2.2.10 due to errors
[ https://issues.apache.org/jira/browse/GROOVY-11484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-11484: --- Fix Version/s: 5.0.0-alpha-11 4.0.24 (was: 4.0.23) (was: 5.0.0-alpha-10) > Downgrade asciidoctorj-diagram to 2.2.10 due to errors > --- > > Key: GROOVY-11484 > URL: https://issues.apache.org/jira/browse/GROOVY-11484 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-11, 4.0.24 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11484) Downgrade asciidoctorj-diagram to 2.2.10 due to errors
Paul King created GROOVY-11484: -- Summary: Downgrade asciidoctorj-diagram to 2.2.10 due to errors Key: GROOVY-11484 URL: https://issues.apache.org/jira/browse/GROOVY-11484 Project: Groovy Issue Type: Dependency upgrade Reporter: Daniel Sun Assignee: Daniel Sun Fix For: 4.0.23, 5.0.0-alpha-10 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11435) Bump asciidoctorj-diagram to 2.3.1
[ https://issues.apache.org/jira/browse/GROOVY-11435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884244#comment-17884244 ] Paul King commented on GROOVY-11435: This seemed to break at least 2 of our diagrams, e.g. Strategy Method UML: https://groovy-lang.org/design-patterns.html#_strategy_pattern I'll revert back to 2.2.10. Versions 2.2.11 and above all give me that error. > Bump asciidoctorj-diagram to 2.3.1 > -- > > Key: GROOVY-11435 > URL: https://issues.apache.org/jira/browse/GROOVY-11435 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 4.0.23, 5.0.0-alpha-10 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11482) Improve documentation using method categories
Paul King created GROOVY-11482:
--
Summary: Improve documentation using method categories
Key: GROOVY-11482
URL: https://issues.apache.org/jira/browse/GROOVY-11482
Project: Groovy
Issue Type: Improvement
Reporter: Paul King
Attachments: image-2024-09-23-20-34-29-532.png,
image-2024-09-23-20-39-02-272.png
This is a placeholder to investigate whether we can use the ideas in the
following article to improve our documentation:
[https://donraab.medium.com/associating-method-categories-with-emojis-in-intellij-and-javadoc-a82aebe1e903]
The structure view within IDEA might look like this:
!image-2024-09-23-20-39-02-272.png!
The Javadoc might look like this:
!image-2024-09-23-20-34-29-532.png!
These pictures are for a mock up of {{DefaultGroovyMethods}}.
We'd need to consider several issues including:
* Can we use some of the ideas without any tooling tweaks needed?
* Would we apply these ideas to extension methods (as per above) or
non-extension methods, or both?
* Do we need to adapt DocGenerator to better support these ideas?
* Do we need to adapt Groovydoc to better support these ideas?
* For some classes we arrange methods in alphabetical order. We'd possibly have
to re-order to be alphabetical within the regions. Would we be happy with this?
--
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=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)
