[jira] [Commented] (GROOVY-10232) Massive increase in memory usage due to CacheableCallSite
[ https://issues.apache.org/jira/browse/GROOVY-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472490#comment-17472490 ] Chad Wilson commented on GROOVY-10232: -- Thanks for the work here! I've been scratching my head about which change has caused instability on builds for [https://github.com/gocd/gocd/] for some time, but suspect this one. Does anyone know if this is likely to have affected all 3.0.x versions, or only a particular point/patch release - i.e could a downgrade to an earlier 3.0.x version help? > Massive increase in memory usage due to CacheableCallSite > - > > Key: GROOVY-10232 > URL: https://issues.apache.org/jira/browse/GROOVY-10232 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 3.0.9 >Reporter: Emond Papegaaij >Assignee: Daniel Sun >Priority: Major > Fix For: 3.0.10, 4.0.0-rc-3 > > Attachments: Screenshot_20210913_161502.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > When upgrading our tests from Spock 1.3 with Groovy 2.5 to Spock 2.0 with > Groovy 3.0.9, we are seeing issue with memory usage caused by > CacheableCallSite. This memory seems to be retained in classes and is > therefore never freed. A single Spock test class can take as much as 150mb > memory. The total amount of memory sums up to several gigabytes of additional > memory, causing our tests to take about 3 times as much memory as with Spock > 1.3 and Groovy 2.5. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GROOVY-10232) Massive increase in memory usage due to CacheableCallSite
[ https://issues.apache.org/jira/browse/GROOVY-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472485#comment-17472485 ] Ian Springer commented on GROOVY-10232: --- [~paulk], when do you think 4 will go GA? Thanks! > Massive increase in memory usage due to CacheableCallSite > - > > Key: GROOVY-10232 > URL: https://issues.apache.org/jira/browse/GROOVY-10232 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 3.0.9 >Reporter: Emond Papegaaij >Assignee: Daniel Sun >Priority: Major > Fix For: 3.0.10, 4.0.0-rc-3 > > Attachments: Screenshot_20210913_161502.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > When upgrading our tests from Spock 1.3 with Groovy 2.5 to Spock 2.0 with > Groovy 3.0.9, we are seeing issue with memory usage caused by > CacheableCallSite. This memory seems to be retained in classes and is > therefore never freed. A single Spock test class can take as much as 150mb > memory. The total amount of memory sums up to several gigabytes of additional > memory, causing our tests to take about 3 times as much memory as with Spock > 1.3 and Groovy 2.5. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GROOVY-10145) Support JDK16
[ https://issues.apache.org/jira/browse/GROOVY-10145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472480#comment-17472480 ] Chad Wilson commented on GROOVY-10145: -- OK, that's a shame. Do you think it'd be possible to clarify the specific problems for those whom the source code is a bit difficult to make sense of? Is it *all* Groovy-generated dynamic proxies that are affected (and will end up inaccessible by the creating module), or do they perhaps have to have specific characteristics in the interface (e.g types, presence of default methods). I'm wondering what the minimal workarounds might be for those who need to/wish to maintain Groovy 3 compatibility. I'm not sure how long it will practically take Gradle, for instance, to bundle Groovy 4. It took a very long to get from 2.5 to 3, IIRC - although perhaps the next one will be easier. > Support JDK16 > - > > Key: GROOVY-10145 > URL: https://issues.apache.org/jira/browse/GROOVY-10145 > Project: Groovy > Issue Type: Bug >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 4.0.0-beta-1 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GROOVY-10232) Massive increase in memory usage due to CacheableCallSite
[ https://issues.apache.org/jira/browse/GROOVY-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472407#comment-17472407 ] Paul King commented on GROOVY-10232: I will do the release for 3.0.10 at the same time or shortly after 4 GA. > Massive increase in memory usage due to CacheableCallSite > - > > Key: GROOVY-10232 > URL: https://issues.apache.org/jira/browse/GROOVY-10232 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 3.0.9 >Reporter: Emond Papegaaij >Assignee: Daniel Sun >Priority: Major > Fix For: 3.0.10, 4.0.0-rc-3 > > Attachments: Screenshot_20210913_161502.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > When upgrading our tests from Spock 1.3 with Groovy 2.5 to Spock 2.0 with > Groovy 3.0.9, we are seeing issue with memory usage caused by > CacheableCallSite. This memory seems to be retained in classes and is > therefore never freed. A single Spock test class can take as much as 150mb > memory. The total amount of memory sums up to several gigabytes of additional > memory, causing our tests to take about 3 times as much memory as with Spock > 1.3 and Groovy 2.5. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GROOVY-10448) Bump gradle versions plugin to 0.41.0 (build dependency)
[ https://issues.apache.org/jira/browse/GROOVY-10448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-10448. Fix Version/s: 4.0.0-rc-3 Resolution: Fixed > Bump gradle versions plugin to 0.41.0 (build dependency) > > > Key: GROOVY-10448 > URL: https://issues.apache.org/jira/browse/GROOVY-10448 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 4.0.0-rc-3 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GROOVY-10448) Bump gradle versions plugin to 0.41.0 (build dependency)
Paul King created GROOVY-10448: -- Summary: Bump gradle versions plugin to 0.41.0 (build dependency) Key: GROOVY-10448 URL: https://issues.apache.org/jira/browse/GROOVY-10448 Project: Groovy Issue Type: Dependency upgrade Reporter: Paul King Assignee: Paul King -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GROOVY-10447) Bump checkstyle to 9.2.1 (build dependency)
[ https://issues.apache.org/jira/browse/GROOVY-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-10447. Fix Version/s: 4.0.0-rc-3 Assignee: Paul King Resolution: Fixed > Bump checkstyle to 9.2.1 (build dependency) > --- > > Key: GROOVY-10447 > URL: https://issues.apache.org/jira/browse/GROOVY-10447 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 4.0.0-rc-3 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GROOVY-10446) Bump logback to 1.2.10 (test dependency)
[ https://issues.apache.org/jira/browse/GROOVY-10446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-10446. Fix Version/s: 4.0.0-rc-3 Resolution: Fixed > Bump logback to 1.2.10 (test dependency) > > > Key: GROOVY-10446 > URL: https://issues.apache.org/jira/browse/GROOVY-10446 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 4.0.0-rc-3 > > > Please see GROOVY-10431 for more comments relating to Groovy config files. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GROOVY-10431) Bump logback to 1.2.9 (test dependency)
[ https://issues.apache.org/jira/browse/GROOVY-10431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-10431. Fix Version/s: 4.0.0-rc-2 Assignee: Paul King Resolution: Fixed > Bump logback to 1.2.9 (test dependency) > --- > > Key: GROOVY-10431 > URL: https://issues.apache.org/jira/browse/GROOVY-10431 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 4.0.0-rc-2 > > > Groovy doesn't bundle a version of Logback in its distribution nor list it as > a dependency in its pom (or bom), so isn't directly affected by > CVE-2021-42550. Folks using logback directly may wish to upgrade their > version or follow the advice in the links. > Note that Logback 1.2.9 disables Groovy configuration support for being "too > powerful". Users relying on that feature may wish to stay using Logback 1.2.8 > but please ensure your configuration files have appropriate file system > protections. > See also: > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-42550 > https://jira.qos.ch/browse/LOGBACK-1591 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GROOVY-10445) Bump Spotbugs/Spotbugs annotations to 4.5.3 (build dependency)
[ https://issues.apache.org/jira/browse/GROOVY-10445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-10445. Fix Version/s: 4.0.0-rc-3 Assignee: Paul King Resolution: Fixed > Bump Spotbugs/Spotbugs annotations to 4.5.3 (build dependency) > -- > > Key: GROOVY-10445 > URL: https://issues.apache.org/jira/browse/GROOVY-10445 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 4.0.0-rc-3 > > > Includes log4j version bumps for CVE-2021-45105 and CVE-2021-44832 > (only affects the build, not relevant for Groovy itself) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [groovy] eric-milles merged pull request #1670: GROOVY-5169, GROOVY-7682: JSON output: serialization fixes
eric-milles merged pull request #1670: URL: https://github.com/apache/groovy/pull/1670 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@groovy.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (GROOVY-10355) Compiler interpret variable name as class name when in parentheses.
[
https://issues.apache.org/jira/browse/GROOVY-10355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olof Asbrink updated GROOVY-10355:
--
Affects Version/s: 4.0.0-rc-2
> Compiler interpret variable name as class name when in parentheses.
>
>
> Key: GROOVY-10355
> URL: https://issues.apache.org/jira/browse/GROOVY-10355
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.8, 4.0.0-rc-2
> Environment: JDK 11.0.12
>Reporter: Olof Asbrink
>Priority: Major
>
> This behavior seems unexpected:
> {code:java}
> String b = "B"
> System.out.println("A" + (b) + "C")
> {code}
> Throws this exception:
> {code:java}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> /tmp/repo1.gm: 2: unable to resolve class b
> @ line 2, column 26.
>System.out.println("A" + (b) + "C")
> ^{code}
> However these examples work:
> {code:java}
> String b = "B"
> System.out.println("A" + b + "C")
> {code}
> and
> {code:java}
> String b = "B"
> System.out.println("A" + (b))
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GROOVY-10355) Compiler interpret variable name as class name when in parentheses.
[
https://issues.apache.org/jira/browse/GROOVY-10355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472337#comment-17472337
]
Olof Asbrink commented on GROOVY-10355:
---
This seems to happen using 4.0.0-rc-2 as well
> Compiler interpret variable name as class name when in parentheses.
>
>
> Key: GROOVY-10355
> URL: https://issues.apache.org/jira/browse/GROOVY-10355
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.8
> Environment: JDK 11.0.12
>Reporter: Olof Asbrink
>Priority: Major
>
> This behavior seems unexpected:
> {code:java}
> String b = "B"
> System.out.println("A" + (b) + "C")
> {code}
> Throws this exception:
> {code:java}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> /tmp/repo1.gm: 2: unable to resolve class b
> @ line 2, column 26.
>System.out.println("A" + (b) + "C")
> ^{code}
> However these examples work:
> {code:java}
> String b = "B"
> System.out.println("A" + b + "C")
> {code}
> and
> {code:java}
> String b = "B"
> System.out.println("A" + (b))
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GROOVY-10355) Compiler interpret variable name as class name when in parentheses.
[
https://issues.apache.org/jira/browse/GROOVY-10355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472255#comment-17472255
]
Olof Asbrink commented on GROOVY-10355:
---
[~emilles] Do you know if this is addressed in 4.0.x and, if so, it's something
that can be backported to 3.0.x?
> Compiler interpret variable name as class name when in parentheses.
>
>
> Key: GROOVY-10355
> URL: https://issues.apache.org/jira/browse/GROOVY-10355
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.8
> Environment: JDK 11.0.12
>Reporter: Olof Asbrink
>Priority: Major
>
> This behavior seems unexpected:
> {code:java}
> String b = "B"
> System.out.println("A" + (b) + "C")
> {code}
> Throws this exception:
> {code:java}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> /tmp/repo1.gm: 2: unable to resolve class b
> @ line 2, column 26.
>System.out.println("A" + (b) + "C")
> ^{code}
> However these examples work:
> {code:java}
> String b = "B"
> System.out.println("A" + b + "C")
> {code}
> and
> {code:java}
> String b = "B"
> System.out.println("A" + (b))
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [groovy] eric-milles merged pull request #1672: GROOVY-6837: prep work
eric-milles merged pull request #1672: URL: https://github.com/apache/groovy/pull/1672 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@groovy.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (GROOVY-10444) Bump javaparser to 3.24.0
[ https://issues.apache.org/jira/browse/GROOVY-10444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun closed GROOVY-10444. --- Fix Version/s: 4.0.0-rc-3 Assignee: Daniel Sun Resolution: Fixed > Bump javaparser to 3.24.0 > - > > Key: GROOVY-10444 > URL: https://issues.apache.org/jira/browse/GROOVY-10444 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 4.0.0-rc-3 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GROOVY-10232) Massive increase in memory usage due to CacheableCallSite
[ https://issues.apache.org/jira/browse/GROOVY-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472170#comment-17472170 ] Daniel Sun commented on GROOVY-10232: - Thanks for your feedback. As for 3.0.10 release plan, [~paulk] can tell us ;) > Massive increase in memory usage due to CacheableCallSite > - > > Key: GROOVY-10232 > URL: https://issues.apache.org/jira/browse/GROOVY-10232 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 3.0.9 >Reporter: Emond Papegaaij >Assignee: Daniel Sun >Priority: Major > Fix For: 3.0.10, 4.0.0-rc-3 > > Attachments: Screenshot_20210913_161502.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > When upgrading our tests from Spock 1.3 with Groovy 2.5 to Spock 2.0 with > Groovy 3.0.9, we are seeing issue with memory usage caused by > CacheableCallSite. This memory seems to be retained in classes and is > therefore never freed. A single Spock test class can take as much as 150mb > memory. The total amount of memory sums up to several gigabytes of additional > memory, causing our tests to take about 3 times as much memory as with Spock > 1.3 and Groovy 2.5. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GROOVY-10232) Massive increase in memory usage due to CacheableCallSite
[ https://issues.apache.org/jira/browse/GROOVY-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun closed GROOVY-10232. --- > Massive increase in memory usage due to CacheableCallSite > - > > Key: GROOVY-10232 > URL: https://issues.apache.org/jira/browse/GROOVY-10232 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 3.0.9 >Reporter: Emond Papegaaij >Assignee: Daniel Sun >Priority: Major > Fix For: 3.0.10, 4.0.0-rc-3 > > Attachments: Screenshot_20210913_161502.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > When upgrading our tests from Spock 1.3 with Groovy 2.5 to Spock 2.0 with > Groovy 3.0.9, we are seeing issue with memory usage caused by > CacheableCallSite. This memory seems to be retained in classes and is > therefore never freed. A single Spock test class can take as much as 150mb > memory. The total amount of memory sums up to several gigabytes of additional > memory, causing our tests to take about 3 times as much memory as with Spock > 1.3 and Groovy 2.5. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GROOVY-10392) Inconsistent metaClass capability for .static properties and methods vs ordinary dynamic properties and methods
[
https://issues.apache.org/jira/browse/GROOVY-10392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472134#comment-17472134
]
William Woodman commented on GROOVY-10392:
--
ok - i've tidied up the sample project a little as follows
latest WillsMetaClass is now here
[https://github.com/woodmawa/GroovyV4sample/blob/master/src/main/groovy/mop/WillsMetaClass.java]
staticExpandoProperty as before is here (this creates the static getter/setters
along with the backing map entries)
[https://github.com/woodmawa/GroovyV4sample/blob/master/src/main/groovy/mop/StaticExpandoProperty.groovy]
tried to right some tests to show its working as it should
[https://github.com/woodmawa/GroovyV4sample/blob/master/src/test/groovy/mop/WillsMetaClassTest.groovy]
and a couple of tests for the new StaticExpandoProperty
[https://github.com/woodmawa/GroovyV4sample/blob/master/src/test/groovy/mop/StaticExpandoPropertyTest.groovy]
not a complete guarantee that i've followed all the behaviour checks full
rebuild back into core code stream. there is alot of convoluted code in
expandoMetaClass and metaClassImpl, so its very easy to get lost so i didnt
want to go to far down the rabbit hole
however this is the basic fix for what i felt is inconsistent behaviour that
current ExpandoMetaClass does when you try and work with metaClass.'static'. I
feel this is somewhat closer and behaves as you'd expect things to at a
semantic level
I hope this helps
regards Will
> Inconsistent metaClass capability for .static properties and methods vs
> ordinary dynamic properties and methods
> -
>
> Key: GROOVY-10392
> URL: https://issues.apache.org/jira/browse/GROOVY-10392
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler
>Affects Versions: 3.0.9, 4.0.0-beta-2
>Reporter: William Woodman
>Priority: Minor
> Fix For: 3.x, 4.x
>
>
> runtime addition and working with static dynamic properties and methods is
> inconsistent and doesnt work the same as the equivalent capability for
> ordinary dynamic properties and methods.
> I've tried to show the problem in the script code below
> {code:groovy}
> package script
> class SomeClass {
> static String classDeclaredStatName = "in class definition static name"
> String name = "instance level name"
> }
> //add a new property to metaclass - works fine
> SomeClass.metaClass.dynProp = "dynamic property added"
> SomeClass.metaClass.dynMethod = \{"dynamic method added as closure"}
> SomeClass.metaClass.static.dynStaticProp = "dynamic static property added"
> SomeClass.metaClass.static.dynStaticMethod = \{"dynamic static method added"}
> assert SomeClass.classDeclaredStatName == "in class definition static name"
> assert SomeClass.dynStaticMethod() == "dynamic static method added"
> //this forces conversion of metaClassImpl to expandoMetaClass
> SomeClass myc = new SomeClass()
> assert myc.name == "instance level name"
> assert myc.classDeclaredStatName == "in class definition static name"
> assert myc.dynProp == "dynamic property added"
> assert myc.dynMethod() == "dynamic method added as closure"
> assert myc.dynStaticMethod() == "dynamic static method added"
> def res
> res = myc.metaClass.properties //returns list of metaBeanProperty
> res = myc.metaClass.getMetaMethods() //works and returns list of metaMethods
> //This is the only method for static's in MOP - this works but you have to
> know the name of the method in advance
> res = myc.metaClass.getStaticMetaMethod("dynStaticMethod", [] as ArrayList)
> //these functions are missing from MOP and would enable you to query for
> static props/methods
> res = myc.metaClass.getStaticMetaMethods() //this method doesnt exist in
> MOP api
> res = myc.metaClass.getStaticProperties() //this method doesnt
> exist in MOP api either
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GROOVY-6603) Static type checks for closure parameters of methods
[
https://issues.apache.org/jira/browse/GROOVY-6603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-6603:
Fix Version/s: 4.0.0-rc-3
> Static type checks for closure parameters of methods
>
>
> Key: GROOVY-6603
> URL: https://issues.apache.org/jira/browse/GROOVY-6603
> Project: Groovy
> Issue Type: Improvement
> Components: Static Type Checker
>Affects Versions: 2.3.0-beta-1
>Reporter: Maxim Medvedev
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0-rc-3
>
>
> Static type checker should check calls to closure parameters with provided
> @ClosureParams information:
> {code}
> @CompileStatic
> void foo(@ClosureParams(value = FromString, options = "java.lang.Number")
> Closure cl) {
> cl("a") //Compilation should fail here
> }
> {code}
> Of course, these checks are not applicable to reassigned parameters, but in
> most cases closure parameters are not reassigned.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GROOVY-4266) CLONE -Wrong generation of import statements in stubs
[
https://issues.apache.org/jira/browse/GROOVY-4266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles resolved GROOVY-4266.
-
Resolution: Fixed
https://github.com/apache/groovy/commit/36d2c3baccfcd7635806db820f7857c42175d6ab
> CLONE -Wrong generation of import statements in stubs
> -
>
> Key: GROOVY-4266
> URL: https://issues.apache.org/jira/browse/GROOVY-4266
> Project: Groovy
> Issue Type: Bug
> Components: Stub generator / Joint compiler
>Affects Versions: 1.7.3
> Environment: Windows XP, Sun JDK 1.6.0_19
>Reporter: Dmytro Rud
>Assignee: Eric Milles
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> NOTE: Below is fixed, this issue is for tracking additional impots added at
> end of other imports, e.g. {{import java.io.*;}}
>
> Single-type import declarations in Groovy files are collected/converted into
> type-on-demand import declarations by the stub compiler -- in other words,
> {code}
> import my.package.Type1
> import my.package.Type2
> {code}
> becomes
> {code}
> import my.package.*;
> {code}
> This breaks the type shadowing mechanisms described in Section 7.5.1 of the
> Java Language Specification (3rd edition) and leads to Java compiler errors
> like "cannot decide which of the classes to use".
> Moreover, current implementations is based on an unordered set, thus
> destroying the order of import declarations.
> Attached patch solves these issues by preserving both the form and the order
> of original import declarations.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [groovy] eric-milles merged pull request #1669: GROOVY-4266: stubgen: only write static imports
eric-milles merged pull request #1669: URL: https://github.com/apache/groovy/pull/1669 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@groovy.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (GROOVY-10447) Bump checkstyle to 9.2.1 (build dependency)
Paul King created GROOVY-10447: -- Summary: Bump checkstyle to 9.2.1 (build dependency) Key: GROOVY-10447 URL: https://issues.apache.org/jira/browse/GROOVY-10447 Project: Groovy Issue Type: Dependency upgrade Reporter: Paul King -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GROOVY-10446) Bump logback to 1.2.10 (test dependency)
Paul King created GROOVY-10446: -- Summary: Bump logback to 1.2.10 (test dependency) Key: GROOVY-10446 URL: https://issues.apache.org/jira/browse/GROOVY-10446 Project: Groovy Issue Type: Dependency upgrade Reporter: Paul King Assignee: Paul King Please see GROOVY-10431 for more comments relating to Groovy config files. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GROOVY-10445) Bump Spotbugs/Spotbugs annotations to 4.5.3 (build dependency)
Paul King created GROOVY-10445: -- Summary: Bump Spotbugs/Spotbugs annotations to 4.5.3 (build dependency) Key: GROOVY-10445 URL: https://issues.apache.org/jira/browse/GROOVY-10445 Project: Groovy Issue Type: Dependency upgrade Reporter: Paul King Includes log4j version bumps for CVE-2021-45105 and CVE-2021-44832 (only affects the build, not relevant for Groovy itself) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GROOVY-10232) Massive increase in memory usage due to CacheableCallSite
[ https://issues.apache.org/jira/browse/GROOVY-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17471824#comment-17471824 ] Emond Papegaaij commented on GROOVY-10232: -- I can also confirm that the memory usage has dropped back to what it was in groovy 2. Do you have any idea when we can expect a 3.0.10 release with this fix? > Massive increase in memory usage due to CacheableCallSite > - > > Key: GROOVY-10232 > URL: https://issues.apache.org/jira/browse/GROOVY-10232 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 3.0.9 >Reporter: Emond Papegaaij >Assignee: Daniel Sun >Priority: Major > Fix For: 3.0.10, 4.0.0-rc-3 > > Attachments: Screenshot_20210913_161502.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > When upgrading our tests from Spock 1.3 with Groovy 2.5 to Spock 2.0 with > Groovy 3.0.9, we are seeing issue with memory usage caused by > CacheableCallSite. This memory seems to be retained in classes and is > therefore never freed. A single Spock test class can take as much as 150mb > memory. The total amount of memory sums up to several gigabytes of additional > memory, causing our tests to take about 3 times as much memory as with Spock > 1.3 and Groovy 2.5. -- This message was sent by Atlassian Jira (v8.20.1#820001)
