[jira] [Resolved] (GROOVY-8835) AstNodeToScriptVisitor - no token needed for EmptyStatement initialization
[
https://issues.apache.org/jira/browse/GROOVY-8835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-8835.
---
Resolution: Fixed
Assignee: Paul King
Fix Version/s: 2.5.3
3.0.0-alpha-4
Thanks for the suggestion. I agree it makes sense to elide the operation token
for the EmptyExpression case. At the moment I have done it only for ASSIGN.
> AstNodeToScriptVisitor - no token needed for EmptyStatement initialization
> --
>
> Key: GROOVY-8835
> URL: https://issues.apache.org/jira/browse/GROOVY-8835
> Project: Groovy
> Issue Type: Bug
> Components: Groovy Console, Swing
>Affects Versions: 2.5.2
>Reporter: Anton Pryamostanov
>Assignee: Paul King
>Priority: Minor
> Labels: inspect
> Fix For: 3.0.0-alpha-4, 2.5.3
>
>
> Consider the following example:
> {code:java}
> package groovy
> import groovy.inspect.swingui.AstNodeToScriptVisitor
> import org.codehaus.groovy.ast.expr.EmptyExpression
> import org.codehaus.groovy.ast.tools.GeneralUtils
> class SandBox {
> static void main(String[] args) {
> new SandBox().someMethod()
> }
> void someMethod() {
> StringWriter stringWriter = new StringWriter()
> GeneralUtils.declS(GeneralUtils.varX("someVariableName"), new
> EmptyExpression()).visit(new AstNodeToScriptVisitor(stringWriter))
> System.out.println("Output:
> "+stringWriter.getBuffer().toString().replace("\$", ""))
> }
> }
> {code}
> Actual result:
> {code}
> Output: java.lang.Object someVariableName =
> {code}
> Expected result:
> {code}
> Output: java.lang.Object someVariableName
> {code}
> When DeclarationExpression (or possibly other BinaryExpression) is
> initialized with EmptyExpression as "right" expression,
> *AstNodeToScriptVisitor* should not output the token ("=" in this example),
> as there is no corresponding expression printed after the token.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-7362) Can't compile Java class extending Groovy abstract class with explicit GroovyObject interface
[
https://issues.apache.org/jira/browse/GROOVY-7362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645938#comment-16645938
]
Paul King commented on GROOVY-7362:
---
Removing 2_5_X fix version for now since GROOVY-8495 was removed for now from
2_5_X. We can add a 2.5.x fix version if/when we backport GROOVY-8495 to 2_5_X.
> Can't compile Java class extending Groovy abstract class with explicit
> GroovyObject interface
> -
>
> Key: GROOVY-7362
> URL: https://issues.apache.org/jira/browse/GROOVY-7362
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.4.0
>Reporter: Peter Gromov
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.0-alpha-4
>
>
> That's a more advanced version of GROOVY-3877
> Compile classes.groovy:
> {code}
> abstract class AbstractClass extends ConcreteClass implements GroovyObject {}
> class ConcreteClass {}
> {code}
> Then compile JavaClass.java:
> {code}
> public class JavaClass extends AbstractClass {}
> {code}
> You get:
> {quote}
> JavaClass.java:1: error: JavaClass is not abstract and does not override
> abstract method setMetaClass(MetaClass) in GroovyObject
> public class JavaClass extends AbstractClass {
>^
> 1 error
> {quote}
> That's likely because setMetaClass is added as a synthetic method in
> ConcreteClass and not overridden in AbstractClass.
> This also happens without explicit GroovyObject interface when using joint
> compilation
> (https://youtrack.jetbrains.com/issue/IDEA-137722#comment=27-952814). Before
> generating stubs, "implements GroovyObject" is added to Groovy classes, and
> if it so happens that AbstractClass is visited before ConcreteClass, then
> "implements GroovyObject" will be added to both Groovy classes, but the
> (synthetic) implementations somehow end up being only in ConcreteClass.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GROOVY-8495) GroovyObject method implementations are marked with ACC_SYNTHETIC
[
https://issues.apache.org/jira/browse/GROOVY-8495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-8495.
---
Resolution: Fixed
Resolving just for 3.0 for now. We can add a 2.5.x fix version if/when we
backport to 2_5_X.
> GroovyObject method implementations are marked with ACC_SYNTHETIC
> -
>
> Key: GROOVY-8495
> URL: https://issues.apache.org/jira/browse/GROOVY-8495
> Project: Groovy
> Issue Type: Bug
> Components: bytecode, class generator, Compiler
>Reporter: Daniil Ovchinnikov
>Assignee: Paul King
>Priority: Critical
> Fix For: 3.0.0-alpha-4
>
>
> {code}
> class GroovyClass {}
> {code}
> {noformat:title=javap -v (stripped)}
> ...
> public class com.example.groovylib.GroovyClass implements
> groovy.lang.GroovyObject
> flags: ACC_PUBLIC, ACC_SUPER
> ...
> {
> public static transient boolean __$stMC;
> descriptor: Z
> flags: ACC_PUBLIC, ACC_STATIC, ACC_TRANSIENT, ACC_SYNTHETIC
> public com.example.groovylib.GroovyClass();
> descriptor: ()V
> flags: ACC_PUBLIC
> protected groovy.lang.MetaClass $getStaticMetaClass();
> descriptor: ()Lgroovy/lang/MetaClass;
> flags: ACC_PROTECTED, ACC_SYNTHETIC
> public groovy.lang.MetaClass getMetaClass();
> descriptor: ()Lgroovy/lang/MetaClass;
> flags: ACC_PUBLIC, ACC_SYNTHETIC
> public void setMetaClass(groovy.lang.MetaClass);
> descriptor: (Lgroovy/lang/MetaClass;)V
> flags: ACC_PUBLIC, ACC_SYNTHETIC
>
> public java.lang.Object invokeMethod(java.lang.String, java.lang.Object);
> descriptor: (Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object;
> flags: ACC_PUBLIC, ACC_SYNTHETIC
>
> public java.lang.Object getProperty(java.lang.String);
> descriptor: (Ljava/lang/String;)Ljava/lang/Object;
> flags: ACC_PUBLIC, ACC_SYNTHETIC
> public void setProperty(java.lang.String, java.lang.Object);
> descriptor: (Ljava/lang/String;Ljava/lang/Object;)V
> flags: ACC_PUBLIC, ACC_SYNTHETIC
> }
> SourceFile: "GroovyClass.groovy"
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GROOVY-8549) Compile Static causes getAt to fail
[
https://issues.apache.org/jira/browse/GROOVY-8549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-8549.
---
Resolution: Fixed
Assignee: Paul King
Fix Version/s: 2.5.3
3.0.0-alpha-4
Proposed PR merged. Note that this covers a lot of simple cases but not all
cases.
> Compile Static causes getAt to fail
> ---
>
> Key: GROOVY-8549
> URL: https://issues.apache.org/jira/browse/GROOVY-8549
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.4.13, 2.5.0-beta-3, 2.4.14, 3.0.0-alpha-2, 2.4.15
> Environment: Intellij plus various versions of Groovy; the same
> problem also occurs in Eclipse-Groovy with the same versions
>Reporter: Jon Kerridge
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.0-alpha-4, 2.5.3
>
>
> I can reproduce by adding @CompileStatic to the example I tried previously
> and can confirm that 2.4.13 is where the regression started. Workaround would
> be to remove @CompileStatic until we can get a fix in place. If you can raise
> a bug issue in Jira, that would be great.
> the reproducer following is a shortened version created by Paul King:
> {code}
> import groovy.transform.CompileStatic
>
> @CompileStatic
> def method() {
> def list = [0, 1, 2, 3]
> for (idx in 1..2) {
> list[idx-1]++
> }
> list
> }
>
> assert method() == [1, 2, 2, 3]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8840) CLONE - Compile Static causes getAt to fail (advanced cases)
[
https://issues.apache.org/jira/browse/GROOVY-8840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645926#comment-16645926
]
Paul King commented on GROOVY-8840:
---
I cloned the issue to cover advanced cases like the one [~jwagenleitner] gave.
> CLONE - Compile Static causes getAt to fail (advanced cases)
>
>
> Key: GROOVY-8840
> URL: https://issues.apache.org/jira/browse/GROOVY-8840
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.4.13, 2.5.0-beta-3, 2.4.14, 3.0.0-alpha-2, 2.4.15
> Environment: Intellij plus various versions of Groovy; the same
> problem also occurs in Eclipse-Groovy with the same versions
>Reporter: Jon Kerridge
>Priority: Major
>
> I can reproduce by adding @CompileStatic to the example I tried previously
> and can confirm that 2.4.13 is where the regression started. Workaround would
> be to remove @CompileStatic until we can get a fix in place. If you can raise
> a bug issue in Jira, that would be great.
> the reproducer following is a shortened version created by Paul King:
> {code}
> import groovy.transform.CompileStatic
>
> @CompileStatic
> def method() {
> def list = [0, 1, 2, 3]
> for (idx in 1..2) {
> list[idx-1]++
> }
> list
> }
>
> assert method() == [1, 2, 2, 3]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8840) CLONE - Compile Static causes getAt to fail (advanced cases)
Paul King created GROOVY-8840:
-
Summary: CLONE - Compile Static causes getAt to fail (advanced
cases)
Key: GROOVY-8840
URL: https://issues.apache.org/jira/browse/GROOVY-8840
Project: Groovy
Issue Type: Bug
Components: Compiler
Affects Versions: 2.4.13, 2.5.0-beta-3, 2.4.14, 3.0.0-alpha-2, 2.4.15
Environment: Intellij plus various versions of Groovy; the same
problem also occurs in Eclipse-Groovy with the same versions
Reporter: Jon Kerridge
I can reproduce by adding @CompileStatic to the example I tried previously and
can confirm that 2.4.13 is where the regression started. Workaround would be to
remove @CompileStatic until we can get a fix in place. If you can raise a bug
issue in Jira, that would be great.
the reproducer following is a shortened version created by Paul King:
{code}
import groovy.transform.CompileStatic
@CompileStatic
def method() {
def list = [0, 1, 2, 3]
for (idx in 1..2) {
list[idx-1]++
}
list
}
assert method() == [1, 2, 2, 3]
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8549) Compile Static causes getAt to fail
[
https://issues.apache.org/jira/browse/GROOVY-8549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645902#comment-16645902
]
ASF GitHub Bot commented on GROOVY-8549:
Github user asfgit closed the pull request at:
https://github.com/apache/groovy/pull/798
> Compile Static causes getAt to fail
> ---
>
> Key: GROOVY-8549
> URL: https://issues.apache.org/jira/browse/GROOVY-8549
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.4.13, 2.5.0-beta-3, 2.4.14, 3.0.0-alpha-2, 2.4.15
> Environment: Intellij plus various versions of Groovy; the same
> problem also occurs in Eclipse-Groovy with the same versions
>Reporter: Jon Kerridge
>Priority: Major
>
> I can reproduce by adding @CompileStatic to the example I tried previously
> and can confirm that 2.4.13 is where the regression started. Workaround would
> be to remove @CompileStatic until we can get a fix in place. If you can raise
> a bug issue in Jira, that would be great.
> the reproducer following is a shortened version created by Paul King:
> {code}
> import groovy.transform.CompileStatic
>
> @CompileStatic
> def method() {
> def list = [0, 1, 2, 3]
> for (idx in 1..2) {
> list[idx-1]++
> }
> list
> }
>
> assert method() == [1, 2, 2, 3]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] groovy pull request #798: GROOVY-8549: Compile Static causes getAt to fail
Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/798 ---
[GitHub] groovy pull request #808: Documentation for @TailRecursive
Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/808 ---
[jira] [Resolved] (GROOVY-8342) Static compilation error with a method returning an array in a type parameter
[
https://issues.apache.org/jira/browse/GROOVY-8342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-8342.
---
Resolution: Fixed
Assignee: Paul King
Fix Version/s: 2.5.3
3.0.0-alpha-4
Incorporated Eric's suggested change.
> Static compilation error with a method returning an array in a type parameter
> -
>
> Key: GROOVY-8342
> URL: https://issues.apache.org/jira/browse/GROOVY-8342
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Reporter: M. Justin
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.0-alpha-4, 2.5.3
>
>
> A compilation error occurs when using static compilation and attempting to
> assign the result of a method that returns a parameterized argument that
> contains an array in the type parameter. The equivalent Java code has no
> issues.
> Here is a specific example:
> {code}@CompileStatic
> class ArrayGenericsIssue {
> static void main(String[] args) {
> Optional value = testArrayMethod(1) //This fails to compile
> }
> static Optional testArrayMethod(E ignored) {
> return Optional.empty()
> }
> }{code}
> The error returned is:
> {code}Error:(11, 33) Groovyc: [Static type checking] - Incompatible generic
> argument types. Cannot assign java.util.Optional to: java.util.Optional
> {code}
> The expected behavior is that this code would compile and run successfully
> with @CompileStatic enabled.
> Note that equivalent code with a non-array generic parameter works just fine:
> {code}
> static void main(String[] args) {
> Optional> value = testListMethod(1)
> }
> static Optional> testListMethod(E ignored) {
> return Optional.empty()
> }
> {code}
> Additionally, there is no compilation issue if the value is cast:
> {code}Optional value = (Optional)
> testArrayMethod(1){code}
> For some context, I'm running into this issue when working with
> [jOOQ|https://www.jooq.org/], as some of its API involves working with array
> type parameters.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8342) Static compilation error with a method returning an array in a type parameter
[
https://issues.apache.org/jira/browse/GROOVY-8342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645818#comment-16645818
]
Paul King commented on GROOVY-8342:
---
Thanks [~emilles]. I haven't thought through whether there is a better way to
refactor/fix this but your change certainly fixes this case, so I'll merge and
we can think about improvements down the track.
> Static compilation error with a method returning an array in a type parameter
> -
>
> Key: GROOVY-8342
> URL: https://issues.apache.org/jira/browse/GROOVY-8342
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Reporter: M. Justin
>Priority: Major
>
> A compilation error occurs when using static compilation and attempting to
> assign the result of a method that returns a parameterized argument that
> contains an array in the type parameter. The equivalent Java code has no
> issues.
> Here is a specific example:
> {code}@CompileStatic
> class ArrayGenericsIssue {
> static void main(String[] args) {
> Optional value = testArrayMethod(1) //This fails to compile
> }
> static Optional testArrayMethod(E ignored) {
> return Optional.empty()
> }
> }{code}
> The error returned is:
> {code}Error:(11, 33) Groovyc: [Static type checking] - Incompatible generic
> argument types. Cannot assign java.util.Optional to: java.util.Optional
> {code}
> The expected behavior is that this code would compile and run successfully
> with @CompileStatic enabled.
> Note that equivalent code with a non-array generic parameter works just fine:
> {code}
> static void main(String[] args) {
> Optional> value = testListMethod(1)
> }
> static Optional> testListMethod(E ignored) {
> return Optional.empty()
> }
> {code}
> Additionally, there is no compilation issue if the value is cast:
> {code}Optional value = (Optional)
> testArrayMethod(1){code}
> For some context, I'm running into this issue when working with
> [jOOQ|https://www.jooq.org/], as some of its API involves working with array
> type parameters.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8806) Immutable classes break in groovy 2.5.2
[
https://issues.apache.org/jira/browse/GROOVY-8806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645528#comment-16645528
]
Roberto Perez Alcolea commented on GROOVY-8806:
---
Hi [~paulk]
Did the vote got approved? :)
> Immutable classes break in groovy 2.5.2
> ---
>
> Key: GROOVY-8806
> URL: https://issues.apache.org/jira/browse/GROOVY-8806
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.2
>Reporter: Roberto Perez Alcolea
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.0-alpha-4, 2.5.3
>
>
> We've being running tests of gradle plugins with latest gradle nightly
> release which upgraded to groovy 2.5.2
> Since then, we've seen multiple plugins breaking with errors around
> immutability:
>
> {code:java}
> > Unsupported type (org.ajoberstar.grgit.Branch) found for field
> > 'trackingBranch' while constructing immutable class
> > org.ajoberstar.grgit.Branch.
> Immutable classes only support properties with effectively immutable types
> including:
> - Strings, primitive types, wrapper types, Class, BigInteger and BigDecimal,
> enums
> - classes annotated with @KnownImmutable and known immutables
> (java.awt.Color, java.net.URI)
> - Cloneable classes, collections, maps and arrays, and other classes with
> special handling
> (java.util.Date and various java.time.* classes and interfaces)
> Other restrictions apply, please see the groovydoc for ImmutableOptions for
> further details{code}
>
> I was wondering if this change is related to
> [https://github.com/apache/groovy/commit/3471f55ea5839ab3c9dfa51cdca081bc7b4c020e#diff-8f745c460bc1abf332f21067b21ec551R754]
>
>
> And also, looks like gradle plugins that use the gradleApi and are compiled
> with groovy 2.4 could break with groovy 2.5 with usages like this one
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8727) JDK 11 Compilation Failure: ClassVisitor.visitNestMemberExperimental throws UnsupportedOperationException
[
https://issues.apache.org/jira/browse/GROOVY-8727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645445#comment-16645445
]
Dimitry Polivaev commented on GROOVY-8727:
--
Hi [~mariano.achaval], there is a snapshot maven repository
https://oss.jfrog.org/artifactory/oss-snapshot-local
> JDK 11 Compilation Failure: ClassVisitor.visitNestMemberExperimental throws
> UnsupportedOperationException
> --
>
> Key: GROOVY-8727
> URL: https://issues.apache.org/jira/browse/GROOVY-8727
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.5.2
>Reporter: Misagh Moayyed
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.0-alpha-4, 2.5.3
>
>
> *Description:*
> Using JDK 11 and Gradle 4.9, the following compilation error is seen:
>
> {code:java}
> > Task :core:cas-server-core-tickets:compileTestGroovy FAILED
> startup failed:
> General error during class generation: java.lang.UnsupportedOperationException
> java.lang.UnsupportedOperationException
> at
> groovyjarjarasm.asm.ClassVisitor.visitNestMemberExperimental(ClassVisitor.java:248)
> at groovyjarjarasm.asm.ClassReader.accept(ClassReader.java:651)
> at groovyjarjarasm.asm.ClassReader.accept(ClassReader.java:391)
> at
> org.codehaus.groovy.ast.decompiled.AsmDecompiler.parseClass(AsmDecompiler.java:83)
> at
> org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:254)
> at
> org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:192)
> at
> org.codehaus.groovy.control.ClassNodeResolver.findClassNode(ClassNodeResolver.java:172)
> at
> org.codehaus.groovy.control.ClassNodeResolver.resolveName(ClassNodeResolver.java:128)
> at
> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveClassNullable(AsmReferenceResolver.java:59)
> at
> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveClass(AsmReferenceResolver.java:46)
> at
> org.codehaus.groovy.ast.decompiled.TypeSignatureParser.visitEnd(TypeSignatureParser.java:112)
> at
> groovyjarjarasm.asm.signature.SignatureReader.parseType(SignatureReader.java:206)
> at
> groovyjarjarasm.asm.signature.SignatureReader.parseType(SignatureReader.java:235)
> at
> groovyjarjarasm.asm.signature.SignatureReader.accept(SignatureReader.java:114)
> at
> org.codehaus.groovy.ast.decompiled.MemberSignatureParser.createMethodNode(MemberSignatureParser.java:95)
> at
> org.codehaus.groovy.ast.decompiled.DecompiledClassNode.lazyInitMembers(DecompiledClassNode.java:195)
> at
> org.codehaus.groovy.ast.decompiled.DecompiledClassNode.getMethods(DecompiledClassNode.java:103)
> at org.codehaus.groovy.ast.ClassNode.getMethods(ClassNode.java:399)
> at
> org.codehaus.groovy.classgen.AnnotationVisitor.checkIfMandatoryAnnotationValuesPassed(AnnotationVisitor.java:168)
> at
> org.codehaus.groovy.classgen.AnnotationVisitor.visit(AnnotationVisitor.java:80)
> at
> org.codehaus.groovy.classgen.ExtendedVerifier.visitAnnotation(ExtendedVerifier.java:311)
> at
> org.codehaus.groovy.classgen.ExtendedVerifier.visitAnnotations(ExtendedVerifier.java:157)
> at
> org.codehaus.groovy.classgen.ExtendedVerifier.visitConstructorOrMethod(ExtendedVerifier.java:112)
> at
> org.codehaus.groovy.classgen.ExtendedVerifier.visitMethod(ExtendedVerifier.java:108)
> at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1103)
> at
> org.codehaus.groovy.classgen.ExtendedVerifier.visitClass(ExtendedVerifier.java:91)
> at
> org.codehaus.groovy.control.CompilationUnit$18.call(CompilationUnit.java:827)
> at
> org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1087)
> at
> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:631)
> at
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:609)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:586)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:565)
> at
> org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:179)
> at
> org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:57)
> at
> org.gradle.api.internal.tasks.compile.GroovyCompilerFactory$DaemonSideCompiler.execute(GroovyCompilerFactory.java:77)
> at
> org.gradle.api.internal.tasks.compile.GroovyCompilerFactory$DaemonSideCompiler.execute(GroovyCompilerFactory.java:65)
> at
>
[jira] [Commented] (GROOVY-8342) Static compilation error with a method returning an array in a type parameter
[
https://issues.apache.org/jira/browse/GROOVY-8342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645315#comment-16645315
]
Eric Milles commented on GROOVY-8342:
-
This may fix the issue (edit indicated in the 2nd half):
{code:java}
private static GenericsType applyGenericsContext(Map
spec, GenericsType gt) {
if (gt.isPlaceholder()) {
String name = gt.getName();
GenericsType specType = spec.get(name);
if (specType!=null) return specType;
if (hasNonTrivialBounds(gt)) {
GenericsType newGT = new GenericsType(gt.getType(),
applyGenericsContext(spec, gt.getUpperBounds()), applyGenericsContext(spec,
gt.getLowerBound()));
newGT.setPlaceholder(true);
return newGT;
}
return gt;
} else if (gt.isWildcard()) {
GenericsType newGT = new GenericsType(gt.getType(),
applyGenericsContext(spec, gt.getUpperBounds()), applyGenericsContext(spec,
gt.getLowerBound()));
newGT.setWildcard(true);
return newGT;
}
ClassNode type = gt.getType();
/* GRECLIPSE edit
if (type.getGenericsTypes()==null) return gt;
ClassNode newType = type.getPlainNodeReference();
newType.setGenericsPlaceHolder(type.isGenericsPlaceHolder());
newType.setGenericsTypes(applyGenericsContext(spec,
type.getGenericsTypes()));
*/
ClassNode newType;
if (type.isArray()) {
newType = applyGenericsContext(spec,
type.getComponentType()).makeArray();
} else {
if (type.getGenericsTypes()==null) return gt;
newType = type.getPlainNodeReference();
newType.setGenericsPlaceHolder(type.isGenericsPlaceHolder());
newType.setGenericsTypes(applyGenericsContext(spec,
type.getGenericsTypes()));
}
GenericsType newGT = new GenericsType(newType);
return newGT;
}
{code}
> Static compilation error with a method returning an array in a type parameter
> -
>
> Key: GROOVY-8342
> URL: https://issues.apache.org/jira/browse/GROOVY-8342
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Reporter: M. Justin
>Priority: Major
>
> A compilation error occurs when using static compilation and attempting to
> assign the result of a method that returns a parameterized argument that
> contains an array in the type parameter. The equivalent Java code has no
> issues.
> Here is a specific example:
> {code}@CompileStatic
> class ArrayGenericsIssue {
> static void main(String[] args) {
> Optional value = testArrayMethod(1) //This fails to compile
> }
> static Optional testArrayMethod(E ignored) {
> return Optional.empty()
> }
> }{code}
> The error returned is:
> {code}Error:(11, 33) Groovyc: [Static type checking] - Incompatible generic
> argument types. Cannot assign java.util.Optional to: java.util.Optional
> {code}
> The expected behavior is that this code would compile and run successfully
> with @CompileStatic enabled.
> Note that equivalent code with a non-array generic parameter works just fine:
> {code}
> static void main(String[] args) {
> Optional> value = testListMethod(1)
> }
> static Optional> testListMethod(E ignored) {
> return Optional.empty()
> }
> {code}
> Additionally, there is no compilation issue if the value is cast:
> {code}Optional value = (Optional)
> testArrayMethod(1){code}
> For some context, I'm running into this issue when working with
> [jOOQ|https://www.jooq.org/], as some of its API involves working with array
> type parameters.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-8342) Static compilation error with a method returning an array in a type parameter
[
https://issues.apache.org/jira/browse/GROOVY-8342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645278#comment-16645278
]
Eric Milles edited comment on GROOVY-8342 at 10/10/18 5:10 PM:
---
Down from the above method, in {{StaticTypeCheckingSupport}}:
{code:java}
private static GenericsType applyGenericsContext(Map
spec, GenericsType gt) {
if (gt.isPlaceholder()) { // returns false for "LE;" -- gt.getType()
returns "E -> java.lang.Object[]"; placeholder is set on the component type
{code}
was (Author: emilles):
Down from the above method, in {{StaticTypeCheckingSupport}}:
{code:java}
private static GenericsType applyGenericsContext(Map
spec, GenericsType gt) {
if (gt.isPlaceholder()) { // returns false for "LE;" -- gt.getType()
returns "T -> java.lang.Object[]"; placeholder is set on the component type
{code}
> Static compilation error with a method returning an array in a type parameter
> -
>
> Key: GROOVY-8342
> URL: https://issues.apache.org/jira/browse/GROOVY-8342
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Reporter: M. Justin
>Priority: Major
>
> A compilation error occurs when using static compilation and attempting to
> assign the result of a method that returns a parameterized argument that
> contains an array in the type parameter. The equivalent Java code has no
> issues.
> Here is a specific example:
> {code}@CompileStatic
> class ArrayGenericsIssue {
> static void main(String[] args) {
> Optional value = testArrayMethod(1) //This fails to compile
> }
> static Optional testArrayMethod(E ignored) {
> return Optional.empty()
> }
> }{code}
> The error returned is:
> {code}Error:(11, 33) Groovyc: [Static type checking] - Incompatible generic
> argument types. Cannot assign java.util.Optional to: java.util.Optional
> {code}
> The expected behavior is that this code would compile and run successfully
> with @CompileStatic enabled.
> Note that equivalent code with a non-array generic parameter works just fine:
> {code}
> static void main(String[] args) {
> Optional> value = testListMethod(1)
> }
> static Optional> testListMethod(E ignored) {
> return Optional.empty()
> }
> {code}
> Additionally, there is no compilation issue if the value is cast:
> {code}Optional value = (Optional)
> testArrayMethod(1){code}
> For some context, I'm running into this issue when working with
> [jOOQ|https://www.jooq.org/], as some of its API involves working with array
> type parameters.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8342) Static compilation error with a method returning an array in a type parameter
[
https://issues.apache.org/jira/browse/GROOVY-8342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645278#comment-16645278
]
Eric Milles commented on GROOVY-8342:
-
Down from the above method, in {{StaticTypeCheckingSupport}}:
{code:java}
private static GenericsType applyGenericsContext(Map
spec, GenericsType gt) {
if (gt.isPlaceholder()) { // returns false for "LE;" -- gt.getType()
returns "T -> java.lang.Object[]"; placeholder is set on the component type
{code}
> Static compilation error with a method returning an array in a type parameter
> -
>
> Key: GROOVY-8342
> URL: https://issues.apache.org/jira/browse/GROOVY-8342
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Reporter: M. Justin
>Priority: Major
>
> A compilation error occurs when using static compilation and attempting to
> assign the result of a method that returns a parameterized argument that
> contains an array in the type parameter. The equivalent Java code has no
> issues.
> Here is a specific example:
> {code}@CompileStatic
> class ArrayGenericsIssue {
> static void main(String[] args) {
> Optional value = testArrayMethod(1) //This fails to compile
> }
> static Optional testArrayMethod(E ignored) {
> return Optional.empty()
> }
> }{code}
> The error returned is:
> {code}Error:(11, 33) Groovyc: [Static type checking] - Incompatible generic
> argument types. Cannot assign java.util.Optional to: java.util.Optional
> {code}
> The expected behavior is that this code would compile and run successfully
> with @CompileStatic enabled.
> Note that equivalent code with a non-array generic parameter works just fine:
> {code}
> static void main(String[] args) {
> Optional> value = testListMethod(1)
> }
> static Optional> testListMethod(E ignored) {
> return Optional.empty()
> }
> {code}
> Additionally, there is no compilation issue if the value is cast:
> {code}Optional value = (Optional)
> testArrayMethod(1){code}
> For some context, I'm running into this issue when working with
> [jOOQ|https://www.jooq.org/], as some of its API involves working with array
> type parameters.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8342) Static compilation error with a method returning an array in a type parameter
[
https://issues.apache.org/jira/browse/GROOVY-8342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645251#comment-16645251
]
Eric Milles commented on GROOVY-8342:
-
{{StaticTypeCheckingVisitor}} seems to have a handle on the generics. When
visiting method {{testListMethod}}, it does manage to understand the link
between {{E}} and {{Integer}}.
{code:java}
protected ClassNode inferReturnTypeGenerics(
ClassNode receiver,
MethodNode method,
Expression arguments,
GenericsType[] explicitTypeHints) {
...
// resolvedPlaceholders: {E=java.lang.Integer}
// returnType: java.util.Optional <[LE;> -> java.util.Optional
return applyGenericsContext(resolvedPlaceholders, returnType);
}
{code}
> Static compilation error with a method returning an array in a type parameter
> -
>
> Key: GROOVY-8342
> URL: https://issues.apache.org/jira/browse/GROOVY-8342
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Reporter: M. Justin
>Priority: Major
>
> A compilation error occurs when using static compilation and attempting to
> assign the result of a method that returns a parameterized argument that
> contains an array in the type parameter. The equivalent Java code has no
> issues.
> Here is a specific example:
> {code}@CompileStatic
> class ArrayGenericsIssue {
> static void main(String[] args) {
> Optional value = testArrayMethod(1) //This fails to compile
> }
> static Optional testArrayMethod(E ignored) {
> return Optional.empty()
> }
> }{code}
> The error returned is:
> {code}Error:(11, 33) Groovyc: [Static type checking] - Incompatible generic
> argument types. Cannot assign java.util.Optional to: java.util.Optional
> {code}
> The expected behavior is that this code would compile and run successfully
> with @CompileStatic enabled.
> Note that equivalent code with a non-array generic parameter works just fine:
> {code}
> static void main(String[] args) {
> Optional> value = testListMethod(1)
> }
> static Optional> testListMethod(E ignored) {
> return Optional.empty()
> }
> {code}
> Additionally, there is no compilation issue if the value is cast:
> {code}Optional value = (Optional)
> testArrayMethod(1){code}
> For some context, I'm running into this issue when working with
> [jOOQ|https://www.jooq.org/], as some of its API involves working with array
> type parameters.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8839) Static compilation and array type parameter causing compile error
[
https://issues.apache.org/jira/browse/GROOVY-8839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-8839:
Attachment: Gr8.zip
> Static compilation and array type parameter causing compile error
> -
>
> Key: GROOVY-8839
> URL: https://issues.apache.org/jira/browse/GROOVY-8839
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.15
>Reporter: Eric Milles
>Priority: Major
> Attachments: Gr8.zip
>
>
> This seems related to GROOVY-8342 (and possibly GROOVY-8638 and GROOVY-7985).
> When using an array in a generics parameter, I get static compilation errors
> for return of a map and also for assignment of return value to a variable.
> {code:java}
> package r;
> public class ResultHandle {}
> {code}
> {code:groovy}
> package p
> import groovy.transform.CompileStatic
> import r.ResultHandle
> @CompileStatic
> class Issue {
> protected Map getResultsByType() {
> Map resultsByType = [:]
> // populate resultsByType
> return resultsByType
> }
> }
> {code}
> When I build using Ant, I get the following error:
> {code}
> Buildfile: ...\Gr8\build.xml
> -init:
> -compile:
> [mkdir] Created dir: ...\Gr8\ant\JavaClasses
> [compile] Compiling 2 source files to ...\Gr8\ant\JavaClasses
> [compile] org.codehaus.groovy.control.MultipleCompilationErrorsException:
> startup failed:
> [compile] ...\Gr8\src\main\bugs\Groovy1234.groovy: 12: [Static type
> checking] - Incompatible generic argument types. Cannot assign
> java.util.LinkedHashMap to:
> java.util.Map
> [compile] @ line 12, column 12.
> [compile]return resultsByType
> [compile] ^
> [compile] 1 error
> BUILD FAILED
> {code}
> Additionally, I would get an error if I assigned the result of the method to
> a typed variable, like this: {{Map resultsByType =
> getResultsByType()}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-8839) Static compilation and array type parameter causing compile error
[
https://issues.apache.org/jira/browse/GROOVY-8839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645139#comment-16645139
]
Eric Milles edited comment on GROOVY-8839 at 10/10/18 3:20 PM:
---
If {{ResultHandle}} is in the same package the error subsides. Also, it seems
important that {{ResultHandle}} is a Java source and not a Groovy one. I also
tried a binary reference like {{Pattern}} from {{java.util.regex}} and that
case did not have the error.
was (Author: emilles):
If {{ResultHandle}} is in the same package the error subsides. Also, it seems
important that {{ResultHandle}} is a Java source and not a Groovy one.
> Static compilation and array type parameter causing compile error
> -
>
> Key: GROOVY-8839
> URL: https://issues.apache.org/jira/browse/GROOVY-8839
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.15
>Reporter: Eric Milles
>Priority: Major
>
> This seems related to GROOVY-8342 (and possibly GROOVY-8638 and GROOVY-7985).
> When using an array in a generics parameter, I get static compilation errors
> for return of a map and also for assignment of return value to a variable.
> {code:java}
> package r;
> public class ResultHandle {}
> {code}
> {code:groovy}
> package p
> import groovy.transform.CompileStatic
> import r.ResultHandle
> @CompileStatic
> class Issue {
> protected Map getResultsByType() {
> Map resultsByType = [:]
> // populate resultsByType
> return resultsByType
> }
> }
> {code}
> When I build using Ant, I get the following error:
> {code}
> Buildfile: ...\Gr8\build.xml
> -init:
> -compile:
> [mkdir] Created dir: ...\Gr8\ant\JavaClasses
> [compile] Compiling 2 source files to ...\Gr8\ant\JavaClasses
> [compile] org.codehaus.groovy.control.MultipleCompilationErrorsException:
> startup failed:
> [compile] ...\Gr8\src\main\bugs\Groovy1234.groovy: 12: [Static type
> checking] - Incompatible generic argument types. Cannot assign
> java.util.LinkedHashMap to:
> java.util.Map
> [compile] @ line 12, column 12.
> [compile]return resultsByType
> [compile] ^
> [compile] 1 error
> BUILD FAILED
> {code}
> Additionally, I would get an error if I assigned the result of the method to
> a typed variable, like this: {{Map resultsByType =
> getResultsByType()}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8839) Static compilation and array type parameter causing compile error
[
https://issues.apache.org/jira/browse/GROOVY-8839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645139#comment-16645139
]
Eric Milles commented on GROOVY-8839:
-
If {{ResultHandle}} is in the same package the error subsides. Also, it seems
important that {{ResultHandle}} is a Java source and not a Groovy one.
> Static compilation and array type parameter causing compile error
> -
>
> Key: GROOVY-8839
> URL: https://issues.apache.org/jira/browse/GROOVY-8839
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.15
>Reporter: Eric Milles
>Priority: Major
>
> This seems related to GROOVY-8342 (and possibly GROOVY-8638 and GROOVY-7985).
> When using an array in a generics parameter, I get static compilation errors
> for return of a map and also for assignment of return value to a variable.
> {code:java}
> package r;
> public class ResultHandle {}
> {code}
> {code:groovy}
> package p
> import groovy.transform.CompileStatic
> import r.ResultHandle
> @CompileStatic
> class Issue {
> protected Map getResultsByType() {
> Map resultsByType = [:]
> // populate resultsByType
> return resultsByType
> }
> }
> {code}
> When I build using Ant, I get the following error:
> {code}
> Buildfile: ...\Gr8\build.xml
> -init:
> -compile:
> [mkdir] Created dir: ...\Gr8\ant\JavaClasses
> [compile] Compiling 2 source files to ...\Gr8\ant\JavaClasses
> [compile] org.codehaus.groovy.control.MultipleCompilationErrorsException:
> startup failed:
> [compile] ...\Gr8\src\main\bugs\Groovy1234.groovy: 12: [Static type
> checking] - Incompatible generic argument types. Cannot assign
> java.util.LinkedHashMap to:
> java.util.Map
> [compile] @ line 12, column 12.
> [compile]return resultsByType
> [compile] ^
> [compile] 1 error
> BUILD FAILED
> {code}
> Additionally, I would get an error if I assigned the result of the method to
> a typed variable, like this: {{Map resultsByType =
> getResultsByType()}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8727) JDK 11 Compilation Failure: ClassVisitor.visitNestMemberExperimental throws UnsupportedOperationException
[
https://issues.apache.org/jira/browse/GROOVY-8727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645123#comment-16645123
]
Mariano commented on GROOVY-8727:
-
Hi [~daniel_sun] I'm also suffering this problem, And I can not try
2.5.3-SNAPSHOT as that branch is not building and there is no snapshot
available, or at least one that I can find (if you have a repo with it can you
point me to). Thanks
> JDK 11 Compilation Failure: ClassVisitor.visitNestMemberExperimental throws
> UnsupportedOperationException
> --
>
> Key: GROOVY-8727
> URL: https://issues.apache.org/jira/browse/GROOVY-8727
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.5.2
>Reporter: Misagh Moayyed
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.0-alpha-4, 2.5.3
>
>
> *Description:*
> Using JDK 11 and Gradle 4.9, the following compilation error is seen:
>
> {code:java}
> > Task :core:cas-server-core-tickets:compileTestGroovy FAILED
> startup failed:
> General error during class generation: java.lang.UnsupportedOperationException
> java.lang.UnsupportedOperationException
> at
> groovyjarjarasm.asm.ClassVisitor.visitNestMemberExperimental(ClassVisitor.java:248)
> at groovyjarjarasm.asm.ClassReader.accept(ClassReader.java:651)
> at groovyjarjarasm.asm.ClassReader.accept(ClassReader.java:391)
> at
> org.codehaus.groovy.ast.decompiled.AsmDecompiler.parseClass(AsmDecompiler.java:83)
> at
> org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:254)
> at
> org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:192)
> at
> org.codehaus.groovy.control.ClassNodeResolver.findClassNode(ClassNodeResolver.java:172)
> at
> org.codehaus.groovy.control.ClassNodeResolver.resolveName(ClassNodeResolver.java:128)
> at
> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveClassNullable(AsmReferenceResolver.java:59)
> at
> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveClass(AsmReferenceResolver.java:46)
> at
> org.codehaus.groovy.ast.decompiled.TypeSignatureParser.visitEnd(TypeSignatureParser.java:112)
> at
> groovyjarjarasm.asm.signature.SignatureReader.parseType(SignatureReader.java:206)
> at
> groovyjarjarasm.asm.signature.SignatureReader.parseType(SignatureReader.java:235)
> at
> groovyjarjarasm.asm.signature.SignatureReader.accept(SignatureReader.java:114)
> at
> org.codehaus.groovy.ast.decompiled.MemberSignatureParser.createMethodNode(MemberSignatureParser.java:95)
> at
> org.codehaus.groovy.ast.decompiled.DecompiledClassNode.lazyInitMembers(DecompiledClassNode.java:195)
> at
> org.codehaus.groovy.ast.decompiled.DecompiledClassNode.getMethods(DecompiledClassNode.java:103)
> at org.codehaus.groovy.ast.ClassNode.getMethods(ClassNode.java:399)
> at
> org.codehaus.groovy.classgen.AnnotationVisitor.checkIfMandatoryAnnotationValuesPassed(AnnotationVisitor.java:168)
> at
> org.codehaus.groovy.classgen.AnnotationVisitor.visit(AnnotationVisitor.java:80)
> at
> org.codehaus.groovy.classgen.ExtendedVerifier.visitAnnotation(ExtendedVerifier.java:311)
> at
> org.codehaus.groovy.classgen.ExtendedVerifier.visitAnnotations(ExtendedVerifier.java:157)
> at
> org.codehaus.groovy.classgen.ExtendedVerifier.visitConstructorOrMethod(ExtendedVerifier.java:112)
> at
> org.codehaus.groovy.classgen.ExtendedVerifier.visitMethod(ExtendedVerifier.java:108)
> at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1103)
> at
> org.codehaus.groovy.classgen.ExtendedVerifier.visitClass(ExtendedVerifier.java:91)
> at
> org.codehaus.groovy.control.CompilationUnit$18.call(CompilationUnit.java:827)
> at
> org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1087)
> at
> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:631)
> at
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:609)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:586)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:565)
> at
> org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:179)
> at
> org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:57)
> at
> org.gradle.api.internal.tasks.compile.GroovyCompilerFactory$DaemonSideCompiler.execute(GroovyCompilerFactory.java:77)
> at
>
[jira] [Updated] (GROOVY-8839) Static compilation and array type parameter causing compile error
[
https://issues.apache.org/jira/browse/GROOVY-8839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-8839:
Description:
This seems related to GROOVY-8342 (and possibly GROOVY-8638 and GROOVY-7985).
When using an array in a generics parameter, I get static compilation errors
for return of a map and also for assignment of return value to a variable.
{code:java}
package r;
public class ResultHandle {}
{code}
{code:groovy}
package p
import groovy.transform.CompileStatic
import r.ResultHandle
@CompileStatic
class Issue {
protected Map getResultsByType() {
Map resultsByType = [:]
// populate resultsByType
return resultsByType
}
}
{code}
When I build using Ant, I get the following error:
{code}
Buildfile: ...\Gr8\build.xml
-init:
-compile:
[mkdir] Created dir: ...\Gr8\ant\JavaClasses
[compile] Compiling 2 source files to ...\Gr8\ant\JavaClasses
[compile] org.codehaus.groovy.control.MultipleCompilationErrorsException:
startup failed:
[compile] ...\Gr8\src\main\bugs\Groovy1234.groovy: 12: [Static type checking]
- Incompatible generic argument types. Cannot assign java.util.LinkedHashMap
to: java.util.Map
[compile] @ line 12, column 12.
[compile]return resultsByType
[compile] ^
[compile] 1 error
BUILD FAILED
{code}
Additionally, I would get an error if I assigned the result of the method to a
typed variable, like this: {{Map resultsByType =
getResultsByType()}}
was:
This seems related to GROOVY-8342 (and possibly GROOVY-8638 and GROOVY-7985).
When using an array in a generics parameter, I get static compilation errors
for return of a map and also for assignment of return value to a variable.
{code:java}
package r;
public class ResultHandle {}
{code}
{code:groovy}
package p
import groovy.transform.CompileStatic
import r.ResultHandle
@CompileStatic
class Issue {
protected Map getResultsByType() {
Map resultsByType = [:]
// populate resultsByType
return resultsByType
}
}
{code}
When I build using Ant, I get the following error:
{code}
Buildfile: ...\Gr8\build.xml
-init:
-compile:
[mkdir] Created dir: ...\Gr8\ant\JavaClasses
[compile] Compiling 2 source files to ...\Gr8\ant\JavaClasses
[compile] org.codehaus.groovy.control.MultipleCompilationErrorsException:
startup failed:
[compile] ...\Gr8\src\main\bugs\Groovy1234.groovy: 12: [Static type checking]
- Incompatible generic argument types. Cannot assign java.util.LinkedHashMap
to: java.util.Map
[compile] @ line 12, column 12.
[compile]return resultsByType
[compile] ^
[compile] 1 error
BUILD FAILED
{code}
Additionally, I would get an error if I assigned the result of the method to a
typed variable, like this: {{Map resultsByType =
issue.getResultsByType()}}
> Static compilation and array type parameter causing compile error
> -
>
> Key: GROOVY-8839
> URL: https://issues.apache.org/jira/browse/GROOVY-8839
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.15
>Reporter: Eric Milles
>Priority: Major
>
> This seems related to GROOVY-8342 (and possibly GROOVY-8638 and GROOVY-7985).
> When using an array in a generics parameter, I get static compilation errors
> for return of a map and also for assignment of return value to a variable.
> {code:java}
> package r;
> public class ResultHandle {}
> {code}
> {code:groovy}
> package p
> import groovy.transform.CompileStatic
> import r.ResultHandle
> @CompileStatic
> class Issue {
> protected Map getResultsByType() {
> Map resultsByType = [:]
> // populate resultsByType
> return resultsByType
> }
> }
> {code}
> When I build using Ant, I get the following error:
> {code}
> Buildfile: ...\Gr8\build.xml
> -init:
> -compile:
> [mkdir] Created dir: ...\Gr8\ant\JavaClasses
> [compile] Compiling 2 source files to ...\Gr8\ant\JavaClasses
> [compile] org.codehaus.groovy.control.MultipleCompilationErrorsException:
> startup failed:
> [compile] ...\Gr8\src\main\bugs\Groovy1234.groovy: 12: [Static type
> checking] - Incompatible generic argument types. Cannot assign
> java.util.LinkedHashMap to:
> java.util.Map
> [compile] @ line 12, column 12.
> [compile]return resultsByType
> [compile] ^
> [compile] 1 error
> BUILD FAILED
> {code}
> Additionally, I would get an error if I assigned the result of the method to
> a typed variable, like this: {{Map resultsByType =
> getResultsByType()}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8839) Static compilation and array type parameter causing compile error
[
https://issues.apache.org/jira/browse/GROOVY-8839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-8839:
Description:
This seems related to GROOVY-8342 (and possibly GROOVY-8638 and GROOVY-7985).
When using an array in a generics parameter, I get static compilation errors
for return of a map and also for assignment of return value to a variable.
{code:java}
package r;
public class ResultHandle {}
{code}
{code:groovy}
package p
import groovy.transform.CompileStatic
import r.ResultHandle
@CompileStatic
class Issue {
protected Map getResultsByType() {
Map resultsByType = [:]
// populate resultsByType
return resultsByType
}
}
{code}
When I build using Ant, I get the following error:
{code}
Buildfile: ...\Gr8\build.xml
-init:
-compile:
[mkdir] Created dir: ...\Gr8\ant\JavaClasses
[compile] Compiling 2 source files to ...\Gr8\ant\JavaClasses
[compile] org.codehaus.groovy.control.MultipleCompilationErrorsException:
startup failed:
[compile] ...\Gr8\src\main\bugs\Groovy1234.groovy: 12: [Static type checking]
- Incompatible generic argument types. Cannot assign java.util.LinkedHashMap
to: java.util.Map
[compile] @ line 12, column 12.
[compile]return resultsByType
[compile] ^
[compile] 1 error
BUILD FAILED
{code}
Additionally, I would get an error if I assigned the result of the method to a
typed variable, like this: {{Map resultsByType =
issue.getResultsByType()}}
was:
This seems related to GROOVY-8342 (and possibly GROOVY-8638 and GROOVY-7985).
When using an array in a generics parameter, I get compile errors for return of
a map and also for assignment of return value to a variable.
{code:java}
package r;
public class ResultHandle {}
{code}
{code:groovy}
package p
import groovy.transform.CompileStatic
import r.ResultHandle
@CompileStatic
class Issue {
protected Map getResultsByType() {
Map resultsByType = [:]
// populate resultsByType
return resultsByType
}
}
{code}
When I build using Ant, I get the following error:
{code}
Buildfile: ...\Gr8\build.xml
-init:
-compile:
[mkdir] Created dir: ...\Gr8\ant\JavaClasses
[compile] Compiling 2 source files to ...\Gr8\ant\JavaClasses
[compile] org.codehaus.groovy.control.MultipleCompilationErrorsException:
startup failed:
[compile] ...\Gr8\src\main\bugs\Groovy1234.groovy: 12: [Static type checking]
- Incompatible generic argument types. Cannot assign java.util.LinkedHashMap
to: java.util.Map
[compile] @ line 12, column 12.
[compile]return resultsByType
[compile] ^
[compile] 1 error
BUILD FAILED
{code}
Additionally, I would get an error if I assigned the result of the method to a
typed variable, like this: {{Map resultsByType =
issue.getResultsByType()}}
> Static compilation and array type parameter causing compile error
> -
>
> Key: GROOVY-8839
> URL: https://issues.apache.org/jira/browse/GROOVY-8839
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.15
>Reporter: Eric Milles
>Priority: Major
>
> This seems related to GROOVY-8342 (and possibly GROOVY-8638 and GROOVY-7985).
> When using an array in a generics parameter, I get static compilation errors
> for return of a map and also for assignment of return value to a variable.
> {code:java}
> package r;
> public class ResultHandle {}
> {code}
> {code:groovy}
> package p
> import groovy.transform.CompileStatic
> import r.ResultHandle
> @CompileStatic
> class Issue {
> protected Map getResultsByType() {
> Map resultsByType = [:]
> // populate resultsByType
> return resultsByType
> }
> }
> {code}
> When I build using Ant, I get the following error:
> {code}
> Buildfile: ...\Gr8\build.xml
> -init:
> -compile:
> [mkdir] Created dir: ...\Gr8\ant\JavaClasses
> [compile] Compiling 2 source files to ...\Gr8\ant\JavaClasses
> [compile] org.codehaus.groovy.control.MultipleCompilationErrorsException:
> startup failed:
> [compile] ...\Gr8\src\main\bugs\Groovy1234.groovy: 12: [Static type
> checking] - Incompatible generic argument types. Cannot assign
> java.util.LinkedHashMap to:
> java.util.Map
> [compile] @ line 12, column 12.
> [compile]return resultsByType
> [compile] ^
> [compile] 1 error
> BUILD FAILED
> {code}
> Additionally, I would get an error if I assigned the result of the method to
> a typed variable, like this: {{Map resultsByType =
> issue.getResultsByType()}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8839) Static compilation and array type parameter causing compile error
Eric Milles created GROOVY-8839:
---
Summary: Static compilation and array type parameter causing
compile error
Key: GROOVY-8839
URL: https://issues.apache.org/jira/browse/GROOVY-8839
Project: Groovy
Issue Type: Question
Affects Versions: 2.4.15
Reporter: Eric Milles
This seems related to GROOVY-8342 (and possibly GROOVY-8638 and GROOVY-7985).
When using an array in a generics parameter, I get compile errors for return of
a map and also for assignment of return value to a variable.
{code:java}
package r;
public class ResultHandle {}
{code}
{code:groovy}
package p
import groovy.transform.CompileStatic
import r.ResultHandle
@CompileStatic
class Issue {
protected Map getResultsByType() {
Map resultsByType = [:]
// populate resultsByType
return resultsByType
}
}
{code}
When I build using Ant, I get the following error:
{code}
Buildfile: ...\Gr8\build.xml
-init:
-compile:
[mkdir] Created dir: ...\Gr8\ant\JavaClasses
[compile] Compiling 2 source files to ...\Gr8\ant\JavaClasses
[compile] org.codehaus.groovy.control.MultipleCompilationErrorsException:
startup failed:
[compile] ...\Gr8\src\main\bugs\Groovy1234.groovy: 12: [Static type checking]
- Incompatible generic argument types. Cannot assign java.util.LinkedHashMap
to: java.util.Map
[compile] @ line 12, column 12.
[compile]return resultsByType
[compile] ^
[compile] 1 error
BUILD FAILED
{code}
Additionally, I would get an error if I assigned the result of the method to a
typed variable, like this: {{Map resultsByType =
issue.getResultsByType()}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8839) Static compilation and array type parameter causing compile error
[
https://issues.apache.org/jira/browse/GROOVY-8839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-8839:
Issue Type: Bug (was: Question)
> Static compilation and array type parameter causing compile error
> -
>
> Key: GROOVY-8839
> URL: https://issues.apache.org/jira/browse/GROOVY-8839
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.15
>Reporter: Eric Milles
>Priority: Major
>
> This seems related to GROOVY-8342 (and possibly GROOVY-8638 and GROOVY-7985).
> When using an array in a generics parameter, I get compile errors for return
> of a map and also for assignment of return value to a variable.
> {code:java}
> package r;
> public class ResultHandle {}
> {code}
> {code:groovy}
> package p
> import groovy.transform.CompileStatic
> import r.ResultHandle
> @CompileStatic
> class Issue {
> protected Map getResultsByType() {
> Map resultsByType = [:]
> // populate resultsByType
> return resultsByType
> }
> }
> {code}
> When I build using Ant, I get the following error:
> {code}
> Buildfile: ...\Gr8\build.xml
> -init:
> -compile:
> [mkdir] Created dir: ...\Gr8\ant\JavaClasses
> [compile] Compiling 2 source files to ...\Gr8\ant\JavaClasses
> [compile] org.codehaus.groovy.control.MultipleCompilationErrorsException:
> startup failed:
> [compile] ...\Gr8\src\main\bugs\Groovy1234.groovy: 12: [Static type
> checking] - Incompatible generic argument types. Cannot assign
> java.util.LinkedHashMap to:
> java.util.Map
> [compile] @ line 12, column 12.
> [compile]return resultsByType
> [compile] ^
> [compile] 1 error
> BUILD FAILED
> {code}
> Additionally, I would get an error if I assigned the result of the method to
> a typed variable, like this: {{Map resultsByType =
> issue.getResultsByType()}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8837) Invalid type inference for redefined generic boundaries
[
https://issues.apache.org/jira/browse/GROOVY-8837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645098#comment-16645098
]
Constantine Plotnikov commented on GROOVY-8837:
---
This specific maven configuration does use stubs, so it might be reverse:
{code:java}
generateStubs
compile
generateTestStubs
testCompile{code}
> Invalid type inference for redefined generic boundaries
> ---
>
> Key: GROOVY-8837
> URL: https://issues.apache.org/jira/browse/GROOVY-8837
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.5.2
>Reporter: Constantine Plotnikov
>Priority: Major
> Attachments: groovy-bug-generic-extension.zip
>
>
> Static compiler incorrectly calculates type boundary for chain calls with
> generic types. When method is called, it takes boundary defined in the method
> of the class (Base in sample), instead of the boundary redefined in subclass
> (SubClass in sample).
> The bug was discovered when working with Lombok SuperBuilder generated
> classes from Groovy. The attached project demonstrate the bug on the smaller
> sample.
> Note that Java test infers type correctly, but groovy does not. However, the
> groovy test works when CompileStatic annotation is disabled.
> IDEA also shows red code here, but it possibly follows Groovy logic.
> The bug also affects earlier versions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8821) groovy.bat doesn't work in Windows Docker nanoserver based containers
[
https://issues.apache.org/jira/browse/GROOVY-8821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akom updated GROOVY-8821:
-
Description:
groovy.bat relies on c:\windows\system32\find.exe, which is notably absent in
Microsoft containers. There is some logic to avoid clashing with cygwin's
version of find.exe (which I do have), but it doesn't cover the case of the
correct find.exe missing altogether.
When running Jenkins, this is what I see:
{noformat}
Unpacking
https://dl.bintray.com/groovy/maven/apache-groovy-binary-2.5.2.zip
to c:\jenkinswork\tools\hudson.plugins.groovy.GroovyInstallation\Groovy_Latest
on docker-003fbd390qkb2 on Windows 01
[00b97b92] $
c:\jenkinswork\tools\hudson.plugins.groovy.GroovyInstallation\Groovy_Latest\bin\groovy.bat
c:\jenkinswork\workspace\infra\test-docker-windows-temp\00b97b92\hudson7647040981337869977.groovy
find: '/I': No such file or directory
find: '/C': No such file or directory
ERROR: JAVA_HOME is set to an invalid directory: c:\jenkins\jdk\JDK_1.9
Please set the JAVA_HOME variable in your environment
{noformat}
As you can see, the error message is rather misleading.
The real issue is that groovy.bat winds up using cygwin's find.exe that has an
entirely different purpose.
was:
groovy.bat relies on c:\windows\system32\find.exe, which is notably absent in
Microsoft containers. There is some logic to avoid clashing with cygwin's
version of find.exe (which I do have), but it doesn't cover the case of the
correct find.exe missing altogether.
When running Jenkins, this is what I see:
{noformat}
Unpacking
https://dl.bintray.com/groovy/maven/apache-groovy-binary-2.5.2.zip
to c:\jenkinswork\tools\hudson.plugins.groovy.GroovyInstallation\Groovy_Latest
on docker-003fbd390qkb2 on Windows 01
[00b97b92] $
c:\jenkinswork\tools\hudson.plugins.groovy.GroovyInstallation\Groovy_Latest\bin\groovy.bat
c:\jenkinswork\workspace\infra\test-docker-windows-temp\00b97b92\hudson7647040981337869977.groovy
find: '/I': No such file or directory
find: '/C': No such file or directory
ERROR: JAVA_HOME is set to an invalid directory: c:\jenkins\jdk\JDK_1.9
Please set the JAVA_HOME variable in your environment
{noformat}
As you can see, the error message is rather misleading.
> groovy.bat doesn't work in Windows Docker nanoserver based containers
> -
>
> Key: GROOVY-8821
> URL: https://issues.apache.org/jira/browse/GROOVY-8821
> Project: Groovy
> Issue Type: Bug
> Environment: Groovy 2.5.2 (or 2.4.3)
> Windows 2016 host with microsoft/nanoserver based Docker container
>Reporter: Akom
>Priority: Minor
> Labels: contrib
>
> groovy.bat relies on c:\windows\system32\find.exe, which is notably absent in
> Microsoft containers. There is some logic to avoid clashing with cygwin's
> version of find.exe (which I do have), but it doesn't cover the case of the
> correct find.exe missing altogether.
> When running Jenkins, this is what I see:
> {noformat}
> Unpacking
> https://dl.bintray.com/groovy/maven/apache-groovy-binary-2.5.2.zip
> to
> c:\jenkinswork\tools\hudson.plugins.groovy.GroovyInstallation\Groovy_Latest
> on docker-003fbd390qkb2 on Windows 01
> [00b97b92] $
> c:\jenkinswork\tools\hudson.plugins.groovy.GroovyInstallation\Groovy_Latest\bin\groovy.bat
>
> c:\jenkinswork\workspace\infra\test-docker-windows-temp\00b97b92\hudson7647040981337869977.groovy
> find: '/I': No such file or directory
> find: '/C': No such file or directory
> ERROR: JAVA_HOME is set to an invalid directory: c:\jenkins\jdk\JDK_1.9
> Please set the JAVA_HOME variable in your environment
> {noformat}
> As you can see, the error message is rather misleading.
> The real issue is that groovy.bat winds up using cygwin's find.exe that has
> an entirely different purpose.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] groovy pull request #808: Documentation for @TailRecursive
Github user PascalSchumacher commented on a diff in the pull request: https://github.com/apache/groovy/pull/808#discussion_r224093386 --- Diff: src/spec/doc/core-metaprogramming.adoc --- @@ -1985,7 +1985,19 @@ _protectedCacheSize>0_ would create an unlimited cache with some results protect [[xform-TailRecursive]] = `@groovy.transform.TailRecursive` -TBD +The `@TailRecursive` annotation can be used to automatically transform a recursive call in the end of a method to an +iterative version of the same code, to avoid stack overflow due to to many recursive calls. Below is an example of --- End diff -- `to to many` should be `to too many` I guess. ---
[jira] [Resolved] (GROOVY-8764) Closure inside an anonymous class uses wrong outside class instance with @CS
[
https://issues.apache.org/jira/browse/GROOVY-8764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-8764.
---
Resolution: Fixed
Assignee: Paul King
Fix Version/s: 2.5.3
3.0.0-alpha-4
Should be fixed in the next release. Thanks for reporting the issue.
> Closure inside an anonymous class uses wrong outside class instance with @CS
>
>
> Key: GROOVY-8764
> URL: https://issues.apache.org/jira/browse/GROOVY-8764
> Project: Groovy
> Issue Type: Bug
> Components: Compiler, Static compilation
>Affects Versions: 2.4.15, 3.0.0-alpha-3, 2.5.2
>Reporter: Xiaoguang Wang
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.0-alpha-4, 2.5.3
>
>
> This bug only occurs with @ComplieStatic
> Affects 2.4/2.5/3.0
>
> {code:java}
> @CompileStatic
> class GroovyTest {
> private String foo
> void test() {
> new Runnable() {
> void run() {
> def c = {
> foo
> }
> c()
> }
> } .run()
> }
> static void main(String ...args) {
> new GroovyTest().test()
> }
> }
> {code}
> Crash:
> {code:java}
> Exception in thread "main" java.lang.ClassCastException:
> com.test.spring4mvc.controller.GroovyTest$1 cannot be cast to
> com.test.spring4mvc.controller.GroovyTest
> at
> com.test.spring4mvc.controller.GroovyTest$1$_run_closure1.doCall(GroovyTest.groovy)
> at
> com.test.spring4mvc.controller.GroovyTest$1$_run_closure1.call(GroovyTest.groovy)
> at com.test.spring4mvc.controller.GroovyTest$1.run(GroovyTest.groovy:16)
> at com.test.spring4mvc.controller.GroovyTest.test(GroovyTest.groovy:11)
> at com.test.spring4mvc.controller.GroovyTest.main(GroovyTest.groovy:22)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] groovy pull request #:
Github user paulk-asert commented on the pull request: https://github.com/apache/groovy/commit/fd21ad4e3b6d2a4297944d079ba8948e8d8e6052#commitcomment-30846605 True, I'll fix ---
[GitHub] groovy pull request #:
Github user danielsun1106 commented on the pull request: https://github.com/apache/groovy/commit/fd21ad4e3b6d2a4297944d079ba8948e8d8e6052#commitcomment-30846491 Using Java 8 API causes the test failure when running on Java 7 ---
[jira] [Comment Edited] (GROOVY-8838) assert in groovy does not produce any result
[ https://issues.apache.org/jira/browse/GROOVY-8838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644843#comment-16644843 ] Paul King edited comment on GROOVY-8838 at 10/10/18 11:26 AM: -- That looks like correct behavior. Replace the assert statements with println and you will see all print true as expected. was (Author: paulk): That looks like correct behavior. > assert in groovy does not produce any result > > > Key: GROOVY-8838 > URL: https://issues.apache.org/jira/browse/GROOVY-8838 > Project: Groovy > Issue Type: Bug > Components: groovy-jdk >Affects Versions: 2.4.3 >Reporter: Thulsi Doss Krishnan >Priority: Major > Labels: simple-assert- > Attachments: GroovyAssert.JPG > > > Hi running a simple assert does not produce any result in the eclipse IDE > def map1 = [user: 'mrhaki', likes: 'Groovy', age: 37] > def map2 = [age: 37.0, likes: 'Groovy', user: 'mrhaki'] > def map3 = [user: 'Hubert Klein Ikkink', likes: 'Groovy'] > assert map1.equals(map2) > assert map1 == map2 > assert !map1.equals(map3) > assert map2 != map3 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8838) assert in groovy does not produce any result
[ https://issues.apache.org/jira/browse/GROOVY-8838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644843#comment-16644843 ] Paul King commented on GROOVY-8838: --- That looks like correct behavior. > assert in groovy does not produce any result > > > Key: GROOVY-8838 > URL: https://issues.apache.org/jira/browse/GROOVY-8838 > Project: Groovy > Issue Type: Bug > Components: groovy-jdk >Affects Versions: 2.4.3 >Reporter: Thulsi Doss Krishnan >Priority: Major > Labels: simple-assert- > Attachments: GroovyAssert.JPG > > > Hi running a simple assert does not produce any result in the eclipse IDE > def map1 = [user: 'mrhaki', likes: 'Groovy', age: 37] > def map2 = [age: 37.0, likes: 'Groovy', user: 'mrhaki'] > def map3 = [user: 'Hubert Klein Ikkink', likes: 'Groovy'] > assert map1.equals(map2) > assert map1 == map2 > assert !map1.equals(map3) > assert map2 != map3 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8837) Invalid type inference for redefined generic boundaries
[ https://issues.apache.org/jira/browse/GROOVY-8837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644837#comment-16644837 ] Paul King commented on GROOVY-8837: --- One possibility might be that Maven doesn't use stub generation for your case but IDEA does? > Invalid type inference for redefined generic boundaries > --- > > Key: GROOVY-8837 > URL: https://issues.apache.org/jira/browse/GROOVY-8837 > Project: Groovy > Issue Type: Bug > Components: Compiler >Affects Versions: 2.5.2 >Reporter: Constantine Plotnikov >Priority: Major > Attachments: groovy-bug-generic-extension.zip > > > Static compiler incorrectly calculates type boundary for chain calls with > generic types. When method is called, it takes boundary defined in the method > of the class (Base in sample), instead of the boundary redefined in subclass > (SubClass in sample). > The bug was discovered when working with Lombok SuperBuilder generated > classes from Groovy. The attached project demonstrate the bug on the smaller > sample. > Note that Java test infers type correctly, but groovy does not. However, the > groovy test works when CompileStatic annotation is disabled. > IDEA also shows red code here, but it possibly follows Groovy logic. > The bug also affects earlier versions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GROOVY-8838) assert in groovy does not produce any result
Thulsi Doss Krishnan created GROOVY-8838: Summary: assert in groovy does not produce any result Key: GROOVY-8838 URL: https://issues.apache.org/jira/browse/GROOVY-8838 Project: Groovy Issue Type: Bug Components: groovy-jdk Affects Versions: 2.4.3 Reporter: Thulsi Doss Krishnan Attachments: GroovyAssert.JPG Hi running a simple assert does not produce any result in the eclipse IDE def map1 = [user: 'mrhaki', likes: 'Groovy', age: 37] def map2 = [age: 37.0, likes: 'Groovy', user: 'mrhaki'] def map3 = [user: 'Hubert Klein Ikkink', likes: 'Groovy'] assert map1.equals(map2) assert map1 == map2 assert !map1.equals(map3) assert map2 != map3 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GROOVY-8714) using process builder in groovy
[ https://issues.apache.org/jira/browse/GROOVY-8714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thulsi Doss Krishnan updated GROOVY-8714: - closed > using process builder in groovy > --- > > Key: GROOVY-8714 > URL: https://issues.apache.org/jira/browse/GROOVY-8714 > Project: Groovy > Issue Type: Question > Components: groovy-jdk >Affects Versions: 2.5.1 >Reporter: Thulsi Doss Krishnan >Priority: Minor > > Im trying to use the following lines of code found at > https://github.com/tthyer/samples/blob/master/groovyProcesses/passEnvVar.groovy > to run the following piece of code > def currentPathToLoader="C:/loader/bin/loader.cmd" > def pathToCsv="C://loader//bin//inputs//loader_test.csv" > Runtime rt = Runtime.getRuntime() > String[] commands =["cmd", "/c", "C://loader//bin//loader.cmd", > "-Dbase.dir=%cd% -writedbonly -verbose -time -insert -TimeSeriesBackfill 1 > inputs/loader_test.csv"] > Process pr = rt.exec(commands) > how ever Im unable to do so ? any help would be appreciated -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-8837) Invalid type inference for redefined generic boundaries
[ https://issues.apache.org/jira/browse/GROOVY-8837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644631#comment-16644631 ] Constantine Plotnikov edited comment on GROOVY-8837 at 10/10/18 9:01 AM: - Maven run successful, but running test from IDEA fails on compile stage. This is strange, I guess I need more investigation for this. Possibly IDEA compiles test differently from maven compiler. I'll post a bug to IDEA too (posted as https://youtrack.jetbrains.com/issue/IDEA-200247). I thought they are using standard Groovy compiler. was (Author: const): Maven run successful, but running test from IDEA fails on compile stage. This is strange, I guess I need more investigation for this. Possibly IDEA compiles test differently from maven compiler. I'll post a bug to IDEA too. I thought they are using standard Groovy compiler. > Invalid type inference for redefined generic boundaries > --- > > Key: GROOVY-8837 > URL: https://issues.apache.org/jira/browse/GROOVY-8837 > Project: Groovy > Issue Type: Bug > Components: Compiler >Affects Versions: 2.5.2 >Reporter: Constantine Plotnikov >Priority: Major > Attachments: groovy-bug-generic-extension.zip > > > Static compiler incorrectly calculates type boundary for chain calls with > generic types. When method is called, it takes boundary defined in the method > of the class (Base in sample), instead of the boundary redefined in subclass > (SubClass in sample). > The bug was discovered when working with Lombok SuperBuilder generated > classes from Groovy. The attached project demonstrate the bug on the smaller > sample. > Note that Java test infers type correctly, but groovy does not. However, the > groovy test works when CompileStatic annotation is disabled. > IDEA also shows red code here, but it possibly follows Groovy logic. > The bug also affects earlier versions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-8837) Invalid type inference for redefined generic boundaries
[ https://issues.apache.org/jira/browse/GROOVY-8837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644631#comment-16644631 ] Constantine Plotnikov edited comment on GROOVY-8837 at 10/10/18 8:39 AM: - Maven run successful, but running test from IDEA fails on compile stage. This is strange, I guess I need more investigation for this. Possibly IDEA compiles test differently from maven compiler. I'll post a bug to IDEA too. I thought they are using standard Groovy compiler. was (Author: const): Maven run successful, but running test from IDEA fails on compile stage. This is strange, I guess I need more investigation for this. Possibly IDEA compiles test differently from maven compiler. I'll post a bug to IDEA too. > Invalid type inference for redefined generic boundaries > --- > > Key: GROOVY-8837 > URL: https://issues.apache.org/jira/browse/GROOVY-8837 > Project: Groovy > Issue Type: Bug > Components: Compiler >Affects Versions: 2.5.2 >Reporter: Constantine Plotnikov >Priority: Major > Attachments: groovy-bug-generic-extension.zip > > > Static compiler incorrectly calculates type boundary for chain calls with > generic types. When method is called, it takes boundary defined in the method > of the class (Base in sample), instead of the boundary redefined in subclass > (SubClass in sample). > The bug was discovered when working with Lombok SuperBuilder generated > classes from Groovy. The attached project demonstrate the bug on the smaller > sample. > Note that Java test infers type correctly, but groovy does not. However, the > groovy test works when CompileStatic annotation is disabled. > IDEA also shows red code here, but it possibly follows Groovy logic. > The bug also affects earlier versions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-8837) Invalid type inference for redefined generic boundaries
[ https://issues.apache.org/jira/browse/GROOVY-8837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644631#comment-16644631 ] Constantine Plotnikov edited comment on GROOVY-8837 at 10/10/18 8:37 AM: - Maven run successful, but running test from IDEA fails on compile stage. This is strange, I guess I need more investigation for this. Possibly IDEA compiles test differently from maven compiler. I'll post a bug to IDEA too. was (Author: const): Maven run successful, but running test from IDEA fails on compile stage. This is strange, I guess I need more investigation for this. Possibly IDEA compiles test differently from maven compiler. > Invalid type inference for redefined generic boundaries > --- > > Key: GROOVY-8837 > URL: https://issues.apache.org/jira/browse/GROOVY-8837 > Project: Groovy > Issue Type: Bug > Components: Compiler >Affects Versions: 2.5.2 >Reporter: Constantine Plotnikov >Priority: Major > Attachments: groovy-bug-generic-extension.zip > > > Static compiler incorrectly calculates type boundary for chain calls with > generic types. When method is called, it takes boundary defined in the method > of the class (Base in sample), instead of the boundary redefined in subclass > (SubClass in sample). > The bug was discovered when working with Lombok SuperBuilder generated > classes from Groovy. The attached project demonstrate the bug on the smaller > sample. > Note that Java test infers type correctly, but groovy does not. However, the > groovy test works when CompileStatic annotation is disabled. > IDEA also shows red code here, but it possibly follows Groovy logic. > The bug also affects earlier versions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8837) Invalid type inference for redefined generic boundaries
[ https://issues.apache.org/jira/browse/GROOVY-8837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16644631#comment-16644631 ] Constantine Plotnikov commented on GROOVY-8837: --- Maven run successful, but running test from IDEA fails on compile stage. This is strange, I guess I need more investigation for this. Possibly IDEA compiles test differently from maven compiler. > Invalid type inference for redefined generic boundaries > --- > > Key: GROOVY-8837 > URL: https://issues.apache.org/jira/browse/GROOVY-8837 > Project: Groovy > Issue Type: Bug > Components: Compiler >Affects Versions: 2.5.2 >Reporter: Constantine Plotnikov >Priority: Major > Attachments: groovy-bug-generic-extension.zip > > > Static compiler incorrectly calculates type boundary for chain calls with > generic types. When method is called, it takes boundary defined in the method > of the class (Base in sample), instead of the boundary redefined in subclass > (SubClass in sample). > The bug was discovered when working with Lombok SuperBuilder generated > classes from Groovy. The attached project demonstrate the bug on the smaller > sample. > Note that Java test infers type correctly, but groovy does not. However, the > groovy test works when CompileStatic annotation is disabled. > IDEA also shows red code here, but it possibly follows Groovy logic. > The bug also affects earlier versions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
