[jira] [Updated] (GROOVY-7306) Invalid stub generated for a constructor using a generic bounded parameter
[
https://issues.apache.org/jira/browse/GROOVY-7306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-7306:
Fix Version/s: 2.5.21
> Invalid stub generated for a constructor using a generic bounded parameter
> --
>
> Key: GROOVY-7306
> URL: https://issues.apache.org/jira/browse/GROOVY-7306
> Project: Groovy
> Issue Type: Bug
> Components: Stub generator / Joint compiler
>Affects Versions: 2.4.0, 2.4.1
>Reporter: Frank Pavageau
>Assignee: Eric Milles
>Priority: Major
> Fix For: 3.0.8, 4.0.0-alpha-3, 2.5.21
>
> Attachments: generic-superclass-stub.tar.gz
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Given the 2 following classes:
> {code}
> class A {
> final T value
> A(T value) {
> this.value = value
> }
> }
> {code}
> and
> {code}
> class B extends A {
> B(Integer value) {
> super(value)
> }
> }
> {code}
> the generated stub for B does not compile, as the constructor parameter is
> cast to the bounded type instead of the actual type:
> {code}
> public class B
> extends A {
> ;
> public B
> (java.lang.Integer value) {
> super ((java.lang.Number)null);
> }
> // ...
> }
> {code}
> The error returned by the compiler is:
> {noformat}
> target/generated-sources/groovy-stubs/main/B.java:[13,1] constructor A in
> class A cannot be applied to given types;
> required: java.lang.Integer
> found: java.lang.Number
> reason: actual argument java.lang.Number cannot be converted to
> java.lang.Integer by method invocation conversion
> {noformat}
> I've attached a test case, which is also available on
> [Github|https://github.com/fpavageau/generic-superclass-stub].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-10464) Wrong cast for type parameter in generated stubs
[
https://issues.apache.org/jira/browse/GROOVY-10464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10464:
-
Fix Version/s: 2.5.21
> Wrong cast for type parameter in generated stubs
>
>
> Key: GROOVY-10464
> URL: https://issues.apache.org/jira/browse/GROOVY-10464
> Project: Groovy
> Issue Type: Bug
> Components: Stub generator / Joint compiler
>Affects Versions: 3.0.9, 4.0.0
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Fix For: 3.0.10, 4.0.1, 2.5.21
>
>
> Consider the following:
> {code:groovy}
> abstract class A {
> A(Class t) {
> }
> }
> class C extends A {
> C() {
> super(E) // stubgen: "super((Class)null);"
> }
> }
> enum E {
> }
> {code}
> When class C is used by java sources, the joint compiler / stub generator
> creates an error for the java source. I was only able to work around this by
> changing "Class" to "Class" which is no longer type-safe. In the case of
> the example given in the comments of GROOVY-10122 where the type parameter T
> is the type of the constructor parameter, it would need to be changed to
> Object.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-6282) groovyc ant task generates invalid stub (picks wrong constructor) and fails in Java 1.7 compilation
[
https://issues.apache.org/jira/browse/GROOVY-6282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-6282:
Fix Version/s: 2.5.21
> groovyc ant task generates invalid stub (picks wrong constructor) and fails
> in Java 1.7 compilation
> ---
>
> Key: GROOVY-6282
> URL: https://issues.apache.org/jira/browse/GROOVY-6282
> Project: Groovy
> Issue Type: Bug
> Components: Stub generator / Joint compiler
>Affects Versions: 2.1.6
>Reporter: Lari Hotari
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0-beta-1, 3.0.9, 2.5.21
>
>
> The current master branch of Grails won't compile with Java 1.7 . It compiles
> ok with Java 1.6 .
> The error message is:
> {code}
> [ant:groovyc] /tmp/groovy-generated-614097634888075990-java-sourc
> [ant:groovyc]
> e/org/codehaus/groovy/grails/cli/interactive/GrailsInteractiveCompletor.java:15:
> error: unreported exception IOException; must b
> [ant:groovyc] e caught or declared to be thrown
> [ant:groovyc] super ((java.io.InputStream)null);
> [ant:groovyc] ^
> {code}
> Reproducing error:
> {code}
> git clone https://github.com/grails/grails-core.git
> cd grails-core
> git checkout 1239b8ed
> ./gradlew clean compileGroovy
> {code}
> Generated stub with error:
> {code}
> package org.codehaus.groovy.grails.cli.interactive;
> import java.lang.*;
> import java.io.*;
> import java.net.*;
> import java.util.*;
> import groovy.lang.*;
> import groovy.util.*;
> @groovy.transform.CompileStatic() public class GrailsInteractiveCompletor
> extends jline.SimpleCompletor implements
> groovy.lang.GroovyObject {
> public GrailsInteractiveCompletor
> (grails.util.BuildSettings settings, java.util.List
> scriptResources) {
> super ((java.io.InputStream)null);
> }
> public groovy.lang.MetaClass getMetaClass() { return
> (groovy.lang.MetaClass)null;}
> public void setMetaClass(groovy.lang.MetaClass mc) { }
> public java.lang.Object invokeMethod(java.lang.String method,
> java.lang.Object arguments) { return null;}
> public java.lang.Object getProperty(java.lang.String property) { return
> null;}
> public void setProperty(java.lang.String property, java.lang.Object value) {
> }
> public grails.util.BuildSettings getSettings() { return
> (grails.util.BuildSettings)null;}
> public void setSettings(grails.util.BuildSettings value) { }
> public java.util.Map getCompletorCache() { return (java.util.Map)null;}
> public void setCompletorCache(java.util.Map value) { }
> @java.lang.Override() public int complete(java.lang.String buffer, int
> cursor, java.util.List clist) { return (int)0;}
> public static java.lang.String[] getScriptNames(java.util.List
> scriptResources) { return (java.lang.String[])null;}
> }
> {code}
> However the stub is ok if I remove "groovyOptions.useAnt = true" and
> "options.useAnt = true" from the build.gradle of Grails:
> {code}
> package org.codehaus.groovy.grails.cli.interactive;
> import java.lang.*;
> import java.io.*;
> import java.net.*;
> import java.util.*;
> import groovy.lang.*;
> import groovy.util.*;
> @groovy.transform.CompileStatic() public class GrailsInteractiveCompletor
> extends jline.SimpleCompletor implements
> groovy.lang.GroovyObject {
> public GrailsInteractiveCompletor
> (grails.util.BuildSettings settings, java.util.List
> scriptResources) {
> super ((java.lang.String)null);
> }
> public groovy.lang.MetaClass getMetaClass() { return
> (groovy.lang.MetaClass)null;}
> public void setMetaClass(groovy.lang.MetaClass mc) { }
> public java.lang.Object invokeMethod(java.lang.String method,
> java.lang.Object arguments) { return null;}
> public java.lang.Object getProperty(java.lang.String property) { return
> null;}
> public void setProperty(java.lang.String property, java.lang.Object value) {
> }
> public grails.util.BuildSettings getSettings() { return
> (grails.util.BuildSettings)null;}
> public void setSettings(grails.util.BuildSettings value) { }
> public java.util.Map getCompletorCache() { return (java.util.Map)null;}
> public void setCompletorCache(java.util.Map value) { }
> @java.lang.Override() public int complete(java.lang.String buffer, int
> cursor, java.util.List clist) { return (int)0;}
> public static java.lang.String[] getScriptNames(java.util.List
> scriptResources) { return (java.lang.String[])null;}
> }
> {code}
> diff of generated stubs:
> {code}
> < super ((java.lang.String)null);
> ---
> > super ((java.io.InputStream)null);
> {code}
> Source code of GrailsInteractiveCompletor:
> https://github.com/grails/grails-core/blob/1239b8edb606cca1c137285393a366898e18e196/grails-bootstrap/src/main/groovy/org/codehaus/groovy/grails/cli/interactive/GrailsInteractiveCompletor.groovy#L47
> however
[jira] [Updated] (GROOVY-10407) unchecked method invocation warning in generated stubs
[
https://issues.apache.org/jira/browse/GROOVY-10407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10407:
-
Fix Version/s: 2.5.21
> unchecked method invocation warning in generated stubs
>
>
> Key: GROOVY-10407
> URL: https://issues.apache.org/jira/browse/GROOVY-10407
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 3.0.9
>Reporter: Joseph Price
>Assignee: Eric Milles
>Priority: Minor
> Fix For: 3.0.10, 4.0.0-rc-2, 2.5.21
>
>
>
> When calling a groovy class from java that takes a Map in the constructor,
> the generated stubs have what looks to be a second constructor that takes a
> null for the parameter, that casted to a raw Map. Since this happens in
> generated code not under my control, this prevents enabling -Werror across
> the project. Providing type arguments for the map or leaving the cast off
> would fix the warning, but I also wonder if suppressing the constructor is
> possible.
> Below are the commands I ran, along with the contents of the java and groovy
> files:
> {code:java}
> groovyc -j -FWerror -FXlint:unchecked Test.java Base.groovy
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> Compile error during compilation with javac.
> /var/folders/mm/8s324dkd6sb1ktx0g48pbvhcgq/T/groovy-generated--java-source3303303787390544788/Base.java:13:
> warning: [unchecked] unchecked method invocation: constructor in
> class Parent is applied to given types
> super ((java.util.Map)null);
> ^
> required: Map
> found: Map
> /var/folders/mm/8s324dkd6sb1ktx0g48pbvhcgq/T/groovy-generated--java-source3303303787390544788/Base.java:13:
> warning: [unchecked] unchecked conversion
> super ((java.util.Map)null);
> ^
> required: Map
> found: Map
> error: warnings found and -Werror specified
> 1 error
> 2 warnings
> {code}
>
> {code:java}
> cat -p Base.groovy
> class Parent {
> Parent(Map map) {
> }
> }
> class Base extends Parent {
> Base(Map map) {
> super(map);
> }
> }
>
> cat -p Test.java
> import java.util.Map;
> class Test {
> Base b = new Base(Map.of());
> } {code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-10122) Wrong cast in stubs generated
[
https://issues.apache.org/jira/browse/GROOVY-10122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10122:
-
Fix Version/s: 2.5.21
> Wrong cast in stubs generated
> -
>
> Key: GROOVY-10122
> URL: https://issues.apache.org/jira/browse/GROOVY-10122
> Project: Groovy
> Issue Type: Bug
> Components: Stub generator / Joint compiler
>Affects Versions: 3.0.8
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0-beta-1, 3.0.9, 2.5.21
>
> Attachments: mre.zip
>
>
> {noformat}
> $ #unzip
> $ cd mre/src
> $ groovy -version
> Groovy Version: 3.0.8 JVM: 15.0.1 Vendor: Oracle Corporation OS: Mac OS X
> $ groovyc -j JavaBase.java GroovyInheritor.groovy JavaUsage.java
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> Compile error during compilation with javac.
> /var/folders/t7/26sb5vb111n3ljbmwv4s340mgn/T/groovy-generated--java-source12536140884342736527/GroovyInheritor.java:14:
> error: incompatible types: Object cannot be converted to Integer
> super((java.lang.Object)null);
> ^
> Note: Some messages have been simplified; recompile with -Xdiags:verbose to
> get full output
> 1 error
> 1 error
> {noformat}
> The issue is not reproducible in 3.0.7.
> Same issue can be reproduced opening the directory in IntelliJ and invoking
> Rebuild Project.
> Related https://youtrack.jetbrains.com/issue/IDEA-270650
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-9777) Stub missing cast, depending on constructor order
[
https://issues.apache.org/jira/browse/GROOVY-9777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-9777:
Fix Version/s: 2.5.21
> Stub missing cast, depending on constructor order
> -
>
> Key: GROOVY-9777
> URL: https://issues.apache.org/jira/browse/GROOVY-9777
> Project: Groovy
> Issue Type: Bug
> Components: Stub generator / Joint compiler
>Affects Versions: 3.0.6
>Reporter: Keegan Witt
>Assignee: Eric Milles
>Priority: Major
> Fix For: 3.0.8, 4.0.0-alpha-3, 2.5.21
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
>
> {code:java}
> package org.apache.groovy.tests
> class Parent {
> Parent(Object context) {
> this(context.class.name)
> }
> Parent(Class context) {
> this(context.name)
> }
> Parent(String context) {}
> }
> class Child extends Parent {
> Child() {
> super(Child.class.name)
> }
> }
> {code}
> Generates this stub for Child, missing the cast in the constructor
> {code:java}
> package org.apache.groovy.tests;
> import java.lang.*;
> import java.util.*;
> import java.io.*;
> import java.net.*;
> import groovy.lang.*;
> import groovy.util.*;
> public class Child
> extends org.apache.groovy.tests.Parent {
> ;
> public Child
> () {
> super (null);
> }
> @groovy.transform.Generated() @groovy.transform.Internal()
> @java.beans.Transient() public groovy.lang.MetaClass getMetaClass() { return
> (groovy.lang.MetaClass)null;}
> @groovy.transform.Generated() @groovy.transform.Internal() public void
> setMetaClass(groovy.lang.MetaClass mc) { }
> }
> {code}
> Which causes the Java compilation to fail
> {noformat}
> Child.java:[14,1] reference to Parent is ambiguous
>both constructor Parent(java.lang.Class) in
> org.apache.groovy.tests.Parent and constructor Parent(java.lang.String) in
> org.apache.groovy.tests.Parent match
> {noformat}
>
> But
> {code:java}
> package org.apache.groovy.tests
> class Parent {
> Parent(Class context) {
> this(context.name)
> }
> Parent(String context) {}
> Parent(Object context) {
> this(context.class.name)
> }
> }
> class Child extends Parent {
> Child() {
> super(Child.class.name)
> }
> }
> {code}
> Generates this stub for Child, with the cast in it
> {code:java}
> package org.apache.groovy.tests;
> import java.lang.*;
> import java.util.*;
> import java.io.*;
> import java.net.*;
> import groovy.lang.*;
> import groovy.util.*;
> public class Child
> extends org.apache.groovy.tests.Parent {
> ;
> public Child
> () {
> super ((java.lang.Class)null);
> }
> @groovy.transform.Generated() @groovy.transform.Internal()
> @java.beans.Transient() public groovy.lang.MetaClass getMetaClass() { return
> (groovy.lang.MetaClass)null;}
> @groovy.transform.Generated() @groovy.transform.Internal() public void
> setMetaClass(groovy.lang.MetaClass mc) { }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-10905) Improve matching implicit arg closures to SAM types
[
https://issues.apache.org/jira/browse/GROOVY-10905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles resolved GROOVY-10905.
--
Fix Version/s: 5.0.0-alpha-1
(was: 5.x)
Resolution: Fixed
https://github.com/apache/groovy/commit/e29b9288ee10d6ebe0443722294021f64371fbad
> Improve matching implicit arg closures to SAM types
> ---
>
> Key: GROOVY-10905
> URL: https://issues.apache.org/jira/browse/GROOVY-10905
> Project: Groovy
> Issue Type: Improvement
>Reporter: Paul King
>Assignee: Paul King
>Priority: Major
> Fix For: 5.0.0-alpha-1
>
>
> When matching Closures to SAM types, we have special treatment for Closures
> without a formal parameter section. Such Closures may have 0 or 1 arguments,
> e.g.:
> {code}
> foo { println 42 } // zero-arg case
> bar { println 'arg:' + it } // one-arg case
> {code}
> Our current matching says that because of this ambiguity, we know nothing
> about the number of parameters, but this assumption is throwing away
> information: the fact that we are expecting 0 or 1 args. I'd like to propose
> for Groovy 5 that we match 0 or 1-arg SAMs more closely that say a 2-arg SAM
> for such a Closure.
> The impact of this is that there will be less ambiguity errors (or
> conversely, less places where we need to cast to get the correct method). It
> obviously doesn't help if there are both 0 and 1-arg options available, where
> casting would still be required.
> Example where 1 and 2-arg variants exist:
> {code}
> def method1(IntUnaryOperator unary) { '1a' }
> def method1(IntBinaryOperator binary) { '1b' }
> // unchanged behavior
> assert method1{ x -> } == '1a'// explicit 1 arg
> assert method1{ x, y -> } == '1b'// explicit 2 args
> assert method1({ } as IntUnaryOperator) == '1a'// explicit cast for
> implicit arg
> assert method1({ } as IntBinaryOperator) == '1b'// explicit cast for
> implicit arg
> // "method1{ -> }" would remain ambiguous
> // proposed change: implicit arg will match Unary over Binary since Unary is
> the only match for 0 or 1 args
> assert method1{ } == '1a' // currently fails with Ambiguous method overloading
> {code}
> Example where 0 and 2-arg variants exist:
> {code}
> def method2(IntSupplier supplier) { '2a' }
> def method2(IntBinaryOperator binary) { '2b' }
> // unchanged behavior
> assert method2{ -> } == '2a'
> assert method2{ x, y -> } == '2b'
> assert method2({ } as IntSupplier) == '2a'
> assert method2({ } as IntBinaryOperator) == '2b'
> // "method2{ a -> }" would remain Ambiguous
> // proposed change: implicit arg will match Supplier over Binary since Unary
> is the only match for 0 or 1 args
> assert method2{} == '2a' // currently fails with Ambiguous method overloading
> {code}
> Example where 0 and 1-arg variants exist:
> {code}
> def method3(IntSupplier supplier) { '3a' }
> def method3(IntUnaryOperator unary) { '3b' }
> assert method3{ -> } == '3a'
> assert method3{ x -> } == '3b'
> assert method3({ } as IntSupplier) == '3a'
> assert method3({ } as IntUnaryOperator) == '3b'
> // "method3{ }" will remain Ambiguous since "0 or 1" matches both; error
> message is unchanged
> {code}
> Example where 0, 1 and 2-arg variants exist:
> {code}
> def method4(IntSupplier supplier) { '4a' }
> def method4(IntUnaryOperator unary) { '4b' }
> def method4(IntBinaryOperator binary) { '4c' }
> assert method4{ -> } == '4a'
> assert method4{ x -> } == '4b'
> assert method4{ x, y -> } == '4c'
> assert method4({ } as IntSupplier) == '4a'
> assert method4({ } as IntUnaryOperator) == '4b'
> assert method4({ } as IntBinaryOperator) == '4c'
> // "method4{ }" will remain Ambiguous but error message will change from:
> //Ambiguous method overloading [...] due to overlapping prototypes
> between:
> //[interface java.util.function.IntBinaryOperator]
> //[interface java.util.function.IntSupplier]
> //[interface java.util.function.IntUnaryOperator]
> // to:
> //Ambiguous method overloading [...] due to overlapping prototypes
> between:
> //[interface java.util.function.IntSupplier]
> //[interface java.util.function.IntUnaryOperator]
> // Since 0 or 1 variants will match closer than higher parameter numbers
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-10905) Improve matching implicit arg closures to SAM types
[
https://issues.apache.org/jira/browse/GROOVY-10905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17678000#comment-17678000
]
ASF GitHub Bot commented on GROOVY-10905:
-
paulk-asert merged PR #1846:
URL: https://github.com/apache/groovy/pull/1846
> Improve matching implicit arg closures to SAM types
> ---
>
> Key: GROOVY-10905
> URL: https://issues.apache.org/jira/browse/GROOVY-10905
> Project: Groovy
> Issue Type: Improvement
>Reporter: Paul King
>Assignee: Paul King
>Priority: Major
> Fix For: 5.x
>
>
> When matching Closures to SAM types, we have special treatment for Closures
> without a formal parameter section. Such Closures may have 0 or 1 arguments,
> e.g.:
> {code}
> foo { println 42 } // zero-arg case
> bar { println 'arg:' + it } // one-arg case
> {code}
> Our current matching says that because of this ambiguity, we know nothing
> about the number of parameters, but this assumption is throwing away
> information: the fact that we are expecting 0 or 1 args. I'd like to propose
> for Groovy 5 that we match 0 or 1-arg SAMs more closely that say a 2-arg SAM
> for such a Closure.
> The impact of this is that there will be less ambiguity errors (or
> conversely, less places where we need to cast to get the correct method). It
> obviously doesn't help if there are both 0 and 1-arg options available, where
> casting would still be required.
> Example where 1 and 2-arg variants exist:
> {code}
> def method1(IntUnaryOperator unary) { '1a' }
> def method1(IntBinaryOperator binary) { '1b' }
> // unchanged behavior
> assert method1{ x -> } == '1a'// explicit 1 arg
> assert method1{ x, y -> } == '1b'// explicit 2 args
> assert method1({ } as IntUnaryOperator) == '1a'// explicit cast for
> implicit arg
> assert method1({ } as IntBinaryOperator) == '1b'// explicit cast for
> implicit arg
> // "method1{ -> }" would remain ambiguous
> // proposed change: implicit arg will match Unary over Binary since Unary is
> the only match for 0 or 1 args
> assert method1{ } == '1a' // currently fails with Ambiguous method overloading
> {code}
> Example where 0 and 2-arg variants exist:
> {code}
> def method2(IntSupplier supplier) { '2a' }
> def method2(IntBinaryOperator binary) { '2b' }
> // unchanged behavior
> assert method2{ -> } == '2a'
> assert method2{ x, y -> } == '2b'
> assert method2({ } as IntSupplier) == '2a'
> assert method2({ } as IntBinaryOperator) == '2b'
> // "method2{ a -> }" would remain Ambiguous
> // proposed change: implicit arg will match Supplier over Binary since Unary
> is the only match for 0 or 1 args
> assert method2{} == '2a' // currently fails with Ambiguous method overloading
> {code}
> Example where 0 and 1-arg variants exist:
> {code}
> def method3(IntSupplier supplier) { '3a' }
> def method3(IntUnaryOperator unary) { '3b' }
> assert method3{ -> } == '3a'
> assert method3{ x -> } == '3b'
> assert method3({ } as IntSupplier) == '3a'
> assert method3({ } as IntUnaryOperator) == '3b'
> // "method3{ }" will remain Ambiguous since "0 or 1" matches both; error
> message is unchanged
> {code}
> Example where 0, 1 and 2-arg variants exist:
> {code}
> def method4(IntSupplier supplier) { '4a' }
> def method4(IntUnaryOperator unary) { '4b' }
> def method4(IntBinaryOperator binary) { '4c' }
> assert method4{ -> } == '4a'
> assert method4{ x -> } == '4b'
> assert method4{ x, y -> } == '4c'
> assert method4({ } as IntSupplier) == '4a'
> assert method4({ } as IntUnaryOperator) == '4b'
> assert method4({ } as IntBinaryOperator) == '4c'
> // "method4{ }" will remain Ambiguous but error message will change from:
> //Ambiguous method overloading [...] due to overlapping prototypes
> between:
> //[interface java.util.function.IntBinaryOperator]
> //[interface java.util.function.IntSupplier]
> //[interface java.util.function.IntUnaryOperator]
> // to:
> //Ambiguous method overloading [...] due to overlapping prototypes
> between:
> //[interface java.util.function.IntSupplier]
> //[interface java.util.function.IntUnaryOperator]
> // Since 0 or 1 variants will match closer than higher parameter numbers
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [groovy] paulk-asert merged pull request #1846: GROOVY-10905: Improve matching no-arg closures to SAM types
paulk-asert merged PR #1846: URL: https://github.com/apache/groovy/pull/1846 -- 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-10902) Dynamic constants for primitive types get default value in Java
[
https://issues.apache.org/jira/browse/GROOVY-10902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10902:
-
Fix Version/s: 3.0.15
> Dynamic constants for primitive types get default value in Java
> ---
>
> Key: GROOVY-10902
> URL: https://issues.apache.org/jira/browse/GROOVY-10902
> Project: Groovy
> Issue Type: Bug
> Components: Stub generator / Joint compiler
>Affects Versions: 3.0.14, 4.0.7
>Reporter: Onni Koskinen
>Assignee: Eric Milles
>Priority: Major
> Fix For: 3.0.15, 4.0.8
>
>
> If we define a constant that is resolved during runtime in a Groovy class and
> reference it in a Java class, it's value gets a static default value in the
> Java class. This seems to be a regression in Groovy 3.0.10 as earlier
> versions don't have the problem. Also affects all 4.0.x versions that I
> tested.
> Example:
> {code:groovy}
> // G.groovy
> class G {
> public static final int DYNAMIC_CONSTANT = (9.9).intValue()
> } {code}
> {code:java}
> // J.java
> public class J {
> public static void main(String[] args) {
> System.out.println(G.DYNAMIC_CONSTANT);
> }
> } {code}
> *Groovy 4.0.7*
> Prints 0 with the following bytecode for J#main
> {code:java}
> 0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
> 3: iconst_0
> 4: invokevirtual #4 // Method java/io/PrintStream.println:(I)V
> 7: return{code}
> *Groovy 3.0.9*
> Correctly prints 9 with the following bytecode:
> {code:java}
> 0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
> 3: getstatic #3 // Field G.DYNAMIC_CONSTANT:I
> 6: invokevirtual #4 // Method java/io/PrintStream.println:(I)V
> 9: return {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GROOVY-10902) Dynamic constants for primitive types get default value in Java
[
https://issues.apache.org/jira/browse/GROOVY-10902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10902:
-
Fix Version/s: 4.0.8
> Dynamic constants for primitive types get default value in Java
> ---
>
> Key: GROOVY-10902
> URL: https://issues.apache.org/jira/browse/GROOVY-10902
> Project: Groovy
> Issue Type: Bug
> Components: Stub generator / Joint compiler
>Affects Versions: 3.0.14, 4.0.7
>Reporter: Onni Koskinen
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.8
>
>
> If we define a constant that is resolved during runtime in a Groovy class and
> reference it in a Java class, it's value gets a static default value in the
> Java class. This seems to be a regression in Groovy 3.0.10 as earlier
> versions don't have the problem. Also affects all 4.0.x versions that I
> tested.
> Example:
> {code:groovy}
> // G.groovy
> class G {
> public static final int DYNAMIC_CONSTANT = (9.9).intValue()
> } {code}
> {code:java}
> // J.java
> public class J {
> public static void main(String[] args) {
> System.out.println(G.DYNAMIC_CONSTANT);
> }
> } {code}
> *Groovy 4.0.7*
> Prints 0 with the following bytecode for J#main
> {code:java}
> 0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
> 3: iconst_0
> 4: invokevirtual #4 // Method java/io/PrintStream.println:(I)V
> 7: return{code}
> *Groovy 3.0.9*
> Correctly prints 9 with the following bytecode:
> {code:java}
> 0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
> 3: getstatic #3 // Field G.DYNAMIC_CONSTANT:I
> 6: invokevirtual #4 // Method java/io/PrintStream.println:(I)V
> 9: return {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GROOVY-10902) Dynamic constants for primitive types get default value in Java
[
https://issues.apache.org/jira/browse/GROOVY-10902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles resolved GROOVY-10902.
--
Resolution: Fixed
https://github.com/apache/groovy/commit/2926b8cbc293fd46b73b051fbaf5bde9eeeb7065
> Dynamic constants for primitive types get default value in Java
> ---
>
> Key: GROOVY-10902
> URL: https://issues.apache.org/jira/browse/GROOVY-10902
> Project: Groovy
> Issue Type: Bug
> Components: Stub generator / Joint compiler
>Affects Versions: 3.0.14, 4.0.7
>Reporter: Onni Koskinen
>Assignee: Eric Milles
>Priority: Major
>
> If we define a constant that is resolved during runtime in a Groovy class and
> reference it in a Java class, it's value gets a static default value in the
> Java class. This seems to be a regression in Groovy 3.0.10 as earlier
> versions don't have the problem. Also affects all 4.0.x versions that I
> tested.
> Example:
> {code:groovy}
> // G.groovy
> class G {
> public static final int DYNAMIC_CONSTANT = (9.9).intValue()
> } {code}
> {code:java}
> // J.java
> public class J {
> public static void main(String[] args) {
> System.out.println(G.DYNAMIC_CONSTANT);
> }
> } {code}
> *Groovy 4.0.7*
> Prints 0 with the following bytecode for J#main
> {code:java}
> 0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
> 3: iconst_0
> 4: invokevirtual #4 // Method java/io/PrintStream.println:(I)V
> 7: return{code}
> *Groovy 3.0.9*
> Correctly prints 9 with the following bytecode:
> {code:java}
> 0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
> 3: getstatic #3 // Field G.DYNAMIC_CONSTANT:I
> 6: invokevirtual #4 // Method java/io/PrintStream.println:(I)V
> 9: return {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
