[jira] [Closed] (GROOVY-11354) Bump javaparser to 3.25.10
[ https://issues.apache.org/jira/browse/GROOVY-11354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun closed GROOVY-11354. --- Fix Version/s: 5.0.0-alpha-8 4.0.21 Assignee: Daniel Sun Resolution: Fixed > Bump javaparser to 3.25.10 > -- > > Key: GROOVY-11354 > URL: https://issues.apache.org/jira/browse/GROOVY-11354 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 5.0.0-alpha-8, 4.0.21 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11354) Bump javaparser to 3.25.10
Daniel Sun created GROOVY-11354: --- Summary: Bump javaparser to 3.25.10 Key: GROOVY-11354 URL: https://issues.apache.org/jira/browse/GROOVY-11354 Project: Groovy Issue Type: Dependency upgrade Reporter: Daniel Sun -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11347) Support JDK 23
[ https://issues.apache.org/jira/browse/GROOVY-11347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun resolved GROOVY-11347. - Fix Version/s: 5.0.0-alpha-8 Assignee: Paul King Resolution: Fixed > Support JDK 23 > -- > > Key: GROOVY-11347 > URL: https://issues.apache.org/jira/browse/GROOVY-11347 > Project: Groovy > Issue Type: Improvement >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-8 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GROOVY-11337) Bump asciidoctorj-diagram to 2.3.0
[ https://issues.apache.org/jira/browse/GROOVY-11337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun reassigned GROOVY-11337: --- Assignee: Paul King (was: Daniel Sun) > Bump asciidoctorj-diagram to 2.3.0 > -- > > Key: GROOVY-11337 > URL: https://issues.apache.org/jira/browse/GROOVY-11337 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-8 > > Attachments: image-2024-03-11-06-06-04-300.png, > image-2024-03-11-06-07-12-504.png, image-2024-03-11-20-23-46-948.png > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11337) Bump asciidoctorj-diagram to 2.3.0
[ https://issues.apache.org/jira/browse/GROOVY-11337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun resolved GROOVY-11337. - Fix Version/s: 5.0.0-alpha-7 Assignee: Daniel Sun Resolution: Fixed > Bump asciidoctorj-diagram to 2.3.0 > -- > > Key: GROOVY-11337 > URL: https://issues.apache.org/jira/browse/GROOVY-11337 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 5.0.0-alpha-7 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11338) Bump asciidoctorj-pdf to 2.3.14
[ https://issues.apache.org/jira/browse/GROOVY-11338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun resolved GROOVY-11338. - Fix Version/s: 5.0.0-alpha-7 Assignee: Daniel Sun Resolution: Fixed > Bump asciidoctorj-pdf to 2.3.14 > --- > > Key: GROOVY-11338 > URL: https://issues.apache.org/jira/browse/GROOVY-11338 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 5.0.0-alpha-7 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11338) Bump asciidoctorj-pdf to 2.3.14
Daniel Sun created GROOVY-11338: --- Summary: Bump asciidoctorj-pdf to 2.3.14 Key: GROOVY-11338 URL: https://issues.apache.org/jira/browse/GROOVY-11338 Project: Groovy Issue Type: Dependency upgrade Reporter: Daniel Sun -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11337) Bump asciidoctorj-diagram to 2.3.0
Daniel Sun created GROOVY-11337: --- Summary: Bump asciidoctorj-diagram to 2.3.0 Key: GROOVY-11337 URL: https://issues.apache.org/jira/browse/GROOVY-11337 Project: Groovy Issue Type: Dependency upgrade Reporter: Daniel Sun -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11324) Bump qdox to 2.1.0
[ https://issues.apache.org/jira/browse/GROOVY-11324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun resolved GROOVY-11324. - Fix Version/s: 5.0.0-alpha-6 Assignee: Daniel Sun Resolution: Fixed > Bump qdox to 2.1.0 > -- > > Key: GROOVY-11324 > URL: https://issues.apache.org/jira/browse/GROOVY-11324 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 5.0.0-alpha-6 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11324) Bump qdox to 2.1.0
Daniel Sun created GROOVY-11324: --- Summary: Bump qdox to 2.1.0 Key: GROOVY-11324 URL: https://issues.apache.org/jira/browse/GROOVY-11324 Project: Groovy Issue Type: Dependency upgrade Reporter: Daniel Sun -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11292) Class without sealed parent cannot be non-sealed
[
https://issues.apache.org/jira/browse/GROOVY-11292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-11292:
Description:
{code:java}
A (java, sealed)
^
|
B (java, non-sealed)
^
|
C (groovy)
{code}
Error "cannot be non-sealed as it has no sealed parent" will occur while
compiling the class {{{}C{}}}.
Java 19+ build fails because of the bug:
{code:java}
startup failed:
/home/daniel/IdeaProjects/groovy/src/test/org/codehaus/groovy/util/ReferenceManagerTest.groovy:
147: The class 'org.codehaus.groovy.util.ReferenceManagerTest$TestReference'
cannot be non-sealed as it has no sealed parent.
@ line 147, column 13.
private class TestReference
^
1 error
> Task :compileTestGroovy FAILED
{code}
Java 19+ declares {{java.lang.ref.Reference}} {{{}sealed{}}}.
was:
{code:java}
A (sealed)
^
|
B (non-sealed)
^
|
C (groovy)
{code}
Error "cannot be non-sealed as it has no sealed parent" will occur while
compiling the class {{C}}.
Java 19+ build fails because of the bug:
{code:java}
startup failed:
/home/daniel/IdeaProjects/groovy/src/test/org/codehaus/groovy/util/ReferenceManagerTest.groovy:
147: The class 'org.codehaus.groovy.util.ReferenceManagerTest$TestReference'
cannot be non-sealed as it has no sealed parent.
@ line 147, column 13.
private class TestReference
^
1 error
> Task :compileTestGroovy FAILED
{code}
Java 19+ declares \{{java.lang.ref.Reference}} \{{sealed}}.
> Class without sealed parent cannot be non-sealed
>
>
> Key: GROOVY-11292
> URL: https://issues.apache.org/jira/browse/GROOVY-11292
> Project: Groovy
> Issue Type: Bug
>Reporter: Daniel Sun
>Priority: Major
>
> {code:java}
> A (java, sealed)
> ^
> |
> B (java, non-sealed)
> ^
> |
> C (groovy)
> {code}
> Error "cannot be non-sealed as it has no sealed parent" will occur while
> compiling the class {{{}C{}}}.
> Java 19+ build fails because of the bug:
> {code:java}
> startup failed:
> /home/daniel/IdeaProjects/groovy/src/test/org/codehaus/groovy/util/ReferenceManagerTest.groovy:
> 147: The class 'org.codehaus.groovy.util.ReferenceManagerTest$TestReference'
> cannot be non-sealed as it has no sealed parent.
> @ line 147, column 13.
>private class TestReference
>^
> 1 error
> > Task :compileTestGroovy FAILED
> {code}
> Java 19+ declares {{java.lang.ref.Reference}} {{{}sealed{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11292) Class without sealed parent cannot be non-sealed
[
https://issues.apache.org/jira/browse/GROOVY-11292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-11292:
Description:
{code:java}
A (sealed)
^
|
B (non-sealed)
^
|
C (groovy)
{code}
Error "cannot be non-sealed as it has no sealed parent" will occur while
compiling the class {{C}}.
Java 19+ build fails because of the bug:
{code:java}
startup failed:
/home/daniel/IdeaProjects/groovy/src/test/org/codehaus/groovy/util/ReferenceManagerTest.groovy:
147: The class 'org.codehaus.groovy.util.ReferenceManagerTest$TestReference'
cannot be non-sealed as it has no sealed parent.
@ line 147, column 13.
private class TestReference
^
1 error
> Task :compileTestGroovy FAILED
{code}
Java 19+ declares \{{java.lang.ref.Reference}} \{{sealed}}.
was:
Java 19+ build fails because of "cannot be non-sealed as it has no sealed
parent" emitted by Groovy compiler.
{code:java}
startup failed:
/home/daniel/IdeaProjects/groovy/src/test/org/codehaus/groovy/util/ReferenceManagerTest.groovy:
147: The class 'org.codehaus.groovy.util.ReferenceManagerTest$TestReference'
cannot be non-sealed as it has no sealed parent.
@ line 147, column 13.
private class TestReference
^
1 error
> Task :compileTestGroovy FAILED
{code}
Java 19+ declares \{{java.lang.ref.Reference}} \{{sealed}}.
> Class without sealed parent cannot be non-sealed
>
>
> Key: GROOVY-11292
> URL: https://issues.apache.org/jira/browse/GROOVY-11292
> Project: Groovy
> Issue Type: Bug
>Reporter: Daniel Sun
>Priority: Major
>
> {code:java}
> A (sealed)
> ^
> |
> B (non-sealed)
> ^
> |
> C (groovy)
> {code}
> Error "cannot be non-sealed as it has no sealed parent" will occur while
> compiling the class {{C}}.
> Java 19+ build fails because of the bug:
> {code:java}
> startup failed:
> /home/daniel/IdeaProjects/groovy/src/test/org/codehaus/groovy/util/ReferenceManagerTest.groovy:
> 147: The class 'org.codehaus.groovy.util.ReferenceManagerTest$TestReference'
> cannot be non-sealed as it has no sealed parent.
> @ line 147, column 13.
>private class TestReference
>^
> 1 error
> > Task :compileTestGroovy FAILED
> {code}
> Java 19+ declares \{{java.lang.ref.Reference}} \{{sealed}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11292) Class without sealed parent cannot be non-sealed
[
https://issues.apache.org/jira/browse/GROOVY-11292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-11292:
Description:
Java 19+ build fails because of "cannot be non-sealed as it has no sealed
parent" emitted by Groovy compiler.
{code:java}
startup failed:
/home/daniel/IdeaProjects/groovy/src/test/org/codehaus/groovy/util/ReferenceManagerTest.groovy:
147: The class 'org.codehaus.groovy.util.ReferenceManagerTest$TestReference'
cannot be non-sealed as it has no sealed parent.
@ line 147, column 13.
private class TestReference
^
1 error
> Task :compileTestGroovy FAILED
{code}
Java 19+ declares \{{java.lang.ref.Reference}} \{{sealed}}.
was:
"cannot be non-sealed as it has no sealed parent" is emitted by Groovy compiler
and just emitted when using Java 19+, because Java 19+ declares
\{{java.lang.ref.Reference}} \{{sealed}}.
{code:java}
startup failed:
/home/daniel/IdeaProjects/groovy/src/test/org/codehaus/groovy/util/ReferenceManagerTest.groovy:
147: The class 'org.codehaus.groovy.util.ReferenceManagerTest$TestReference'
cannot be non-sealed as it has no sealed parent.
@ line 147, column 13.
private class TestReference
^
1 error
> Task :compileTestGroovy FAILED
{code}
> Class without sealed parent cannot be non-sealed
>
>
> Key: GROOVY-11292
> URL: https://issues.apache.org/jira/browse/GROOVY-11292
> Project: Groovy
> Issue Type: Bug
>Reporter: Daniel Sun
>Priority: Major
>
> Java 19+ build fails because of "cannot be non-sealed as it has no sealed
> parent" emitted by Groovy compiler.
> {code:java}
> startup failed:
> /home/daniel/IdeaProjects/groovy/src/test/org/codehaus/groovy/util/ReferenceManagerTest.groovy:
> 147: The class 'org.codehaus.groovy.util.ReferenceManagerTest$TestReference'
> cannot be non-sealed as it has no sealed parent.
> @ line 147, column 13.
>private class TestReference
>^
> 1 error
> > Task :compileTestGroovy FAILED
> {code}
> Java 19+ declares \{{java.lang.ref.Reference}} \{{sealed}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11292) Class without sealed parent cannot be non-sealed
[
https://issues.apache.org/jira/browse/GROOVY-11292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-11292:
Description:
"cannot be non-sealed as it has no sealed parent" is emitted by Groovy compiler
and just emitted when using Java 19+, because Java 19+ declares
\{{java.lang.ref.Reference}} \{{sealed}}.
{code:java}
startup failed:
/home/daniel/IdeaProjects/groovy/src/test/org/codehaus/groovy/util/ReferenceManagerTest.groovy:
147: The class 'org.codehaus.groovy.util.ReferenceManagerTest$TestReference'
cannot be non-sealed as it has no sealed parent.
@ line 147, column 13.
private class TestReference
^
1 error
> Task :compileTestGroovy FAILED
{code}
was:
"cannot be non-sealed as it has no sealed parent" is emitted by Groovy compiler
and just emitted when using Java 21, because Java 21 declares
\{{java.lang.ref.Reference}} \{{sealed}}.
{code:java}
startup failed:
/home/daniel/IdeaProjects/groovy/src/test/org/codehaus/groovy/util/ReferenceManagerTest.groovy:
147: The class 'org.codehaus.groovy.util.ReferenceManagerTest$TestReference'
cannot be non-sealed as it has no sealed parent.
@ line 147, column 13.
private class TestReference
^
1 error
> Task :compileTestGroovy FAILED
{code}
> Class without sealed parent cannot be non-sealed
>
>
> Key: GROOVY-11292
> URL: https://issues.apache.org/jira/browse/GROOVY-11292
> Project: Groovy
> Issue Type: Bug
>Reporter: Daniel Sun
>Priority: Major
>
> "cannot be non-sealed as it has no sealed parent" is emitted by Groovy
> compiler and just emitted when using Java 19+, because Java 19+ declares
> \{{java.lang.ref.Reference}} \{{sealed}}.
> {code:java}
> startup failed:
> /home/daniel/IdeaProjects/groovy/src/test/org/codehaus/groovy/util/ReferenceManagerTest.groovy:
> 147: The class 'org.codehaus.groovy.util.ReferenceManagerTest$TestReference'
> cannot be non-sealed as it has no sealed parent.
> @ line 147, column 13.
>private class TestReference
>^
> 1 error
> > Task :compileTestGroovy FAILED
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-11293) Error "BUG! At this point argument array length and parameter array length should be the same"
[
https://issues.apache.org/jira/browse/GROOVY-11293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809103#comment-17809103
]
Daniel Sun edited comment on GROOVY-11293 at 1/21/24 11:52 AM:
---
The minimal reproducer works well on my local machine, I added a test:
*branch 4_0_X:*
[https://github.com/apache/groovy/commit/735a32922537c6822d0d3adc633f3bc910bdf169]
{*}master, i.e. 5{*}{*}_0_X{*}{*}:{*}
[https://github.com/apache/groovy/commit/6b8915fbd1ab898bb590caf27bfdd05d3296e7cb]
was (Author: daniel_sun):
The minimal reproducer works well on my local machine, I added a test:
*branch 4_0_X:*
[https://github.com/apache/groovy/commit/735a32922537c6822d0d3adc633f3bc910bdf169]
*master:*
[https://github.com/apache/groovy/commit/6b8915fbd1ab898bb590caf27bfdd05d3296e7cb]
> Error "BUG! At this point argument array length and parameter array length
> should be the same"
> --
>
> Key: GROOVY-11293
> URL: https://issues.apache.org/jira/browse/GROOVY-11293
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.4, 4.0.16, 4.0.18
>Reporter: Alexander Kriegisch
>Priority: Major
>
> When I compile and run this Spock 2.3-groovy-4.0 test on JDK 17 (build target
> 8), it works fine:
> {code:groovy}
> import com.github.marschall.memoryfilesystem.MemoryFileSystemBuilder
> import com.google.common.jimfs.Configuration
> import com.google.common.jimfs.Jimfs
> import spock.lang.Specification
> import spock.lang.Unroll
> import java.nio.file.FileSystems
> import java.nio.file.Files
> @Grab('com.google.jimfs:jimfs:1.3.0')
> @Grab('com.github.marschall:memoryfilesystem:2.8.0')
> class NestedZipTest extends Specification {
> @Unroll('#scenario')
> def 'create nested zip file'() {
> given: 'a text file on the default FS'
> def sourceFS = MemoryFileSystemBuilder.newEmpty().build()
> def rootTxtPath = sourceFS.getPath('root.txt')
> Files.write(rootTxtPath, 'Hello root!'.bytes)
> when: 'creating a zip FS on the target FS, adding two text files'
> def outerZipPath = targetFS.getPath('outer.zip')
> if (Files.exists(outerZipPath))
> Files.delete(outerZipPath)
> def outerZipFS = FileSystems.newFileSystem(outerZipPath, [create: 'true'])
> Files.write(outerZipFS.getPath('outer.txt'), 'Hello outer!'.bytes)
> Files.copy(rootTxtPath, outerZipFS.getPath('from-root.txt'))
> and: 'creating a zip FS inside the outer zip file, adding two text files'
> def innerZipPath = outerZipFS.getPath('inner.zip')
> def innerZipFS = FileSystems.newFileSystem(innerZipPath, [create: 'true'])
> Files.write(innerZipFS.getPath('inner.txt'), 'Hello inner!'.bytes)
> Files.copy(rootTxtPath, innerZipFS.getPath('from-root.txt'))
> and: 'creating a zip FS inside the inner zip file, adding two text files'
> def inner2ZipPath = innerZipFS.getPath('inner2.zip')
> def inner2ZipFS = FileSystems.newFileSystem(inner2ZipPath, [create:
> 'true'])
> Files.write(inner2ZipFS.getPath('inner2.txt'), 'Hello inner2!'.bytes)
> Files.copy(rootTxtPath, inner2ZipFS.getPath('from-root.txt'))
> then: 'no errors occur'
> noExceptionThrown()
> cleanup:
> inner2ZipFS?.close()
> innerZipFS?.close()
> outerZipFS?.close()
> where:
> scenario | targetFS
> 'on disk' | FileSystems.default
> 'JimFS'|
> Jimfs.newFileSystem(Configuration.unix().toBuilder().setWorkingDirectory('/').build())
> 'MemoryFileSystem' | MemoryFileSystemBuilder.newEmpty().build()
> }
> }
> {code}
> Try it in the [Groovy Web
> Console|https://gwc-experiment.appspot.com/?g=groovy_4_0=eNqdVVFv0zAQfs-vOMSDU2kYCC-oEmICNhASCKlDSCAeXOeSenPsyHZoC-y_4zhpnXSZ1tKHyD3ffXffd9adqGptHHBd0VK4VbOkFTOWr5iUtMJKm20hJNqtdVjRT8Fw6Q2LYHjTCJmjScQAROtSIvXHSit6LarC0rdaFaJsDHNCq4ecP7bfnZOtNb-hkqmSLmrkohB8BDK4_6qMljLZ3VyzX4wqoWlbPo0l2_sdbJKcvzdsmZJBbaGoefd9Tl_QZ2Q28jrQbH6o2TyjL0MQl8xa-IzemH8X9ZU_AG4cqtzCiBv8SQDOOzopeWw5KmaE9hAAORZAuEHmEFSAgt-ihjYdSWchEqAUv1DNgTBwPkG4BA_rVtjGs0Y6uFyQ4NriWd0YjpcLeAX39JcqXF9UtdumM7psTelsH220dlcb94W5lQfYYdESgykl7T11G0e6kKAzXRvhMB2EngH5gFLqAPeI0OXWoZ0lIWS9CmwCa6FKYIGyr7fn5Jjx2bzhDFietx5urSN1G5nqxqHx2vfFdoHDYoMD9fB9taKAtKsYN8I6mw4RZp3PjlOOEj2pkcedzEHlwWNslY1_R8Fn8KNrtOfuTIPk510FI-whh6D4XtVgi7JGGK7r7bgPU5CF0dWT2Mi-L0zlk20RyoocQ2sC2P6FPtgfodSwP1OlBJdBh4ZhD4g7RD9G3Ah7mH4sbrAdJ-4U5H-LG8BOFDeL6t5LL5uSNztS3-xUgbPpEiYkzk7QODtKZNdNFqUBjdHGgua8MZ1kSl9sONbtQL5aGb1WaR_EJTLV1PNuQMRkrymX2mI_GqO6Y3t809G-m3IGO9DdxIf4-7sfVsGD-NGXC3tDhh7DzvRzvnP2G9XPexjBhS170MDRmqaNEhs_753ul4A_W3TftLnxr-ydMMid3xUpeUr2S6GjSA63CPH5Ttost8lt8g9XIuDH].
> You can also comment out the test iterations for JimFS and MemoryFileSystem
> in the {{where}} blocks, if you want to test without external dependencies.
> When running
[jira] [Commented] (GROOVY-11293) Error "BUG! At this point argument array length and parameter array length should be the same"
[
https://issues.apache.org/jira/browse/GROOVY-11293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809103#comment-17809103
]
Daniel Sun commented on GROOVY-11293:
-
The minimal reproducer works well on my local machine, I added a test:
*branch 4_0_X:*
[https://github.com/apache/groovy/commit/735a32922537c6822d0d3adc633f3bc910bdf169]
*master:*
[https://github.com/apache/groovy/commit/6b8915fbd1ab898bb590caf27bfdd05d3296e7cb]
> Error "BUG! At this point argument array length and parameter array length
> should be the same"
> --
>
> Key: GROOVY-11293
> URL: https://issues.apache.org/jira/browse/GROOVY-11293
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.4, 4.0.16, 4.0.18
>Reporter: Alexander Kriegisch
>Priority: Major
>
> When I compile and run this Spock 2.3-groovy-4.0 test on JDK 17 (build target
> 8), it works fine:
> {code:groovy}
> import com.github.marschall.memoryfilesystem.MemoryFileSystemBuilder
> import com.google.common.jimfs.Configuration
> import com.google.common.jimfs.Jimfs
> import spock.lang.Specification
> import spock.lang.Unroll
> import java.nio.file.FileSystems
> import java.nio.file.Files
> @Grab('com.google.jimfs:jimfs:1.3.0')
> @Grab('com.github.marschall:memoryfilesystem:2.8.0')
> class NestedZipTest extends Specification {
> @Unroll('#scenario')
> def 'create nested zip file'() {
> given: 'a text file on the default FS'
> def sourceFS = MemoryFileSystemBuilder.newEmpty().build()
> def rootTxtPath = sourceFS.getPath('root.txt')
> Files.write(rootTxtPath, 'Hello root!'.bytes)
> when: 'creating a zip FS on the target FS, adding two text files'
> def outerZipPath = targetFS.getPath('outer.zip')
> if (Files.exists(outerZipPath))
> Files.delete(outerZipPath)
> def outerZipFS = FileSystems.newFileSystem(outerZipPath, [create: 'true'])
> Files.write(outerZipFS.getPath('outer.txt'), 'Hello outer!'.bytes)
> Files.copy(rootTxtPath, outerZipFS.getPath('from-root.txt'))
> and: 'creating a zip FS inside the outer zip file, adding two text files'
> def innerZipPath = outerZipFS.getPath('inner.zip')
> def innerZipFS = FileSystems.newFileSystem(innerZipPath, [create: 'true'])
> Files.write(innerZipFS.getPath('inner.txt'), 'Hello inner!'.bytes)
> Files.copy(rootTxtPath, innerZipFS.getPath('from-root.txt'))
> and: 'creating a zip FS inside the inner zip file, adding two text files'
> def inner2ZipPath = innerZipFS.getPath('inner2.zip')
> def inner2ZipFS = FileSystems.newFileSystem(inner2ZipPath, [create:
> 'true'])
> Files.write(inner2ZipFS.getPath('inner2.txt'), 'Hello inner2!'.bytes)
> Files.copy(rootTxtPath, inner2ZipFS.getPath('from-root.txt'))
> then: 'no errors occur'
> noExceptionThrown()
> cleanup:
> inner2ZipFS?.close()
> innerZipFS?.close()
> outerZipFS?.close()
> where:
> scenario | targetFS
> 'on disk' | FileSystems.default
> 'JimFS'|
> Jimfs.newFileSystem(Configuration.unix().toBuilder().setWorkingDirectory('/').build())
> 'MemoryFileSystem' | MemoryFileSystemBuilder.newEmpty().build()
> }
> }
> {code}
> Try it in the [Groovy Web
> Console|https://gwc-experiment.appspot.com/?g=groovy_4_0=eNqdVVFv0zAQfs-vOMSDU2kYCC-oEmICNhASCKlDSCAeXOeSenPsyHZoC-y_4zhpnXSZ1tKHyD3ffXffd9adqGptHHBd0VK4VbOkFTOWr5iUtMJKm20hJNqtdVjRT8Fw6Q2LYHjTCJmjScQAROtSIvXHSit6LarC0rdaFaJsDHNCq4ecP7bfnZOtNb-hkqmSLmrkohB8BDK4_6qMljLZ3VyzX4wqoWlbPo0l2_sdbJKcvzdsmZJBbaGoefd9Tl_QZ2Q28jrQbH6o2TyjL0MQl8xa-IzemH8X9ZU_AG4cqtzCiBv8SQDOOzopeWw5KmaE9hAAORZAuEHmEFSAgt-ihjYdSWchEqAUv1DNgTBwPkG4BA_rVtjGs0Y6uFyQ4NriWd0YjpcLeAX39JcqXF9UtdumM7psTelsH220dlcb94W5lQfYYdESgykl7T11G0e6kKAzXRvhMB2EngH5gFLqAPeI0OXWoZ0lIWS9CmwCa6FKYIGyr7fn5Jjx2bzhDFietx5urSN1G5nqxqHx2vfFdoHDYoMD9fB9taKAtKsYN8I6mw4RZp3PjlOOEj2pkcedzEHlwWNslY1_R8Fn8KNrtOfuTIPk510FI-whh6D4XtVgi7JGGK7r7bgPU5CF0dWT2Mi-L0zlk20RyoocQ2sC2P6FPtgfodSwP1OlBJdBh4ZhD4g7RD9G3Ah7mH4sbrAdJ-4U5H-LG8BOFDeL6t5LL5uSNztS3-xUgbPpEiYkzk7QODtKZNdNFqUBjdHGgua8MZ1kSl9sONbtQL5aGb1WaR_EJTLV1PNuQMRkrymX2mI_GqO6Y3t809G-m3IGO9DdxIf4-7sfVsGD-NGXC3tDhh7DzvRzvnP2G9XPexjBhS170MDRmqaNEhs_753ul4A_W3TftLnxr-ydMMid3xUpeUr2S6GjSA63CPH5Ttost8lt8g9XIuDH].
> You can also comment out the test iterations for JimFS and MemoryFileSystem
> in the {{where}} blocks, if you want to test without external dependencies.
> When running the same code on JDK 8, there is a {{MissingMethodException}},
> which is fine, because some JDK API I am calling only exists since JDK 13.
> I.e., I expect the {{MissingMethodException}} on JDKs 8-12 and a working test
> on 13+.
> What happens instead is that on JDKs 9-16, I see: *"BUG! At this point
> argument array length and parameter array length should be the
[jira] [Updated] (GROOVY-11292) Class without sealed parent cannot be non-sealed
[
https://issues.apache.org/jira/browse/GROOVY-11292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-11292:
Issue Type: Bug (was: Improvement)
> Class without sealed parent cannot be non-sealed
>
>
> Key: GROOVY-11292
> URL: https://issues.apache.org/jira/browse/GROOVY-11292
> Project: Groovy
> Issue Type: Bug
>Reporter: Daniel Sun
>Priority: Major
>
> "cannot be non-sealed as it has no sealed parent" is emitted by Groovy
> compiler and just emitted when using Java 21, because Java 21 declares
> \{{java.lang.ref.Reference}} \{{sealed}}.
> {code:java}
> startup failed:
> /home/daniel/IdeaProjects/groovy/src/test/org/codehaus/groovy/util/ReferenceManagerTest.groovy:
> 147: The class 'org.codehaus.groovy.util.ReferenceManagerTest$TestReference'
> cannot be non-sealed as it has no sealed parent.
> @ line 147, column 13.
>private class TestReference
>^
> 1 error
> > Task :compileTestGroovy FAILED
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11292) Class without sealed parent cannot be non-sealed
[
https://issues.apache.org/jira/browse/GROOVY-11292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-11292:
Description:
"cannot be non-sealed as it has no sealed parent" is emitted by Groovy compiler
and just emitted when using Java 21, because Java 21 declares
\{{java.lang.ref.Reference}} \{{sealed}}.
{code:java}
startup failed:
/home/daniel/IdeaProjects/groovy/src/test/org/codehaus/groovy/util/ReferenceManagerTest.groovy:
147: The class 'org.codehaus.groovy.util.ReferenceManagerTest$TestReference'
cannot be non-sealed as it has no sealed parent.
@ line 147, column 13.
private class TestReference
^
1 error
> Task :compileTestGroovy FAILED
{code}
was:
"cannot be non-sealed as it has no sealed parent" is emitted by Groovy compiler
and just emitted when using Java 21+
{code:java}
startup failed:
/home/daniel/IdeaProjects/groovy/src/test/org/codehaus/groovy/util/ReferenceManagerTest.groovy:
147: The class 'org.codehaus.groovy.util.ReferenceManagerTest$TestReference'
cannot be non-sealed as it has no sealed parent.
@ line 147, column 13.
private class TestReference
^
1 error
> Task :compileTestGroovy FAILED
{code}
> Class without sealed parent cannot be non-sealed
>
>
> Key: GROOVY-11292
> URL: https://issues.apache.org/jira/browse/GROOVY-11292
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Priority: Major
>
> "cannot be non-sealed as it has no sealed parent" is emitted by Groovy
> compiler and just emitted when using Java 21, because Java 21 declares
> \{{java.lang.ref.Reference}} \{{sealed}}.
> {code:java}
> startup failed:
> /home/daniel/IdeaProjects/groovy/src/test/org/codehaus/groovy/util/ReferenceManagerTest.groovy:
> 147: The class 'org.codehaus.groovy.util.ReferenceManagerTest$TestReference'
> cannot be non-sealed as it has no sealed parent.
> @ line 147, column 13.
>private class TestReference
>^
> 1 error
> > Task :compileTestGroovy FAILED
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11292) Class without sealed parent cannot be non-sealed
[
https://issues.apache.org/jira/browse/GROOVY-11292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-11292:
Description:
"cannot be non-sealed as it has no sealed parent" is emitted by Groovy compiler
and just emitted when using Java 21+
{code:java}
startup failed:
/home/daniel/IdeaProjects/groovy/src/test/org/codehaus/groovy/util/ReferenceManagerTest.groovy:
147: The class 'org.codehaus.groovy.util.ReferenceManagerTest$TestReference'
cannot be non-sealed as it has no sealed parent.
@ line 147, column 13.
private class TestReference
^
1 error
> Task :compileTestGroovy FAILED
{code}
was:
Java 21 has more strict check for {{non-sealed}} classes, i.e. class cannot be
non-sealed if it has no sealed parent. We have to align with check rule of Java
21, and declare class {{non-sealed}} by default if and only if it has
{{sealed}} parent.
Before the proposed improvement, {{TestReference}} will be declared
{{non-sealed}} by default, but its parent {{SoftReference}} is {{non-sealed}}
and {{SoftReference}}'s parent {{Reference}} is {{sealed}}, so Java 21 will
emit the following error:
{code:java}
startup failed:
/home/daniel/IdeaProjects/groovy/src/test/org/codehaus/groovy/util/ReferenceManagerTest.groovy:
147: The class 'org.codehaus.groovy.util.ReferenceManagerTest$TestReference'
cannot be non-sealed as it has no sealed parent.
@ line 147, column 13.
private class TestReference
^
1 error
> Task :compileTestGroovy FAILED
{code}
> Class without sealed parent cannot be non-sealed
>
>
> Key: GROOVY-11292
> URL: https://issues.apache.org/jira/browse/GROOVY-11292
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Priority: Major
>
> "cannot be non-sealed as it has no sealed parent" is emitted by Groovy
> compiler and just emitted when using Java 21+
> {code:java}
> startup failed:
> /home/daniel/IdeaProjects/groovy/src/test/org/codehaus/groovy/util/ReferenceManagerTest.groovy:
> 147: The class 'org.codehaus.groovy.util.ReferenceManagerTest$TestReference'
> cannot be non-sealed as it has no sealed parent.
> @ line 147, column 13.
>private class TestReference
>^
> 1 error
> > Task :compileTestGroovy FAILED
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GROOVY-11292) Class without sealed parent cannot be non-sealed
Daniel Sun created GROOVY-11292:
---
Summary: Class without sealed parent cannot be non-sealed
Key: GROOVY-11292
URL: https://issues.apache.org/jira/browse/GROOVY-11292
Project: Groovy
Issue Type: Improvement
Reporter: Daniel Sun
Java 21 has more strict check for {{non-sealed}} classes, i.e. class cannot be
non-sealed if it has no sealed parent. We have to align with check rule of Java
21, and declare class {{non-sealed}} by default if and only if it has
{{sealed}} parent.
Before the proposed improvement, {{TestReference}} will be declared
{{non-sealed}} by default, but its parent {{SoftReference}} is {{non-sealed}}
and {{SoftReference}}'s parent {{Reference}} is {{sealed}}, so Java 21 will
emit the following error:
{code:java}
startup failed:
/home/daniel/IdeaProjects/groovy/src/test/org/codehaus/groovy/util/ReferenceManagerTest.groovy:
147: The class 'org.codehaus.groovy.util.ReferenceManagerTest$TestReference'
cannot be non-sealed as it has no sealed parent.
@ line 147, column 13.
private class TestReference
^
1 error
> Task :compileTestGroovy FAILED
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11271) ConcurrentCommonCache causes memory leaks.
[ https://issues.apache.org/jira/browse/GROOVY-11271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun updated GROOVY-11271: Fix Version/s: 2.5.24 3.0.21 > ConcurrentCommonCache causes memory leaks. > -- > > Key: GROOVY-11271 > URL: https://issues.apache.org/jira/browse/GROOVY-11271 > Project: Groovy > Issue Type: Bug > Components: ast builder >Affects Versions: 4.0.7 >Reporter: cong yang >Assignee: Daniel Sun >Priority: Critical > Fix For: 2.5.24, 4.0.18, 3.0.21 > > > ConcurrentCommonCache uses a read-write lock to wrap CommonCache into a > thread-safe data structure. However, CommonCache uses the underlying > LinkedHashMap, which causes conflicts when using the LRU algorithm because > the LinkedHashMap.get method modifies the internal linked list. This > conflicts with the read lock used by the get method in ConcurrentCommonCache > when multiple threads access it. Due to multithreading conflicts, the maximum > cache size of 64 becomes ineffective, ultimately causing memory leaks. > Additionally, we have already encountered memory leaks in our production > environment. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11271) ConcurrentCommonCache causes memory leaks.
[ https://issues.apache.org/jira/browse/GROOVY-11271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun resolved GROOVY-11271. - Fix Version/s: 4.0.18 Assignee: Daniel Sun Resolution: Fixed > ConcurrentCommonCache causes memory leaks. > -- > > Key: GROOVY-11271 > URL: https://issues.apache.org/jira/browse/GROOVY-11271 > Project: Groovy > Issue Type: Bug > Components: ast builder >Affects Versions: 4.0.7 >Reporter: cong yang >Assignee: Daniel Sun >Priority: Critical > Fix For: 4.0.18 > > > ConcurrentCommonCache uses a read-write lock to wrap CommonCache into a > thread-safe data structure. However, CommonCache uses the underlying > LinkedHashMap, which causes conflicts when using the LRU algorithm because > the LinkedHashMap.get method modifies the internal linked list. This > conflicts with the read lock used by the get method in ConcurrentCommonCache > when multiple threads access it. Due to multithreading conflicts, the maximum > cache size of 64 becomes ineffective, ultimately causing memory leaks. > Additionally, we have already encountered memory leaks in our production > environment. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11272) Generate `serialVersionUID` for each closure
[
https://issues.apache.org/jira/browse/GROOVY-11272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun resolved GROOVY-11272.
-
Fix Version/s: 5.0.0-alpha-5
(was: 5.x)
Assignee: Daniel Sun
Resolution: Fixed
> Generate `serialVersionUID` for each closure
>
>
> Key: GROOVY-11272
> URL: https://issues.apache.org/jira/browse/GROOVY-11272
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 5.0.0-alpha-5
>
>
> Though {{Closure}} implements {{Serializable}}, but generated closures have
> not {{serialVersionUID}}, which may cause serialization issue, so it's better
> to generate {{serialVersionUID}} field for each closure.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11272) Generate `serialVersionUID` for each closure
[
https://issues.apache.org/jira/browse/GROOVY-11272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804410#comment-17804410
]
Daniel Sun commented on GROOVY-11272:
-
I prefer the {{serialVersionUID}} stable for a given source to changing with
each compilation.
> Generate `serialVersionUID` for each closure
>
>
> Key: GROOVY-11272
> URL: https://issues.apache.org/jira/browse/GROOVY-11272
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Priority: Major
> Fix For: 5.x
>
>
> Though {{Closure}} implements {{Serializable}}, but generated closures have
> not {{serialVersionUID}}, which may cause serialization issue, so it's better
> to generate {{serialVersionUID}} field for each closure.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-11138) Bump gradle to 8.5
[ https://issues.apache.org/jira/browse/GROOVY-11138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun resolved GROOVY-11138. - Fix Version/s: 5.0.0-alpha-5 Assignee: Daniel Sun Resolution: Fixed > Bump gradle to 8.5 > -- > > Key: GROOVY-11138 > URL: https://issues.apache.org/jira/browse/GROOVY-11138 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 5.0.0-alpha-5 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11272) Generate `serialVersionUID` for each closure
[
https://issues.apache.org/jira/browse/GROOVY-11272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804365#comment-17804365
]
Daniel Sun commented on GROOVY-11272:
-
{quote}
Closure itself provides serialVersionUID.
{quote}
True. But {{Closure}} subclasses including the generated closures can not
derive their parent class's {{serialVersionUID}}, which is {{private}}.
Here is a case to show why I propose to generate {{serialVersionUID}} for each
closure:
[https://github.com/apache/groovy/actions/runs/7303097289/job/19910219335#step:6:193]
{code:java}
Error: Exception in thread "main" java.io.InvalidClassException:
precompiled_OrgApacheGroovyAsciidoctor$_run_closure5$_closure20; local class
incompatible: stream classdesc serialVersionUID = 4477335110646737576, local
class serialVersionUID = -4624195846785189806
at
java.base/java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:597)
at
java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2051)
at
java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1898)
at
java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2224)
at
java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1733)
at
java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:509)
at
java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:467)
at java.base/java.util.ArrayList.readObject(ArrayList.java:899)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at
java.base/java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1100)
at
java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2423)
at
java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2257)
at
java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1733)
at
java.base/java.io.ObjectInputStream$FieldValues.(ObjectInputStream.java:2606)
at
java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2457)
at
java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2257)
at
java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1733)
at
java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:509)
at
java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:467)
at java.base/java.util.ArrayList.readObject(ArrayList.java:899)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at
java.base/java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1100)
at
java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2423)
at
java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2257)
at
java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1733)
at
java.base/java.io.ObjectInputStream$FieldValues.(ObjectInputStream.java:2606)
at
java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2457)
at
java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2257)
at
java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1733)
at
java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:509)
at
java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:467)
at
org.asciidoctor.gradle.remote.AsciidoctorJavaExec$_main_closure1$_closure7.doCall(AsciidoctorJavaExec.groovy:45)
at
org.asciidoctor.gradle.remote.AsciidoctorJavaExec$_main_closure1$_closure7.call(AsciidoctorJavaExec.groovy)
at
org.codehaus.groovy.runtime.IOGroovyMethods.withCloseable(IOGroovyMethods.java:1607)
at
org.asciidoctor.gradle.remote.AsciidoctorJavaExec$_main_closure1.doCall(AsciidoctorJavaExec.groovy:44)
at
org.asciidoctor.gradle.remote.AsciidoctorJavaExec$_main_closure1.call(AsciidoctorJavaExec.groovy)
at
org.codehaus.groovy.runtime.IOGroovyMethods.withStream(IOGroovyMethods.java:1184)
at
[jira] [Created] (GROOVY-11272) Generate `serialVersionUID` for each closure
Daniel Sun created GROOVY-11272:
---
Summary: Generate `serialVersionUID` for each closure
Key: GROOVY-11272
URL: https://issues.apache.org/jira/browse/GROOVY-11272
Project: Groovy
Issue Type: Improvement
Reporter: Daniel Sun
Fix For: 5.x
Though {{Closure}} implements {{Serializable}}, but generated closures have not
{{serialVersionUID}}, which may cause serialization issue, so it's better to
generate {{serialVersionUID}} field for each closure.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11271) ConcurrentCommonCache causes memory leaks.
[
https://issues.apache.org/jira/browse/GROOVY-11271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804349#comment-17804349
]
Daniel Sun commented on GROOVY-11271:
-
{quote}
This is correct, but then it is not much better than a synchronized collection
{quote}
[~blackdrag] After trading off between function and performance, I chosen the
{{ConcurrentLinkedHashMap}} instead of {{synchronized}} when LRU is enabled.
> ConcurrentCommonCache causes memory leaks.
> --
>
> Key: GROOVY-11271
> URL: https://issues.apache.org/jira/browse/GROOVY-11271
> Project: Groovy
> Issue Type: Bug
> Components: ast builder
>Affects Versions: 4.0.7
>Reporter: cong yang
>Priority: Critical
>
> ConcurrentCommonCache uses a read-write lock to wrap CommonCache into a
> thread-safe data structure. However, CommonCache uses the underlying
> LinkedHashMap, which causes conflicts when using the LRU algorithm because
> the LinkedHashMap.get method modifies the internal linked list. This
> conflicts with the read lock used by the get method in ConcurrentCommonCache
> when multiple threads access it. Due to multithreading conflicts, the maximum
> cache size of 64 becomes ineffective, ultimately causing memory leaks.
> Additionally, we have already encountered memory leaks in our production
> environment.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11271) ConcurrentCommonCache causes memory leaks.
[ https://issues.apache.org/jira/browse/GROOVY-11271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804211#comment-17804211 ] Daniel Sun commented on GROOVY-11271: - The fastest way to fix the issue is abandoning the usage of read lock and use write lock instead. > ConcurrentCommonCache causes memory leaks. > -- > > Key: GROOVY-11271 > URL: https://issues.apache.org/jira/browse/GROOVY-11271 > Project: Groovy > Issue Type: Bug > Components: ast builder >Affects Versions: 4.0.7 >Reporter: cong yang >Priority: Critical > > ConcurrentCommonCache uses a read-write lock to wrap CommonCache into a > thread-safe data structure. However, CommonCache uses the underlying > LinkedHashMap, which causes conflicts when using the LRU algorithm because > the LinkedHashMap.get method modifies the internal linked list. This > conflicts with the read lock used by the get method in ConcurrentCommonCache > when multiple threads access it. Due to multithreading conflicts, the maximum > cache size of 64 becomes ineffective, ultimately causing memory leaks. > Additionally, we have already encountered memory leaks in our production > environment. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11263) Analyze dead code
[
https://issues.apache.org/jira/browse/GROOVY-11263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-11263:
Description:
As we all know, source code is meant for developers to read, and the less
redundant code there is, the more developer-friendly it becomes, but Groovy
allows dead code after {{throw}}, {{return}}, {{break}} and {{continue}}, e.g.
{code:java}
def m() {
return
def a = 1
}
{code}
It's better to avoid such dead code.
was:
Groovy allows dead code after {{throw}}, {{return}}, {{break}} and
{{continue}}, e.g.
{code:java}
def m() {
return
def a = 1
}
{code}
It's better to avoid such dead code.
> Analyze dead code
> -
>
> Key: GROOVY-11263
> URL: https://issues.apache.org/jira/browse/GROOVY-11263
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Priority: Major
> Labels: breaking_change
> Fix For: 5.x
>
>
> As we all know, source code is meant for developers to read, and the less
> redundant code there is, the more developer-friendly it becomes, but Groovy
> allows dead code after {{throw}}, {{return}}, {{break}} and {{continue}}, e.g.
> {code:java}
> def m() {
>return
>def a = 1
> }
> {code}
> It's better to avoid such dead code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11263) Analyze dead code
[
https://issues.apache.org/jira/browse/GROOVY-11263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-11263:
Description:
Groovy allows dead code after {{throw}}, {{return}}, {{break}} and
{{continue}}, e.g.
{code:java}
def m() {
return
def a = 1
}
{code}
It's better to avoid such dead code.
was:
Groovy allows dead code after {{return}}, {{break}} and {{continue}}, e.g.
{code:java}
def m() {
return
def a = 1
}
{code}
It's better to avoid such dead code.
> Analyze dead code
> -
>
> Key: GROOVY-11263
> URL: https://issues.apache.org/jira/browse/GROOVY-11263
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Priority: Major
> Labels: breaking_change
> Fix For: 5.x
>
>
> Groovy allows dead code after {{throw}}, {{return}}, {{break}} and
> {{continue}}, e.g.
> {code:java}
> def m() {
>return
>def a = 1
> }
> {code}
> It's better to avoid such dead code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GROOVY-11264) Bump jarjar to 1.13.1
Daniel Sun created GROOVY-11264: --- Summary: Bump jarjar to 1.13.1 Key: GROOVY-11264 URL: https://issues.apache.org/jira/browse/GROOVY-11264 Project: Groovy Issue Type: Dependency upgrade Reporter: Daniel Sun -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11263) Analyze dead code
[
https://issues.apache.org/jira/browse/GROOVY-11263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-11263:
Fix Version/s: 5.x
> Analyze dead code
> -
>
> Key: GROOVY-11263
> URL: https://issues.apache.org/jira/browse/GROOVY-11263
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Priority: Major
> Labels: breaking_change
> Fix For: 5.x
>
>
> Groovy allows dead code after {{return}}, {{break}} and {{continue}}, e.g.
> {code:java}
> def m() {
>return
>def a = 1
> }
> {code}
> It's better to avoid such dead code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11263) Analyze dead code
[
https://issues.apache.org/jira/browse/GROOVY-11263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-11263:
Labels: breaking_change (was: )
> Analyze dead code
> -
>
> Key: GROOVY-11263
> URL: https://issues.apache.org/jira/browse/GROOVY-11263
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Priority: Major
> Labels: breaking_change
>
> Groovy allows dead code after {{return}}, {{break}} and {{continue}}, e.g.
> {code:java}
> def m() {
>return
>def a = 1
> }
> {code}
> It's better to avoid such dead code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11263) Analyze dead code
[
https://issues.apache.org/jira/browse/GROOVY-11263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801469#comment-17801469
]
Daniel Sun commented on GROOVY-11263:
-
[~blackdrag] We could use the following code to skip ;-)
{code:java}
if (true) return
// some other code
{code}
> Analyze dead code
> -
>
> Key: GROOVY-11263
> URL: https://issues.apache.org/jira/browse/GROOVY-11263
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Priority: Major
>
> Groovy allows dead code after {{return}}, {{break}} and {{continue}}, e.g.
> {code:java}
> def m() {
>return
>def a = 1
> }
> {code}
> It's better to avoid such dead code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11263) Analyze dead code
[
https://issues.apache.org/jira/browse/GROOVY-11263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-11263:
Description:
Groovy allows dead code after {{return}}, {{break}} and {{continue}}, e.g.
{code:java}
def m() {
return
def a = 1
}
{code}
It's better to avoid such dead code.
was:
Groovy allows dead code after {{return}}, e.g.
{code:java}
def m() {
return
def a = 1
}
{code}
It's better to avoid such dead code.
> Analyze dead code
> -
>
> Key: GROOVY-11263
> URL: https://issues.apache.org/jira/browse/GROOVY-11263
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Priority: Major
>
> Groovy allows dead code after {{return}}, {{break}} and {{continue}}, e.g.
> {code:java}
> def m() {
>return
>def a = 1
> }
> {code}
> It's better to avoid such dead code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GROOVY-11263) Analyze dead code
Daniel Sun created GROOVY-11263:
---
Summary: Analyze dead code
Key: GROOVY-11263
URL: https://issues.apache.org/jira/browse/GROOVY-11263
Project: Groovy
Issue Type: Improvement
Reporter: Daniel Sun
Groovy allows dead code after {{return}}, e.g.
{code:java}
def m() {
return
def a = 1
}
{code}
It's better to avoid such dead code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11138) Bump gradle to 8.5
[ https://issues.apache.org/jira/browse/GROOVY-11138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801449#comment-17801449 ] Daniel Sun commented on GROOVY-11138: - https://github.com/apache/groovy/commit/6e8b11fca9f956a8291e9da7dcbd675cd84db285 Waiting for the release of asciidoctor-gradle 4.0 > Bump gradle to 8.5 > -- > > Key: GROOVY-11138 > URL: https://issues.apache.org/jira/browse/GROOVY-11138 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (GROOVY-11138) Bump gradle to 8.5
[ https://issues.apache.org/jira/browse/GROOVY-11138 ]
Daniel Sun deleted comment on GROOVY-11138:
-
was (Author: daniel_sun):
https://github.com/apache/groovy/actions/runs/5701869495/job/15452991059
{code:java}
FAILURE: Build failed with an exception.
* What went wrong:
Could not determine the dependencies of task ':test'.
> Could not resolve all task dependencies for configuration
> ':testRuntimeClasspath'.
> No variants of project : match the consumer attributes:
- Configuration ':grapesRuntimeElements' variant classes declares a
library for use during runtime, compatible with Java 11, and its dependencies
declared externally:
- Incompatible because this component declares a component,
preferably in the form of class files and the consumer needed a component,
packaged as a jar
- Other compatible attributes:
- Doesn't say anything about org.apache.groovy.internal
(required 'true')
- Doesn't say anything about its target Java environment
(preferred optimized for standard JVMs)
- Configuration ':grapesRuntimeElements' variant resources declares a
library for use during runtime, compatible with Java 11, and its dependencies
declared externally:
- Incompatible because this component declares a component,
preferably only the resources files and the consumer needed a component,
packaged as a jar
- Other compatible attributes:
- Doesn't say anything about org.apache.groovy.internal
(required 'true')
- Doesn't say anything about its target Java environment
(preferred optimized for standard JVMs)
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Get more help at https://help.gradle.org.
BUILD FAILED in 1m 19s
Publishing build scan...
https://ge.apache.org/s/ukzvepmkdll6u
Error: Process completed with exit code 1.
{code}
> Bump gradle to 8.5
> --
>
> Key: GROOVY-11138
> URL: https://issues.apache.org/jira/browse/GROOVY-11138
> Project: Groovy
> Issue Type: Dependency upgrade
>Reporter: Daniel Sun
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11138) Bump gradle to 8.5
[ https://issues.apache.org/jira/browse/GROOVY-11138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun updated GROOVY-11138: Summary: Bump gradle to 8.5 (was: Bump gradle to 8.2.1) > Bump gradle to 8.5 > -- > > Key: GROOVY-11138 > URL: https://issues.apache.org/jira/browse/GROOVY-11138 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11262) Avoid processing duplicated entries within META-INF
[
https://issues.apache.org/jira/browse/GROOVY-11262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-11262:
Fix Version/s: 4.0.18
> Avoid processing duplicated entries within META-INF
> ---
>
> Key: GROOVY-11262
> URL: https://issues.apache.org/jira/browse/GROOVY-11262
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 4.0.18, 5.0.0-alpha-5
>
>
> Though only one entry is found within META-INF, e.g.
> {{{}META-INF/groovy/org.codehaus.groovy.source.Extensions{}}}, two entries
> are retrieved via {{getResources}} method.
> {code:java}
> def loader = this.class.classLoader
> def r =
> loader.getResources("META-INF/groovy/org.codehaus.groovy.source.Extensions").toList()
> println r
> {code}
> Output:
> {code:java}
> [jar:file:/D:/_DEV/Groovy/groovy-4.0.14/lib/groovy-4.0.14.jar!/META-INF/groovy/org.codehaus.groovy.source.Extensions,
>
> jar:file:/D:/_DEV/Groovy/groovy-4.0.14/lib/groovy-4.0.14.jar!/META-INF/groovy/org.codehaus.groovy.source.Extensions]
> {code}
> As a result, Groovy processes them repeatedly, which is meaningless and
> should be avoided.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-11262) Avoid processing duplicated entries within META-INF
[
https://issues.apache.org/jira/browse/GROOVY-11262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun resolved GROOVY-11262.
-
Fix Version/s: 5.0.0-alpha-5
Resolution: Fixed
> Avoid processing duplicated entries within META-INF
> ---
>
> Key: GROOVY-11262
> URL: https://issues.apache.org/jira/browse/GROOVY-11262
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 5.0.0-alpha-5
>
>
> Though only one entry is found within META-INF, e.g.
> {{{}META-INF/groovy/org.codehaus.groovy.source.Extensions{}}}, two entries
> are retrieved via {{getResources}} method.
> {code:java}
> def loader = this.class.classLoader
> def r =
> loader.getResources("META-INF/groovy/org.codehaus.groovy.source.Extensions").toList()
> println r
> {code}
> Output:
> {code:java}
> [jar:file:/D:/_DEV/Groovy/groovy-4.0.14/lib/groovy-4.0.14.jar!/META-INF/groovy/org.codehaus.groovy.source.Extensions,
>
> jar:file:/D:/_DEV/Groovy/groovy-4.0.14/lib/groovy-4.0.14.jar!/META-INF/groovy/org.codehaus.groovy.source.Extensions]
> {code}
> As a result, Groovy processes them repeatedly, which is meaningless and
> should be avoided.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11262) Avoid processing duplicated entries within META-INF
[
https://issues.apache.org/jira/browse/GROOVY-11262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-11262:
Description:
Though only one entry is found within META-INF, e.g.
{{{}META-INF/groovy/org.codehaus.groovy.source.Extensions{}}}, two entries are
retrieved via {{getResources}} method.
{code:java}
def loader = this.class.classLoader
def r =
loader.getResources("META-INF/groovy/org.codehaus.groovy.source.Extensions").toList()
println r
{code}
Output:
{code:java}
[jar:file:/D:/_DEV/Groovy/groovy-4.0.14/lib/groovy-4.0.14.jar!/META-INF/groovy/org.codehaus.groovy.source.Extensions,
jar:file:/D:/_DEV/Groovy/groovy-4.0.14/lib/groovy-4.0.14.jar!/META-INF/groovy/org.codehaus.groovy.source.Extensions]
{code}
As a result, Groovy processes them repeatedly, which is meaningless and should
be avoided.
was:
Though only one entry found within META-INF, e.g.
{{{}META-INF/groovy/org.codehaus.groovy.source.Extensions{}}}, two entries are
retrieved via {{getResources}} method.
{code:java}
def loader = this.class.classLoader
def r =
loader.getResources("META-INF/groovy/org.codehaus.groovy.source.Extensions").toList()
println r
{code}
Output:
{code:java}
[jar:file:/D:/_DEV/Groovy/groovy-4.0.14/lib/groovy-4.0.14.jar!/META-INF/groovy/org.codehaus.groovy.source.Extensions,
jar:file:/D:/_DEV/Groovy/groovy-4.0.14/lib/groovy-4.0.14.jar!/META-INF/groovy/org.codehaus.groovy.source.Extensions]
{code}
As a result, Groovy processes them repeatedly, which is meaningless and should
be avoided.
> Avoid processing duplicated entries within META-INF
> ---
>
> Key: GROOVY-11262
> URL: https://issues.apache.org/jira/browse/GROOVY-11262
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
>
> Though only one entry is found within META-INF, e.g.
> {{{}META-INF/groovy/org.codehaus.groovy.source.Extensions{}}}, two entries
> are retrieved via {{getResources}} method.
> {code:java}
> def loader = this.class.classLoader
> def r =
> loader.getResources("META-INF/groovy/org.codehaus.groovy.source.Extensions").toList()
> println r
> {code}
> Output:
> {code:java}
> [jar:file:/D:/_DEV/Groovy/groovy-4.0.14/lib/groovy-4.0.14.jar!/META-INF/groovy/org.codehaus.groovy.source.Extensions,
>
> jar:file:/D:/_DEV/Groovy/groovy-4.0.14/lib/groovy-4.0.14.jar!/META-INF/groovy/org.codehaus.groovy.source.Extensions]
> {code}
> As a result, Groovy processes them repeatedly, which is meaningless and
> should be avoided.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GROOVY-11262) Avoid processing duplicated entries within META-INF
Daniel Sun created GROOVY-11262:
---
Summary: Avoid processing duplicated entries within META-INF
Key: GROOVY-11262
URL: https://issues.apache.org/jira/browse/GROOVY-11262
Project: Groovy
Issue Type: Improvement
Reporter: Daniel Sun
Assignee: Daniel Sun
Though only one entry found within META-INF, e.g.
{{{}META-INF/groovy/org.codehaus.groovy.source.Extensions{}}}, two entries are
retrieved via {{getResources}} method.
{code:java}
def loader = this.class.classLoader
def r =
loader.getResources("META-INF/groovy/org.codehaus.groovy.source.Extensions").toList()
println r
{code}
Output:
{code:java}
[jar:file:/D:/_DEV/Groovy/groovy-4.0.14/lib/groovy-4.0.14.jar!/META-INF/groovy/org.codehaus.groovy.source.Extensions,
jar:file:/D:/_DEV/Groovy/groovy-4.0.14/lib/groovy-4.0.14.jar!/META-INF/groovy/org.codehaus.groovy.source.Extensions]
{code}
As a result, Groovy processes them repeatedly, which is meaningless and should
be avoided.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-10998) Not reporting cyclic dependency in function's type parameters
[
https://issues.apache.org/jira/browse/GROOVY-10998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun resolved GROOVY-10998.
-
Fix Version/s: 4.0.18
Assignee: Daniel Sun
Resolution: Fixed
> Not reporting cyclic dependency in function's type parameters
> -
>
> Key: GROOVY-10998
> URL: https://issues.apache.org/jira/browse/GROOVY-10998
> Project: Groovy
> Issue Type: Bug
>Reporter: Thodoris Sotiropoulos
>Assignee: Daniel Sun
>Priority: Minor
> Fix For: 4.0.18
>
>
> This is related to GROOVY-10113.
> The check for detecting cycles in type parameters is not there for
> parameterized functions.
> {code}
> class Test {
> static void test() {}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11244) Cannot define Java-like lambda inside closure
[
https://issues.apache.org/jira/browse/GROOVY-11244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798221#comment-17798221
]
Daniel Sun commented on GROOVY-11244:
-
It is an ambiguous code for parser. Adding a parentheses to the expression at
the right hand should work too.
{code:java}
import java.util.function.Function;
class Test {
void test() {
Closure clo = {
Function x = ((z) -> 1 + z);
return "f";
}
}
}
{code}
> Cannot define Java-like lambda inside closure
> -
>
> Key: GROOVY-11244
> URL: https://issues.apache.org/jira/browse/GROOVY-11244
> Project: Groovy
> Issue Type: Bug
> Components: parser-antlr4
>Reporter: Thodoris Sotiropoulos
>Priority: Minor
>
> I have the following program
> {code}
> import java.util.function.Function;
> class Test {
> void test() {
> Closure clo = {
> Function x = (z) -> 1 + z;
> return "f";
> }
> }
> }
> {code}
> h3. Actual behavior
> {code}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> test.groovy: 6: [Static type checking] - The variable [z] is undeclared.
> @ line 6, column 49.
>eger, Integer> x = (z) -> 1 + z;
> ^
> test.groovy: 6: [Static type checking] - Cannot find matching method
> int#plus(java.lang.Object). Please check if the declared type is correct and
> if the method exists.
> @ line 6, column 45.
> x = (z) -> 1 + z;
> ^
> test.groovy: 6: [Static type checking] - The variable [z] is undeclared.
> @ line 6, column 38.
> Function x = (z) -> 1 + z;
> ^
> 3 errors
> {code}
> h3. Expected behavior
> Compile successfully
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-11243) Bump antlr to 4.13.1.3
[ https://issues.apache.org/jira/browse/GROOVY-11243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun resolved GROOVY-11243. - Resolution: Fixed > Bump antlr to 4.13.1.3 > -- > > Key: GROOVY-11243 > URL: https://issues.apache.org/jira/browse/GROOVY-11243 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 5.0.0-alpha-4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11243) Bump antlr to 4.13.1.3
Daniel Sun created GROOVY-11243: --- Summary: Bump antlr to 4.13.1.3 Key: GROOVY-11243 URL: https://issues.apache.org/jira/browse/GROOVY-11243 Project: Groovy Issue Type: Dependency upgrade Reporter: Daniel Sun Assignee: Daniel Sun Fix For: 5.0.0-alpha-4 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11240) Tweak cleanup DFA cache of parser
[
https://issues.apache.org/jira/browse/GROOVY-11240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun resolved GROOVY-11240.
-
Resolution: Fixed
> Tweak cleanup DFA cache of parser
> -
>
> Key: GROOVY-11240
> URL: https://issues.apache.org/jira/browse/GROOVY-11240
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 5.0.0-alpha-4
>
>
> We should keep the DFA cache as long as possible for better parsing
> performance, but the DFA cache may be very huge and results in OOM usually if
> we do not handle it correctly.
> Our current solution is to set a threshold to cleanup DFA cache, but the
> threshold is hard for users to evaluate for a reasonable value.
> The new solution relies on GC, if the object referenced by soft reference is
> collected by GC, we trigger the cleanup of DFA cache. We just need set the
> threshold to {{0}} to enable the smart cleanup.
> For better compatibility, we keep the existing cleanup setting as it is.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11229) Support pattern matching and destructure
[ https://issues.apache.org/jira/browse/GROOVY-11229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun updated GROOVY-11229: Description: See also: [https://openjdk.org/jeps/394] [https://openjdk.java.net/jeps/440] [https://openjdk.org/jeps/441] was:See also https://openjdk.org/jeps/394 Summary: Support pattern matching and destructure (was: Support pattern matching for `instanceof`) > Support pattern matching and destructure > > > Key: GROOVY-11229 > URL: https://issues.apache.org/jira/browse/GROOVY-11229 > Project: Groovy > Issue Type: New Feature >Reporter: Daniel Sun >Priority: Major > > See also: > [https://openjdk.org/jeps/394] > [https://openjdk.java.net/jeps/440] > [https://openjdk.org/jeps/441] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-11229) Support pattern matching for `instanceof`
[
https://issues.apache.org/jira/browse/GROOVY-11229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17791843#comment-17791843
]
Daniel Sun commented on GROOVY-11229:
-
Let me refine the ticket according to comments later, it is hard for me to edit
with my smart phone.
{{o instanceof Point(int x, int y) p}} will have a pattern variable {{p}}.
Even if Java does not support it, Groovy could support it.
As for VariableExpression, could you elaborate your suggestion by some
examples? I wonder what the AST looks like.
> Support pattern matching for `instanceof`
> -
>
> Key: GROOVY-11229
> URL: https://issues.apache.org/jira/browse/GROOVY-11229
> Project: Groovy
> Issue Type: New Feature
>Reporter: Daniel Sun
>Priority: Major
>
> See also https://openjdk.org/jeps/394
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11229) Support pattern matching for `instanceof`
[ https://issues.apache.org/jira/browse/GROOVY-11229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17791149#comment-17791149 ] Daniel Sun commented on GROOVY-11229: - It's better to support pattern matching for record and switch too for better Java compatibility. > Support pattern matching for `instanceof` > - > > Key: GROOVY-11229 > URL: https://issues.apache.org/jira/browse/GROOVY-11229 > Project: Groovy > Issue Type: New Feature >Reporter: Daniel Sun >Priority: Major > > See also https://openjdk.org/jeps/394 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11240) Tweak cleanup DFA cache of parser
[
https://issues.apache.org/jira/browse/GROOVY-11240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-11240:
Description:
We should keep the DFA cache as long as possible for better parsing
performance, but the DFA cache may be very huge and results in OOM usually if
we do not handle it correctly.
Our current solution is to set a threshold to cleanup DFA cache, but the
threshold is hard for users to evaluate for a reasonable value.
The new solution relies on GC, if the object referenced by soft reference is
collected by GC, we trigger the cleanup of DFA cache. We just need set the
threshold to {{0}} to enable the smart cleanup.
For better compatibility, we keep the existing cleanup setting as it is.
was:
We should keep the DFA cache as possible as we could for better parsing
performance, but the DFA cache may be very huge and results in OOM usually.
Our current solution is to set a threshold to cleanup DFA cache, but the
threshold is hard for users to evaluate reasonable value.
The new solution relies on GC, if the object referenced by soft reference is
collected by GC, we trigger the cleanup of DFA cache. We just need set the
threshold to {{0}} to enable the smart cleanup.
For better compatibility, we keep the existing cleanup as it is.
> Tweak cleanup DFA cache of parser
> -
>
> Key: GROOVY-11240
> URL: https://issues.apache.org/jira/browse/GROOVY-11240
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 5.0.0-alpha-4
>
>
> We should keep the DFA cache as long as possible for better parsing
> performance, but the DFA cache may be very huge and results in OOM usually if
> we do not handle it correctly.
> Our current solution is to set a threshold to cleanup DFA cache, but the
> threshold is hard for users to evaluate for a reasonable value.
> The new solution relies on GC, if the object referenced by soft reference is
> collected by GC, we trigger the cleanup of DFA cache. We just need set the
> threshold to {{0}} to enable the smart cleanup.
> For better compatibility, we keep the existing cleanup setting as it is.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11240) Tweak cleanup DFA cache of parser
[
https://issues.apache.org/jira/browse/GROOVY-11240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-11240:
Description:
We should keep the DFA cache as possible as we could for better parsing
performance, but the DFA cache may be very huge and results in OOM usually.
Our current solution is to set a threshold to cleanup DFA cache, but the
threshold is hard for users to evaluate reasonable value.
The new solution relies on GC, if the object referenced by soft reference is
collected by GC, we trigger the cleanup of DFA cache. We just need set the
threshold to {{0}} to enable the smart cleanup.
For better compatibility, we keep the existing cleanup as it is.
was:
We should keep the DFA cache as possible as we could, but the DFA cache is very
huge and results in OOM.
Our current solution is to set a threshold to cleanup DFA cache, but the
threshold is hard for users to evaluate reasonable value.
The new solution relies on GC, if the object referenced by soft reference is
collected by GC, we trigger the cleanup of DFA cache. We just need set the
threshold to {{0}} to enable the smart cleanup.
For better compatibility, we keep the existing cleanup as it is.
> Tweak cleanup DFA cache of parser
> -
>
> Key: GROOVY-11240
> URL: https://issues.apache.org/jira/browse/GROOVY-11240
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 5.0.0-alpha-4
>
>
> We should keep the DFA cache as possible as we could for better parsing
> performance, but the DFA cache may be very huge and results in OOM usually.
> Our current solution is to set a threshold to cleanup DFA cache, but the
> threshold is hard for users to evaluate reasonable value.
> The new solution relies on GC, if the object referenced by soft reference is
> collected by GC, we trigger the cleanup of DFA cache. We just need set the
> threshold to {{0}} to enable the smart cleanup.
> For better compatibility, we keep the existing cleanup as it is.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GROOVY-11240) Tweak cleanup DFA cache of parser
Daniel Sun created GROOVY-11240:
---
Summary: Tweak cleanup DFA cache of parser
Key: GROOVY-11240
URL: https://issues.apache.org/jira/browse/GROOVY-11240
Project: Groovy
Issue Type: Improvement
Reporter: Daniel Sun
Assignee: Daniel Sun
Fix For: 5.0.0-alpha-4
We should keep the DFA cache as possible as we could, but the DFA cache is very
huge and results in OOM.
Our current solution is to set a threshold to cleanup DFA cache, but the
threshold is hard for users to evaluate reasonable value.
The new solution relies on GC, if the object referenced by soft reference is
collected by GC, we trigger the cleanup of DFA cache. We just need set the
threshold to {{0}} to enable the smart cleanup.
For better compatibility, we keep the existing cleanup as it is.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-11194) groovyc missing features from the library compiler
[
https://issues.apache.org/jira/browse/GROOVY-11194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun resolved GROOVY-11194.
-
Fix Version/s: 5.0.0-alpha-3
Resolution: Fixed
> groovyc missing features from the library compiler
> --
>
> Key: GROOVY-11194
> URL: https://issues.apache.org/jira/browse/GROOVY-11194
> Project: Groovy
> Issue Type: New Feature
> Components: command line processing, Compiler
>Affects Versions: 3.0.19, 5.0.0-alpha-2, 4.0.15
>Reporter: Benjamin Marwell
>Assignee: Keegan Witt
>Priority: Critical
> Fix For: 5.0.0-alpha-3
>
>
> Hello groovy team,
> no version of the groovy distribution supports any of those features on the
> {{groovyc}} command line, which are available when invoking the groovy
> compiler via library means:
> * setDebug( boolean )
> * setVerbose( boolean )
> * setWarningLevel( int )
> * setTolerance( int )
> * invokeDynamic via optimizationOptions.put("indy", true);
> optimizationOptions.put("int", false);
> * parallel Parsing via optimizationOptions.put("parallelParse", true);
> This is important when gplus-maven-plugin shall run in fork mode. Draft PR:
> https://github.com/groovy/GMavenPlus/pull/283
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11230) ProxyGenerator creates a lot of AtomicReference instances regardless of "groovy.adapter.cache.default.size" setting
[
https://issues.apache.org/jira/browse/GROOVY-11230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787687#comment-17787687
]
Daniel Sun commented on GROOVY-11230:
-
The threads might get stuck in an infinite loop[1] if accessing {{HashMap}}
concurrently.
AFAIK, {{LinkedHashMap}} is based on {{HashMap}}, so {{LinkedHashMap}} has the
issue too.
[1] https://mailinator.blogspot.com/2009/06/beautiful-race-condition.html?m=1
> ProxyGenerator creates a lot of AtomicReference instances regardless of
> "groovy.adapter.cache.default.size" setting
> ---
>
> Key: GROOVY-11230
> URL: https://issues.apache.org/jira/browse/GROOVY-11230
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
>
> ProxyGenerator uses LRUCache which uses ConcurrentLinkedHashMap. This
> creates a 2d array of AtomicReference that is sized based on number of
> processor cores, not cache sizing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GROOVY-11229) Support pattern matching for `instanceof`
Daniel Sun created GROOVY-11229: --- Summary: Support pattern matching for `instanceof` Key: GROOVY-11229 URL: https://issues.apache.org/jira/browse/GROOVY-11229 Project: Groovy Issue Type: New Feature Reporter: Daniel Sun See also https://openjdk.org/jeps/394 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11228) Bump antlr to 4.13.1.2
[ https://issues.apache.org/jira/browse/GROOVY-11228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun resolved GROOVY-11228. - Fix Version/s: 4.0.16 Resolution: Fixed > Bump antlr to 4.13.1.2 > -- > > Key: GROOVY-11228 > URL: https://issues.apache.org/jira/browse/GROOVY-11228 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 4.0.16 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11228) Bump antlr to 4.13.1.2
Daniel Sun created GROOVY-11228: --- Summary: Bump antlr to 4.13.1.2 Key: GROOVY-11228 URL: https://issues.apache.org/jira/browse/GROOVY-11228 Project: Groovy Issue Type: Dependency upgrade Reporter: Daniel Sun Assignee: Daniel Sun -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11227) Bump antlr to 4.13.1.1
[ https://issues.apache.org/jira/browse/GROOVY-11227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun resolved GROOVY-11227. - Fix Version/s: 4.0.16 Resolution: Fixed > Bump antlr to 4.13.1.1 > -- > > Key: GROOVY-11227 > URL: https://issues.apache.org/jira/browse/GROOVY-11227 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 4.0.16 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11227) Bump antlr to 4.13.1.1
Daniel Sun created GROOVY-11227: --- Summary: Bump antlr to 4.13.1.1 Key: GROOVY-11227 URL: https://issues.apache.org/jira/browse/GROOVY-11227 Project: Groovy Issue Type: Dependency upgrade Reporter: Daniel Sun Assignee: Daniel Sun -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11183) Add `allThreads` method to `Thread`
[
https://issues.apache.org/jira/browse/GROOVY-11183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun resolved GROOVY-11183.
-
Fix Version/s: 4.0.16
Resolution: Fixed
> Add `allThreads` method to `Thread`
> ---
>
> Key: GROOVY-11183
> URL: https://issues.apache.org/jira/browse/GROOVY-11183
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 4.0.16
>
>
> {{Thread}} has `currentThread` method already, it's nice to add `allThreads`
> method to it too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GROOVY-11183) Add `allThreads` method to `Thread`
Daniel Sun created GROOVY-11183:
---
Summary: Add `allThreads` method to `Thread`
Key: GROOVY-11183
URL: https://issues.apache.org/jira/browse/GROOVY-11183
Project: Groovy
Issue Type: Improvement
Reporter: Daniel Sun
Assignee: Daniel Sun
{{Thread}} has `currentThread` method already, it's nice to add `allThreads`
method to it too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11141) Improve documentation for indy performance system properties
[
https://issues.apache.org/jira/browse/GROOVY-11141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749298#comment-17749298
]
Daniel Sun commented on GROOVY-11141:
-
{quote}
{{{}groovy.indy.callsite.cache.size{}}}, {{groovy.indy.optimize.threshold}} and
{{{}groovy.indy.fallback.threshold{}}}. I've just set all setting to
arbitrarily high values, and the performance is better
{quote}
{{groovy.indy.optimize.threshold}} and {{{}groovy.indy.fallback.threshold{}}}
should be tuned and should not to be set to high values.
> Improve documentation for indy performance system properties
>
>
> Key: GROOVY-11141
> URL: https://issues.apache.org/jira/browse/GROOVY-11141
> Project: Groovy
> Issue Type: Improvement
>Reporter: Paul King
>Priority: Major
>
> From slack:
> {quote}We have recently migrated from Groovy 3 to 4, and now have some
> performance issues, presumably because of the indy-only approach in Groovy 4.
> I have now identified some system properties, where the runtime behavior of
> the indy calls can be tweaked, namely {{groovy.indy.callsite.cache.size}},
> {{groovy.indy.optimize.threshold}} and {{groovy.indy.fallback.threshold}}.
> I've just set all setting to arbitrarily high values, and the performance is
> better. But is there a more systematic approach, how to get "good" values? A
> documentation what those parameters influence, would be very much appreciated.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748948#comment-17748948
]
Daniel Sun commented on GROOVY-10931:
-
[~emilles] I have checked the builds of master, no new illegal access warnings
surprise me so far.
Thanks for your great work!
> Remove $getLookup method generation (Groovy 4+)
> ---
>
> Key: GROOVY-10931
> URL: https://issues.apache.org/jira/browse/GROOVY-10931
> Project: Groovy
> Issue Type: Wish
> Components: class generator, Compiler
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Labels: breaking, invokedynamic, jdk16, jdk17
> Fix For: 5.0.0-alpha-1
>
>
> The new {{$getLookup()}} method was discussed somewhat in the comments of
> GROOVY-10273. Groovy 3 has had JEP 396 (illegal access enforcement) support
> backported to the invoke dynamic pathways, without {{$getLookup}}. So, I'd
> like to restart the discussion to find out if there are any illegal-access
> scenarios that Groovy 4 supports that don't have a test case in Groovy 3.
> And if there are no scenarios that remain, I'd like to propose the removal of
> {{$getLookup}} method generation.
> I have disabled its generation in the Groovy 5 codebase, and there are no
> tests that fail. So I have good confidence that it can be removed and the
> security hole can be plugged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11138) Bump gradle to 8.2.1
[
https://issues.apache.org/jira/browse/GROOVY-11138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748947#comment-17748947
]
Daniel Sun commented on GROOVY-11138:
-
https://github.com/apache/groovy/actions/runs/5701869495/job/15452991059
{code:java}
FAILURE: Build failed with an exception.
* What went wrong:
Could not determine the dependencies of task ':test'.
> Could not resolve all task dependencies for configuration
> ':testRuntimeClasspath'.
> No variants of project : match the consumer attributes:
- Configuration ':grapesRuntimeElements' variant classes declares a
library for use during runtime, compatible with Java 11, and its dependencies
declared externally:
- Incompatible because this component declares a component,
preferably in the form of class files and the consumer needed a component,
packaged as a jar
- Other compatible attributes:
- Doesn't say anything about org.apache.groovy.internal
(required 'true')
- Doesn't say anything about its target Java environment
(preferred optimized for standard JVMs)
- Configuration ':grapesRuntimeElements' variant resources declares a
library for use during runtime, compatible with Java 11, and its dependencies
declared externally:
- Incompatible because this component declares a component,
preferably only the resources files and the consumer needed a component,
packaged as a jar
- Other compatible attributes:
- Doesn't say anything about org.apache.groovy.internal
(required 'true')
- Doesn't say anything about its target Java environment
(preferred optimized for standard JVMs)
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Get more help at https://help.gradle.org.
BUILD FAILED in 1m 19s
Publishing build scan...
https://ge.apache.org/s/ukzvepmkdll6u
Error: Process completed with exit code 1.
{code}
> Bump gradle to 8.2.1
>
>
> Key: GROOVY-11138
> URL: https://issues.apache.org/jira/browse/GROOVY-11138
> Project: Groovy
> Issue Type: Dependency upgrade
>Reporter: Daniel Sun
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GROOVY-11138) Bump gradle to 8.2.1
Daniel Sun created GROOVY-11138: --- Summary: Bump gradle to 8.2.1 Key: GROOVY-11138 URL: https://issues.apache.org/jira/browse/GROOVY-11138 Project: Groovy Issue Type: Dependency upgrade Reporter: Daniel Sun -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GROOVY-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17746006#comment-17746006
]
Daniel Sun commented on GROOVY-10931:
-
Could you tell me how you make Groovy avoid illegal reflective warnings under
pre-Java16, e.g. Java11?
p.s. I tried to look over the changes of the improvement but failed to find the
rationale.
> Remove $getLookup method generation (Groovy 4+)
> ---
>
> Key: GROOVY-10931
> URL: https://issues.apache.org/jira/browse/GROOVY-10931
> Project: Groovy
> Issue Type: Wish
> Components: class generator, Compiler
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Labels: invokedynamic, jdk16, jdk17
> Fix For: 5.0.0-alpha-1
>
>
> The new {{$getLookup()}} method was discussed somewhat in the comments of
> GROOVY-10273. Groovy 3 has had JEP 396 (illegal access enforcement) support
> backported to the invoke dynamic pathways, without {{$getLookup}}. So, I'd
> like to restart the discussion to find out if there are any illegal-access
> scenarios that Groovy 4 supports that don't have a test case in Groovy 3.
> And if there are no scenarios that remain, I'd like to propose the removal of
> {{$getLookup}} method generation.
> I have disabled its generation in the Groovy 5 codebase, and there are no
> tests that fail. So I have good confidence that it can be removed and the
> security hole can be plugged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17746002#comment-17746002
]
Daniel Sun commented on GROOVY-10931:
-
I found a new warning in the JDK11 build for Groovy 5:
{code:java}
> Task :test
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.codehaus.groovy.vmplugin.v9.Java9
(file:/home/runner/work/groovy/groovy/build/libs/groovy-raw-5.0.0-SNAPSHOT.jar)
to field java.io.FilterReader.in
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
{code}
> Remove $getLookup method generation (Groovy 4+)
> ---
>
> Key: GROOVY-10931
> URL: https://issues.apache.org/jira/browse/GROOVY-10931
> Project: Groovy
> Issue Type: Wish
> Components: class generator, Compiler
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Labels: invokedynamic, jdk16, jdk17
> Fix For: 5.0.0-alpha-1
>
>
> The new {{$getLookup()}} method was discussed somewhat in the comments of
> GROOVY-10273. Groovy 3 has had JEP 396 (illegal access enforcement) support
> backported to the invoke dynamic pathways, without {{$getLookup}}. So, I'd
> like to restart the discussion to find out if there are any illegal-access
> scenarios that Groovy 4 supports that don't have a test case in Groovy 3.
> And if there are no scenarios that remain, I'd like to propose the removal of
> {{$getLookup}} method generation.
> I have disabled its generation in the Groovy 5 codebase, and there are no
> tests that fail. So I have good confidence that it can be removed and the
> security hole can be plugged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745928#comment-17745928
]
Daniel Sun edited comment on GROOVY-10931 at 7/22/23 12:04 PM:
---
Hi Jochen,
Here is the code for transform method, i.e. to find visible method in the
type tree.
[https://github.com/apache/groovy/blob/244886a6da837afe3ab39b318c32e5f8765e99cc/src/main/java/org/codehaus/groovy/vmplugin/v9/Java9.java#L234]
$getLookup method of each Groovy class can just help us to access all
members of the Groovy class with the $getLookup method.
If the Groovy class is declared in a JPMS module and not be exported, the
$getLookup methods outside the module will not work either.
As we can see, $getLookup is just trying to keep compatibility for
reflection as possible as it could.
was (Author: daniel_sun):
Hi Jochen,
Here is the code for transform method, i.e. to find visible method in the
type tree.
[https://github.com/apache/groovy/blob/244886a6da837afe3ab39b318c32e5f8765e99cc/src/main/java/org/codehaus/groovy/vmplugin/v9/Java9.java#L234]
$getLookup method of each Groovy class can just help us to access all
members of the Groovy class with the $getLookup method.
If the Groovy class is declared in a JPMS module and not be exported,
$getLookup will not work either.
As we can see, $getLookup is just trying to keep compatibility for
reflection as possible as it could.
> Remove $getLookup method generation (Groovy 4+)
> ---
>
> Key: GROOVY-10931
> URL: https://issues.apache.org/jira/browse/GROOVY-10931
> Project: Groovy
> Issue Type: Wish
> Components: class generator, Compiler
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Labels: invokedynamic, jdk16, jdk17
> Fix For: 5.0.0-alpha-1
>
>
> The new {{$getLookup()}} method was discussed somewhat in the comments of
> GROOVY-10273. Groovy 3 has had JEP 396 (illegal access enforcement) support
> backported to the invoke dynamic pathways, without {{$getLookup}}. So, I'd
> like to restart the discussion to find out if there are any illegal-access
> scenarios that Groovy 4 supports that don't have a test case in Groovy 3.
> And if there are no scenarios that remain, I'd like to propose the removal of
> {{$getLookup}} method generation.
> I have disabled its generation in the Groovy 5 codebase, and there are no
> tests that fail. So I have good confidence that it can be removed and the
> security hole can be plugged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745928#comment-17745928
]
Daniel Sun commented on GROOVY-10931:
-
Hi Jochen,
Here is the code for transform method, i.e. to find visible method in the
type tree.
[https://github.com/apache/groovy/blob/244886a6da837afe3ab39b318c32e5f8765e99cc/src/main/java/org/codehaus/groovy/vmplugin/v9/Java9.java#L234]
$getLookup method of each Groovy class can just help us to access all
members of the Groovy class with the $getLookup method.
If the Groovy class is declared in a JPMS module and not be exported,
$getLookup will not work either.
As we can see, $getLookup is just trying to keep compatibility for
reflection as possible as it could.
> Remove $getLookup method generation (Groovy 4+)
> ---
>
> Key: GROOVY-10931
> URL: https://issues.apache.org/jira/browse/GROOVY-10931
> Project: Groovy
> Issue Type: Wish
> Components: class generator, Compiler
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Labels: invokedynamic, jdk16, jdk17
> Fix For: 5.0.0-alpha-1
>
>
> The new {{$getLookup()}} method was discussed somewhat in the comments of
> GROOVY-10273. Groovy 3 has had JEP 396 (illegal access enforcement) support
> backported to the invoke dynamic pathways, without {{$getLookup}}. So, I'd
> like to restart the discussion to find out if there are any illegal-access
> scenarios that Groovy 4 supports that don't have a test case in Groovy 3.
> And if there are no scenarios that remain, I'd like to propose the removal of
> {{$getLookup}} method generation.
> I have disabled its generation in the Groovy 5 codebase, and there are no
> tests that fail. So I have good confidence that it can be removed and the
> security hole can be plugged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745869#comment-17745869
]
Daniel Sun edited comment on GROOVY-10931 at 7/22/23 7:24 AM:
--
As Groovy allows illegal reflection since it borned, Groovy users benefit from
the feature in their projects especially useful when testing internals.
The illegal reflective warnings appear since JDK 9, which introduces the JPMS.
The warnings are very annoying and drive Groovy users crazy... so we tried our
best to keep the compatibility, i.e. no warnings and continue support accessing
invisible members, even if JDK 9+ breaks the compatibility... The solution
applied by Groovy 4 is add $getLookup method to each Groovy class, the method
can help us access all members of the Groovy class without any warnings.
To sum up, we really care about the illegal access warnings.
was (Author: daniel_sun):
As Groovy allows illegal reflection since it borned, Groovy users benefit from
the feature in their projects especially useful when testing internals.
The illegal reflective warnings appear since JDK 9, which introduces the JPMS.
The warnings are very annoying and drive Groovy users crazy... so we tried our
best to keep the compatibility, i.e. no warnings and continue support accessing
invisible members, even if JDK 9+ breaks the compatibility...
To sum up, we really care about the illegal access warnings.
> Remove $getLookup method generation (Groovy 4+)
> ---
>
> Key: GROOVY-10931
> URL: https://issues.apache.org/jira/browse/GROOVY-10931
> Project: Groovy
> Issue Type: Wish
> Components: class generator, Compiler
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Labels: invokedynamic, jdk16, jdk17
> Fix For: 5.0.0-alpha-1
>
>
> The new {{$getLookup()}} method was discussed somewhat in the comments of
> GROOVY-10273. Groovy 3 has had JEP 396 (illegal access enforcement) support
> backported to the invoke dynamic pathways, without {{$getLookup}}. So, I'd
> like to restart the discussion to find out if there are any illegal-access
> scenarios that Groovy 4 supports that don't have a test case in Groovy 3.
> And if there are no scenarios that remain, I'd like to propose the removal of
> {{$getLookup}} method generation.
> I have disabled its generation in the Groovy 5 codebase, and there are no
> tests that fail. So I have good confidence that it can be removed and the
> security hole can be plugged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745869#comment-17745869
]
Daniel Sun edited comment on GROOVY-10931 at 7/22/23 7:22 AM:
--
As Groovy allows illegal reflection since it borned, Groovy users benefit from
the feature in their projects especially useful when testing internals.
The illegal reflective warnings appear since JDK 9, which introduces the JPMS.
The warnings are very annoying and drive Groovy users crazy... so we tried our
best to keep the compatibility, i.e. no warnings and continue support accessing
invisible members, even if JDK 9+ breaks the compatibility...
To sum up, we really care about the illegal access warnings.
was (Author: daniel_sun):
As Groovy allows illegal reflection since it borned, Groovy users benefit from
the feature in their projects especially useful when testing internals.
The illegal reflective warnings appear since JDK 9, which introduces the JPMS.
The warnings are very annoying and drive Groovy users crazy... so we tried our
best to keep the compatibility, i.e. no warnings, even if JDK 9+ breaks the
compatibility...
To sum up, we really care about the illegal access warnings.
> Remove $getLookup method generation (Groovy 4+)
> ---
>
> Key: GROOVY-10931
> URL: https://issues.apache.org/jira/browse/GROOVY-10931
> Project: Groovy
> Issue Type: Wish
> Components: class generator, Compiler
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Labels: invokedynamic, jdk16, jdk17
> Fix For: 5.0.0-alpha-1
>
>
> The new {{$getLookup()}} method was discussed somewhat in the comments of
> GROOVY-10273. Groovy 3 has had JEP 396 (illegal access enforcement) support
> backported to the invoke dynamic pathways, without {{$getLookup}}. So, I'd
> like to restart the discussion to find out if there are any illegal-access
> scenarios that Groovy 4 supports that don't have a test case in Groovy 3.
> And if there are no scenarios that remain, I'd like to propose the removal of
> {{$getLookup}} method generation.
> I have disabled its generation in the Groovy 5 codebase, and there are no
> tests that fail. So I have good confidence that it can be removed and the
> security hole can be plugged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745870#comment-17745870
]
Daniel Sun edited comment on GROOVY-10931 at 7/22/23 7:21 AM:
--
In order to avoid the warnings, we have to find legal access ways through
transforming methods for Java members, i.e. written in Java. If no legal
access ways found, the warnings can not be avoided as you could find in the
Groovy 4_0_0 builds.
But we tried to provide $getLookup method for Groovy classes in order to ensure
legal access ways can be found.
was (Author: daniel_sun):
We have to find legal access ways through transforming methods for Java
members, i.e. written in Java. If no legal access ways found, the warnings can
not be avoided as you could find in the Groovy 4_0_0 builds.
But we tried to provide $getLookup method for Groovy classes in order to ensure
legal access ways can be found.
> Remove $getLookup method generation (Groovy 4+)
> ---
>
> Key: GROOVY-10931
> URL: https://issues.apache.org/jira/browse/GROOVY-10931
> Project: Groovy
> Issue Type: Wish
> Components: class generator, Compiler
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Labels: invokedynamic, jdk16, jdk17
> Fix For: 5.0.0-alpha-1
>
>
> The new {{$getLookup()}} method was discussed somewhat in the comments of
> GROOVY-10273. Groovy 3 has had JEP 396 (illegal access enforcement) support
> backported to the invoke dynamic pathways, without {{$getLookup}}. So, I'd
> like to restart the discussion to find out if there are any illegal-access
> scenarios that Groovy 4 supports that don't have a test case in Groovy 3.
> And if there are no scenarios that remain, I'd like to propose the removal of
> {{$getLookup}} method generation.
> I have disabled its generation in the Groovy 5 codebase, and there are no
> tests that fail. So I have good confidence that it can be removed and the
> security hole can be plugged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745870#comment-17745870
]
Daniel Sun edited comment on GROOVY-10931 at 7/22/23 4:20 AM:
--
We have to find legal access ways through transforming methods for Java
members, i.e. written in Java. If no legal access ways found, the warnings can
not be avoided as you could find in the Groovy 4_0_0 builds.
But we tried to provide $getLookup method for Groovy classes in order to ensure
legal access ways can be found.
was (Author: daniel_sun):
We have to find legal access ways through transforming methods for Java
members, i.e. written in Java. If no legal access ways found, the warnings can
not avoided as you found in the Groovy 4_0_0 builds.
But we tried to provide $getLookup method for Groovy classes in order to ensure
legal access ways can be found.
> Remove $getLookup method generation (Groovy 4+)
> ---
>
> Key: GROOVY-10931
> URL: https://issues.apache.org/jira/browse/GROOVY-10931
> Project: Groovy
> Issue Type: Wish
> Components: class generator, Compiler
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Labels: invokedynamic, jdk16, jdk17
> Fix For: 5.0.0-alpha-1
>
>
> The new {{$getLookup()}} method was discussed somewhat in the comments of
> GROOVY-10273. Groovy 3 has had JEP 396 (illegal access enforcement) support
> backported to the invoke dynamic pathways, without {{$getLookup}}. So, I'd
> like to restart the discussion to find out if there are any illegal-access
> scenarios that Groovy 4 supports that don't have a test case in Groovy 3.
> And if there are no scenarios that remain, I'd like to propose the removal of
> {{$getLookup}} method generation.
> I have disabled its generation in the Groovy 5 codebase, and there are no
> tests that fail. So I have good confidence that it can be removed and the
> security hole can be plugged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745870#comment-17745870
]
Daniel Sun edited comment on GROOVY-10931 at 7/22/23 4:17 AM:
--
We have to find legal access ways through transforming methods for Java
members, i.e. written in Java. If no legal access ways found, the warnings can
not avoided as you found in the Groovy 4_0_0 builds.
But we tried to provide $getLookup method for Groovy classes in order to ensure
legal access ways can be found.
was (Author: daniel_sun):
We find to find legal access ways through transforming methods for Java
members, i.e. written in Java. If no legal access ways found, the warnings can
not avoided as you found in the Groovy 4_0_0 builds.
But we tried to provide $getLookup method for Groovy classes in order to ensure
legal access ways can be found.
> Remove $getLookup method generation (Groovy 4+)
> ---
>
> Key: GROOVY-10931
> URL: https://issues.apache.org/jira/browse/GROOVY-10931
> Project: Groovy
> Issue Type: Wish
> Components: class generator, Compiler
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Labels: invokedynamic, jdk16, jdk17
> Fix For: 5.0.0-alpha-1
>
>
> The new {{$getLookup()}} method was discussed somewhat in the comments of
> GROOVY-10273. Groovy 3 has had JEP 396 (illegal access enforcement) support
> backported to the invoke dynamic pathways, without {{$getLookup}}. So, I'd
> like to restart the discussion to find out if there are any illegal-access
> scenarios that Groovy 4 supports that don't have a test case in Groovy 3.
> And if there are no scenarios that remain, I'd like to propose the removal of
> {{$getLookup}} method generation.
> I have disabled its generation in the Groovy 5 codebase, and there are no
> tests that fail. So I have good confidence that it can be removed and the
> security hole can be plugged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745870#comment-17745870
]
Daniel Sun commented on GROOVY-10931:
-
We find to find legal access ways through transforming methods for Java
members, i.e. written in Java. If no legal access ways found, the warnings can
not avoided as you found in the Groovy 4_0_0 builds.
But we tried to provide $getLookup method for Groovy classes in order to ensure
legal access ways can be found.
> Remove $getLookup method generation (Groovy 4+)
> ---
>
> Key: GROOVY-10931
> URL: https://issues.apache.org/jira/browse/GROOVY-10931
> Project: Groovy
> Issue Type: Wish
> Components: class generator, Compiler
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Labels: invokedynamic, jdk16, jdk17
> Fix For: 5.0.0-alpha-1
>
>
> The new {{$getLookup()}} method was discussed somewhat in the comments of
> GROOVY-10273. Groovy 3 has had JEP 396 (illegal access enforcement) support
> backported to the invoke dynamic pathways, without {{$getLookup}}. So, I'd
> like to restart the discussion to find out if there are any illegal-access
> scenarios that Groovy 4 supports that don't have a test case in Groovy 3.
> And if there are no scenarios that remain, I'd like to propose the removal of
> {{$getLookup}} method generation.
> I have disabled its generation in the Groovy 5 codebase, and there are no
> tests that fail. So I have good confidence that it can be removed and the
> security hole can be plugged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745869#comment-17745869
]
Daniel Sun commented on GROOVY-10931:
-
As Groovy allows illegal reflection since it borned, Groovy users benefit from
the feature in their projects especially useful when testing internals.
The illegal reflective warnings appear since JDK 9, which introduces the JPMS.
The warnings are very annoying and drive Groovy users crazy... so we tried our
best to keep the compatibility, i.e. no warnings, even if JDK 9+ breaks the
compatibility...
To sum up, we really care about the illegal access warnings.
> Remove $getLookup method generation (Groovy 4+)
> ---
>
> Key: GROOVY-10931
> URL: https://issues.apache.org/jira/browse/GROOVY-10931
> Project: Groovy
> Issue Type: Wish
> Components: class generator, Compiler
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Labels: invokedynamic, jdk16, jdk17
> Fix For: 5.0.0-alpha-1
>
>
> The new {{$getLookup()}} method was discussed somewhat in the comments of
> GROOVY-10273. Groovy 3 has had JEP 396 (illegal access enforcement) support
> backported to the invoke dynamic pathways, without {{$getLookup}}. So, I'd
> like to restart the discussion to find out if there are any illegal-access
> scenarios that Groovy 4 supports that don't have a test case in Groovy 3.
> And if there are no scenarios that remain, I'd like to propose the removal of
> {{$getLookup}} method generation.
> I have disabled its generation in the Groovy 5 codebase, and there are no
> tests that fail. So I have good confidence that it can be removed and the
> security hole can be plugged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-10931) Remove $getLookup method generation (Groovy 4+)
[
https://issues.apache.org/jira/browse/GROOVY-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745857#comment-17745857
]
Daniel Sun commented on GROOVY-10931:
-
Hi Eric,
$getLookup implementation can handle all JDKs by the same way, but it has
its own flaw as you found, so I am very happy to see the improvement, but I do
not understand how the improvement help us avoid the illegal reflective
warnings under pre-16 JDKs, so I went to check the output of test build for
JDK11 and found some warnings, could you tweak the improvement further more?
https://github.com/apache/groovy/actions/runs/5625969498/job/15245826217#step:6:309
> Task :groovy-datetime:testClasses
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.codehaus.groovy.vmplugin.v9.Java9
(file:/home/runner/work/groovy/groovy/build/libs/groovy-raw-5.0.0-SNAPSHOT.jar)
to method sun.util.calendar.ZoneInfo.equals(java.lang.Object)
> Remove $getLookup method generation (Groovy 4+)
> ---
>
> Key: GROOVY-10931
> URL: https://issues.apache.org/jira/browse/GROOVY-10931
> Project: Groovy
> Issue Type: Wish
> Components: class generator, Compiler
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Labels: invokedynamic, jdk16, jdk17
> Fix For: 5.0.0-alpha-1
>
>
> The new {{$getLookup()}} method was discussed somewhat in the comments of
> GROOVY-10273. Groovy 3 has had JEP 396 (illegal access enforcement) support
> backported to the invoke dynamic pathways, without {{$getLookup}}. So, I'd
> like to restart the discussion to find out if there are any illegal-access
> scenarios that Groovy 4 supports that don't have a test case in Groovy 3.
> And if there are no scenarios that remain, I'd like to propose the removal of
> {{$getLookup}} method generation.
> I have disabled its generation in the Groovy 5 codebase, and there are no
> tests that fail. So I have good confidence that it can be removed and the
> security hole can be plugged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11126) Null-safe Dereference fails after time
[
https://issues.apache.org/jira/browse/GROOVY-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744898#comment-17744898
]
Daniel Sun commented on GROOVY-11126:
-
We can bypass the PIC for safe invocation, but I still can not understand why
NPE will happen in your code sometimes... Could you reproduce the issue?
See also,
https://github.com/apache/groovy/blob/732a204a6439bfadece45b222758c1138cce3292/src/main/java/org/codehaus/groovy/vmplugin/v8/IndyInterface.java#L329
> Null-safe Dereference fails after time
> --
>
> Key: GROOVY-11126
> URL: https://issues.apache.org/jira/browse/GROOVY-11126
> Project: Groovy
> Issue Type: Bug
> Components: bytecode
>Affects Versions: 4.0.11, 4.0.12
> Environment: Zulu Java 17.0.7, Amazon Linux 2023, Spring Boot 3.1.1
>Reporter: Kenneth W DeLong
>Priority: Critical
> Attachments: javapOutput.txt, javapOutput2.txt
>
>
> I have a server-side app that works perfectly for a long time (18-24h) then
> suddenly starts throwing "impossible" errors.
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.lang.CharSequence.length()" because "self" is null
> at
> org.codehaus.groovy.runtime.StringGroovyMethods.size(StringGroovyMethods.java:2693)
> at org.codehaus.groovy.runtime.dgm$1323.doMethodInvoke(Unknown Source)
> at
> com.hatchbaby.model.ColorParser.isOneByteFormat(ColorParser.groovy:74)
> at com.hatchbaby.model.ColorParser.getRed(ColorParser.groovy:13)
> at com.hatchbaby.domain.Content.getRed(Content.groovy:173)
> {code}
> The line of code at ColorParser:74 is:
> {code:java}
> int size = color?.size() ?: 0 {code}
> The variable `color` is a String. The null-safe dereference operator has
> ceased to short-circuit.
> This code is years old and has run flawlessly. Since the upgrade from Spring
> Boot 2.7.4 to Boot 3.1.1, it runs fine for 18-24h, then it starts throwing
> NullPointerExceptions. This is happening at a couple of other places in the
> code, all on null-safe dereferences that don't short-circuit. The above code
> is hit 9,000+ times/day. We have a cluster of servers and they seem to
> develop the problem within a couple hours of each other.
> The server is running with Spring Boot 3.1.1 (hence Groovy 4.0.12) running on
> Java 17.0.7 (Azul Zulu) on Amazon Linux 2023. The project is joint Java and
> Groovy code that is compiled with the GMavenPlus 3.0.0 Maven plugin (maven
> 3.9.1)
> I have tried to reproduce the error by running a tiny program that mimics the
> error, but so far after running 1.4 million invocations over 24h with no
> errors (as you might expect).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GROOVY-10305) Groovy records do not allow creating non-compact constructors with signature matching the record one
[
https://issues.apache.org/jira/browse/GROOVY-10305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun closed GROOVY-10305.
---
Fix Version/s: 4.0.11
Assignee: Daniel Sun
Resolution: Fixed
> Groovy records do not allow creating non-compact constructors with signature
> matching the record one
>
>
> Key: GROOVY-10305
> URL: https://issues.apache.org/jira/browse/GROOVY-10305
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 4.0.0-beta-1
>Reporter: Konstantin Nisht
>Assignee: Daniel Sun
>Priority: Critical
> Labels: ClassFormatError
> Fix For: 4.0.11
>
>
> The following code
> {code:java}
> record X(int a) {
> public X(int a) {
> println "abcd"
> }
> }
> def x = new X(10){code}
>
> fails to run with an exception "java.lang.ClassFormatError: Duplicate method
> name "" with signature "(I)V" in class file X". Similar code in java
> works fine.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GROOVY-11018) Bump picocli to 4.7.2
[ https://issues.apache.org/jira/browse/GROOVY-11018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun closed GROOVY-11018. --- Fix Version/s: 4.0.12 Assignee: Daniel Sun Resolution: Fixed > Bump picocli to 4.7.2 > - > > Key: GROOVY-11018 > URL: https://issues.apache.org/jira/browse/GROOVY-11018 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 4.0.12 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GROOVY-11017) Bump jarjar to 1.8.2 (build dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun closed GROOVY-11017. --- Fix Version/s: 4.0.12 Assignee: Daniel Sun Resolution: Fixed > Bump jarjar to 1.8.2 (build dependency) > --- > > Key: GROOVY-11017 > URL: https://issues.apache.org/jira/browse/GROOVY-11017 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 4.0.12 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11018) Bump picocli to 4.7.2
Daniel Sun created GROOVY-11018: --- Summary: Bump picocli to 4.7.2 Key: GROOVY-11018 URL: https://issues.apache.org/jira/browse/GROOVY-11018 Project: Groovy Issue Type: Dependency upgrade Reporter: Daniel Sun -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GROOVY-11017) Bump jarjar to 1.8.2 (build dependency)
[ https://issues.apache.org/jira/browse/GROOVY-11017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun updated GROOVY-11017: Summary: Bump jarjar to 1.8.2 (build dependency) (was: Bump jarjar to 1.8.2) > Bump jarjar to 1.8.2 (build dependency) > --- > > Key: GROOVY-11017 > URL: https://issues.apache.org/jira/browse/GROOVY-11017 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11017) Bump jarjar to 1.8.2
Daniel Sun created GROOVY-11017: --- Summary: Bump jarjar to 1.8.2 Key: GROOVY-11017 URL: https://issues.apache.org/jira/browse/GROOVY-11017 Project: Groovy Issue Type: Dependency upgrade Reporter: Daniel Sun -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-11015) [GINQ]Leverage the power of Virtual Thread
[
https://issues.apache.org/jira/browse/GROOVY-11015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun resolved GROOVY-11015.
-
Fix Version/s: 4.0.12
Resolution: Fixed
> [GINQ]Leverage the power of Virtual Thread
> --
>
> Key: GROOVY-11015
> URL: https://issues.apache.org/jira/browse/GROOVY-11015
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 4.0.12
>
>
> GINQ supports run querying in parallel with thread pool created by
> {{Executors.newFixedThreadPool}} by default.
> It's great to use Virtual Thread created by
> {{Executors.newVirtualThreadPerTaskExecutor}} to optimize the performance if
> the new feature Virtual Thread is available.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GROOVY-11016) Bump javaparser to 3.25.2
[ https://issues.apache.org/jira/browse/GROOVY-11016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun closed GROOVY-11016. --- Fix Version/s: 4.0.12 Assignee: Daniel Sun Resolution: Fixed > Bump javaparser to 3.25.2 > - > > Key: GROOVY-11016 > URL: https://issues.apache.org/jira/browse/GROOVY-11016 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 4.0.12 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11016) Bump javaparser to 3.25.2
Daniel Sun created GROOVY-11016: --- Summary: Bump javaparser to 3.25.2 Key: GROOVY-11016 URL: https://issues.apache.org/jira/browse/GROOVY-11016 Project: Groovy Issue Type: Dependency upgrade Reporter: Daniel Sun -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-11015) [GINQ]Leverage the power of Virtual Thread
Daniel Sun created GROOVY-11015:
---
Summary: [GINQ]Leverage the power of Virtual Thread
Key: GROOVY-11015
URL: https://issues.apache.org/jira/browse/GROOVY-11015
Project: Groovy
Issue Type: Improvement
Reporter: Daniel Sun
Assignee: Daniel Sun
GINQ supports run querying in parallel with thread pool created by
{{Executors.newFixedThreadPool}} by default.
It's great to use Virtual Thread created by
{{Executors.newVirtualThreadPerTaskExecutor}} to optimize the performance if
the new feature Virtual Thread is available.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-10921) Optimised variants for AGM#each
[ https://issues.apache.org/jira/browse/GROOVY-10921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun resolved GROOVY-10921. - Fix Version/s: 5.0.0-alpha-1 Resolution: Fixed > Optimised variants for AGM#each > --- > > Key: GROOVY-10921 > URL: https://issues.apache.org/jira/browse/GROOVY-10921 > Project: Groovy > Issue Type: Improvement >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-1 > > > Similarly as for min/max, we can have variants for each which use IntConsumer > and save boxing/unboxing overheads. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-10983) Bump asm to 9.5, add JDK21 constant
[ https://issues.apache.org/jira/browse/GROOVY-10983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun resolved GROOVY-10983. - Fix Version/s: 5.0.0-alpha-1 4.0.11 Assignee: Paul King Resolution: Fixed > Bump asm to 9.5, add JDK21 constant > --- > > Key: GROOVY-10983 > URL: https://issues.apache.org/jira/browse/GROOVY-10983 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 5.0.0-alpha-1, 4.0.11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GROOVY-10892) Bump javaparser to 3.24.10
[ https://issues.apache.org/jira/browse/GROOVY-10892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun closed GROOVY-10892. --- Fix Version/s: 4.0.8 Assignee: Daniel Sun Resolution: Fixed > Bump javaparser to 3.24.10 > -- > > Key: GROOVY-10892 > URL: https://issues.apache.org/jira/browse/GROOVY-10892 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 4.0.8 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-10892) Bump javaparser to 3.24.10
Daniel Sun created GROOVY-10892: --- Summary: Bump javaparser to 3.24.10 Key: GROOVY-10892 URL: https://issues.apache.org/jira/browse/GROOVY-10892 Project: Groovy Issue Type: Dependency upgrade Reporter: Daniel Sun -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GROOVY-10884) Bump xstream to 1.4.20
[ https://issues.apache.org/jira/browse/GROOVY-10884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun closed GROOVY-10884. --- Fix Version/s: 4.0.8 Assignee: Daniel Sun Resolution: Fixed > Bump xstream to 1.4.20 > -- > > Key: GROOVY-10884 > URL: https://issues.apache.org/jira/browse/GROOVY-10884 > Project: Groovy > Issue Type: Bug >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 4.0.8 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-10884) Bump xstream to 1.4.20
Daniel Sun created GROOVY-10884: --- Summary: Bump xstream to 1.4.20 Key: GROOVY-10884 URL: https://issues.apache.org/jira/browse/GROOVY-10884 Project: Groovy Issue Type: Bug Reporter: Daniel Sun -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GROOVY-10879) Potential additional DGM collectEntries variants
[
https://issues.apache.org/jira/browse/GROOVY-10879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun resolved GROOVY-10879.
-
Fix Version/s: 5.0.0-alpha-1
Resolution: Fixed
The proposed PR has been merged. Thanks!
https://github.com/apache/groovy/commit/60c90bf9bc810aa36106cf03e2c9e9bf0cfa5828
> Potential additional DGM collectEntries variants
>
>
> Key: GROOVY-10879
> URL: https://issues.apache.org/jira/browse/GROOVY-10879
> Project: Groovy
> Issue Type: Improvement
>Reporter: Paul King
>Assignee: Paul King
>Priority: Major
> Fix For: 5.0.0-alpha-1
>
>
> As discussed in the mailing list:
> https://lists.apache.org/thread/7rd6wdblnh7bmdf6socjnbf21crg37g0
> Existing variants:
> {code}
> var languages = ['Kotlin', 'Groovy', 'Java', 'Clojure']
> assert languages.collectEntries{ [it.toLowerCase(), it.size()] } ==
> [kotlin:6, groovy:6, java:4, clojure:7]
> assert languages.collectEntries{ [it.toLowerCase(), it] } ==
> [kotlin:'Kotlin', groovy:'Groovy', java:'Java', clojure:'Clojure']
> assert languages.collectEntries(Scala:5){ [it, it.size()] } ==
> [Scala:5, Kotlin:6, Groovy:6, Java:4, Clojure:7]
> {code}
> Proposed new variants:
> {code}
> assert languages.collectEntries(String::toLowerCase, String::size) ==
> [kotlin:6, groovy:6, java:4, clojure:7]
> assert languages.withCollectedKeys(String::toLowerCase) == [kotlin:'Kotlin',
> groovy:'Groovy', java:'Java', clojure:'Clojure']
> assert languages.withCollectedValues([Scala:5], String::size) == [Scala:5,
> Kotlin:6, Groovy:6, Java:4, Clojure:7]
> def squared = e -> e ** 2
> assert [Scala:5, Kotlin:6, Groovy:6, Java:4,
> Clojure:7].collectEntries(String::toLowerCase, squared) ==
> [scala:25, kotlin:36, groovy:36, java:16, clojure:49]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-10772) Possible memory leak, CacheableCallSite retains objects across invocations
[
https://issues.apache.org/jira/browse/GROOVY-10772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17649279#comment-17649279
]
Daniel Sun commented on GROOVY-10772:
-
{quote}
This is a binary incompatible (breaking) change for an internal class. We don't
anticipate any knock-on ramifications but we should monitor any feedback
carefully.
{quote}
We can add a new method and deprecate the old one
> Possible memory leak, CacheableCallSite retains objects across invocations
> --
>
> Key: GROOVY-10772
> URL: https://issues.apache.org/jira/browse/GROOVY-10772
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.3, 4.0.4, 4.0.5
>Reporter: Sterling Greene
>Assignee: Paul King
>Priority: Major
> Labels: breaking
> Attachments: GROOVY-10772-4_0_3.patch, real-problem-gc-paths.png,
> reproducer-gc-paths.png
>
>
> We're seeing this in a test with Gradle + Groovy 4, so it's hard to reproduce
> exactly what we're seeing in pure Groovy.
> In Gradle, we run a build with a 150MB byte array ("memory hog") added as a
> property to a Project object.
> https://github.com/gradle/gradle/blob/5c4e492a9dc1665e9a80235cc0fe9292ead88434/subprojects/workers/src/integTest/groovy/org/gradle/workers/internal/WorkerExecutorIntegrationTest.groovy#L228
> We then run a second build and third build to show that this doesn't cause
> the daemon to OOM by retaining old Project references.
> With Groovy 3, this test passes. With Groovy 3 + indy jars + indy
> compilation, this test passes.
> With Groovy 4 (4.0.5), this test fails with a OOM.
> https://ge.gradle.org/s/xywk2kx7iqdna/tests/:workers:embeddedIntegTest/org.gradle.workers.internal.WorkerExecutorIntegrationTest/does%20not%20leak%20project%20state%20across%20multiple%20builds?top-execution=1
> I've seen failures with Java 8 and 11, but it _seems_ like the real problem
> is easier to reproduce with Java 8.
> Looking at the heap dump, we can see `CacheableCallSite` is involved somehow
> with hanging on to the byte array. To make it easier to identified which
> generation the byte array came from, I set the first byte to 1, 2, 3... In
> the real failure, the OOM happens on the second invocation with the first
> generation byte array held by `CacheableCallSite`.
> This script produces a OOM with a similar looking GC-path:
> {code:java}
> class Project {
> private final byte[] memoryHog = new byte[150*1024*1024]
> }
> def func = {
>def project = new Project()
>project.memoryHog[0] = 1
>println "hello $it " + project
>project = null
> }
> func(1)
> func = {
>def project = new Project()
>project.memoryHog[0] = 2
>println "hello $it " + project
>project = null
> }
> func(2)
> func = {
>def project = new Project()
>project.memoryHog[0] = 3
>println "hello $it " + project
>project = null
> }
> func(3)
> {code}
> I'm running this with:
> > JAVA_OPTS="-Xmx512m -Xms256m -XX:+HeapDumpOnOutOfMemoryError" groovy
> > memoryhog.groovy
> This script runs with Groovy 3.0.12 with and without indy. This fails with
> Groovy 4.0.4.
> Would anything else be useful for diagnosing this?
> Maybe related to https://issues.apache.org/jira/browse/GROOVY-10232
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-10877) Record with ThreadInterruptibleASTTransformation applied fails to run
[
https://issues.apache.org/jira/browse/GROOVY-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun resolved GROOVY-10877.
-
Resolution: Fixed
> Record with ThreadInterruptibleASTTransformation applied fails to run
> -
>
> Key: GROOVY-10877
> URL: https://issues.apache.org/jira/browse/GROOVY-10877
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.6
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 4.0.7
>
>
> {code:java}
> @groovy.transform.ThreadInterrupt
> record Point(int x, int y) {}
> def p = new Point(1, 2)
> assert 'Point[x=1, y=2]' == p.toString()
> {code}
> {code:java}
> java.lang.ClassFormatError: StackMapTable format error: reserved frame type
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3373)
> at java.base/java.lang.Class.getDeclaredConstructors(Class.java:2555)
> at
> org.codehaus.groovy.reflection.CachedClass$2.lambda$initValue$4(CachedClass.java:68)
> at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
> at
> org.codehaus.groovy.reflection.CachedClass.doPrivileged(CachedClass.java:138)
> at
> org.codehaus.groovy.reflection.CachedClass$2.initValue(CachedClass.java:73)
> at
> org.codehaus.groovy.reflection.CachedClass$2.initValue(CachedClass.java:63)
> at
> org.codehaus.groovy.util.LazyReference.getLocked(LazyReference.java:50)
> at org.codehaus.groovy.util.LazyReference.get(LazyReference.java:37)
> at
> org.codehaus.groovy.reflection.CachedClass.getConstructors(CachedClass.java:262)
> at groovy.lang.MetaClassImpl.(MetaClassImpl.java:233)
> at groovy.lang.MetaClassImpl.(MetaClassImpl.java:243)
> at
> groovy.lang.MetaClassRegistry$MetaClassCreationHandle.createNormalMetaClass(MetaClassRegistry.java:166)
> at
> groovy.lang.MetaClassRegistry$MetaClassCreationHandle.createWithCustomLookup(MetaClassRegistry.java:156)
> at
> groovy.lang.MetaClassRegistry$MetaClassCreationHandle.create(MetaClassRegistry.java:139)
> at
> org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:271)
> at
> org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:314)
> at
> org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.getMetaClass(MetaClassRegistryImpl.java:269)
> at
> org.codehaus.groovy.vmplugin.v8.Selector$InitSelector.getMetaClass(Selector.java:404)
> at
> org.codehaus.groovy.vmplugin.v8.Selector$MethodSelector.setCallSiteTarget(Selector.java:1021)
> at
> org.codehaus.groovy.vmplugin.v8.IndyInterface.fallback(IndyInterface.java:359)
> at
> org.codehaus.groovy.vmplugin.v8.IndyInterface$FallbackSupplier.get(IndyInterface.java:282)
> at
> org.codehaus.groovy.vmplugin.v8.IndyInterface.lambda$fromCache$1(IndyInterface.java:304)
> at
> org.codehaus.groovy.vmplugin.v8.CacheableCallSite.getAndPut(CacheableCallSite.java:70)
> at
> org.codehaus.groovy.vmplugin.v8.IndyInterface.lambda$fromCache$2(IndyInterface.java:301)
> at
> org.codehaus.groovy.vmplugin.v8.IndyInterface.doWithCallSite(IndyInterface.java:375)
> at
> org.codehaus.groovy.vmplugin.v8.IndyInterface.fromCache(IndyInterface.java:298)
> at ConsoleScript10.run(ConsoleScript10:4)
> at
> groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:287)
> at groovy.lang.GroovyShell.run(GroovyShell.java:393)
> at groovy.lang.GroovyShell.run(GroovyShell.java:372)
> at groovy.lang.GroovyShell.run(GroovyShell.java:198)
> at groovy.console.ui.Console$GroovySourceType.run(Console.groovy:1189)
> at groovy.console.ui.Console.doRun(Console.groovy:1421)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:343)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:328)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:342)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1010)
> at
> org.codehaus.groovy.vmplugin.v8.IndyInterface.fromCache(IndyInterface.java:321)
> at
> groovy.console.ui.Console$_runScriptImpl_closure23.doCall(Console.groovy:1379)
> at
>
