[jira] [Resolved] (GROOVY-11284) Generated size() method on records performs unnecessary boxing
[
https://issues.apache.org/jira/browse/GROOVY-11284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-11284.
Resolution: Fixed
> Generated size() method on records performs unnecessary boxing
> --
>
> Key: GROOVY-11284
> URL: https://issues.apache.org/jira/browse/GROOVY-11284
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.17
>Reporter: Oscar N
>Assignee: Paul King
>Priority: Minor
> Fix For: 4.0.19, 5.0.0-alpha-6
>
>
> I have the following code:
> {code:groovy}
> import groovy.transform.CompileStatic
> @CompileStatic
> static void main(String[] args) {
> println(new Person("John", 42).size())
> }
> @CompileStatic
> record Person(String name, int age) {} {code}
> When checking the compiled output, the size method performs unnecessary
> boxing:
> {code:java}
> @Generated
> public final int size() {
> return Integer.valueOf(2);
> }
> {code}
> {code:java}
> // access flags 0x11
> public final size()I
> @Lgroovy/transform/Generated;()
> L0
> ICONST_2
> INVOKESTATIC java/lang/Integer.valueOf (I)Ljava/lang/Integer;
> INVOKEVIRTUAL java/lang/Integer.intValue ()I
> IRETURN
> L1
> LOCALVARIABLE this Lorg/example/Person; L0 L1 0
> MAXSTACK = 1
> MAXLOCALS = 1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-11285) Generated toList() and toMap() methods on records perform unnecessary wrapping
[
https://issues.apache.org/jira/browse/GROOVY-11285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-11285.
Resolution: Fixed
> Generated toList() and toMap() methods on records perform unnecessary wrapping
> --
>
> Key: GROOVY-11285
> URL: https://issues.apache.org/jira/browse/GROOVY-11285
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.17
>Reporter: Oscar N
>Assignee: Paul King
>Priority: Minor
> Fix For: 4.0.19, 5.0.0-alpha-6
>
>
> I have the following code:
> {code:groovy}
> import groovy.transform.CompileStatic
> @CompileStatic
> static void main(String[] args) {
> println(new Person("John", 42).size())
> }
> @CompileStatic
> record Person(String name, int age) {}
> {code}
> When checking the compiled output, the toList and toMap methods appear to
> call a helper method to create a mutable list and map, respectively. These
> are then wrapped inside another ArrayList/LinkedHashMap:
> {code:java}
> @Generated
> public final List toList() {
> return new ArrayList(ScriptBytecodeAdapter.createList(new
> Object[]{this.name(), this.age()}));
> }
> @Generated
> public final Map toMap() {
> return new LinkedHashMap(ScriptBytecodeAdapter.createMap(new
> Object[]{"name", this.name(), "age", this.age()}));
> }
> {code}
> This wrapping is unnecessary.
> Sidenote: Should these return mutable collections considering records are
> expected to be heavily immutable? If not, might be worth considering changing
> them to immutable in Groovy 5, something along the lines of:
> {code:java}
> @Generated
> public final List toList() {
> return List.of(new Object[]{this.name(), this.age()});
> }
> @Generated
> public final Map toMap() {
> return Map.of(new Object[]{"name", this.name(), "age", this.age()});
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11285) Generated toList() and toMap() methods on records perform unnecessary wrapping
[
https://issues.apache.org/jira/browse/GROOVY-11285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-11285:
---
Fix Version/s: 5.0.0-alpha-6
> Generated toList() and toMap() methods on records perform unnecessary wrapping
> --
>
> Key: GROOVY-11285
> URL: https://issues.apache.org/jira/browse/GROOVY-11285
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.17
>Reporter: Oscar N
>Assignee: Paul King
>Priority: Minor
> Fix For: 4.0.19, 5.0.0-alpha-6
>
>
> I have the following code:
> {code:groovy}
> import groovy.transform.CompileStatic
> @CompileStatic
> static void main(String[] args) {
> println(new Person("John", 42).size())
> }
> @CompileStatic
> record Person(String name, int age) {}
> {code}
> When checking the compiled output, the toList and toMap methods appear to
> call a helper method to create a mutable list and map, respectively. These
> are then wrapped inside another ArrayList/LinkedHashMap:
> {code:java}
> @Generated
> public final List toList() {
> return new ArrayList(ScriptBytecodeAdapter.createList(new
> Object[]{this.name(), this.age()}));
> }
> @Generated
> public final Map toMap() {
> return new LinkedHashMap(ScriptBytecodeAdapter.createMap(new
> Object[]{"name", this.name(), "age", this.age()}));
> }
> {code}
> This wrapping is unnecessary.
> Sidenote: Should these return mutable collections considering records are
> expected to be heavily immutable? If not, might be worth considering changing
> them to immutable in Groovy 5, something along the lines of:
> {code:java}
> @Generated
> public final List toList() {
> return List.of(new Object[]{this.name(), this.age()});
> }
> @Generated
> public final Map toMap() {
> return Map.of(new Object[]{"name", this.name(), "age", this.age()});
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-11284) Generated size() method on records performs unnecessary boxing
[
https://issues.apache.org/jira/browse/GROOVY-11284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-11284:
---
Fix Version/s: 5.0.0-alpha-6
> Generated size() method on records performs unnecessary boxing
> --
>
> Key: GROOVY-11284
> URL: https://issues.apache.org/jira/browse/GROOVY-11284
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 4.0.17
>Reporter: Oscar N
>Assignee: Paul King
>Priority: Minor
> Fix For: 4.0.19, 5.0.0-alpha-6
>
>
> I have the following code:
> {code:groovy}
> import groovy.transform.CompileStatic
> @CompileStatic
> static void main(String[] args) {
> println(new Person("John", 42).size())
> }
> @CompileStatic
> record Person(String name, int age) {} {code}
> When checking the compiled output, the size method performs unnecessary
> boxing:
> {code:java}
> @Generated
> public final int size() {
> return Integer.valueOf(2);
> }
> {code}
> {code:java}
> // access flags 0x11
> public final size()I
> @Lgroovy/transform/Generated;()
> L0
> ICONST_2
> INVOKESTATIC java/lang/Integer.valueOf (I)Ljava/lang/Integer;
> INVOKEVIRTUAL java/lang/Integer.intValue ()I
> IRETURN
> L1
> LOCALVARIABLE this Lorg/example/Person; L0 L1 0
> MAXSTACK = 1
> MAXLOCALS = 1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-11204) Incorrect overload selection for subclasses
[
https://issues.apache.org/jira/browse/GROOVY-11204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17808776#comment-17808776
]
Eric Milles edited comment on GROOVY-11204 at 1/19/24 6:27 PM:
---
GROOVY-11258 discusses the possibility of adding a rule like java's to the
method selection where the most-specific type is the one used. In this case,
when 2 overloads are available for the {{MyConfigurer}} argument:
{code:java}
SecurityConfigurer AbstractConfiguredSecurityBuilder.apply(
org.springframework.security.config.annotation.SecurityConfigurer)
SecurityConfigurerAdapter AbstractConfiguredSecurityBuilder.apply(
org.springframework.security.config.annotation.SecurityConfigurerAdapter)
{code}
Because {{SecurityConfigurerAdapter}} is a {{SecurityConfigurer}}, the
{{SecurityConfigurer}} overload would be discarded (kind of like covariant
bridge methods).
was (Author: emilles):
GROOVY-11258 discusses the possibility of adding a rule like java's to the
method selection where the most-specific type is the one used. In this case,
when 2 overloads are available for the {{MyConfigurer}} argument:
{code:java}
SecurityConfigurer AbstractConfiguredSecurityBuilder.apply(
org.springframework.security.config.annotation.SecurityConfigurer)
SecurityConfigurerAdapter AbstractConfiguredSecurityBuilder.apply(
org.springframework.security.config.annotation.SecurityConfigurerAdapter)
{code}
Because {{SecurityConfigurerAdapter}} is a {{SecurityConfigurer}}, the
{{SecurityConfigurer}} overload would be discarded (kind of like covariant
bride methods).
> Incorrect overload selection for subclasses
> ---
>
> Key: GROOVY-11204
> URL: https://issues.apache.org/jira/browse/GROOVY-11204
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 4.0.12
>Reporter: Christopher Smith
>Assignee: Eric Milles
>Priority: Major
>
> I'm writing a Spring Security configurer and trying to add it to my
> configuration using {{apply(C)}}, but the Groovy compiler selects the wrong
> overload, and necessary initialization is not performed.
> {code:groovy}
> @Grab('org.springframework.security:spring-security-config:5.7.11')
> import
> org.springframework.security.config.annotation.authentication.builders.*
> import org.springframework.security.config.annotation.web.configurers.*
> import org.springframework.security.config.annotation.web.builders.*
> @Grab('org.springframework.security:spring-security-web:5.7.11')
> import org.springframework.security.web.*
> @Grab('javax.servlet:servlet-api:2.5')
> // AbstractHttpConfigurer extends SecurityConfigurerAdapter
> class MyConfigurer extends AbstractHttpConfigurer
> {}
> SecurityFilterChain securityFilterChain(HttpSecurity http) {
> http.apply(new MyConfigurer())
> // ^ should select apply(SecurityConfigurerAdapter), but selects
> apply(SecurityConfigurer)
> .and()
> .build()
> }
> securityFilterChain(new HttpSecurity({ }, new AuthenticationManagerBuilder({
> }), [:]))
> {code}
> This is probably a result of an edge case in the generics, since the bounds
> on the overloads are determined by type parameters.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-11204) Incorrect overload selection for subclasses
[
https://issues.apache.org/jira/browse/GROOVY-11204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17808776#comment-17808776
]
Eric Milles commented on GROOVY-11204:
--
GROOVY-11258 discusses the possibility of adding a rule like java's to the
method selection where the most-specific type is the one used. In this case,
when 2 overloads are available for the {{MyConfigurer}} argument:
{code:java}
SecurityConfigurer AbstractConfiguredSecurityBuilder.apply(
org.springframework.security.config.annotation.SecurityConfigurer)
SecurityConfigurerAdapter AbstractConfiguredSecurityBuilder.apply(
org.springframework.security.config.annotation.SecurityConfigurerAdapter)
{code}
Because {{SecurityConfigurerAdapter}} is a {{SecurityConfigurer}}, the
{{SecurityConfigurer}} overload would be discarded (kind of like covariant
bride methods).
> Incorrect overload selection for subclasses
> ---
>
> Key: GROOVY-11204
> URL: https://issues.apache.org/jira/browse/GROOVY-11204
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 4.0.12
>Reporter: Christopher Smith
>Assignee: Eric Milles
>Priority: Major
>
> I'm writing a Spring Security configurer and trying to add it to my
> configuration using {{apply(C)}}, but the Groovy compiler selects the wrong
> overload, and necessary initialization is not performed.
> {code:groovy}
> @Grab('org.springframework.security:spring-security-config:5.7.11')
> import
> org.springframework.security.config.annotation.authentication.builders.*
> import org.springframework.security.config.annotation.web.configurers.*
> import org.springframework.security.config.annotation.web.builders.*
> @Grab('org.springframework.security:spring-security-web:5.7.11')
> import org.springframework.security.web.*
> @Grab('javax.servlet:servlet-api:2.5')
> // AbstractHttpConfigurer extends SecurityConfigurerAdapter
> class MyConfigurer extends AbstractHttpConfigurer
> {}
> SecurityFilterChain securityFilterChain(HttpSecurity http) {
> http.apply(new MyConfigurer())
> // ^ should select apply(SecurityConfigurerAdapter), but selects
> apply(SecurityConfigurer)
> .and()
> .build()
> }
> securityFilterChain(new HttpSecurity({ }, new AuthenticationManagerBuilder({
> }), [:]))
> {code}
> This is probably a result of an edge case in the generics, since the bounds
> on the overloads are determined by type parameters.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-10887) groovyc STC loses generic information in extension methods
[
https://issues.apache.org/jira/browse/GROOVY-10887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17808769#comment-17808769
]
Eric Milles commented on GROOVY-10887:
--
Is this still an issue under 4.0.18? If so, could you provide a sample project?
> groovyc STC loses generic information in extension methods
> --
>
> Key: GROOVY-10887
> URL: https://issues.apache.org/jira/browse/GROOVY-10887
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 4.0.6, 4.0.7
>Reporter: Christopher Smith
>Assignee: Eric Milles
>Priority: Major
>
> N.B.: This code compiles as expected under GRECLIPSE (both the 2022-12-06 and
> 2022-12-26 nightlies) but fails under groovyc.
> I have extension methods that are intended to be applied to Spring
> Integration DSLs:
> {code}
> public final class SpringIntegrationDefaultMethods {
> public static MessageChannelSpec>
> S markMessagesAsJumpered(S self) {
> return self.interceptor(new JumperInterceptor()); // returns S
> }
> }
> {code}
> {code}
> moduleName = example-util-spring-integration
> moduleVersion = 0.0.1
> extensionClasses =
> com.example.util.spring.integration.groovy.SpringIntegrationDefaultMethods
> {code}
> From a Groovy configuration class:
> {code}
> @Bean(CHANNEL_DISPATCH_MESSAGE)
> MessageChannel dispatchQueueOutgoing() {
> // org.springframework.integration.dsl.MessageChannels.
> publishSubscribe(true) // line 49
> .minSubscribers(2)
> .markMessagesAsJumpered()
> .get()
> }
> {code}
> In Eclipse, this compiles as expected. In groovyc 4.0.6 and 4.0.7, I get
> {code}
> [ERROR] /home/christopher/git/.../DispatchHandlingIntegration.groovy: 49:
> [Static type checking] - Cannot find matching method S#get(). Please check if
> the declared type is correct and if the method exists.
> [ERROR] @ line 49, column 9.
> [ERROR]publishSubscribe(true)
> {code}
> Adding an explicit type witness
> {code}
> .>
> markMessagesAsJumpered()
> {code}
> resolves the error in groovyc.
--
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)
