[jira] [Resolved] (GROOVY-8649) Class loading in Groovy 2.5 breaks class loading hierarchy
[
https://issues.apache.org/jira/browse/GROOVY-8649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8649.
---
Resolution: Not A Bug
Assignee: John Wagenleitner
> Class loading in Groovy 2.5 breaks class loading hierarchy
> --
>
> Key: GROOVY-8649
> URL: https://issues.apache.org/jira/browse/GROOVY-8649
> Project: Groovy
> Issue Type: Bug
> Components: class generator
>Affects Versions: 2.5.0
>Reporter: Alexander Veit
>Assignee: John Wagenleitner
>Priority: Blocker
>
> Prior to Groovy 2.5 GroovyClassLoader passed classes requested by script code
> like
> {quote}def obj = new org.example.NonScriptableClass(){quote}
> to its parent class loader (hereby the NonScriptableClasses are Java classes).
> We use this behavior to allow or deny loading of Java classes with the parent
> class loader based on certain annotations on the respective class.
> With Groovy 2.5 this behavior has changed. org.example.NonScriptableClass is
> no more passed to the parent class loader. This breaks our security mechanism.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8649) Class loading in Groovy 2.5 breaks class loading hierarchy
[
https://issues.apache.org/jira/browse/GROOVY-8649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520480#comment-16520480
]
John Wagenleitner commented on GROOVY-8649:
---
Just want to clarify that the ASM resolving is used at compilation in order to
build AST nodes for referenced classes instead of via reflection (and
classloader) as before. It does not affect runtime where things like object
equality and security mechanisms come into play.
Sounds like your use case was to prevent compilation by providing a custom
classloader. Another way to hook into the compilation process would be to
provide a custom {{ClassNodeResovler}}, [according to the
docs|http://docs.groovy-lang.org/latest/html/gapi/org/codehaus/groovy/control/ClassNodeResolver.html]
it is meant to be a "pluggable way to resolve class names".
With 2.5.0 out it's likely too late to undo the default. With the compiler
option to disable it and with other ways to hook in like a ClassNodeResolver,
does this address your issue?
> Class loading in Groovy 2.5 breaks class loading hierarchy
> --
>
> Key: GROOVY-8649
> URL: https://issues.apache.org/jira/browse/GROOVY-8649
> Project: Groovy
> Issue Type: Bug
> Components: class generator
>Affects Versions: 2.5.0
>Reporter: Alexander Veit
>Priority: Blocker
>
> Prior to Groovy 2.5 GroovyClassLoader passed classes requested by script code
> like
> {quote}def obj = new org.example.NonScriptableClass(){quote}
> to its parent class loader (hereby the NonScriptableClasses are Java classes).
> We use this behavior to allow or deny loading of Java classes with the parent
> class loader based on certain annotations on the respective class.
> With Groovy 2.5 this behavior has changed. org.example.NonScriptableClass is
> no more passed to the parent class loader. This breaks our security mechanism.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GROOVY-8505) ArrayIndexOutOfBoundsException with @Nullable change
[
https://issues.apache.org/jira/browse/GROOVY-8505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8505.
---
Resolution: Fixed
Assignee: John Wagenleitner
Fix Version/s: 2.5.1
2.4.16
Thanks for reporting the issue.
> ArrayIndexOutOfBoundsException with @Nullable change
>
>
> Key: GROOVY-8505
> URL: https://issues.apache.org/jira/browse/GROOVY-8505
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.4.12
> Environment: See
> https://scans.gradle.com/s/gr3dszv44wkfg/console-log#L476 for execution
> details.
>Reporter: Lóránt Pintér
>Assignee: John Wagenleitner
>Priority: Major
> Fix For: 2.4.16, 2.5.1
>
>
> *Steps to reproduce:*
> {code}
> $ git clone [https://github.com/gradle/gradle
> $ cd gradle
> $ git checkout c8e7ac4adb2f72390ed681eb8bfdaa4baa8e
> $ ./gradlew :core:compileTestGroovy
> $ # ^ This version works
> $ git revert --no-commit head
> $ ./gradlew :core:compileTestGroovy
> $ # ^ This will fail
> {code}
> The reverted commit is this:
> https://github.com/gradle/gradle/pull/4682/commits/c8e7ac4adb2f72390ed681eb8bfdaa4baa8e
> It removes a {{@Nullable}} annotation from a constructor parameter. If the
> annotation is present (i.e. the commit is reverted), {{./gradlew
> :core:compileTestGroovy}} will produce the following exception:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 1
> at
> org.codehaus.groovy.vmplugin.v5.Java5.makeParameters(Java5.java:451)
> at
> org.codehaus.groovy.vmplugin.v5.Java5.configureClassNode(Java5.java:382)
> at org.codehaus.groovy.ast.ClassNode.lazyClassInit(ClassNode.java:280)
> at
> org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:1009)
> at
> org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:1004)
> at org.codehaus.groovy.ast.ClassNode.getSuperClass(ClassNode.java:998)
> at org.codehaus.groovy.ast.ClassNode.isDerivedFrom(ClassNode.java:941)
> at
> org.codehaus.groovy.classgen.asm.InvocationWriter.castToNonPrimitiveIfNecessary(InvocationWriter.java:863)
> at
> org.codehaus.groovy.classgen.asm.OperandStack.doConvertAndCast(OperandStack.java:345)
> at
> org.codehaus.groovy.classgen.asm.OperandStack.doGroovyCast(OperandStack.java:282)
> at
> org.codehaus.groovy.classgen.asm.BinaryExpressionHelper.evaluateEqual(BinaryExpressionHelper.java:344)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitDeclarationExpression(AsmClassGenerator.java:637)
> at
> org.codehaus.groovy.ast.expr.DeclarationExpression.visit(DeclarationExpression.java:89)
> at
> org.codehaus.groovy.classgen.asm.StatementWriter.writeExpressionStatement(StatementWriter.java:613)
> at
> org.codehaus.groovy.classgen.asm.OptimizingStatementWriter.writeExpressionStatement(OptimizingStatementWriter.java:366)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitExpressionStatement(AsmClassGenerator.java:624)
> at
> org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:42)
> at
> org.codehaus.groovy.classgen.asm.StatementWriter.writeBlockStatement(StatementWriter.java:85)
> at
> org.codehaus.groovy.classgen.asm.OptimizingStatementWriter.writeBlockStatement(OptimizingStatementWriter.java:159)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitBlockStatement(AsmClassGenerator.java:570)
> at
> org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:71)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:104)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:115)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitStdMethod(AsmClassGenerator.java:434)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:387)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:126)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:511)
> at
> org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1081)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:53)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitClass(AsmClassGenerator.java:233)
> at
> org.codehaus.groovy.control.CompilationUnit.call(CompilationUnit.java:825)
> at
>
[jira] [Resolved] (GROOVY-8008) @CompileStatic causes failure to compile Groovy class that calls overloaded Java method
[ https://issues.apache.org/jira/browse/GROOVY-8008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Wagenleitner resolved GROOVY-8008. --- Resolution: Fixed Assignee: John Wagenleitner Fix Version/s: 2.5.1 2.4.16 Thanks for reporting the issue. > @CompileStatic causes failure to compile Groovy class that calls overloaded > Java method > --- > > Key: GROOVY-8008 > URL: https://issues.apache.org/jira/browse/GROOVY-8008 > Project: Groovy > Issue Type: Bug >Affects Versions: 2.4.5, 2.4.7, 2.4.8 > Environment: Mac OS / Java 8_u112 >Reporter: Renato Athaydes >Assignee: John Wagenleitner >Priority: Major > Fix For: 2.4.16, 2.5.1 > > > This bug is not making sense to me, but I want to report it because it's > incredibly frustrating to get an error message that won't even tell me which > file the compiler was trying to compile before throwing an Exception. > Here's the stacktrace: > Error:Groovyc: While compiling osgiaas-cli-groovy_main: > java.lang.ArrayIndexOutOfBoundsException: 2 > at org.codehaus.groovy.vmplugin.v5.Java5.makeParameters(Java5.java:443) > at > org.codehaus.groovy.vmplugin.v5.Java5.configureClassNode(Java5.java:376) > at org.codehaus.groovy.ast.ClassNode.lazyClassInit(ClassNode.java:265) > at org.codehaus.groovy.ast.ClassNode.getAnnotations(ClassNode.java:1431) > at org.codehaus.groovy.ast.ClassNode.getAnnotations(ClassNode.java:1430) > at > org.codehaus.groovy.transform.trait.Traits.isAnnotatedWithTrait(Traits.java:170) > at org.codehaus.groovy.transform.trait.Traits.isTrait(Traits.java:149) > at > org.codehaus.groovy.transform.trait.Traits.collectSelfTypes(Traits.java:309) > at > org.codehaus.groovy.transform.trait.Traits.collectSelfTypes(Traits.java:291) > at > org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.addSelfTypes(StaticTypeCheckingVisitor.java:3102) > at > org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.makeOwnerList(StaticTypeCheckingVisitor.java:3083) > at > org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethodCallExpression(StaticTypeCheckingVisitor.java:2852) > at > org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethodCallExpression(StaticCompilationVisitor.java:297) > at > org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:66) > at > org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethodCallExpression(StaticTypeCheckingVisitor.java:2735) > at > org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethodCallExpression(StaticCompilationVisitor.java:297) > at > org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:66) > at > org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethodCallExpression(StaticTypeCheckingVisitor.java:2735) > at > org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethodCallExpression(StaticCompilationVisitor.java:297) > at > org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:66) > at > org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethodCallExpression(StaticTypeCheckingVisitor.java:2735) > at > org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethodCallExpression(StaticCompilationVisitor.java:297) > at > org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:66) > at > org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitProperty(ClassCodeVisitorSupport.java:144) > at > org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitProperty(StaticTypeCheckingVisitor.java:1518) > at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1074) > at > org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:53) > at > org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitClass(StaticTypeCheckingVisitor.java:249) > at > org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitClass(StaticCompilationVisitor.java:122) > at > org.codehaus.groovy.transform.sc.StaticCompileTransformation.visit(StaticCompileTransformation.java:63) > at > org.codehaus.groovy.transform.ASTTransformationVisitor.visitClass(ASTTransformationVisitor.java:134) > at > org.codehaus.groovy.transform.ASTTransformationVisitor$2.call(ASTTransformationVisitor.java:178) > at > org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1055) > at >
[jira] [Resolved] (GROOVY-8654) Can't compile documentation, no Gradle task defined for this
[
https://issues.apache.org/jira/browse/GROOVY-8654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8654.
---
Resolution: Fixed
Assignee: John Wagenleitner
Fix Version/s: 2.5.1
Thanks for reporting the issue and for the pull request.
> Can't compile documentation, no Gradle task defined for this
> -
>
> Key: GROOVY-8654
> URL: https://issues.apache.org/jira/browse/GROOVY-8654
> Project: Groovy
> Issue Type: Bug
> Components: GroovyDoc
>Affects Versions: 3.x
>Reporter: Andrej Balles
>Assignee: John Wagenleitner
>Priority: Trivial
> Fix For: 2.5.1
>
>
> Hi!
> trying to build the documentation fails, because no gradle task defined:
> {code:java}
> gradlew assembleAsciidoc
> ...
> * What went wrong:
> Task 'assembleAsciidoc' not found in root project 'groovy'.{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GROOVY-8614) Invalid reference generated in InnerClasses attribute for nested interface
[
https://issues.apache.org/jira/browse/GROOVY-8614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8614.
---
Resolution: Fixed
Assignee: John Wagenleitner
Fix Version/s: 2.5.1
2.4.16
Thanks for reporting the issue.
> Invalid reference generated in InnerClasses attribute for nested interface
> --
>
> Key: GROOVY-8614
> URL: https://issues.apache.org/jira/browse/GROOVY-8614
> Project: Groovy
> Issue Type: Bug
> Components: class generator
>Affects Versions: 2.4.15
>Reporter: Tony Abbott
>Assignee: John Wagenleitner
>Priority: Minor
> Fix For: 2.4.16, 2.5.1
>
>
> Compiling a class with a nested interface results in a reference to a
> non-existent inner class "X$Y$1" in the InnerClasses attribute of the
> resultant class file. Nested classes and inner classes do not exhibit this
> problem, only nested interfaces.
> Sample class that demonstrates the problem:
> {code:java}
> class X {
> interface Y {}
> }
> {code}
> Examining the resultant class file:
> {noformat}
> $ javap -v -cp . X.class
> ...
> SourceFile: "X.groovy"
> InnerClasses:
> public #139= #138 of #2; //Y=class X$Y of class X
> static #142= #141 of #2; //1=class X$Y$1 of class X
> {noformat}
> There is a reference to "X$Y$1" which does not exist. This breaks some tools,
> for example JUnit 5 test discovery.
>
> It looks to me like this is related to
> https://issues.apache.org/jira/browse/GROOVY-5082, being the same bug just
> manifesting for nested interfaces.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8649) Class loading in Groovy 2.5 breaks class loading hierarchy
[
https://issues.apache.org/jira/browse/GROOVY-8649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516175#comment-16516175
]
John Wagenleitner commented on GROOVY-8649:
---
This might be due to the new class resolving strategy used by default in 2.5.0
which uses ASM to read class files on the classpath instead of a classloader. I
don't know of an easy way to disable the ASM resolving in order to revert back
to the prior behavior. But if you have the ability to pass in a
{{CompilerConfiguration}} to the {{GroovyClassLoader}} or other compiler your
using (assuming it's under your control), something like the following would
work to disable the ASM resolving and it would fall back to using the
classloader:
{code}
import org.codehaus.groovy.control.CompilerConfiguration
ClassLoader loader = this.getClass().getClassLoader()
CompilerConfiguration compilerConfig = new
CompilerConfiguration(CompilerConfiguration.DEFAULT)
compilerConfig.getOptimizationOptions().put("asmResolving", false)
GroovyClassLoader gcl = new GroovyClassLoader(loader, compilerConfig)
gcl.parseClass("def obj = new org.example.NonScriptableClass()"){code}
> Class loading in Groovy 2.5 breaks class loading hierarchy
> --
>
> Key: GROOVY-8649
> URL: https://issues.apache.org/jira/browse/GROOVY-8649
> Project: Groovy
> Issue Type: Bug
> Components: class generator
>Affects Versions: 2.5.0
>Reporter: Alexander Veit
>Priority: Blocker
>
> Prior to Groovy 2.5 GroovyClassLoader passed classes requested by script code
> like
> {quote}def obj = new org.example.NonScriptableClass(){quote}
> to its parent class loader (hereby the NonScriptableClasses are Java classes).
> We use this behavior to allow or deny loading of Java classes with the parent
> class loader based on certain annotations on the respective class.
> With Groovy 2.5 this behavior has changed. org.example.NonScriptableClass is
> no more passed to the parent class loader. This breaks our security mechanism.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GROOVY-8195) CompileStatic fails to infer correct type when using elvis operator
[
https://issues.apache.org/jira/browse/GROOVY-8195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8195.
---
Resolution: Fixed
Assignee: John Wagenleitner
Fix Version/s: 2.4.13
Thanks for reporting the issue, looks like this was fixed in 2.4.13.
> CompileStatic fails to infer correct type when using elvis operator
> ---
>
> Key: GROOVY-8195
> URL: https://issues.apache.org/jira/browse/GROOVY-8195
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.4.9
>Reporter: Richard Zhang
>Assignee: John Wagenleitner
>Priority: Major
> Fix For: 2.4.13
>
>
> see the following example:
> {code}
> import groovy.transform.CompileStatic
> @CompileStatic
> def foo() {
> Map strongMap
> Map elvisMap = strongMap ?: [:] // won't compile
> Map initStrongMap = [:] // compiles ok
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8648) Compound assignment to attribute fails with ASM error
[
https://issues.apache.org/jira/browse/GROOVY-8648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner updated GROOVY-8648:
--
Description:
The following will fail with 2.4.14 and above.
{code:java}
class Account {
int balance = 0
void credit(int add) {
this.@balance += add
}
}
def acct = new Account()
acct.credit(3)
assert acct.balance == 3
{code}
Fails with the following in 2.5.0
{code:java}
groovy.lang.GroovyRuntimeException: ASM reporting processing error for
Account#credit with signature void credit(int)
{code}
And this starting in 2.4.14
{code:java}
java.lang.VerifyError: (class: Account, method: credit signature: (I)V) Unable
to pop operand off an empty stack
{code}
Possibly related to the fixes for GROOVY-8385 and the operand stack not being
marked to handle the compound assignment operators.
Issue reported on the [dev mailing
list|https://mail-archives.apache.org/mod_mbox/groovy-dev/201806.mbox/%3Cef1093fea2ceab17b52fc021631b7b2b5e86ca4e.camel%40winder.org.uk%3E].
was:
The following will faile with 2.4.14 and above.
{code}
class Account {
int balance = 0
void credit(int add) {
this.@balance += add
}
}
def acct = new Account()
acct.credit(3)
assert acct.balance == 3
{code}
Fails with the following in 2.5.0
{code:java}
groovy.lang.GroovyRuntimeException: ASM reporting processing error for
Account#credit with signature void credit(int)
{code}
And this starting in 2.4.14
{code:java}
java.lang.VerifyError: (class: Account, method: credit signature: (I)V) Unable
to pop operand off an empty stack
{code}
Possibly related to the fixes for GROOVY-8385 and the operand stack not being
marked to handle the compound assignment operators.
Issue reported on the [dev mailing
list|https://mail-archives.apache.org/mod_mbox/groovy-dev/201806.mbox/%3Cef1093fea2ceab17b52fc021631b7b2b5e86ca4e.camel%40winder.org.uk%3E].
> Compound assignment to attribute fails with ASM error
> -
>
> Key: GROOVY-8648
> URL: https://issues.apache.org/jira/browse/GROOVY-8648
> Project: Groovy
> Issue Type: Bug
> Components: class generator
>Affects Versions: 2.4.14, 2.5.0
>Reporter: John Wagenleitner
>Priority: Major
>
> The following will fail with 2.4.14 and above.
> {code:java}
> class Account {
> int balance = 0
> void credit(int add) {
> this.@balance += add
> }
> }
> def acct = new Account()
> acct.credit(3)
> assert acct.balance == 3
> {code}
> Fails with the following in 2.5.0
> {code:java}
> groovy.lang.GroovyRuntimeException: ASM reporting processing error for
> Account#credit with signature void credit(int)
> {code}
> And this starting in 2.4.14
> {code:java}
> java.lang.VerifyError: (class: Account, method: credit signature: (I)V)
> Unable to pop operand off an empty stack
> {code}
> Possibly related to the fixes for GROOVY-8385 and the operand stack not being
> marked to handle the compound assignment operators.
> Issue reported on the [dev mailing
> list|https://mail-archives.apache.org/mod_mbox/groovy-dev/201806.mbox/%3Cef1093fea2ceab17b52fc021631b7b2b5e86ca4e.camel%40winder.org.uk%3E].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8648) Compound assignment to attribute fails with ASM error
John Wagenleitner created GROOVY-8648:
-
Summary: Compound assignment to attribute fails with ASM error
Key: GROOVY-8648
URL: https://issues.apache.org/jira/browse/GROOVY-8648
Project: Groovy
Issue Type: Bug
Components: class generator
Affects Versions: 2.5.0, 2.4.14
Reporter: John Wagenleitner
The following will faile with 2.4.14 and above.
{code}
class Account {
int balance = 0
void credit(int add) {
this.@balance += add
}
}
def acct = new Account()
acct.credit(3)
assert acct.balance == 3
{code}
Fails with the following in 2.5.0
{code:java}
groovy.lang.GroovyRuntimeException: ASM reporting processing error for
Account#credit with signature void credit(int)
{code}
And this starting in 2.4.14
{code:java}
java.lang.VerifyError: (class: Account, method: credit signature: (I)V) Unable
to pop operand off an empty stack
{code}
Possibly related to the fixes for GROOVY-8385 and the operand stack not being
marked to handle the compound assignment operators.
Issue reported on the [dev mailing
list|https://mail-archives.apache.org/mod_mbox/groovy-dev/201806.mbox/%3Cef1093fea2ceab17b52fc021631b7b2b5e86ca4e.camel%40winder.org.uk%3E].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GROOVY-8632) Groovy 2.5.0 fails to compile Google Java Client sample code
[
https://issues.apache.org/jira/browse/GROOVY-8632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8632.
---
Resolution: Fixed
Fix Version/s: 2.5.1
Thanks for reporting the issue.
> Groovy 2.5.0 fails to compile Google Java Client sample code
>
>
> Key: GROOVY-8632
> URL: https://issues.apache.org/jira/browse/GROOVY-8632
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.5.0
> Environment: Ubuntu 18.04, Oracle Java 1.8.0_171-b11, Groovy 2.5.0
>Reporter: Robert Kasanicky
>Assignee: John Wagenleitner
>Priority: Major
> Fix For: 2.5.1
>
>
> I have been using Google Java Client libraries with Groovy 2.4.x successfully
> but now I'm getting multiple compilation errors when trying to upgrade to
> Groovy 2.5.0. Note that none of the classes mentioned are actually abstract
> although the 2.5.0 compiler clearly thinks they are.
> {code}
> @Grab('com.google.apis:google-api-services-analyticsreporting:v4-rev124-1.23.0')
> import com.google.api.services.analyticsreporting.v4.AnalyticsReporting
> @Grab('com.google.apis:google-api-services-sheets:v4-rev525-1.23.0')
> import com.google.api.services.sheets.v4.Sheets
> @Grab('com.google.apis:google-api-services-drive:v3-rev120-1.23.0')
> import com.google.api.services.drive.Drive
> final HTTP_TRANSPORT = null
> final JSON_FACTORY = null
> def requestInitializer = null
> def credential = null
> def builderAnalytics = new AnalyticsReporting.Builder(HTTP_TRANSPORT,
> JSON_FACTORY, requestInitializer)
> def builderSheets = new Sheets.Builder(HTTP_TRANSPORT, JSON_FACTORY,
> credential)
> def builderDrive = new Drive.Builder(HTTP_TRANSPORT, JSON_FACTORY, credential)
> {code}
> {code}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> /home/edited/bug25.groovy: 13: You cannot create an instance from the
> abstract class
> 'com.google.api.services.analyticsreporting.v4.AnalyticsReporting$Builder'.
> @ line 13, column 24.
> def builderAnalytics = new AnalyticsReporting.Builder(HTTP_TRANSPORT,
> JSON_FACTORY, requestInitializer)
> ^
> /home/edited/bug25.groovy: 15: You cannot create an instance from the
> abstract class 'com.google.api.services.sheets.v4.Sheets$Builder'.
> @ line 15, column 21.
> def builderSheets = new Sheets.Builder(HTTP_TRANSPORT, JSON_FACTORY,
> credential)
> ^
> /home/edited/bug25.groovy: 17: You cannot create an instance from the
> abstract class 'com.google.api.services.drive.Drive$Builder'.
> @ line 17, column 20.
> def builderDrive = new Drive.Builder(HTTP_TRANSPORT, JSON_FACTORY,
> credential)
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8505) ArrayIndexOutOfBoundsException with @Nullable change
[
https://issues.apache.org/jira/browse/GROOVY-8505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16513256#comment-16513256
]
John Wagenleitner commented on GROOVY-8505:
---
This is the same issue as GROOVY-8008.
> ArrayIndexOutOfBoundsException with @Nullable change
>
>
> Key: GROOVY-8505
> URL: https://issues.apache.org/jira/browse/GROOVY-8505
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.4.12
> Environment: See
> https://scans.gradle.com/s/gr3dszv44wkfg/console-log#L476 for execution
> details.
>Reporter: Lóránt Pintér
>Priority: Major
>
> *Steps to reproduce:*
> {code}
> $ git clone [https://github.com/gradle/gradle
> $ cd gradle
> $ git checkout c8e7ac4adb2f72390ed681eb8bfdaa4baa8e
> $ ./gradlew :core:compileTestGroovy
> $ # ^ This version works
> $ git revert --no-commit head
> $ ./gradlew :core:compileTestGroovy
> $ # ^ This will fail
> {code}
> The reverted commit is this:
> https://github.com/gradle/gradle/pull/4682/commits/c8e7ac4adb2f72390ed681eb8bfdaa4baa8e
> It removes a {{@Nullable}} annotation from a constructor parameter. If the
> annotation is present (i.e. the commit is reverted), {{./gradlew
> :core:compileTestGroovy}} will produce the following exception:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 1
> at
> org.codehaus.groovy.vmplugin.v5.Java5.makeParameters(Java5.java:451)
> at
> org.codehaus.groovy.vmplugin.v5.Java5.configureClassNode(Java5.java:382)
> at org.codehaus.groovy.ast.ClassNode.lazyClassInit(ClassNode.java:280)
> at
> org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:1009)
> at
> org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:1004)
> at org.codehaus.groovy.ast.ClassNode.getSuperClass(ClassNode.java:998)
> at org.codehaus.groovy.ast.ClassNode.isDerivedFrom(ClassNode.java:941)
> at
> org.codehaus.groovy.classgen.asm.InvocationWriter.castToNonPrimitiveIfNecessary(InvocationWriter.java:863)
> at
> org.codehaus.groovy.classgen.asm.OperandStack.doConvertAndCast(OperandStack.java:345)
> at
> org.codehaus.groovy.classgen.asm.OperandStack.doGroovyCast(OperandStack.java:282)
> at
> org.codehaus.groovy.classgen.asm.BinaryExpressionHelper.evaluateEqual(BinaryExpressionHelper.java:344)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitDeclarationExpression(AsmClassGenerator.java:637)
> at
> org.codehaus.groovy.ast.expr.DeclarationExpression.visit(DeclarationExpression.java:89)
> at
> org.codehaus.groovy.classgen.asm.StatementWriter.writeExpressionStatement(StatementWriter.java:613)
> at
> org.codehaus.groovy.classgen.asm.OptimizingStatementWriter.writeExpressionStatement(OptimizingStatementWriter.java:366)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitExpressionStatement(AsmClassGenerator.java:624)
> at
> org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:42)
> at
> org.codehaus.groovy.classgen.asm.StatementWriter.writeBlockStatement(StatementWriter.java:85)
> at
> org.codehaus.groovy.classgen.asm.OptimizingStatementWriter.writeBlockStatement(OptimizingStatementWriter.java:159)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitBlockStatement(AsmClassGenerator.java:570)
> at
> org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:71)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:104)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:115)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitStdMethod(AsmClassGenerator.java:434)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:387)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:126)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:511)
> at
> org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1081)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:53)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitClass(AsmClassGenerator.java:233)
> at
> org.codehaus.groovy.control.CompilationUnit.call(CompilationUnit.java:825)
> at
> org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1065)
> at
> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603)
> at
[jira] [Commented] (GROOVY-8612) sql query with empty parameter list returns errors
[
https://issues.apache.org/jira/browse/GROOVY-8612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512827#comment-16512827
]
John Wagenleitner commented on GROOVY-8612:
---
A work-around in Groovy 2.4.15 would be to set the following prior to executing
the sql:
{code}
sql.enableMetaDataChecking = true{code}
In 2.5.0 it's turned on by default.
> sql query with empty parameter list returns errors
> --
>
> Key: GROOVY-8612
> URL: https://issues.apache.org/jira/browse/GROOVY-8612
> Project: Groovy
> Issue Type: Bug
> Components: SQL processing
>Affects Versions: 2.4.15
>Reporter: Ludger Wolter
>Priority: Major
>
> {code:java}
> import groovy.sql.Sql
> import oracle.jdbc.driver.OracleConnection
> def sql = Sql.newInstance("jdbc:oracle:thin:@dev6418:1521:l101", "allcus",
> "allcus", "oracle.jdbc.OracleDriver")
> def sqlParams = [:]
> def row = sql.firstRow('select count(*) icount from all_tables',
> Arrays.asList(sqlParams))
> println row.icount
> {code}
> {code:java}
> Mai 28, 2018 4:08:36 PM groovy.sql.Sql$AbstractQueryCommand execute
> WARNUNG: Failed to execute: select count(*) icount from all_tables because:
> Ungültiger Spaltentyp
> Mai 28, 2018 4:08:36 PM groovy.sql.Sql$AbstractQueryCommand execute
> WARNUNG: Failed to execute: select count(*) icount from all_tables because:
> Ungültiger Spaltentyp
> Exception thrown
> java.sql.SQLException: Ungültiger Spaltentyp
> at
> oracle.jdbc.driver.OraclePreparedStatement.setObjectCritical(OraclePreparedStatement.java:10495)
> at
> oracle.jdbc.driver.OraclePreparedStatement.setObjectInternal(OraclePreparedStatement.java:9974)
> at
> oracle.jdbc.driver.OraclePreparedStatement.setObjectInternal(OraclePreparedStatement.java:10799)
> at
> oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePreparedStatement.java:10776)
> at
> oracle.jdbc.driver.OraclePreparedStatementWrapper.setObject(OraclePreparedStatementWrapper.java:241)
> at ConsoleScript8.run(ConsoleScript8:8)
> {code}
> {code:java}
> def sqlParams = [a:1]{code}
> also provides an error but following works
> {code}
> def sqlParams = [a:1, b:1]
> def row = sql.firstRow('select count(*) icount from all_tables where 1=:a',
> Arrays.asList(sqlParams))
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8634) New warning messages for 2.5 and Java7
[
https://issues.apache.org/jira/browse/GROOVY-8634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510271#comment-16510271
]
John Wagenleitner commented on GROOVY-8634:
---
Even if not explicitly using it Groovy will try to load all extension classes
on startup.
{quote}I had a similar problem awhile ago with java nio on a server still using
Java 6. For that I just removed a jar from the groovy lib directory. I wonder
if there is something similar I can do for this.
{quote}
Removing or renaming (remove jar extension) the
{{lib\groovy-datetime-.jar}} file should get rid of those warnings.
> New warning messages for 2.5 and Java7
> --
>
> Key: GROOVY-8634
> URL: https://issues.apache.org/jira/browse/GROOVY-8634
> Project: Groovy
> Issue Type: Bug
> Environment: -bash-4.1$ uname -a
> Linux xx 2.6.32-696.20.1.el6.x86_64 #1 SMP Thu Jan 25
> 15:32:38 PST 2018 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Erick Nelson
>Priority: Blocker
>
> On a server we still have Java7 installed, I'm getting these warning
> messages. They look like JUL logging but I'm not sure. I have the
> jul-to-slf4j bridge installed but these messages don't seem to be rerouted so
> I'm not sure what the source is at the moment. I don't mind the warnings, as
> long as I can capture and properly log them.
>
> -bash-4.1$ /opt/apps/tools/groovy/bin/groovy -v
> Jun 04, 2018 7:03:01 AM
> org.codehaus.groovy.runtime.m12n.MetaInfExtensionModule newModule
> WARNING: Module [groovy-datetime] - Unable to load extension class
> [org.apache.groovy.datetime.extensions.DateTimeExtensions]
> Jun 04, 2018 7:03:01 AM
> org.codehaus.groovy.runtime.m12n.MetaInfExtensionModule newModule
> WARNING: Module [groovy-datetime] - Unable to load extension class
> [org.apache.groovy.datetime.extensions.DateTimeStaticExtensions]
> Groovy Version: *2.5.0* JVM*: 1.7.0_161* Vendor: Oracle Corporation OS: Linux
>
> The bridge that I am using is...
>
> org.slf4j
> jul-to-slf4j
> 1.7.9
>
>
> And I'm invoking it in my startup with...
> static void createJulBridge (BaseScript script) {
> try {
> java.util.logging.LogManager.getLogManager().reset()
> SLF4JBridgeHandler.removeHandlersForRootLogger()
> SLF4JBridgeHandler.install()
> }
> catch (Exception e) {
> script._warn << "jul->slf4j bridge install error [${e.message}]"
> }
> }
>
> I think my problem might be that those messages are coming up before I can
> hookup the bridge.
>
> Any insight on this you can give me?
> It would be nice if there was a way to suppress or delay these warnings. As
> it is , this is keeping me from using 2.5.0.
> In the meantime I am trying to get our admins to upgrade to at least Java8...
> but that might take some time.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8640) Cannot find matching comparator method
[
https://issues.apache.org/jira/browse/GROOVY-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509954#comment-16509954
]
John Wagenleitner commented on GROOVY-8640:
---
I believe this is related to GROOVY-8562. Inside that closure {{this}} would
refer to {{Test.Nested}} and it does have a {{MAX_LINES}} property because of
the delegate. If you remove {{CompileStatic}} you would see that {{MAX_LINES}}
resolves to {{NULL}} which dynamic groovy handles as 0. So I think this error
is correct and the fix would be to use {{Test.MAX_LINES}} inside the closure
instead of the implicit {{this.MAX_LINES}}.
> Cannot find matching comparator method
> --
>
> Key: GROOVY-8640
> URL: https://issues.apache.org/jira/browse/GROOVY-8640
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.5.0
>Reporter: paolo di tommaso
>Priority: Minor
>
> The following class static compilation fails
> {code:java}
> @CompileStatic
> class Test {
> static private int MAX_LINES = 100
> private static class Nested {
> @Delegate
> private Map delegate = [:]
> private String fetch(Path path) {
> int c=0
> def result = new StringBuilder()
> path.withReader { reader ->
> String line
> while( (line=reader.readLine()) && c++ result << line
> }
> }
> result
> }
> }
> }{code}
>
> Reported error:
> {code:java}
> Test.groovy: 45: [Static type checking] - Cannot find matching method
> java.lang.Integer#compareTo(java.lang.Object). Please check if the declared
> type is correct and if the method exists.
> @ line 45, column 55.
> line=reader.readLine()) && c++ ^{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8632) Groovy 2.5.0 fails to compile Google Java Client sample code
[
https://issues.apache.org/jira/browse/GROOVY-8632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506743#comment-16506743
]
John Wagenleitner commented on GROOVY-8632:
---
This issue is with the new ASM class file based resolver that is turned on by
default in 2.5.0. As it visits classes it stores inner class access modifiers
by the short class name (i.e., {{Builder}}).
https://github.com/apache/groovy/blob/334b5df0af1e6f06aeca101136f01201312a0259/src/main/java/org/codehaus/groovy/ast/decompiled/AsmDecompiler.java#L106
When building the actual {{ClassNode}} for inner classes it tries to determine
if the inner class is static by finding the outer class and looking in it’s
{{innerClassModifiers}} map.
https://github.com/apache/groovy/blob/334b5df0af1e6f06aeca101136f01201312a0259/src/main/java/org/codehaus/groovy/ast/decompiled/DecompiledClassNode.java#L58-L75
The problem is that it only stores the short name rather than the fully
qualified name. A class file may contain INNERCLASS references to another
classes’ inner class and it could have the same name, which is the case for the
Google API class {{AnalyticsReporting}} class. In that case that other class’
abstract modifier is being picked up and causing the reported error.
{code:java}
// class version 49.0 (49)
// access flags 0x21
public class com/google/api/services/analyticsreporting/v4/AnalyticsReporting
extends com/google/api/client/googleapis/services/json/AbstractGoogleJsonClient
{
// compiled from: AnalyticsReporting.java
// access flags 0x19
public final static INNERCLASS
com/google/api/services/analyticsreporting/v4/AnalyticsReporting$Builder
com/google/api/services/analyticsreporting/v4/AnalyticsReporting Builder
// access flags 0x1
public INNERCLASS
com/google/api/services/analyticsreporting/v4/AnalyticsReporting$Reports
com/google/api/services/analyticsreporting/v4/AnalyticsReporting Reports
// access flags 0x409
public static abstract INNERCLASS
com/google/api/client/googleapis/services/json/AbstractGoogleJsonClient$Builder
com/google/api/client/googleapis/services/json/AbstractGoogleJsonClient Builder
….
….
{code}
While this could be fixed by storing the fully qualified name, the logic might
be simplified since the class file for inner classes contain a self referenced
INNERCLASS entry. So it not necessary to resolve the outer class. During the
{{visitInnerClass}} call if the top level class name matches the inner class
name, those modifiers could be stored and used later to determine the full
access modifiers for inner classes.
{code:java}
// class version 49.0 (49)
// access flags 0x31
public final class
com/google/api/services/analyticsreporting/v4/AnalyticsReporting$Builder
extends
com/google/api/client/googleapis/services/json/AbstractGoogleJsonClient$Builder
{
// compiled from: AnalyticsReporting.java
// access flags 0x19
public final static INNERCLASS
com/google/api/services/analyticsreporting/v4/AnalyticsReporting$Builder
com/google/api/services/analyticsreporting/v4/AnalyticsReporting Builder
// access flags 0x409
public static abstract INNERCLASS
com/google/api/client/googleapis/services/json/AbstractGoogleJsonClient$Builder
com/google/api/client/googleapis/services/json/AbstractGoogleJsonClient Builder
// access flags 0x409
public static abstract INNERCLASS
com/google/api/client/googleapis/services/AbstractGoogleClient$Builder
com/google/api/client/googleapis/services/AbstractGoogleClient Builder
….
….
{code}
> Groovy 2.5.0 fails to compile Google Java Client sample code
>
>
> Key: GROOVY-8632
> URL: https://issues.apache.org/jira/browse/GROOVY-8632
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.5.0
> Environment: Ubuntu 18.04, Oracle Java 1.8.0_171-b11, Groovy 2.5.0
>Reporter: Robert Kasanicky
>Assignee: John Wagenleitner
>Priority: Major
>
> I have been using Google Java Client libraries with Groovy 2.4.x successfully
> but now I'm getting multiple compilation errors when trying to upgrade to
> Groovy 2.5.0. Note that none of the classes mentioned are actually abstract
> although the 2.5.0 compiler clearly thinks they are.
> {code}
> @Grab('com.google.apis:google-api-services-analyticsreporting:v4-rev124-1.23.0')
> import com.google.api.services.analyticsreporting.v4.AnalyticsReporting
> @Grab('com.google.apis:google-api-services-sheets:v4-rev525-1.23.0')
> import com.google.api.services.sheets.v4.Sheets
> @Grab('com.google.apis:google-api-services-drive:v3-rev120-1.23.0')
> import com.google.api.services.drive.Drive
> final HTTP_TRANSPORT = null
> final JSON_FACTORY = null
> def requestInitializer = null
> def credential = null
> def builderAnalytics = new
[jira] [Assigned] (GROOVY-8632) Groovy 2.5.0 fails to compile Google Java Client sample code
[
https://issues.apache.org/jira/browse/GROOVY-8632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner reassigned GROOVY-8632:
-
Assignee: John Wagenleitner
> Groovy 2.5.0 fails to compile Google Java Client sample code
>
>
> Key: GROOVY-8632
> URL: https://issues.apache.org/jira/browse/GROOVY-8632
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.5.0
> Environment: Ubuntu 18.04, Oracle Java 1.8.0_171-b11, Groovy 2.5.0
>Reporter: Robert Kasanicky
>Assignee: John Wagenleitner
>Priority: Major
>
> I have been using Google Java Client libraries with Groovy 2.4.x successfully
> but now I'm getting multiple compilation errors when trying to upgrade to
> Groovy 2.5.0. Note that none of the classes mentioned are actually abstract
> although the 2.5.0 compiler clearly thinks they are.
> {code}
> @Grab('com.google.apis:google-api-services-analyticsreporting:v4-rev124-1.23.0')
> import com.google.api.services.analyticsreporting.v4.AnalyticsReporting
> @Grab('com.google.apis:google-api-services-sheets:v4-rev525-1.23.0')
> import com.google.api.services.sheets.v4.Sheets
> @Grab('com.google.apis:google-api-services-drive:v3-rev120-1.23.0')
> import com.google.api.services.drive.Drive
> final HTTP_TRANSPORT = null
> final JSON_FACTORY = null
> def requestInitializer = null
> def credential = null
> def builderAnalytics = new AnalyticsReporting.Builder(HTTP_TRANSPORT,
> JSON_FACTORY, requestInitializer)
> def builderSheets = new Sheets.Builder(HTTP_TRANSPORT, JSON_FACTORY,
> credential)
> def builderDrive = new Drive.Builder(HTTP_TRANSPORT, JSON_FACTORY, credential)
> {code}
> {code}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> /home/edited/bug25.groovy: 13: You cannot create an instance from the
> abstract class
> 'com.google.api.services.analyticsreporting.v4.AnalyticsReporting$Builder'.
> @ line 13, column 24.
> def builderAnalytics = new AnalyticsReporting.Builder(HTTP_TRANSPORT,
> JSON_FACTORY, requestInitializer)
> ^
> /home/edited/bug25.groovy: 15: You cannot create an instance from the
> abstract class 'com.google.api.services.sheets.v4.Sheets$Builder'.
> @ line 15, column 21.
> def builderSheets = new Sheets.Builder(HTTP_TRANSPORT, JSON_FACTORY,
> credential)
> ^
> /home/edited/bug25.groovy: 17: You cannot create an instance from the
> abstract class 'com.google.api.services.drive.Drive$Builder'.
> @ line 17, column 20.
> def builderDrive = new Drive.Builder(HTTP_TRANSPORT, JSON_FACTORY,
> credential)
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8610) STC NPE using DGM collect on Iterator
[
https://issues.apache.org/jira/browse/GROOVY-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner updated GROOVY-8610:
--
Priority: Minor (was: Major)
> STC NPE using DGM collect on Iterator
> -
>
> Key: GROOVY-8610
> URL: https://issues.apache.org/jira/browse/GROOVY-8610
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.5.0
>Reporter: John Wagenleitner
>Assignee: John Wagenleitner
>Priority: Minor
>
> {code:groovy}
> @groovy.transform.TypeChecked
> def m() {
> List list = ['foo', 'bar', 'baz']
> list.iterator().collect { it.startsWith('ba') } == [false, true, true]
> }
> m()
> {code}
> Results in:
> {code:java}
> BUG! exception in phase 'instruction selection' in source unit
> 'TestScript.groovy' unexpected NullpointerException
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8610) STC NPE using DGM collect on Iterator
[
https://issues.apache.org/jira/browse/GROOVY-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492127#comment-16492127
]
John Wagenleitner commented on GROOVY-8610:
---
Stacktrace
{code:java}
BUG! exception in phase 'instruction selection' in source unit
'TestScripttestDGM_collectOnIterator0.groovy' unexpected NullpointerException
at
org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1092)
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)
Caused by: java.lang.NullPointerException
at org.codehaus.groovy.ast.GenericsType.(GenericsType.java:50)
at org.codehaus.groovy.ast.GenericsType.(GenericsType.java:58)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.resolveGenericsFromTypeHint(StaticTypeCheckingVisitor.java:2825)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.doInferClosureParameterTypes(StaticTypeCheckingVisitor.java:2746)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.inferClosureParameterTypes(StaticTypeCheckingVisitor.java:2591)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethodCallArguments(StaticTypeCheckingVisitor.java:2556)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethodCallExpression(StaticTypeCheckingVisitor.java:3254)
at
org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:70)
{code}
> STC NPE using DGM collect on Iterator
> -
>
> Key: GROOVY-8610
> URL: https://issues.apache.org/jira/browse/GROOVY-8610
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.5.0
>Reporter: John Wagenleitner
>Assignee: John Wagenleitner
>Priority: Major
>
> {code:groovy}
> @groovy.transform.TypeChecked
> def m() {
> List list = ['foo', 'bar', 'baz']
> list.iterator().collect { it.startsWith('ba') } == [false, true, true]
> }
> m()
> {code}
> Results in:
> {code:java}
> BUG! exception in phase 'instruction selection' in source unit
> 'TestScript.groovy' unexpected NullpointerException
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GROOVY-8610) STC NPE using DGM collect on Iterator
[
https://issues.apache.org/jira/browse/GROOVY-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner reassigned GROOVY-8610:
-
Assignee: John Wagenleitner
> STC NPE using DGM collect on Iterator
> -
>
> Key: GROOVY-8610
> URL: https://issues.apache.org/jira/browse/GROOVY-8610
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.5.0
>Reporter: John Wagenleitner
>Assignee: John Wagenleitner
>Priority: Major
>
> {code:groovy}
> @groovy.transform.TypeChecked
> def m() {
> List list = ['foo', 'bar', 'baz']
> list.iterator().collect { it.startsWith('ba') } == [false, true, true]
> }
> m()
> {code}
> Results in:
> {code:java}
> BUG! exception in phase 'instruction selection' in source unit
> 'TestScript.groovy' unexpected NullpointerException
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8610) STC NPE using DGM collect on Iterator
John Wagenleitner created GROOVY-8610:
-
Summary: STC NPE using DGM collect on Iterator
Key: GROOVY-8610
URL: https://issues.apache.org/jira/browse/GROOVY-8610
Project: Groovy
Issue Type: Bug
Components: Static Type Checker
Affects Versions: 2.5.0
Reporter: John Wagenleitner
{code:groovy}
@groovy.transform.TypeChecked
def m() {
List list = ['foo', 'bar', 'baz']
list.iterator().collect { it.startsWith('ba') } == [false, true, true]
}
m()
{code}
Results in:
{code:java}
BUG! exception in phase 'instruction selection' in source unit
'TestScript.groovy' unexpected NullpointerException
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-8595) Expected parameter of type XXX but got YYY static compile error
[
https://issues.apache.org/jira/browse/GROOVY-8595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16486187#comment-16486187
]
John Wagenleitner edited comment on GROOVY-8595 at 5/23/18 12:28 AM:
-
I tested this (quick test with groovy console) with that PR (fix for
GROOVY-8590) and it seems to resolves this issue. That PR has been applied.
was (Author: jwagenleitner):
I tested this with that PR (fix for GROOVY-8590) and that resolves this issue.
That PR has been applied, if possible if you can confirm the fix I'll go ahead
and resolve this.
> Expected parameter of type XXX but got YYY static compile error
> ---
>
> Key: GROOVY-8595
> URL: https://issues.apache.org/jira/browse/GROOVY-8595
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.5.0-rc-3
>Reporter: paolo di tommaso
>Priority: Major
>
> The following code report a compilation error:
> {code:java}
> @CompileStatic
> class Test {
> List foo() {
> return []
> }
> List bar() {
> return foo().collect { Foo it -> it.instanceId }
> }
> }
> @CompileStatic
> class Foo {
> String instanceId
> }{code}
>
> Error message
> {code:java}
> Test.groovy: 36: Expected parameter of type java.lang.String but got
> nextflow.Foo
> @ line 36, column 32.
> return foo().collect { Foo it -> it.instanceId }
> ^
> Test.groovy: 36: [Static type checking] - No such property: instanceId for
> class: java.lang.String
> @ line 36, column 42.
> urn foo().collect { Foo it -> it.instanc{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8595) Expected parameter of type XXX but got YYY static compile error
[
https://issues.apache.org/jira/browse/GROOVY-8595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16486187#comment-16486187
]
John Wagenleitner commented on GROOVY-8595:
---
I tested this with that PR (fix for GROOVY-8590) and that resolves this issue.
That PR has been applied, if possible if you can confirm the fix I'll go ahead
and resolve this.
> Expected parameter of type XXX but got YYY static compile error
> ---
>
> Key: GROOVY-8595
> URL: https://issues.apache.org/jira/browse/GROOVY-8595
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.5.0-rc-3
>Reporter: paolo di tommaso
>Priority: Major
>
> The following code report a compilation error:
> {code:java}
> @CompileStatic
> class Test {
> List foo() {
> return []
> }
> List bar() {
> return foo().collect { Foo it -> it.instanceId }
> }
> }
> @CompileStatic
> class Foo {
> String instanceId
> }{code}
>
> Error message
> {code:java}
> Test.groovy: 36: Expected parameter of type java.lang.String but got
> nextflow.Foo
> @ line 36, column 32.
> return foo().collect { Foo it -> it.instanceId }
> ^
> Test.groovy: 36: [Static type checking] - No such property: instanceId for
> class: java.lang.String
> @ line 36, column 42.
> urn foo().collect { Foo it -> it.instanc{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8590) STC incorrectly infers type of nested method call used in a return stmt
John Wagenleitner created GROOVY-8590:
-
Summary: STC incorrectly infers type of nested method call used in
a return stmt
Key: GROOVY-8590
URL: https://issues.apache.org/jira/browse/GROOVY-8590
Project: Groovy
Issue Type: Bug
Components: Static Type Checker
Affects Versions: 2.5.0-rc-3
Reporter: John Wagenleitner
{code:groovy}
class Source {
Object getValue() { '32' }
}
@groovy.transform.CompileStatic
int m(Source src) {
return Integer.parseInt((String) src.getValue())
}
null
{code}
Fails with
{code}
[Static type checking] - Inconvertible types: cannot cast int to
java.lang.String
{code}
Git bisect shows it is related to change for GROOVY-7753 ([commit
9d7c1bf1b07d43c1efd16c9252b|https://github.com/apache/groovy/commit/9d7c1bf1b07d43c1efd16c9252b209d29d739ced#diff-8f6109b9267c3330807df2c0ce2fab92R3237]).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GROOVY-8171) Escaped dollar slashy difference between old and parrot parsers
[
https://issues.apache.org/jira/browse/GROOVY-8171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8171.
---
Resolution: Fixed
Assignee: John Wagenleitner
Fix Version/s: 3.0.0-alpha-3
2.6.0-alpha-4
> Escaped dollar slashy difference between old and parrot parsers
> ---
>
> Key: GROOVY-8171
> URL: https://issues.apache.org/jira/browse/GROOVY-8171
> Project: Groovy
> Issue Type: Bug
> Components: parser-antlr4
>Affects Versions: 2.6.0-alpha-3, 3.0.0-alpha-2
>Reporter: John Wagenleitner
>Assignee: John Wagenleitner
>Priority: Minor
> Fix For: 2.6.0-alpha-4, 3.0.0-alpha-3
>
>
> The following test passes with the legacy parser but fails with Parrot
> {code}
> // legacy parser
> def s1 = $/this $$/ is an escaped dollar forward slash/$
> assert s1 == 'this $/ is an escaped dollar forward slash'
> {code}
> {code}
> // antlr4 enabled (parrot)
> assert s1 == 'this $/ is an escaped dollar forward slash'
>| |
>| false
>this / is an escaped dollar forward slash
> {code}
> Noticed this when I inadvertently changed a spec test in commit
> [0fb89906aa|https://github.com/apache/groovy/commit/0fb89906aa587920d11fae063bba1d1f8fe26254].
> When testing for an escaped dollar slash the test had to be changed
> ([commit
> 942cf4eb3e|https://github.com/apache/groovy/commit/942cf4eb3e87f2718df490b9e3547f2042720781])
> to pass using the Antlr4 parser.
> Based on the [dollar slashy
> docs|http://www.groovy-lang.org/syntax.html#_dollar_slashy_string] I am not
> sure if the old behavior is correct or not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8171) Escaped dollar slashy difference between old and parrot parsers
[
https://issues.apache.org/jira/browse/GROOVY-8171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner updated GROOVY-8171:
--
Component/s: (was: parser-antlr2)
parser-antlr4
> Escaped dollar slashy difference between old and parrot parsers
> ---
>
> Key: GROOVY-8171
> URL: https://issues.apache.org/jira/browse/GROOVY-8171
> Project: Groovy
> Issue Type: Bug
> Components: parser-antlr4
>Affects Versions: 2.6.0-alpha-3, 3.0.0-alpha-2
>Reporter: John Wagenleitner
>Priority: Minor
>
> The following test passes with the legacy parser but fails with Parrot
> {code}
> // legacy parser
> def s1 = $/this $$/ is an escaped dollar forward slash/$
> assert s1 == 'this $/ is an escaped dollar forward slash'
> {code}
> {code}
> // antlr4 enabled (parrot)
> assert s1 == 'this $/ is an escaped dollar forward slash'
>| |
>| false
>this / is an escaped dollar forward slash
> {code}
> Noticed this when I inadvertently changed a spec test in commit
> [0fb89906aa|https://github.com/apache/groovy/commit/0fb89906aa587920d11fae063bba1d1f8fe26254].
> When testing for an escaped dollar slash the test had to be changed
> ([commit
> 942cf4eb3e|https://github.com/apache/groovy/commit/942cf4eb3e87f2718df490b9e3547f2042720781])
> to pass using the Antlr4 parser.
> Based on the [dollar slashy
> docs|http://www.groovy-lang.org/syntax.html#_dollar_slashy_string] I am not
> sure if the old behavior is correct or not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8171) Escaped dollar slashy difference between old and parrot parsers
[
https://issues.apache.org/jira/browse/GROOVY-8171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner updated GROOVY-8171:
--
Affects Version/s: (was: 3.x)
2.6.0-alpha-3
3.0.0-alpha-2
> Escaped dollar slashy difference between old and parrot parsers
> ---
>
> Key: GROOVY-8171
> URL: https://issues.apache.org/jira/browse/GROOVY-8171
> Project: Groovy
> Issue Type: Bug
> Components: parser-antlr4
>Affects Versions: 2.6.0-alpha-3, 3.0.0-alpha-2
>Reporter: John Wagenleitner
>Priority: Minor
>
> The following test passes with the legacy parser but fails with Parrot
> {code}
> // legacy parser
> def s1 = $/this $$/ is an escaped dollar forward slash/$
> assert s1 == 'this $/ is an escaped dollar forward slash'
> {code}
> {code}
> // antlr4 enabled (parrot)
> assert s1 == 'this $/ is an escaped dollar forward slash'
>| |
>| false
>this / is an escaped dollar forward slash
> {code}
> Noticed this when I inadvertently changed a spec test in commit
> [0fb89906aa|https://github.com/apache/groovy/commit/0fb89906aa587920d11fae063bba1d1f8fe26254].
> When testing for an escaped dollar slash the test had to be changed
> ([commit
> 942cf4eb3e|https://github.com/apache/groovy/commit/942cf4eb3e87f2718df490b9e3547f2042720781])
> to pass using the Antlr4 parser.
> Based on the [dollar slashy
> docs|http://www.groovy-lang.org/syntax.html#_dollar_slashy_string] I am not
> sure if the old behavior is correct or not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8568) SAM coercion doesn't work with abstract classes in @CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-8568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479505#comment-16479505
]
John Wagenleitner commented on GROOVY-8568:
---
I'm not able to reproduce the error with 2.5.0-rc-1 or rc-2 or 2.4.13 with the
given code sample.
> SAM coercion doesn't work with abstract classes in @CompileStatic
> --
>
> Key: GROOVY-8568
> URL: https://issues.apache.org/jira/browse/GROOVY-8568
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.13, 2.5.0-rc-1
>Reporter: Alexey Afanasiev
>Priority: Major
>
> {code:java}
> import groovy.transform.CompileStatic
> abstract class A1 {
> def abstract foo()
> }
> @CompileStatic
> def m() {
> A1 a = { print this } //Groovyc: [Static type checking] - Cannot assign
> value of type groovy.lang.Closure to variable of type A1
> }
> {code}
> Looks like it should work as in dynamic mode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8509) SC: error for call to protected method from same package
[
https://issues.apache.org/jira/browse/GROOVY-8509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477881#comment-16477881
]
John Wagenleitner commented on GROOVY-8509:
---
Thanks for the suggested patch.
{quote}Why does @TypeChecked not support these warnings? Are calls to private,
package-private and protected methods supported for @TypeChecked code?
{quote}
I believe this is because {{@TypeChecked}} performs runtime dispatch so behaves
similar to dynamic mode when it comes to being able to access methods that
wouldn't be accessible in static mode. It looks like GROOVY-7883 changed this
(not sure if intentional or not) so this may no longer be the case from 2.5.0
on.
> SC: error for call to protected method from same package
>
>
> Key: GROOVY-8509
> URL: https://issues.apache.org/jira/browse/GROOVY-8509
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.0-beta-2, 2.6.0-alpha-3
>Reporter: Eric Milles
>Priority: Major
>
> Groovy 2.5+ is producing compilation errors for @CompileStatic test class
> calling a protected method of class under test (in same package). This
> should be allowed as protected is "package-private" plus subtypes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8563) Documentation methodMissing example incorrect
[
https://issues.apache.org/jira/browse/GROOVY-8563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16473199#comment-16473199
]
John Wagenleitner commented on GROOVY-8563:
---
{quote}If you wish I could provide pull request. On what repository it should
be made?
{quote}
Documentation improvements are very welcomed. PR can be submitted at
https://github.com/apache/groovy.
> Documentation methodMissing example incorrect
> -
>
> Key: GROOVY-8563
> URL: https://issues.apache.org/jira/browse/GROOVY-8563
> Project: Groovy
> Issue Type: Bug
>Reporter: Pavel
>Priority: Minor
>
> [Doc|http://docs.groovy-lang.org/next/html/documentation/core-metaprogramming.html#_methodmissing]
> provide example:
> {code}
> class GORM {
>def dynamicMethods = [...] // an array of dynamic methods that use regex
>def methodMissing(String name, args) {
>def method = dynamicMethods.find { it.match(name) }
>if(method) {
> GORM.metaClass."$name" = { Object[] varArgs ->
> method.invoke(delegate, name, varArgs)
> }
> return method.invoke(delegate,name, args)
>}
>else throw new MissingMethodException(name, delegate, args)
>}
> }
> {code}
> Which reasonable leads to exception:
> {noformat}groovy.lang.MissingPropertyException: No such property: delegate
> for class: ru.taskdata.EgronReader{noformat}
> Instead of second
> {code}
> method.invoke(delegate, name, varArgs)
> {code}
> Should be something like:
> {code}
> return method.invoke(this, args)
> {code}
> If you wish I could provide pull request. On what repository it should be
> made?
--
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=16440952#comment-16440952
]
John Wagenleitner commented on GROOVY-8549:
---
Another work-around is to cast the expression to an {{int/Integer}}, ex.
{{list[(int)idx-1]++}}
The following may be somewhat related though might warrant a separate issue
since it doesn't seem to work in any 2.x release.
{code:groovy}
import groovy.transform.CompileStatic
@CompileStatic
def method() {
def list = [0, 1, 2, 3]
List board = [1]
//works with casting to `int`/`Integer`, list[board[0] as Integer]++
//and up to 2.4.12 works if part of an expression, list[board[0] - 0]++
list[board[0]]++
list
}
assert method() == [0, 2, 2, 3]{code}
> 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)
[jira] [Resolved] (GROOVY-8422) Incorrect properties copy in Sql.newInstance
[ https://issues.apache.org/jira/browse/GROOVY-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Wagenleitner resolved GROOVY-8422. --- Resolution: Fixed Assignee: John Wagenleitner Fix Version/s: 2.4.15 Thanks for reporting the issue. > Incorrect properties copy in Sql.newInstance > - > > Key: GROOVY-8422 > URL: https://issues.apache.org/jira/browse/GROOVY-8422 > Project: Groovy > Issue Type: Bug > Components: SQL processing >Affects Versions: 2.4.13 >Reporter: Thomas Weise >Assignee: John Wagenleitner >Priority: Major > Fix For: 2.4.15 > > > The constructor `Properties(Properties defaults)` does not create a copy, but > a new object with the argument as defaults. That breaks JDBC drivers that > expect the properties to be present in the object directly (enumerating of > keys, containsKey etc.). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GROOVY-8475) CLONE - I am unable to instantiate objects using the "new" keyword
[
https://issues.apache.org/jira/browse/GROOVY-8475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8475.
---
Resolution: Fixed
Assignee: John Wagenleitner
Fix Version/s: 2.4.15
Thanks for reporting the issue.
> CLONE - I am unable to instantiate objects using the "new" keyword
> --
>
> Key: GROOVY-8475
> URL: https://issues.apache.org/jira/browse/GROOVY-8475
> Project: Groovy
> Issue Type: Bug
> Components: Groovysh
>Affects Versions: 2.4.0, 2.4.12, 2.4.13
> Environment: Linux - Debian jessie/sid 64 bits
> Linux - Ubuntu 16 64 bits
>Reporter: Rémy Letient
>Assignee: John Wagenleitner
>Priority: Major
> Fix For: 2.4.15
>
> Attachments: image-2018-02-10-18-36-27-122.png, testA.groovy
>
>
> I am embedding Groovysh in a java application. After some tests, I realized
> that the "new" keyword seems to not work in the last groovysh version. When I
> try to do:
> {code}a = new A(){code}
> I obtain: "unable to resolve class A"
> This is an example:
> {code}
> groovy:000> class A {
> class A {
> groovy:001> public A() {
> public A() {
> groovy:002> name = "default"
> name = "default"
> groovy:003> }
> }
> groovy:004> String name;
> String name;
> groovy:005> }
> }
> ===> true
> groovy:000> a = new A()
> a = new A()
> ERROR org.codehaus.groovy.control.MultipleCompilationErrorsException:
> startup failed:
> script14159599676571305654112.groovy: 1: unable to resolve class A
> @ line 1, column 5.
>a = new A()
>^
> 1 error
> {code}
> However, if I use the newInstance method it works:
> {code}
> groovy:000> a = A.newInstance()
> a = A.newInstance()
> ===> A@2154cecb
> {code}
> I tested the same code in the previous version (2.3.7) and it works
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8475) CLONE - I am unable to instantiate objects using the "new" keyword
[
https://issues.apache.org/jira/browse/GROOVY-8475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16385405#comment-16385405
]
John Wagenleitner commented on GROOVY-8475:
---
Just a note for those that try to replicate the issue, it only appears to
happen if {{interpreterMode}} is set.
{code}
~/java$ ./groovy-2.4.14/bin/groovysh
Groovy Shell (2.4.14, JVM: 1.8.0_161)
Type ':help' or ':h' for help.
---
groovy:000> :set
No preferences are set
groovy:000> class A {}
===> true
groovy:000> a = new A()
===> A@d771cc9
groovy:000> :set interpreterMode
groovy:000> :set
Preferences:
interpreterMode=true
groovy:000> b = new A()
script15202002754441192361825.groovy: 1: unable to resolve class A
@ line 1, column 5.
b = new A()
^
{code}
> CLONE - I am unable to instantiate objects using the "new" keyword
> --
>
> Key: GROOVY-8475
> URL: https://issues.apache.org/jira/browse/GROOVY-8475
> Project: Groovy
> Issue Type: Bug
> Components: Groovysh
>Affects Versions: 2.4.0, 2.4.12, 2.4.13
> Environment: Linux - Debian jessie/sid 64 bits
> Linux - Ubuntu 16 64 bits
>Reporter: Rémy Letient
>Priority: Major
> Attachments: image-2018-02-10-18-36-27-122.png, testA.groovy
>
>
> I am embedding Groovysh in a java application. After some tests, I realized
> that the "new" keyword seems to not work in the last groovysh version. When I
> try to do:
> {code}a = new A(){code}
> I obtain: "unable to resolve class A"
> This is an example:
> {code}
> groovy:000> class A {
> class A {
> groovy:001> public A() {
> public A() {
> groovy:002> name = "default"
> name = "default"
> groovy:003> }
> }
> groovy:004> String name;
> String name;
> groovy:005> }
> }
> ===> true
> groovy:000> a = new A()
> a = new A()
> ERROR org.codehaus.groovy.control.MultipleCompilationErrorsException:
> startup failed:
> script14159599676571305654112.groovy: 1: unable to resolve class A
> @ line 1, column 5.
>a = new A()
>^
> 1 error
> {code}
> However, if I use the newInstance method it works:
> {code}
> groovy:000> a = A.newInstance()
> a = A.newInstance()
> ===> A@2154cecb
> {code}
> I tested the same code in the previous version (2.3.7) and it works
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8475) CLONE - I am unable to instantiate objects using the "new" keyword
[
https://issues.apache.org/jira/browse/GROOVY-8475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner updated GROOVY-8475:
--
Description:
I am embedding Groovysh in a java application. After some tests, I realized
that the "new" keyword seems to not work in the last groovysh version. When I
try to do:
{code}a = new A(){code}
I obtain: "unable to resolve class A"
This is an example:
{code}
groovy:000> class A {
class A {
groovy:001> public A() {
public A() {
groovy:002> name = "default"
name = "default"
groovy:003> }
}
groovy:004> String name;
String name;
groovy:005> }
}
===> true
groovy:000> a = new A()
a = new A()
ERROR org.codehaus.groovy.control.MultipleCompilationErrorsException:
startup failed:
script14159599676571305654112.groovy: 1: unable to resolve class A
@ line 1, column 5.
a = new A()
^
1 error
{code}
However, if I use the newInstance method it works:
{code}
groovy:000> a = A.newInstance()
a = A.newInstance()
===> A@2154cecb
{code}
I tested the same code in the previous version (2.3.7) and it works
was:
I am embedding Groovysh in a java application. After some tests, I realized
that the "new" keyword seems to not work in the last groovysh version. When I
try to do:
a = new A()
I obtain: "unable to resolve class A"
This is an example:
groovy:000> class A {
class A {
groovy:001> public A() {
public A() {
groovy:002> name = "default"
name = "default"
groovy:003> }
}
groovy:004> String name;
String name;
groovy:005> }
}
===> true
groovy:000> a = new A()
a = new A()
ERROR org.codehaus.groovy.control.MultipleCompilationErrorsException:
startup failed:
script14159599676571305654112.groovy: 1: unable to resolve class A
@ line 1, column 5.
a = new A()
^
1 error
However, if I use the newInstance method it works:
groovy:000> a = A.newInstance()
a = A.newInstance()
===> A@2154cecb
I tested the same code in the previous version (2.3.7) and it works
> CLONE - I am unable to instantiate objects using the "new" keyword
> --
>
> Key: GROOVY-8475
> URL: https://issues.apache.org/jira/browse/GROOVY-8475
> Project: Groovy
> Issue Type: Bug
> Components: Groovysh
>Affects Versions: 2.4.0, 2.4.12, 2.4.13
> Environment: Linux - Debian jessie/sid 64 bits
> Linux - Ubuntu 16 64 bits
>Reporter: Rémy Letient
>Priority: Major
> Attachments: image-2018-02-10-18-36-27-122.png, testA.groovy
>
>
> I am embedding Groovysh in a java application. After some tests, I realized
> that the "new" keyword seems to not work in the last groovysh version. When I
> try to do:
> {code}a = new A(){code}
> I obtain: "unable to resolve class A"
> This is an example:
> {code}
> groovy:000> class A {
> class A {
> groovy:001> public A() {
> public A() {
> groovy:002> name = "default"
> name = "default"
> groovy:003> }
> }
> groovy:004> String name;
> String name;
> groovy:005> }
> }
> ===> true
> groovy:000> a = new A()
> a = new A()
> ERROR org.codehaus.groovy.control.MultipleCompilationErrorsException:
> startup failed:
> script14159599676571305654112.groovy: 1: unable to resolve class A
> @ line 1, column 5.
>a = new A()
>^
> 1 error
> {code}
> However, if I use the newInstance method it works:
> {code}
> groovy:000> a = A.newInstance()
> a = A.newInstance()
> ===> A@2154cecb
> {code}
> I tested the same code in the previous version (2.3.7) and it works
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8488) STC: floating-point literals no longer accepted as args to method with double parameter
[
https://issues.apache.org/jira/browse/GROOVY-8488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16384543#comment-16384543
]
John Wagenleitner commented on GROOVY-8488:
---
This is related to the change for GROOVY-8325 [commit
d965023c266899|https://github.com/apache/groovy/commit/d965023c2668991e744c213c5125c5adcc677cd9].
Looks like the change restricts the comparison of the primitive (number) types
and their wrappers. Before the change it was valid to pass a {{BigDecimal}} or
{{BigInteger}} (or even an {{AtomicLong}}) to a method taking a {{short}}.
In the test case provided the {{1.0}} is a {{BigDecimal}}, the method call
works if {{1.0f}} is used.
> STC: floating-point literals no longer accepted as args to method with double
> parameter
> ---
>
> Key: GROOVY-8488
> URL: https://issues.apache.org/jira/browse/GROOVY-8488
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.4.13
>Reporter: Eric Milles
>Priority: Major
>
> I'm not sure if this recent change was intentional or not. If it is
> intended, so be it. But in case this has not been seen by anyone else, we
> had a lot of code that did floating-point computations and used
> @CompileStatic. Starting with Groovy 2.4.13 (I think), we are seeing STC
> errors.
> {code:groovy}
> import groovy.transform.CompileStatic
> @CompileStatic
> class Static {
> def main() {
> meth(1.0) // STC error
> }
> def meth(double val) {
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8488) STC: floating-point literals no longer accepted as args to method with double parameter
[
https://issues.apache.org/jira/browse/GROOVY-8488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner updated GROOVY-8488:
--
Affects Version/s: 2.4.13
> STC: floating-point literals no longer accepted as args to method with double
> parameter
> ---
>
> Key: GROOVY-8488
> URL: https://issues.apache.org/jira/browse/GROOVY-8488
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.13
>Reporter: Eric Milles
>Priority: Major
>
> I'm not sure if this recent change was intentional or not. If it is
> intended, so be it. But in case this has not been seen by anyone else, we
> had a lot of code that did floating-point computations and used
> @CompileStatic. Starting with Groovy 2.4.13 (I think), we are seeing STC
> errors.
> {code:groovy}
> import groovy.transform.CompileStatic
> @CompileStatic
> class Static {
> def main() {
> meth(1.0) // STC error
> }
> def meth(double val) {
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GROOVY-8324) Enabling groovy.indy.logging can lead to stack overflows
[
https://issues.apache.org/jira/browse/GROOVY-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8324.
---
Resolution: Fixed
Assignee: John Wagenleitner
Fix Version/s: 2.4.13
Thanks for reporting the issue and for the fix.
> Enabling groovy.indy.logging can lead to stack overflows
>
>
> Key: GROOVY-8324
> URL: https://issues.apache.org/jira/browse/GROOVY-8324
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: Matt Whipple
>Assignee: John Wagenleitner
>Priority: Minor
> Labels: invokedynamic
> Fix For: 2.4.13
>
>
> Still digging through this a bit more, but while trying to diagnose
> performance issues I enabled indy logging which led to:
> {noformat}
> ! Caused by: java.lang.StackOverflowError: null
> ! at java.lang.Class.getEnclosingMethodInfo(Class.java:1072)
> ! at java.lang.Class.getEnclosingClass(Class.java:1272)
> ! at java.lang.Class.getSimpleBinaryName(Class.java:1443)
> ! at java.lang.Class.getSimpleName(Class.java:1309)
> ! at java.lang.invoke.MethodType.toString(MethodType.java:797)
> ! at java.lang.String.valueOf(String.java:2982)<---
> Loops back to here
> ! at java.lang.StringBuilder.append(StringBuilder.java:131)
> ! at
> org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.(Selector.java:488)
> ! at org.codehaus.groovy.vmplugin.v7.Selector.getSelector(Selector.java:98)
> ! at
> org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:227)
> ! at MyDomainClass.toString(MyDomainClass.groovy)
> {noformat}
> The domain class itself stringifies without issue, changing the class to use
> {{@CompileStatic}} seems to have resolved this issue. It might be nice if
> that specific log message could be toggled independently of the others to try
> to avoid the possibility of blowing up while attempting to troubleshooting.
> {noformat}
> java version "1.8.0_45"
> Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GROOVY-4018) Make the Groovy truth value of NaN be false
[
https://issues.apache.org/jira/browse/GROOVY-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-4018.
---
Resolution: Fixed
Assignee: John Wagenleitner
Fix Version/s: (was: 3.x)
2.6.0-alpha-2
Thanks for reporting the issue.
> Make the Groovy truth value of NaN be false
> ---
>
> Key: GROOVY-4018
> URL: https://issues.apache.org/jira/browse/GROOVY-4018
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Reporter: Steve Tekell
>Assignee: John Wagenleitner
> Labels: breaking
> Fix For: 2.6.0-alpha-2
>
>
> Similar to null and empty-string, have Groovy evaluate NaN as false rather
> than true.
> {noformat}
> def result = a?.b?.calcX(...)
> if (result) {
> // now I have a valid non-null number
> }
> {noformat}
> This is how JavaScript treats NaN and like other Groovy design choices, it
> just makes sense.
> Discussed in this thread
> http://old.nabble.com/Shouldn't-the-Groovy-truth-value-of-NaN-be-false--tt27348256.html
> That is, if NaN was false the following should work:
> assert !(Double.NaN)
> assert !((Double.NaN as Boolean) == true)
> assert ((Double.NaN as Boolean) == false)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8213) Closures are maybe not Threadsafe
[
https://issues.apache.org/jira/browse/GROOVY-8213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16187573#comment-16187573
]
John Wagenleitner commented on GROOVY-8213:
---
I am not sure how to craft a benchmark that you wish for. I can revert the
change or maybe the following would be acceptable logic after removing the
{{volatile}} modifier?
{code}
protected boolean isInitialized() {
if (initialized) {
return true;
}
synchronized (this) {
return initialized;
}
}
{code}
Since the normal state is to be initialized this only rechecks if false.
> Closures are maybe not Threadsafe
> -
>
> Key: GROOVY-8213
> URL: https://issues.apache.org/jira/browse/GROOVY-8213
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.10
> Environment: Gradle 3.5
>Reporter: Björn Kautler
>Assignee: John Wagenleitner
> Fix For: 2.4.13
>
>
> I just upgraded our Gradle build from 1.12 (including Groovy 1.8.6) to 3.5
> (including Groovy 2.4.10).
> Now I get a very strange behavior for stuff that is there for years already
> and it looks to me as if this is a Groovy bug, maybe a non-threadsafeness of
> Closures.
> I have a custom task that contains the following code:
> {code}
> def sourceFilesSize = getSourceFiles().files.size()
> def poolSize = Runtime.runtime.availableProcessors()
> def executor = new ThreadPoolExecutor(poolSize, poolSize, 0, SECONDS,
> new ArrayBlockingQueue([sourceFilesSize, 1].max()))
> def tasks = []
> inputs.outOfDate { toTransform ->
> tasks.add executor.submit {
> project.exec {
>if (gscPath) { // here starts
> com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11
> environment 'GSC', gscPath
> def tempDir = "$temporaryDir/${Thread.currentThread().name}"
> project.file(tempDir).mkdirs()
> environment 'TEMP', tempDir
>}
>executable executablePath
>def arguments = [toTransform.file.absolutePath]
>if ((sourceFilesSize == 1) && getDestinationFile()) {
> arguments << getDestinationFile().absolutePath
>} else if (destinationDirectory) {
> arguments << new File(destinationDirectory,
> fileNameMapping(toTransform.file.name)).absolutePath
>} else {
> arguments << new File(toTransform.file.parentFile,
> fileNameMapping(toTransform.file.name)).absolutePath
>}
>args arguments // here ends
> com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11
> }
> }
> }
> executor.shutdown()
> executor.awaitTermination 1, HOURS
> tasks*.get() // here is line 137
> {code}
> When this task is executed e. g. with five source files, sometimes all works
> fine, sometime the build fails with
> {noformat}
> ...
> Caused by: java.util.concurrent.ExecutionException:
> java.lang.IllegalStateException: initialize must be called for meta class of
> class com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11(class
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass) to complete
> initialisation process before any invocation or field/property access can be
> done
> at com.empic.build.tasks.Ghostscript.exec(Ghostscript.groovy:137)
> at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
> ... 80 more
> Caused by: java.lang.IllegalStateException: initialize must be called for
> meta class of class
> com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11(class
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass) to complete
> initialisation process before any invocation or field/property access can be
> done
> {noformat}
> Actually I was not able to reproduce the problem locally, but if I run the
> build on our CI server and attach a debugger, I indeed was able to reproduce
> the problem with a relatively high reproduction rate. (as in every second to
> third build approximately, opposed to once every 100 builds)
> I logged the current thread when the {{initialized}} property is set to
> {{true}} and when it is requested with non-suspending breakpoints, but this
> seems to have caused the timing to change enough already that I was not able
> to reproduce the error within approximately the first two dozens of tries.
> I was able to successfully break at the throwing of the
> {{IllegalStateException}} though. This happens in
> {{groovy.lang.MetaClassImpl.checkInitalised}}.
> The stacktrace at this point is:
> {noformat}
> "pool-2-thread-3@10709" prio=5 tid=0x47 nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at
[jira] [Resolved] (GROOVY-8213) Closures are maybe not Threadsafe
[
https://issues.apache.org/jira/browse/GROOVY-8213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8213.
---
Resolution: Fixed
Assignee: John Wagenleitner
Fix Version/s: 2.4.13
I went ahead and merged the {{volatile}} change. Thanks for reporting the
issue. Not sure how easy this will be to test with 2.4 snapshots, but if
possible would like to get feedback on whether this fixes the issue you were
seeing on the CI server.
> Closures are maybe not Threadsafe
> -
>
> Key: GROOVY-8213
> URL: https://issues.apache.org/jira/browse/GROOVY-8213
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.10
> Environment: Gradle 3.5
>Reporter: Björn Kautler
>Assignee: John Wagenleitner
> Fix For: 2.4.13
>
>
> I just upgraded our Gradle build from 1.12 (including Groovy 1.8.6) to 3.5
> (including Groovy 2.4.10).
> Now I get a very strange behavior for stuff that is there for years already
> and it looks to me as if this is a Groovy bug, maybe a non-threadsafeness of
> Closures.
> I have a custom task that contains the following code:
> {code}
> def sourceFilesSize = getSourceFiles().files.size()
> def poolSize = Runtime.runtime.availableProcessors()
> def executor = new ThreadPoolExecutor(poolSize, poolSize, 0, SECONDS,
> new ArrayBlockingQueue([sourceFilesSize, 1].max()))
> def tasks = []
> inputs.outOfDate { toTransform ->
> tasks.add executor.submit {
> project.exec {
>if (gscPath) { // here starts
> com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11
> environment 'GSC', gscPath
> def tempDir = "$temporaryDir/${Thread.currentThread().name}"
> project.file(tempDir).mkdirs()
> environment 'TEMP', tempDir
>}
>executable executablePath
>def arguments = [toTransform.file.absolutePath]
>if ((sourceFilesSize == 1) && getDestinationFile()) {
> arguments << getDestinationFile().absolutePath
>} else if (destinationDirectory) {
> arguments << new File(destinationDirectory,
> fileNameMapping(toTransform.file.name)).absolutePath
>} else {
> arguments << new File(toTransform.file.parentFile,
> fileNameMapping(toTransform.file.name)).absolutePath
>}
>args arguments // here ends
> com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11
> }
> }
> }
> executor.shutdown()
> executor.awaitTermination 1, HOURS
> tasks*.get() // here is line 137
> {code}
> When this task is executed e. g. with five source files, sometimes all works
> fine, sometime the build fails with
> {noformat}
> ...
> Caused by: java.util.concurrent.ExecutionException:
> java.lang.IllegalStateException: initialize must be called for meta class of
> class com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11(class
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass) to complete
> initialisation process before any invocation or field/property access can be
> done
> at com.empic.build.tasks.Ghostscript.exec(Ghostscript.groovy:137)
> at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
> ... 80 more
> Caused by: java.lang.IllegalStateException: initialize must be called for
> meta class of class
> com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11(class
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass) to complete
> initialisation process before any invocation or field/property access can be
> done
> {noformat}
> Actually I was not able to reproduce the problem locally, but if I run the
> build on our CI server and attach a debugger, I indeed was able to reproduce
> the problem with a relatively high reproduction rate. (as in every second to
> third build approximately, opposed to once every 100 builds)
> I logged the current thread when the {{initialized}} property is set to
> {{true}} and when it is requested with non-suspending breakpoints, but this
> seems to have caused the timing to change enough already that I was not able
> to reproduce the error within approximately the first two dozens of tries.
> I was able to successfully break at the throwing of the
> {{IllegalStateException}} though. This happens in
> {{groovy.lang.MetaClassImpl.checkInitalised}}.
> The stacktrace at this point is:
> {noformat}
> "pool-2-thread-3@10709" prio=5 tid=0x47 nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at groovy.lang.MetaClassImpl.checkInitalised(MetaClassImpl.java:1647)
> at
>
[jira] [Commented] (GROOVY-8213) Closures are maybe not Threadsafe
[
https://issues.apache.org/jira/browse/GROOVY-8213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16187269#comment-16187269
]
John Wagenleitner commented on GROOVY-8213:
---
A related Gradle issue is https://github.com/gradle/gradle/issues/1420.
While I do believe the publication of the {{initialized}} variable could be an
issue and should be addressed, another possible cause of this could be related
to the way the {{respondTo}} methods are implemented by unsetting the
{{initialized}} variable during a call to {{super.initialize()}} in the
{{loadMetaInfo()}} method.
https://github.com/apache/groovy/blob/7b101dd98ffc04b1bfd2447bbe277340d8954add/src/main/org/codehaus/groovy/runtime/metaclass/ClosureMetaClass.java#L724-L740
But in this case and the Gradle issue I'm not sure the {{respondTo}} methods
are in play.
> Closures are maybe not Threadsafe
> -
>
> Key: GROOVY-8213
> URL: https://issues.apache.org/jira/browse/GROOVY-8213
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.10
> Environment: Gradle 3.5
>Reporter: Björn Kautler
>
> I just upgraded our Gradle build from 1.12 (including Groovy 1.8.6) to 3.5
> (including Groovy 2.4.10).
> Now I get a very strange behavior for stuff that is there for years already
> and it looks to me as if this is a Groovy bug, maybe a non-threadsafeness of
> Closures.
> I have a custom task that contains the following code:
> {code}
> def sourceFilesSize = getSourceFiles().files.size()
> def poolSize = Runtime.runtime.availableProcessors()
> def executor = new ThreadPoolExecutor(poolSize, poolSize, 0, SECONDS,
> new ArrayBlockingQueue([sourceFilesSize, 1].max()))
> def tasks = []
> inputs.outOfDate { toTransform ->
> tasks.add executor.submit {
> project.exec {
>if (gscPath) { // here starts
> com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11
> environment 'GSC', gscPath
> def tempDir = "$temporaryDir/${Thread.currentThread().name}"
> project.file(tempDir).mkdirs()
> environment 'TEMP', tempDir
>}
>executable executablePath
>def arguments = [toTransform.file.absolutePath]
>if ((sourceFilesSize == 1) && getDestinationFile()) {
> arguments << getDestinationFile().absolutePath
>} else if (destinationDirectory) {
> arguments << new File(destinationDirectory,
> fileNameMapping(toTransform.file.name)).absolutePath
>} else {
> arguments << new File(toTransform.file.parentFile,
> fileNameMapping(toTransform.file.name)).absolutePath
>}
>args arguments // here ends
> com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11
> }
> }
> }
> executor.shutdown()
> executor.awaitTermination 1, HOURS
> tasks*.get() // here is line 137
> {code}
> When this task is executed e. g. with five source files, sometimes all works
> fine, sometime the build fails with
> {noformat}
> ...
> Caused by: java.util.concurrent.ExecutionException:
> java.lang.IllegalStateException: initialize must be called for meta class of
> class com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11(class
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass) to complete
> initialisation process before any invocation or field/property access can be
> done
> at com.empic.build.tasks.Ghostscript.exec(Ghostscript.groovy:137)
> at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
> ... 80 more
> Caused by: java.lang.IllegalStateException: initialize must be called for
> meta class of class
> com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11(class
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass) to complete
> initialisation process before any invocation or field/property access can be
> done
> {noformat}
> Actually I was not able to reproduce the problem locally, but if I run the
> build on our CI server and attach a debugger, I indeed was able to reproduce
> the problem with a relatively high reproduction rate. (as in every second to
> third build approximately, opposed to once every 100 builds)
> I logged the current thread when the {{initialized}} property is set to
> {{true}} and when it is requested with non-suspending breakpoints, but this
> seems to have caused the timing to change enough already that I was not able
> to reproduce the error within approximately the first two dozens of tries.
> I was able to successfully break at the throwing of the
> {{IllegalStateException}} though. This happens in
> {{groovy.lang.MetaClassImpl.checkInitalised}}.
> The
[jira] [Commented] (GROOVY-8213) Closures are maybe not Threadsafe
[
https://issues.apache.org/jira/browse/GROOVY-8213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16187262#comment-16187262
]
John Wagenleitner commented on GROOVY-8213:
---
I created a JMH benchmark to test a volatile read vs a recheck and sync,
https://github.com/jwagenleitner/testing-groovy/tree/master/issues/groovy8213.
Based on my runs the volatile read is very close to a normal read. Doing a
branched check (without needing to sync) was actually worse in terms of
performance. Based on those benchmarks I'd suggest making {{initialized}}
volatile in both {{ClosureMetaClass}} and also in {{MetaClassImpl}}.
> Closures are maybe not Threadsafe
> -
>
> Key: GROOVY-8213
> URL: https://issues.apache.org/jira/browse/GROOVY-8213
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.10
> Environment: Gradle 3.5
>Reporter: Björn Kautler
>
> I just upgraded our Gradle build from 1.12 (including Groovy 1.8.6) to 3.5
> (including Groovy 2.4.10).
> Now I get a very strange behavior for stuff that is there for years already
> and it looks to me as if this is a Groovy bug, maybe a non-threadsafeness of
> Closures.
> I have a custom task that contains the following code:
> {code}
> def sourceFilesSize = getSourceFiles().files.size()
> def poolSize = Runtime.runtime.availableProcessors()
> def executor = new ThreadPoolExecutor(poolSize, poolSize, 0, SECONDS,
> new ArrayBlockingQueue([sourceFilesSize, 1].max()))
> def tasks = []
> inputs.outOfDate { toTransform ->
> tasks.add executor.submit {
> project.exec {
>if (gscPath) { // here starts
> com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11
> environment 'GSC', gscPath
> def tempDir = "$temporaryDir/${Thread.currentThread().name}"
> project.file(tempDir).mkdirs()
> environment 'TEMP', tempDir
>}
>executable executablePath
>def arguments = [toTransform.file.absolutePath]
>if ((sourceFilesSize == 1) && getDestinationFile()) {
> arguments << getDestinationFile().absolutePath
>} else if (destinationDirectory) {
> arguments << new File(destinationDirectory,
> fileNameMapping(toTransform.file.name)).absolutePath
>} else {
> arguments << new File(toTransform.file.parentFile,
> fileNameMapping(toTransform.file.name)).absolutePath
>}
>args arguments // here ends
> com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11
> }
> }
> }
> executor.shutdown()
> executor.awaitTermination 1, HOURS
> tasks*.get() // here is line 137
> {code}
> When this task is executed e. g. with five source files, sometimes all works
> fine, sometime the build fails with
> {noformat}
> ...
> Caused by: java.util.concurrent.ExecutionException:
> java.lang.IllegalStateException: initialize must be called for meta class of
> class com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11(class
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass) to complete
> initialisation process before any invocation or field/property access can be
> done
> at com.empic.build.tasks.Ghostscript.exec(Ghostscript.groovy:137)
> at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
> ... 80 more
> Caused by: java.lang.IllegalStateException: initialize must be called for
> meta class of class
> com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11(class
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass) to complete
> initialisation process before any invocation or field/property access can be
> done
> {noformat}
> Actually I was not able to reproduce the problem locally, but if I run the
> build on our CI server and attach a debugger, I indeed was able to reproduce
> the problem with a relatively high reproduction rate. (as in every second to
> third build approximately, opposed to once every 100 builds)
> I logged the current thread when the {{initialized}} property is set to
> {{true}} and when it is requested with non-suspending breakpoints, but this
> seems to have caused the timing to change enough already that I was not able
> to reproduce the error within approximately the first two dozens of tries.
> I was able to successfully break at the throwing of the
> {{IllegalStateException}} though. This happens in
> {{groovy.lang.MetaClassImpl.checkInitalised}}.
> The stacktrace at this point is:
> {noformat}
> "pool-2-thread-3@10709" prio=5 tid=0x47 nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at
[jira] [Resolved] (GROOVY-8303) VerifyError for nested class this call to static method
[
https://issues.apache.org/jira/browse/GROOVY-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8303.
---
Resolution: Fixed
Assignee: John Wagenleitner
Fix Version/s: 2.5.0-beta-2
> VerifyError for nested class this call to static method
> ---
>
> Key: GROOVY-8303
> URL: https://issues.apache.org/jira/browse/GROOVY-8303
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.0-beta-1
>Reporter: John Wagenleitner
>Assignee: John Wagenleitner
> Fix For: 2.5.0-beta-2
>
>
> {code}
> class Base {
> static class Nested {
> private String b
> static String getData() { return "ABCD" }
> Nested() { this(getData()) }
> Nested(String b) { this.b = b }
> String toString() { b }
> }
> }
> assert new Base.Nested().toString() == 'ABCD'
> {code}
> Results in
> {code}
> java.lang.VerifyError: (class: Base$Nested, method: signature: ()V)
> Expecting to find object/array on stack.
> {code}
> The same code works if a top-level class.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (GROOVY-8303) VerifyError for nested class this call to static method
John Wagenleitner created GROOVY-8303:
-
Summary: VerifyError for nested class this call to static method
Key: GROOVY-8303
URL: https://issues.apache.org/jira/browse/GROOVY-8303
Project: Groovy
Issue Type: Bug
Affects Versions: 2.5.0-beta-1
Reporter: John Wagenleitner
{code}
class Base {
static class Nested {
private String b
static String getData() { return "ABCD" }
Nested() { this(getData()) }
Nested(String b) { this.b = b }
String toString() { b }
}
}
assert new Base.Nested().toString() == 'ABCD'
{code}
Results in
{code}
java.lang.VerifyError: (class: Base$Nested, method: signature: ()V)
Expecting to find object/array on stack.
{code}
The same code works if a top-level class.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GROOVY-8205) Static type checking failure for enums
[
https://issues.apache.org/jira/browse/GROOVY-8205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8205.
---
Resolution: Fixed
Assignee: John Wagenleitner
Fix Version/s: 2.5.0-beta-2
> Static type checking failure for enums
> --
>
> Key: GROOVY-8205
> URL: https://issues.apache.org/jira/browse/GROOVY-8205
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.4.10
> Environment: Windows 7, JDK 1.8.0_66
>Reporter: Iurii
>Assignee: John Wagenleitner
> Fix For: 2.5.0-beta-2
>
>
> Declare enum:
> {code}
> public enum Functions {
> A, B, C
> }
> {code}
> Create test class, add the following test and try to compile:
> {code}
> @Test
> @CompileStatic
> void testEachForEnum() {
> Functions.values().each { println it.name() }
> }
> {code}
> Result: Groovyc: [Static type checking] - Cannot find matching method
> java.lang.Object#name(). Please check if the declared type is right and if
> the method exists.
> Expected: code should compile without errors
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8205) Static type checking failure for enums
[
https://issues.apache.org/jira/browse/GROOVY-8205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16142881#comment-16142881
]
John Wagenleitner commented on GROOVY-8205:
---
This particular issue was fixed by [commit
8c218dec34|https://github.com/apache/groovy/commit/8c218dec34730e92eb020cbb1b0888dcc89bd35b]
for GROOVY-7283 which is part of the 2.5 release.
> Static type checking failure for enums
> --
>
> Key: GROOVY-8205
> URL: https://issues.apache.org/jira/browse/GROOVY-8205
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.4.10
> Environment: Windows 7, JDK 1.8.0_66
>Reporter: Iurii
>
> Declare enum:
> {code}
> public enum Functions {
> A, B, C
> }
> {code}
> Create test class, add the following test and try to compile:
> {code}
> @Test
> @CompileStatic
> void testEachForEnum() {
> Functions.values().each { println it.name() }
> }
> {code}
> Result: Groovyc: [Static type checking] - Cannot find matching method
> java.lang.Object#name(). Please check if the declared type is right and if
> the method exists.
> Expected: code should compile without errors
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GROOVY-8294) Return 404 for non-existing paths in `TemplateServlet` when running from .war
[
https://issues.apache.org/jira/browse/GROOVY-8294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8294.
---
Resolution: Fixed
Assignee: John Wagenleitner
Fix Version/s: 2.4.13
Thanks for reporting the issue and the PR.
> Return 404 for non-existing paths in `TemplateServlet` when running from .war
> -
>
> Key: GROOVY-8294
> URL: https://issues.apache.org/jira/browse/GROOVY-8294
> Project: Groovy
> Issue Type: Bug
> Environment: Payara Micro
>Reporter: Thomas Reifenberger
>Assignee: John Wagenleitner
> Labels: breaking
> Fix For: 2.4.13
>
> Attachments: broken-template-servlet.tar.gz
>
>
> When TemplateServlet is used in application servers that don't unpack a war
> (i.e. when the real path of resources could not be retrieved), an internal
> server error is returned upon trying to retrieve a non-existing template file.
> The expected behavior would be to get a 404, just as it is already the case
> when running from a extracted war.
> I had this behavior when running on a [payara
> micro|https://www.payara.fish/payara_micro] application server using the
> following {{web.xml}} snippet:
> {code}
> http://java.sun.com/xml/ns/javaee; version="2.5">
>
> GroovyTemplate
> groovy.servlet.TemplateServlet
>
>
> GroovyTemplate
> *.gsp
>
>
> {code}
> and requesting an url ending in {{*.gsp}}, but without a template with that
> name present.
> Please see the attached minimal example (docker required):
> Run it with:
> {code}
> ./gradlew runDockerContainer
> {code}
> and test the URLs
> http://localhost:8080/test.gsp (works)
> http://localhost:8080/unknown.gsp (500, but I would actually expect a 404)
> The corresponding stacktrace is
> {code}
> java.lang.NullPointerException
> at
> groovy.servlet.TemplateServlet.getTemplate(TemplateServlet.java:331)
> at groovy.servlet.TemplateServlet.service(TemplateServlet.java:445)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1606)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:258)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:654)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:593)
> at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> at
> org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:371)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:238)
> at
> com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:466)
> at
> com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:169)
> at
> org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
> at
> org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
> at
> org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
> at
> org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
> at
> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
> at
> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
> at
> org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
> at
> org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
> at
> org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
> at
> org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:539)
> at
> org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
> at
> org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
> at
> org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
> at
> org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
> at
> org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:593)
> at
>
[jira] [Commented] (GROOVY-8294) Return 404 for non-existing paths in `TemplateServlet` when running from .war
[
https://issues.apache.org/jira/browse/GROOVY-8294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16141050#comment-16141050
]
John Wagenleitner commented on GROOVY-8294:
---
I labelled as {{breaking}} just to call out the change in behavior, but think
it does fix a bug and should go in the next 2.4.x release.
> Return 404 for non-existing paths in `TemplateServlet` when running from .war
> -
>
> Key: GROOVY-8294
> URL: https://issues.apache.org/jira/browse/GROOVY-8294
> Project: Groovy
> Issue Type: Bug
> Environment: Payara Micro
>Reporter: Thomas Reifenberger
> Labels: breaking
> Attachments: broken-template-servlet.tar.gz
>
>
> When TemplateServlet is used in application servers that don't unpack a war
> (i.e. when the real path of resources could not be retrieved), an internal
> server error is returned upon trying to retrieve a non-existing template file.
> The expected behavior would be to get a 404, just as it is already the case
> when running from a extracted war.
> I had this behavior when running on a [payara
> micro|https://www.payara.fish/payara_micro] application server using the
> following {{web.xml}} snippet:
> {code}
> http://java.sun.com/xml/ns/javaee; version="2.5">
>
> GroovyTemplate
> groovy.servlet.TemplateServlet
>
>
> GroovyTemplate
> *.gsp
>
>
> {code}
> and requesting an url ending in {{*.gsp}}, but without a template with that
> name present.
> Please see the attached minimal example (docker required):
> Run it with:
> {code}
> ./gradlew runDockerContainer
> {code}
> and test the URLs
> http://localhost:8080/test.gsp (works)
> http://localhost:8080/unknown.gsp (500, but I would actually expect a 404)
> The corresponding stacktrace is
> {code}
> java.lang.NullPointerException
> at
> groovy.servlet.TemplateServlet.getTemplate(TemplateServlet.java:331)
> at groovy.servlet.TemplateServlet.service(TemplateServlet.java:445)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1606)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:258)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
> at
> org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:654)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:593)
> at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> at
> org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:371)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:238)
> at
> com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:466)
> at
> com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:169)
> at
> org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
> at
> org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
> at
> org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
> at
> org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
> at
> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
> at
> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
> at
> org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
> at
> org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
> at
> org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
> at
> org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:539)
> at
> org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
> at
> org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
> at
> org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
> at
> org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
> at
> org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:593)
> at
>
[jira] [Updated] (GROOVY-8034) Compile error when using generic type with lower bound
[
https://issues.apache.org/jira/browse/GROOVY-8034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner updated GROOVY-8034:
--
Component/s: Static Type Checker
> Compile error when using generic type with lower bound
> --
>
> Key: GROOVY-8034
> URL: https://issues.apache.org/jira/browse/GROOVY-8034
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.4.6, 2.4.7
> Environment: groovy JDK 2.4.7, 2.4.6,
> Java used: jdk1.7.0_51, jdk1.8.0_40, 9-ea+114,
> RedHat\java-1.8.0-openjdk-1.8.0.111-3
>Reporter: Yuriy Kiselev
>
> I'm trying to implement chained generics. It works as Java code but fails to
> compile by groovyc:
> {code}
> Error:(38, 9) Groovyc: [Static type checking] - Cannot call com.github.ykiselev.ChainTest.A>
> com.github.ykiselev.ChainTest$A java.lang.Object, ?>#andThen(C)
> with arguments [com.github.ykiselev.ChainTest$A ]
> {code}
> Code (JUnit4 unit test)
> {code}
> package com.github.ykiselev
> import groovy.transform.TypeChecked
> import org.junit.Test
> @TypeChecked
> class ChainTest {
> static class A {
> def > C andThen(C next) {
> return next
> }
> }
> static C chain(A self, C next) {
> self.andThen(next)
> return next
> }
> @Test
> void "should chain"() {
> def a1 = new A()
> def a2 = new A()
> def a3 = new A()
> def a4 = new A()
> def a5 = new A()
> a1.andThen(a2) // ok
> a2.andThen(a3) // ok
> a3.andThen(a4) // ok
> a4.andThen(a5) // ok (even without "? super O")
> chain(a1, a2).andThen(a3) // ok
> chain(chain(chain(chain(a1, a2), a3), a4), a5) // ok
> a1.andThen(a2)
> .andThen(a3) // static type checker error
> .andThen(a4)
> .andThen(a5)
> }
> }
> {code}
> This would compile if I change bounded type parameter like this:
> {code}
> def > C andThen(C next) {
> return next
> }
> {code}
> but I need it bounded.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (GROOVY-8190) CompileStatic cant infer type when using map as map key
[
https://issues.apache.org/jira/browse/GROOVY-8190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner updated GROOVY-8190:
--
Component/s: Static Type Checker
> CompileStatic cant infer type when using map as map key
> ---
>
> Key: GROOVY-8190
> URL: https://issues.apache.org/jira/browse/GROOVY-8190
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.4.6
>Reporter: Richard Zhang
>
> open groovy console, paste code below
> {code}
> import groovy.transform.*
> @CompileStatic
> void foo(Map, List>> map){
> for(Map key : map.keySet()) {
> def x = map[key]
> def y = x[0][""]
> }
> }
> {code}
> and you will see it fails to compile
> {noformat}
> Result: org.codehaus.groovy.control.MultipleCompilationErrorsException:
> startup failed:
> ideaGroovyConsole.groovy: 7: [Static type checking] - Cannot find matching
> method java.lang.Object#getAt(int). Please check if the declared type is
> right and if the method exists.
> @ line 7, column 17.
>def y = x[0][""]
>^
> 1 error
> at
> org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
> at
> org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1075)
> at
> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:591)
> at
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:569)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:546)
> at
> groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
> at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
> at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
> at groovy.lang.GroovyShell.run(GroovyShell.java:517)
> at groovy.lang.GroovyShell.run(GroovyShell.java:497)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSite.invoke(PogoMetaMethodSite.java:169)
> at
> org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.call(PogoMetaMethodSite.java:71)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:133)
> at console.run(console.txt:25)
> at groovy.ui.GroovyMain.processReader(GroovyMain.java:631)
> at groovy.ui.GroovyMain.processFiles(GroovyMain.java:539)
> at groovy.ui.GroovyMain.run(GroovyMain.java:382)
> at groovy.ui.GroovyMain.process(GroovyMain.java:370)
> at groovy.ui.GroovyMain.processArgs(GroovyMain.java:129)
> at groovy.ui.GroovyMain.main(GroovyMain.java:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:109)
> at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:131)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> com.intellij.rt.execution.CommandLineWrapper.main(CommandLineWrapper.java:65)
> {noformat}
> and if you change map key to other type (e.g a {{List<>}}), it will compile
> just fine.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (GROOVY-7850) Documentation on primitives and wrappers is misleading
[
https://issues.apache.org/jira/browse/GROOVY-7850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner updated GROOVY-7850:
--
Component/s: Documentation
> Documentation on primitives and wrappers is misleading
> --
>
> Key: GROOVY-7850
> URL: https://issues.apache.org/jira/browse/GROOVY-7850
> Project: Groovy
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 2.4.6
> Environment: Groovy Version: 2.4.6 JVM: 1.7.0_79 Vendor: Oracle
> Corporation OS: Mac OS X
>Reporter: Sebb
> Attachments: test1.groovy, test2.groovy, test3.groovy
>
>
> The doc [1] has the following example:
> {code:title=test1.groovy}
> int i
> m(i)
> void m(long l) { // This is the method that Java would call, since
> widening has precedence over unboxing.
> println "in m(long)"
> }
> void m(Integer i) { // This is the method Groovy actually calls, since
> all primitive references use their wrapper class.
> println "in m(Integer)"
> }
> {code}
> Whilst the comment correctly identifies the method which is called by Groovy,
> it's somewhat misleading, since the code involves both widening and boxing.
> The following code shows why:
> {code:title=test2.groovy}
> int i
> m(i)
> void m(int l) { // Groovy calls this method
> println "in m(int)"
> }
> void m(Integer i) {
> println "in m(Integer)"
> }
> {code}
> In the code sample above, Groovy does not autowrap the primitive int.
> See also the following example:
> {code:title=test3.groovy}
> int i
> m(i)
> void m(long l) { // called by Groovy
> println "in m(long)"
> }
> void m(Long i) {
> println "in m(Long)"
> }
> {code}
> This shows that Groovy widens rather than boxes.
> So I think the statement "since all primitive references use their wrapper
> class." is at best misleading, and may be wrong.
> [1] http://groovy-lang.org/differences.html#_primitives_and_wrappers
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (GROOVY-8195) CompileStatic fails to infer correct type when using elvis operator
[
https://issues.apache.org/jira/browse/GROOVY-8195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner updated GROOVY-8195:
--
Component/s: Static Type Checker
> CompileStatic fails to infer correct type when using elvis operator
> ---
>
> Key: GROOVY-8195
> URL: https://issues.apache.org/jira/browse/GROOVY-8195
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.4.9
>Reporter: Richard Zhang
>
> see the following example:
> {code}
> import groovy.transform.CompileStatic
> @CompileStatic
> def foo() {
> Map strongMap
> Map elvisMap = strongMap ?: [:] // won't compile
> Map initStrongMap = [:] // compiles ok
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (GROOVY-7763) Various problems with type inference in Groovy 2.4.6
[ https://issues.apache.org/jira/browse/GROOVY-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Wagenleitner updated GROOVY-7763: -- Component/s: Static Type Checker > Various problems with type inference in Groovy 2.4.6 > > > Key: GROOVY-7763 > URL: https://issues.apache.org/jira/browse/GROOVY-7763 > Project: Groovy > Issue Type: Bug > Components: Static Type Checker >Affects Versions: 2.4.6 >Reporter: Graeme Rocher >Priority: Critical > > After trying to upgrade Grails to Groovy 2.4.6 there are numerous problems > with @CompileStatic and type inference with Maps and Lists. If I had seen the > vote for the release in time I would have tested and voted -1, so sorry for > only reporting this afterwards. > This commits shows the changes I had to make in order to get Grails to > compile with Groovy 2.4.6: > https://github.com/grails/grails-core/commit/a6d70aaf7925fb7f2e847a803a8e1f3c95bf8cf8 > You can see for example that previously returning a list initialised with > variables of the correct type compiled, but no longer does: > https://github.com/grails/grails-core/commit/a6d70aaf7925fb7f2e847a803a8e1f3c95bf8cf8#diff-3092a650525dc131a0394eca4282362bL35 > Also empty lists and maps no longer seem to compile. See: > https://github.com/grails/grails-core/commit/a6d70aaf7925fb7f2e847a803a8e1f3c95bf8cf8#diff-07f8418b033d870eee3c1cee97e44f4cL121 > https://github.com/grails/grails-core/commit/a6d70aaf7925fb7f2e847a803a8e1f3c95bf8cf8#diff-15a1d1d639cada3a0c85c7200547db02L40 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GROOVY-7763) Various problems with type inference in Groovy 2.4.6
[ https://issues.apache.org/jira/browse/GROOVY-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Wagenleitner updated GROOVY-7763: -- Labels: static (was: ) > Various problems with type inference in Groovy 2.4.6 > > > Key: GROOVY-7763 > URL: https://issues.apache.org/jira/browse/GROOVY-7763 > Project: Groovy > Issue Type: Bug >Affects Versions: 2.4.6 >Reporter: Graeme Rocher >Priority: Critical > > After trying to upgrade Grails to Groovy 2.4.6 there are numerous problems > with @CompileStatic and type inference with Maps and Lists. If I had seen the > vote for the release in time I would have tested and voted -1, so sorry for > only reporting this afterwards. > This commits shows the changes I had to make in order to get Grails to > compile with Groovy 2.4.6: > https://github.com/grails/grails-core/commit/a6d70aaf7925fb7f2e847a803a8e1f3c95bf8cf8 > You can see for example that previously returning a list initialised with > variables of the correct type compiled, but no longer does: > https://github.com/grails/grails-core/commit/a6d70aaf7925fb7f2e847a803a8e1f3c95bf8cf8#diff-3092a650525dc131a0394eca4282362bL35 > Also empty lists and maps no longer seem to compile. See: > https://github.com/grails/grails-core/commit/a6d70aaf7925fb7f2e847a803a8e1f3c95bf8cf8#diff-07f8418b033d870eee3c1cee97e44f4cL121 > https://github.com/grails/grails-core/commit/a6d70aaf7925fb7f2e847a803a8e1f3c95bf8cf8#diff-15a1d1d639cada3a0c85c7200547db02L40 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GROOVY-7763) Various problems with type inference in Groovy 2.4.6
[ https://issues.apache.org/jira/browse/GROOVY-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Wagenleitner updated GROOVY-7763: -- Labels: (was: static) > Various problems with type inference in Groovy 2.4.6 > > > Key: GROOVY-7763 > URL: https://issues.apache.org/jira/browse/GROOVY-7763 > Project: Groovy > Issue Type: Bug >Affects Versions: 2.4.6 >Reporter: Graeme Rocher >Priority: Critical > > After trying to upgrade Grails to Groovy 2.4.6 there are numerous problems > with @CompileStatic and type inference with Maps and Lists. If I had seen the > vote for the release in time I would have tested and voted -1, so sorry for > only reporting this afterwards. > This commits shows the changes I had to make in order to get Grails to > compile with Groovy 2.4.6: > https://github.com/grails/grails-core/commit/a6d70aaf7925fb7f2e847a803a8e1f3c95bf8cf8 > You can see for example that previously returning a list initialised with > variables of the correct type compiled, but no longer does: > https://github.com/grails/grails-core/commit/a6d70aaf7925fb7f2e847a803a8e1f3c95bf8cf8#diff-3092a650525dc131a0394eca4282362bL35 > Also empty lists and maps no longer seem to compile. See: > https://github.com/grails/grails-core/commit/a6d70aaf7925fb7f2e847a803a8e1f3c95bf8cf8#diff-07f8418b033d870eee3c1cee97e44f4cL121 > https://github.com/grails/grails-core/commit/a6d70aaf7925fb7f2e847a803a8e1f3c95bf8cf8#diff-15a1d1d639cada3a0c85c7200547db02L40 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (GROOVY-8278) Groovysh: unable to resolve previously declared classes with interpreterMode=true
[
https://issues.apache.org/jira/browse/GROOVY-8278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner closed GROOVY-8278.
-
Resolution: Duplicate
Assignee: John Wagenleitner
> Groovysh: unable to resolve previously declared classes with
> interpreterMode=true
> -
>
> Key: GROOVY-8278
> URL: https://issues.apache.org/jira/browse/GROOVY-8278
> Project: Groovy
> Issue Type: Bug
> Components: Groovysh
>Affects Versions: 2.4.12
> Environment: Linux x86-64,
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Øyvind Stegard
>Assignee: John Wagenleitner
>
> Classes declared in a Groovysh session cannot be used properly later on when
> using {{interpreterMode=true}}.
> This fails with error "unable to resolve class C":
> {code:java}
> :set interpreterMode true
> class C { }
> instance = new C()
> {code}
> However, this clunky workaround works:
> {code:java}
> :set interpreterMode true
> class C { }
> new C()
> instance = _
> assert instance.getClass() == C.class
> {code}
> Groovysh session showing the issue when {{interpreterMode}} is enabled:
> {noformat}
> groovysh -d
> DEBUG [org.codehaus.groovy.tools.shell.BufferManager] Created new buffer with
> index: 0
> DEBUG [org.codehaus.groovy.tools.shell.BufferManager] Buffers reset
> DEBUG [org.codehaus.groovy.tools.shell.Parser] Using parser flavor: rigid
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command: ?
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :help
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :quit
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :exit
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> import
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :display
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :clear
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :show
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :inspect
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :purge
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :edit
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command: .
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :load
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :save
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :record
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :history
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :alias
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :set
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :register
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :doc
> DEBUG [org.codehaus.groovy.tools.shell.InteractiveShellRunner] Using history
> file: /home/oyvind/.groovy/groovysh.history
> DEBUG [org.codehaus.groovy.tools.shell.Groovysh] Terminal
> (jline.UnixTerminal@d737b89)
> DEBUG [org.codehaus.groovy.tools.shell.Groovysh] Supported: true
> DEBUG [org.codehaus.groovy.tools.shell.Groovysh] ECHO: (enabled:
> false)
> DEBUG [org.codehaus.groovy.tools.shell.Groovysh] H x W: 64 x 115
> DEBUG [org.codehaus.groovy.tools.shell.Groovysh] ANSI: true
> Groovy Shell (2.4.12, JVM: 1.8.0_144)
> Type ':help' or ':h' for help.
> --
> DEBUG [org.codehaus.groovy.tools.shell.CommandsMultiCompleter] Added
> completer[1] for command: :help
> DEBUG [org.codehaus.groovy.tools.shell.CommandsMultiCompleter] Added
> completer[2] for command: ?
> DEBUG [org.codehaus.groovy.tools.shell.CommandsMultiCompleter] Added
> completer[3] for command: :exit
> DEBUG [org.codehaus.groovy.tools.shell.CommandsMultiCompleter] Added
> completer[4] for command: :quit
> DEBUG [org.codehaus.groovy.tools.shell.CommandsMultiCompleter] Added
> completer[5] for command: import
> DEBUG [org.codehaus.groovy.tools.shell.CommandsMultiCompleter] Added
> completer[6] for command: :display
> DEBUG [org.codehaus.groovy.tools.shell.CommandsMultiCompleter] Added
> completer[7] for command: :clear
> DEBUG [org.codehaus.groovy.tools.shell.CommandsMultiCompleter] Added
> completer[8] for command:
[jira] [Commented] (GROOVY-8278) Groovysh: unable to resolve previously declared classes with interpreterMode=true
[
https://issues.apache.org/jira/browse/GROOVY-8278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16126718#comment-16126718
]
John Wagenleitner commented on GROOVY-8278:
---
Looks like this is fixed in 2.5.0 (in beta) by GROOVY-7562 [commit
6b80966a4e|https://github.com/apache/groovy/commit/6b80966a4e50b0e24b86832eaa01be96d2dded3d#diff-3cf65a35f1b86ee676b39d8581fde0cc].
It was noted in GROOVY-7562 that it wasn't merged in 2.4 due to some
compatibility concerns. So unless it's critical for 2.4 I'd suggest this be
closed with the work-around to be turn off interpreter mode. If critical then
with some work the fix might be able to be back-ported to 2.4 and still retain
compatibility.
> Groovysh: unable to resolve previously declared classes with
> interpreterMode=true
> -
>
> Key: GROOVY-8278
> URL: https://issues.apache.org/jira/browse/GROOVY-8278
> Project: Groovy
> Issue Type: Bug
> Components: Groovysh
>Affects Versions: 2.4.12
> Environment: Linux x86-64,
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Øyvind Stegard
>
> Classes declared in a Groovysh session cannot be used properly later on when
> using {{interpreterMode=true}}.
> This fails with error "unable to resolve class C":
> {code:java}
> :set interpreterMode true
> class C { }
> instance = new C()
> {code}
> However, this clunky workaround works:
> {code:java}
> :set interpreterMode true
> class C { }
> new C()
> instance = _
> assert instance.getClass() == C.class
> {code}
> Groovysh session showing the issue when {{interpreterMode}} is enabled:
> {noformat}
> groovysh -d
> DEBUG [org.codehaus.groovy.tools.shell.BufferManager] Created new buffer with
> index: 0
> DEBUG [org.codehaus.groovy.tools.shell.BufferManager] Buffers reset
> DEBUG [org.codehaus.groovy.tools.shell.Parser] Using parser flavor: rigid
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command: ?
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :help
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :quit
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :exit
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> import
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :display
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :clear
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :show
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :inspect
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :purge
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :edit
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command: .
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :load
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :save
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :record
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :history
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :alias
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :set
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :register
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :doc
> DEBUG [org.codehaus.groovy.tools.shell.InteractiveShellRunner] Using history
> file: /home/oyvind/.groovy/groovysh.history
> DEBUG [org.codehaus.groovy.tools.shell.Groovysh] Terminal
> (jline.UnixTerminal@d737b89)
> DEBUG [org.codehaus.groovy.tools.shell.Groovysh] Supported: true
> DEBUG [org.codehaus.groovy.tools.shell.Groovysh] ECHO: (enabled:
> false)
> DEBUG [org.codehaus.groovy.tools.shell.Groovysh] H x W: 64 x 115
> DEBUG [org.codehaus.groovy.tools.shell.Groovysh] ANSI: true
> Groovy Shell (2.4.12, JVM: 1.8.0_144)
> Type ':help' or ':h' for help.
> --
> DEBUG [org.codehaus.groovy.tools.shell.CommandsMultiCompleter] Added
> completer[1] for command: :help
> DEBUG [org.codehaus.groovy.tools.shell.CommandsMultiCompleter] Added
> completer[2] for command: ?
> DEBUG [org.codehaus.groovy.tools.shell.CommandsMultiCompleter] Added
> completer[3] for command: :exit
> DEBUG
[jira] [Commented] (GROOVY-8213) Closures are maybe not Threadsafe
[
https://issues.apache.org/jira/browse/GROOVY-8213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125099#comment-16125099
]
John Wagenleitner commented on GROOVY-8213:
---
I have not been able to reproduce the issue. My suspicion would be the
{{initialized}} variable. It is updated in synchronized blocks but has a
non-synchronized accessor method. Looking at the history of it (and its
counterpart in {{MetaClassImpl}}) it does appear that one time it was
synchronized. Since it's not {{volatile}} it may be possible that the
{{ClosureMetaClass#isInitialized}} method may return a stale value. Having a
standalone reproducible test would be helpful.
> Closures are maybe not Threadsafe
> -
>
> Key: GROOVY-8213
> URL: https://issues.apache.org/jira/browse/GROOVY-8213
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.10
> Environment: Gradle 3.5
>Reporter: Björn Kautler
>
> I just upgraded our Gradle build from 1.12 (including Groovy 1.8.6) to 3.5
> (including Groovy 2.4.10).
> Now I get a very strange behavior for stuff that is there for years already
> and it looks to me as if this is a Groovy bug, maybe a non-threadsafeness of
> Closures.
> I have a custom task that contains the following code:
> {code}
> def sourceFilesSize = getSourceFiles().files.size()
> def poolSize = Runtime.runtime.availableProcessors()
> def executor = new ThreadPoolExecutor(poolSize, poolSize, 0, SECONDS,
> new ArrayBlockingQueue([sourceFilesSize, 1].max()))
> def tasks = []
> inputs.outOfDate { toTransform ->
> tasks.add executor.submit {
> project.exec {
>if (gscPath) { // here starts
> com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11
> environment 'GSC', gscPath
> def tempDir = "$temporaryDir/${Thread.currentThread().name}"
> project.file(tempDir).mkdirs()
> environment 'TEMP', tempDir
>}
>executable executablePath
>def arguments = [toTransform.file.absolutePath]
>if ((sourceFilesSize == 1) && getDestinationFile()) {
> arguments << getDestinationFile().absolutePath
>} else if (destinationDirectory) {
> arguments << new File(destinationDirectory,
> fileNameMapping(toTransform.file.name)).absolutePath
>} else {
> arguments << new File(toTransform.file.parentFile,
> fileNameMapping(toTransform.file.name)).absolutePath
>}
>args arguments // here ends
> com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11
> }
> }
> }
> executor.shutdown()
> executor.awaitTermination 1, HOURS
> tasks*.get() // here is line 137
> {code}
> When this task is executed e. g. with five source files, sometimes all works
> fine, sometime the build fails with
> {noformat}
> ...
> Caused by: java.util.concurrent.ExecutionException:
> java.lang.IllegalStateException: initialize must be called for meta class of
> class com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11(class
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass) to complete
> initialisation process before any invocation or field/property access can be
> done
> at com.empic.build.tasks.Ghostscript.exec(Ghostscript.groovy:137)
> at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
> ... 80 more
> Caused by: java.lang.IllegalStateException: initialize must be called for
> meta class of class
> com.empic.build.tasks.Ghostscript$_exec_closure8$_closure11(class
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass) to complete
> initialisation process before any invocation or field/property access can be
> done
> {noformat}
> Actually I was not able to reproduce the problem locally, but if I run the
> build on our CI server and attach a debugger, I indeed was able to reproduce
> the problem with a relatively high reproduction rate. (as in every second to
> third build approximately, opposed to once every 100 builds)
> I logged the current thread when the {{initialized}} property is set to
> {{true}} and when it is requested with non-suspending breakpoints, but this
> seems to have caused the timing to change enough already that I was not able
> to reproduce the error within approximately the first two dozens of tries.
> I was able to successfully break at the throwing of the
> {{IllegalStateException}} though. This happens in
> {{groovy.lang.MetaClassImpl.checkInitalised}}.
> The stacktrace at this point is:
> {noformat}
> "pool-2-thread-3@10709" prio=5 tid=0x47 nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at
[jira] [Commented] (GROOVY-8250) VariableScopeVisitor does not set declaring class on property nodes
[
https://issues.apache.org/jira/browse/GROOVY-8250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125093#comment-16125093
]
John Wagenleitner commented on GROOVY-8250:
---
Setting the type on the property based on the first match will cause a problem
if there are multiple setters for the given property. For reference, [commit
4f28eab3cc|https://github.com/apache/groovy/commit/4f28eab3cca03a15ca146c7c8301f5ecddf6fa89]
contains tests that will fail if the first resolved setter parameter type is
chosen.
One alternative may be to check all methods and if a single type if found use
it else fall back to Object.
> VariableScopeVisitor does not set declaring class on property nodes
> ---
>
> Key: GROOVY-8250
> URL: https://issues.apache.org/jira/browse/GROOVY-8250
> Project: Groovy
> Issue Type: Bug
>Reporter: Eric Milles
>
> VariableScopeVisitor.findClassMember creates PropertyNode instances for
> methods (ex: foo.bar will have a property node created if getBar() is
> implemented). This is done inside the MethodNode for loop circa line 165.
> The nodes created by this visitor lack a declaring class setting as well as
> having an improper type. Without these values, type inferencing is more
> difficult for anyone that processes the AST. These are reasonable simple to
> remedy:
> {code}
> private Variable findClassMember(ClassNode cn, String name) {
> if (cn == null) return null;
> if (cn.isScript()) {
> return new DynamicVariable(name, false);
> }
> for (FieldNode fn : cn.getFields()) {
> if (fn.getName().equals(name)) return fn;
> }
> for (MethodNode mn : cn.getMethods()) {
> String pName = getPropertyName(mn);
> // GRECLIPSE edit
> //if (pName != null && pName.equals(name))
> //return new PropertyNode(pName, mn.getModifiers(),
> ClassHelper.OBJECT_TYPE, cn, null, null, null);
> if (pName != null && pName.equals(name)) {
> PropertyNode property = new PropertyNode(pName,
> mn.getModifiers(), getPropertyType(mn), cn, null, null, null);
> property.getField().setDeclaringClass(cn);
> property.setDeclaringClass(cn);
> return property;
> }
> // GRECLIPSE end
> }
> ...
> // GRECLIPSE add
> private ClassNode getPropertyType(MethodNode m) {
> if (m.getReturnType() != ClassHelper.VOID_TYPE) {
> return m.getReturnType();
> }
> return m.getParameters()[0].getType();
> }
> // GRECLIPSE end
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8278) Groovysh: unable to resolve previously declared classes
[
https://issues.apache.org/jira/browse/GROOVY-8278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125027#comment-16125027
]
John Wagenleitner commented on GROOVY-8278:
---
I am not able to reproduce the issue. Do you have any [profile
scripts|http://www.groovy-lang.org/groovysh.html#GroovyShell-UserProfileScriptsandState]
that might run or some custom preferences (:show preferences)?
{code}
~/projects/ASF/groovy (master)$ ~/java/groovy-2.4.12/bin/groovysh
Groovy Shell (2.4.12, JVM: 1.8.0_144)
Type ':help' or ':h' for help.
---
groovy:000> class C { }
===> true
groovy:000> instance = new C()
===> C@51549490
groovy:000> :show preferences
No preferences are set
groovy:000> :exit
{code}
> Groovysh: unable to resolve previously declared classes
> ---
>
> Key: GROOVY-8278
> URL: https://issues.apache.org/jira/browse/GROOVY-8278
> Project: Groovy
> Issue Type: Bug
> Components: Groovysh
>Affects Versions: 2.4.12
> Environment: Linux x86-64,
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Øyvind Stegard
>
> Classes declared in a Groovysh session cannot be used properly later on.
> This fails with error "unable to resolve class C":
> {code:java}
> class C { }
> instance = new C()
> {code}
> However, this clunky workaround works:
> {code:java}
> class C { }
> new C()
> instance = _
> assert instance.getClass() == C.class
> {code}
> Groovysh session showing the issue:
> {noformat}
> groovysh -d
> DEBUG [org.codehaus.groovy.tools.shell.BufferManager] Created new buffer with
> index: 0
> DEBUG [org.codehaus.groovy.tools.shell.BufferManager] Buffers reset
> DEBUG [org.codehaus.groovy.tools.shell.Parser] Using parser flavor: rigid
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command: ?
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :help
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :quit
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :exit
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> import
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :display
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :clear
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :show
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :inspect
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :purge
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :edit
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command: .
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :load
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :save
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :record
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :history
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :alias
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :set
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :register
> DEBUG [org.codehaus.groovy.tools.shell.CommandRegistry] Registered command:
> :doc
> DEBUG [org.codehaus.groovy.tools.shell.InteractiveShellRunner] Using history
> file: /home/oyvind/.groovy/groovysh.history
> DEBUG [org.codehaus.groovy.tools.shell.Groovysh] Terminal
> (jline.UnixTerminal@d737b89)
> DEBUG [org.codehaus.groovy.tools.shell.Groovysh] Supported: true
> DEBUG [org.codehaus.groovy.tools.shell.Groovysh] ECHO: (enabled:
> false)
> DEBUG [org.codehaus.groovy.tools.shell.Groovysh] H x W: 64 x 115
> DEBUG [org.codehaus.groovy.tools.shell.Groovysh] ANSI: true
> Groovy Shell (2.4.12, JVM: 1.8.0_144)
> Type ':help' or ':h' for help.
> --
> DEBUG [org.codehaus.groovy.tools.shell.CommandsMultiCompleter] Added
> completer[1] for command: :help
> DEBUG [org.codehaus.groovy.tools.shell.CommandsMultiCompleter] Added
> completer[2] for command: ?
> DEBUG [org.codehaus.groovy.tools.shell.CommandsMultiCompleter] Added
> completer[3] for command: :exit
> DEBUG [org.codehaus.groovy.tools.shell.CommandsMultiCompleter] Added
> completer[4] for command: :quit
> DEBUG
[jira] [Resolved] (GROOVY-8208) VariableExpressionTransformer does not set source position on property expressions
[
https://issues.apache.org/jira/browse/GROOVY-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8208.
---
Resolution: Fixed
Assignee: John Wagenleitner
Fix Version/s: 2.4.13
Thanks for reporting the issue and providing the patch.
> VariableExpressionTransformer does not set source position on property
> expressions
> --
>
> Key: GROOVY-8208
> URL: https://issues.apache.org/jira/browse/GROOVY-8208
> Project: Groovy
> Issue Type: Bug
> Components: xforms
>Reporter: Eric Milles
>Assignee: John Wagenleitner
>Priority: Minor
> Fix For: 2.4.13
>
>
> Two paths in VariableExpressionTransformer create PropertyExpression nodes to
> stand in for unresolved variable references. Neither case sets the exp source
> position onto the new node. Other paths through this method transfer position
> info.
> The fix is simple:
> {code}
> private static Expression tryTransformDelegateToProperty(VariableExpression
> expr) {
> // we need to transform variable expressions that go to a delegate
> // to a property expression, as ACG would loose the information
> // in processClassVariable before it reaches any makeCall, that could
> // handle it
> Object val =
> expr.getNodeMetaData(StaticTypesMarker.IMPLICIT_RECEIVER);
> if (val == null) return null;
> VariableExpression implicitThis = new VariableExpression("this");
> PropertyExpression pexp = new PropertyExpression(implicitThis,
> expr.getName());
> pexp.copyNodeMetaData(expr);
> pexp.setImplicitThis(true);
> // GRECLIPSE add
> pexp.getProperty().setSourcePosition(expr);
> // GRECLIPSE end
> ClassNode owner =
> expr.getNodeMetaData(StaticCompilationMetadataKeys.PROPERTY_OWNER);
> if (owner != null) {
> implicitThis.putNodeMetaData(StaticTypesMarker.INFERRED_TYPE,
> owner);
> implicitThis.putNodeMetaData(StaticTypesMarker.IMPLICIT_RECEIVER,
> val);
> }
> return pexp;
> }
> private static Expression
> tryTransformPrivateFieldAccess(VariableExpression expr) {
> FieldNode field =
> expr.getNodeMetaData(StaticTypesMarker.PV_FIELDS_ACCESS);
> if (field == null) {
> field =
> expr.getNodeMetaData(StaticTypesMarker.PV_FIELDS_MUTATION);
> }
> if (field != null) {
> // access to a private field from a section of code that normally
> doesn't have access to it, like a
> // closure or an inner class
> VariableExpression receiver = new VariableExpression("this");
> PropertyExpression pexp = new PropertyExpression(
> receiver,
> expr.getName()
> );
> pexp.setImplicitThis(true);
> // GRECLIPSE add
> pexp.getProperty().setSourcePosition(expr);
> // GRECLIPSE end
> // put the receiver inferred type so that the class writer knows
> that it will have to call a bridge method
> receiver.putNodeMetaData(StaticTypesMarker.INFERRED_TYPE,
> field.getDeclaringClass());
> // add inferred type information
> pexp.putNodeMetaData(StaticTypesMarker.INFERRED_TYPE,
> field.getOriginType());
> return pexp;
> }
> return null;
> }
> {code}
> The first method affects code like
> {code}
> @groovy.transform.CompileStatic
> class E {
> D d = new D()
> void doSomething() {
> d.with { // 'foo' and 'bar' VariableExpressions are xformed to
> PropertyExpressions
> foo = 'foo'
> bar = new D()
> bar.foo = 'bar'
> }
> }
> }
> {code}
> The second method affects code like
> {code}
> @groovy.transform.CompileStatic
> class X {
> String id
> @Lazy Object thing = { ->
> Directory.lookup(id) // 'id' is transformed from a VariableExpression to
> a PropertyExpression
> }()
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8269) Unclear/incorrect definition of default behavior for trait multiple inheritence conflicts
[
https://issues.apache.org/jira/browse/GROOVY-8269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16124810#comment-16124810
]
John Wagenleitner commented on GROOVY-8269:
---
Would adding a reference to the implements clause help make it more clear?
{quote}
In this case, the default behavior is that the method from the *last declared
trait* in the {{implements}} clause wins.
{quote}
> Unclear/incorrect definition of default behavior for trait multiple
> inheritence conflicts
> -
>
> Key: GROOVY-8269
> URL: https://issues.apache.org/jira/browse/GROOVY-8269
> Project: Groovy
> Issue Type: Documentation
> Components: Documentation
>Affects Versions: 2.4.12
>Reporter: Sasha Volokh
>Priority: Minor
> Attachments: problem.png
>
>
> In section 2.10.1, Default conflict resolution, the text says "In this case,
> the default behavior is that methods from the last declared trait wins", when
> in fact the order they are implemented is what decides the winning method
> (and if this is what the wording was intending to say, then it isn't clear
> because the example has trait B declared after trait A as well as C
> implementing B after A).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GROOVY-7995) Short syntax of closure call invokes wrong closure if wrapped in another closure and @CompileStatic is applied
[
https://issues.apache.org/jira/browse/GROOVY-7995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-7995.
---
Resolution: Fixed
Assignee: John Wagenleitner
Fix Version/s: 2.4.13
Thanks for reporting the issue.
> Short syntax of closure call invokes wrong closure if wrapped in another
> closure and @CompileStatic is applied
> --
>
> Key: GROOVY-7995
> URL: https://issues.apache.org/jira/browse/GROOVY-7995
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.7
>Reporter: Krzysztof Kowalczyk
>Assignee: John Wagenleitner
> Fix For: 2.4.13
>
>
> The following would fail:
> {code}
> import groovy.transform.CompileStatic
> @CompileStatic
> class Foo {
> Closure c = { "ok" }
> Closure wrap = {
> c()
> }
> def run(){
> wrap()
> }
> }
> assert new Foo().run() == "ok" // stack overflow
> {code}
> It works fine without CompileStatic or if invokation is done by c.call()
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GROOVY-8245) @Newify(auto=false) causing error (in Groovy Web Console)
[
https://issues.apache.org/jira/browse/GROOVY-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8245.
---
Resolution: Fixed
Assignee: John Wagenleitner
Fix Version/s: 2.4.13
Thanks for reporting the issue.
> @Newify(auto=false) causing error (in Groovy Web Console)
> -
>
> Key: GROOVY-8245
> URL: https://issues.apache.org/jira/browse/GROOVY-8245
> Project: Groovy
> Issue Type: Bug
>Reporter: Eric Milles
>Assignee: John Wagenleitner
> Fix For: 2.4.13
>
>
> When I run this with no {{auto=flase}} attribute or with {{auto=true}}, it
> runs successfully (in Groovy Web Console). When I run as below, I get a
> strange error: {code}
> java.lang.ExceptionInInitializerError
> at Script1.run(Script1.groovy:15)
> Caused by: groovy.lang.MissingMethodException: No signature of method: static
> Bar.Foo() is applicable for argument types: () values: []
> Possible solutions: any(), is(java.lang.Object), any(groovy.lang.Closure),
> use([Ljava.lang.Object;), use(java.util.List, groovy.lang.Closure),
> use(java.lang.Class, groovy.lang.Closure)
> at Bar.(Script1.groovy:10)
> {code}
> {code}
> class Foo {
> Foo() {
> println 'new foo'
> }
> }
> @Newify(auto=false, value=Foo)
> class Bar {
> static {
> Foo foo = Foo()
> }
> static void method() {}
> }
> Bar.method()
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GROOVY-8242) Javadoc for Newify is missing some attribute values
[
https://issues.apache.org/jira/browse/GROOVY-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8242.
---
Resolution: Fixed
Assignee: John Wagenleitner
Fix Version/s: 2.4.13
Thanks for reporting the issue, default has been added for the value attribute
to denote it's not required (in cases when using the Ruby-style).
> Javadoc for Newify is missing some attribute values
> ---
>
> Key: GROOVY-8242
> URL: https://issues.apache.org/jira/browse/GROOVY-8242
> Project: Groovy
> Issue Type: Bug
>Reporter: Eric Milles
>Assignee: John Wagenleitner
>Priority: Minor
> Fix For: 2.4.13
>
>
> I was looking at thw Newify AST transform. Some of the Javadoc appears
> incorrect since the annotation requires a value.
> {code}
> * or this ("Ruby-style"):
> *
> * {@code @Newify} class MyTreeProcessor { -- Is this supposed to be
> @Newify([Tree,Leaf])?
> * def myTree = Tree.new(Tree.new(Leaf.new("A"), Leaf.new("B")),
> Leaf.new("C"))
> * def process() { ... }
> * }
> *
> {code}
> {code}
> * An example showing how to use the annotation at different levels:
> *
> * {@code @Newify(auto=false, value=Foo)}
> * class Main {
> * {@code @Newify} // turn auto on for field -- Is this supposed to be
> @Newify(BigInteger)?
> * def field1 = java.math.BigInteger.new(42)
> * def field2, field3, field4
> *
> * {@code @Newify(Bar)}
> * def process() {
> * field2 = Bar("my bar")
> * }
> *
> * {@code @Newify(Baz)}
> * Main() {
> * field3 = Foo("my foo")
> * field4 = Baz("my baz")
> * }
> * }
> *
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8275) Newify transform docs missing support for local variable declaration
[
https://issues.apache.org/jira/browse/GROOVY-8275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16115509#comment-16115509
]
John Wagenleitner commented on GROOVY-8275:
---
For #2 and #3, looks like adding local variable support was part of GROOVY-4876
as a way to [enable usage in
scripts|https://github.com/apache/groovy/commit/a0c8d2418286d46182ee647d5f3c6d48212a508f#diff-43aa4979f66a79c1de9464bf9059cf4eR97].
Based on GROOVY-4876 I'm not sure if this is by design; that the presence of
the annotation on a local variable turns it on for all others in the script.
For example:
{code}
@Newify
def x = Integer.new(1)
def y = Integer.new(2)
def z = Integer.new(3)
assert x + y + z == 6
{code}
It does lead to unexpected results when used in a Class.
{code}
class Foo {
int bar() {
def x = Integer.new(1)
}
int baz() {
@Newify
def y = Integer.new(2)
}
}
assert new Foo().bar() == 1
assert new Foo().baz() == 2
{code}
> Newify transform docs missing support for local variable declaration
>
>
> Key: GROOVY-8275
> URL: https://issues.apache.org/jira/browse/GROOVY-8275
> Project: Groovy
> Issue Type: Documentation
> Components: xforms
>Reporter: Eric Milles
>Priority: Minor
>
> Javadocs and online documentation for the Newify AST transform is not quite
> clear in a couple instances.
> 1) Online docs http://groovy-lang.org/metaprogramming.html#xform-Newify
> Ruby-style section could be more clear IMO if the {{([Tree,Leaf])}} were
> removed since it only enables the Python-style expressions.
> 2) Javadoc and online docs do not mention that {{@Newify}} can be applied to
> a local variable declaration, like: {{@Newify def o = Object.new()}}.
> 3) The scoping of the transform is pretty clear for the class, method and
> field/property cases. However for the local variable case, it appears that
> the transform applies throughout the containing scope of the local variable.
> That is, I can use the extra constructors anywhere in the block to
> re-initialize the variable. {{@Newify def o = Object.new(); ... o =
> Object.new() ...}}. Is this the intended behavior? My intuition was that
> the initializer expression was the only place the transform applied, like in
> the case of a field.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GROOVY-8259) add suppressed exceptions for with[Auto]Closeable methods
[
https://issues.apache.org/jira/browse/GROOVY-8259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8259.
---
Resolution: Fixed
Fix Version/s: 2.5.0-beta-2
Proposed PR merged.
> add suppressed exceptions for with[Auto]Closeable methods
> -
>
> Key: GROOVY-8259
> URL: https://issues.apache.org/jira/browse/GROOVY-8259
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Affects Versions: 2.5.0-beta-1
>Reporter: John Wagenleitner
>Assignee: John Wagenleitner
>Priority: Minor
> Fix For: 2.5.0-beta-2
>
>
> As with the try-with-resources statement, if multiple exceptions are thrown
> the exception from the closure should be returned and the exception from
> closing should be added as a suppressed exception.
> Currently the withCloseable/withAutoCloseable method return the closure
> exception and log a warning if an exception is thrown on the call to
> {{close()}}. With this improvement the exception from {{close()}} would also
> be added as a suppressed exception to the exception thrown from the closure.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GROOVY-8251) Implement withCloseable on AutoCloseable
[
https://issues.apache.org/jira/browse/GROOVY-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8251.
---
Resolution: Fixed
Assignee: John Wagenleitner
Fix Version/s: 2.5.0-beta-2
Thanks for reporting the issue. The {{withAutoCloseable}} method has been
moved from the NIO subproject to core and renamed {{withCloseable}} to be
consistent with the existing method for {{java.io.Closeable}}.
> Implement withCloseable on AutoCloseable
>
>
> Key: GROOVY-8251
> URL: https://issues.apache.org/jira/browse/GROOVY-8251
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Affects Versions: 2.5.0-beta-1
>Reporter: Henri Tremblay
>Assignee: John Wagenleitner
> Fix For: 2.5.0-beta-2
>
>
> The Groovy implementation of try-with-resource is through
> {{withCloseable()}}. The problem is that {{withCloseable}} only exists for
> classes implementing the {{Closeable}} interface.
> But a try-with-resource works with the {{AutoCloseable}} interface. So
> {{withCloseable}} should probably be moved on step below to {{AutoCloseable}}
> (that {{Closeable}} extends).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (GROOVY-7158) minus(List, Collection) considers different objects equal if they have equal hashCodes
[
https://issues.apache.org/jira/browse/GROOVY-7158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner closed GROOVY-7158.
-
Resolution: Fixed
Assignee: John Wagenleitner
This issue was fixed by the fix for GROOVY-7530 and the [code in
question|https://github.com/apache/groovy/blob/6a8232a5ba4fdf89c7c3d1eddba68b909f4a732a/src/main/org/codehaus/groovy/runtime/NumberAwareComparator.java#L53]
now compares using {{equals}}.
> minus(List, Collection) considers different objects equal if they have equal
> hashCodes
> --
>
> Key: GROOVY-7158
> URL: https://issues.apache.org/jira/browse/GROOVY-7158
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Reporter: motto
>Assignee: John Wagenleitner
>
> This is essentially a duplicate of GROOVY-4101 and the related ticket
> GROOVY-4124.
> In [org.codehaus.groovy.runtime.DefaultGroovyMethods.minus(Collection
> self, Collection
> removeMe)|https://github.com/groovy/groovy-core/blob/master/src/main/org/codehaus/groovy/runtime/DefaultGroovyMethods.java#L10048]
> {noformat}
> Comparator numberComparator = new NumberAwareComparator();
> ...
> if (numberComparator.compare(element, (T)elt) == 0) {
> iter.remove();
> elementRemoved = true;
> }
> {noformat}
> objects not implementing
> [Comparable|http://docs.oracle.com/javase/7/docs/api/java/lang/Comparable.html]
> and without a compareTo method are compared using the
> [NumberAwareComparator|https://github.com/groovy/groovy-core/blob/master/src/main/org/codehaus/groovy/runtime/NumberAwareComparator.java#L37]
> {noformat}
> // since the object does not have a valid compareTo method
> // we compare using the hashcodes. null cases are handled by
> // DefaultTypeTransformation.compareTo
> int x1 = o1.hashCode();
> int x2 = o2.hashCode();
> if (x1 == x2) return 0;
> if (x1 < x2) return -1;
> return 1;
> {noformat}
> which incorrectly removes unequal objects from the original collection.
> This is exceedingly frustrating because the results are therefore sporadic
> and supposedly resolved according to GROOVY-4101 and GROOVY-4124. After a
> fair amount of head scratching and debugging (on more than 1 occasion) I went
> looking at the sources on github and it appears the patch has never made it
> into master. Is it possible the patch was deemed unfit? Was it forgotten
> about? Is this something I should fix myself?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GROOVY-8218) Allow to specify reverse order for @Sortable
[
https://issues.apache.org/jira/browse/GROOVY-8218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8218.
---
Resolution: Fixed
Assignee: John Wagenleitner
Fix Version/s: 2.5.0-beta-2
Thanks for the improvement suggestion and PR.
> Allow to specify reverse order for @Sortable
>
>
> Key: GROOVY-8218
> URL: https://issues.apache.org/jira/browse/GROOVY-8218
> Project: Groovy
> Issue Type: Improvement
>Reporter: Paul-Julien Vauthier
>Assignee: John Wagenleitner
>Priority: Minor
> Fix For: 2.5.0-beta-2
>
>
> When using the Sortable annotation it is not possible to use reverse order.
> For a leaderboard, you may want to sort its entries by points.
> {code}
> @Sortable(reversed = true)
> class LeaderBoardEntry {
> int points
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8258) Create a LINQ-like DSL
[
https://issues.apache.org/jira/browse/GROOVY-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16089058#comment-16089058
]
John Wagenleitner commented on GROOVY-8258:
---
The DSL looks like it could be useful in certain situations. But my opinion is
that something like this would be best provided as an external library and not
included (from the start anyway) as part of Groovy itself or one of its
subprojects.
> Create a LINQ-like DSL
> --
>
> Key: GROOVY-8258
> URL: https://issues.apache.org/jira/browse/GROOVY-8258
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>
> *Pojos:*
> {code:java}
> class Category {
>String name
>List articles
> }
> class Article {
> String name
> Integer voteCount
> String categoryName
> }
> {code}
> *Example1:*
> {code:java}
> linq { // return an Iterator>
> from c of categories
> join a of articles on a.categoryName == c.name // join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> limit 100 offset 50 // pagination
> select { // create a map, its keys: articleName, voteNum, categoryName
> articleName = a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *Example2:*
> {code:java}
> linq { // return an Iterator>
> from c of categories
> join a of {
> from tempA of articles
> where tempA.voteCount > 10
> select tempA
> } on a.categoryName == c.name // join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> limit 100 offset 50 // pagination
> select { // create a map, its keys: articleName, voteNum, categoryName
> articleName = a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *Example3:*
> {code:java}
> linq { // return an Iterator
> from c of categories
> from a of c.articles // another join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> select Article { // create an Article instance
> a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *TO BE CONTINUED...*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-7572) Add withAutoClosable method
[
https://issues.apache.org/jira/browse/GROOVY-7572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16089045#comment-16089045
]
John Wagenleitner commented on GROOVY-7572:
---
Just noting here that GROOVY-8251 is proposing that the method be renamed to
{{withCloseable}} to be consistent with the existing
{{withCloseable(java.io.Closeable...)}} method that exists in
{{IOGroovyMethods}}. See [PR 572|https://github.com/apache/groovy/pull/572].
> Add withAutoClosable method
> ---
>
> Key: GROOVY-7572
> URL: https://issues.apache.org/jira/browse/GROOVY-7572
> Project: Groovy
> Issue Type: Improvement
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
> Fix For: 2.5.0-alpha-1
>
>
> see pull request submitted by Dominik Przybysz for details:
> [https://github.com/apache/incubator-groovy/pull/103]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (GROOVY-8259) add suppressed exceptions for with[Auto]Closeable methods
John Wagenleitner created GROOVY-8259:
-
Summary: add suppressed exceptions for with[Auto]Closeable methods
Key: GROOVY-8259
URL: https://issues.apache.org/jira/browse/GROOVY-8259
Project: Groovy
Issue Type: Improvement
Components: groovy-runtime
Affects Versions: 2.5.0-beta-1
Reporter: John Wagenleitner
Assignee: John Wagenleitner
Priority: Minor
As with the try-with-resources statement, if multiple exceptions are thrown the
exception from the closure should be returned and the exception from closing
should be added as a suppressed exception.
Currently the withCloseable/withAutoCloseable method return the closure
exception and log a warning if an exception is thrown on the call to
{{close()}}. With this improvement the exception from {{close()}} would also
be added as a suppressed exception to the exception thrown from the closure.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8067) Possible deadlock when creating new ClassInfo entries in the cache
[
https://issues.apache.org/jira/browse/GROOVY-8067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16088706#comment-16088706
]
John Wagenleitner commented on GROOVY-8067:
---
{quote}
So guess the question would be whether the responsibility lies with the caller
of {{ExpandoMetaClass#enableGlobally}} to check first to see if already enabled
or whether that method should not clear if already enabled.
{quote}
The enableGlobally call does already check and only clears if the
{{ExpandoMetaClassCreationHandle}} is not the current handle. In tracing the
calls to clearModifiedExpandos when running the sample project
grails-javamelody-issue the plugin triggers 2 calls to clearModifiedExpandos,
first call in {{ExpandoMetaClassCreationHandle#create}} (via
{{ExpandoMetaClass.enableGlobally}}) and second one in
{{MetaClassRegistryImpl#setMetaClassCreationHandle}} (via the before mentioned
create call). So even with the old {{ManagedLinkedList}} (in Groovy 2.4.8) the
plugin would have removed 2 modified expandos, those for
{{org.grails.plugins.codecs.URLCodec}} and
{{org.grails.encoder.impl.JavaScriptCodec}}.
> Possible deadlock when creating new ClassInfo entries in the cache
> --
>
> Key: GROOVY-8067
> URL: https://issues.apache.org/jira/browse/GROOVY-8067
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.4.8
>Reporter: John Wagenleitner
>Assignee: John Wagenleitner
>Priority: Critical
> Fix For: 2.4.9
>
> Attachments: ClassInfoDeadlockTest.java
>
>
> When running Groovy without {{-Dgroovy.use.classvalue=true}} the ClassInfo
> instances are cached in a {{ManagedConcurrentMap}} (MCM). New values are
> computed on demand and computation involves both a lock on a segment within
> the MCM and a lock on the {{GlobalClassSet}} (GCS) which is backed by a
> {{ManagedLinkedList}}. The problem is that both the ManagedConcurrentMap and
> the GlobalClassSet share the same ReferenceQueue.
> Assume there is an enqueued {{ClassInfo}} value that is stored in Segment2 of
> the MCM. Now assume that Thread1 and Thread2 both request
> {{ClassInfo.getClassInfo(..)}} for two different classes that do not
> currently exist in the cache. Assume that based on hashing Thread1 gets a
> lock on Segment1 and Thread2 gets a lock on Segment2. Assume that Thread1 is
> the first to call computeValue which in turn calls
> {{GlobalClassSet.add(..)}}. This call adds a new value to a
> {{ManagedLinkedList}}, and since it's managed the add operation will process
> the ReferenceQueue. So Thread1 will attempt to dequeue the ClassInfo and the
> finalizeReference method on it's entry will attempt to remove it from
> Segment2. Thread2 holds the lock for Segment2 and Thread2 is blocked and
> can't progress it's waiting on the the lock Thread1 holds the lock for the
> GlobalClassSet, so deadlock occurs.
> The attached test case includes a thread dump at the bottom.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8067) Possible deadlock when creating new ClassInfo entries in the cache
[
https://issues.apache.org/jira/browse/GROOVY-8067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16088680#comment-16088680
]
John Wagenleitner commented on GROOVY-8067:
---
It looks like the issue might be related to the {{ManagedLinkedList}} (MLL)
iterator vs the {{ManagedConcurrentLinkedQueue}} (MCLQ) iterator. The MLL
{{iterator#remove}} method seems to not correctly relink the list (head, tail).
{code}
import org.codehaus.groovy.util.*
mml = new ManagedLinkedList(ReferenceBundle.getHardBundle())
//mml = new
ManagedConcurrentLinkedQueue(ReferenceBundle.getHardBundle())
mml.add('foo')
mml.add('bar')
mml.add('baz')
for (Iterator itr = mml.iterator(); itr.hasNext(); ) {
String s = itr.next()
println s
itr.remove()
}
{code}
Output from MLL:
{code}
foo
{code}
Output from MCLQ:
{code}
foo
bar
baz
{code}
So with the old code using MLL any calls to {{clearModifiedExpandos}} would
always only remove the first one.
The [call to ExpandoMetaClass.enableGlobally in the
grails-melody-plugin|https://github.com/javamelody/grails-melody-plugin/blob/4da5c1e7092f7841e6133fd790baa0419340a6ad/src/main/groovy/grails/melody/plugin/MelodyInterceptorEnhancer.groovy#L32]
triggers a call to {{clearModifiedExpandos}}. By this time Grails core has
already added the {{encode}} methods. The old code just by luck would not
remove the modified expandos (and more importantly is the call to
{{setStrongMetaClass(null)}}) but the new MCLQ really does clear all modified
expandos.
Assuming that's the problem, not sure what's the appropriate fix. It seems to
me like the old MLL is broken, it doesn't look like this would have been the
intended behavior. So guess the question would be whether the responsibility
lies with the caller of {{ExpandoMetaClass#enableGlobally}} to check first to
see if already enabled or whether that method should not clear if already
enabled.
> Possible deadlock when creating new ClassInfo entries in the cache
> --
>
> Key: GROOVY-8067
> URL: https://issues.apache.org/jira/browse/GROOVY-8067
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.4.8
>Reporter: John Wagenleitner
>Assignee: John Wagenleitner
>Priority: Critical
> Fix For: 2.4.9
>
> Attachments: ClassInfoDeadlockTest.java
>
>
> When running Groovy without {{-Dgroovy.use.classvalue=true}} the ClassInfo
> instances are cached in a {{ManagedConcurrentMap}} (MCM). New values are
> computed on demand and computation involves both a lock on a segment within
> the MCM and a lock on the {{GlobalClassSet}} (GCS) which is backed by a
> {{ManagedLinkedList}}. The problem is that both the ManagedConcurrentMap and
> the GlobalClassSet share the same ReferenceQueue.
> Assume there is an enqueued {{ClassInfo}} value that is stored in Segment2 of
> the MCM. Now assume that Thread1 and Thread2 both request
> {{ClassInfo.getClassInfo(..)}} for two different classes that do not
> currently exist in the cache. Assume that based on hashing Thread1 gets a
> lock on Segment1 and Thread2 gets a lock on Segment2. Assume that Thread1 is
> the first to call computeValue which in turn calls
> {{GlobalClassSet.add(..)}}. This call adds a new value to a
> {{ManagedLinkedList}}, and since it's managed the add operation will process
> the ReferenceQueue. So Thread1 will attempt to dequeue the ClassInfo and the
> finalizeReference method on it's entry will attempt to remove it from
> Segment2. Thread2 holds the lock for Segment2 and Thread2 is blocked and
> can't progress it's waiting on the the lock Thread1 holds the lock for the
> GlobalClassSet, so deadlock occurs.
> The attached test case includes a thread dump at the bottom.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8255) Odd problems with flow typing and generics in Groovy 2.4.12+
[
https://issues.apache.org/jira/browse/GROOVY-8255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16087363#comment-16087363
]
John Wagenleitner commented on GROOVY-8255:
---
This looks like it might be related to GROOVY-8220 which was caused by flow
typing parameters in GROOVY-8157.
> Odd problems with flow typing and generics in Groovy 2.4.12+
>
>
> Key: GROOVY-8255
> URL: https://issues.apache.org/jira/browse/GROOVY-8255
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: Graeme Rocher
>
> In order to get the GORM codebase to compile I had to make this change:
> https://github.com/grails/grails-data-mapping/commit/1ef850c496d13d8ca915b27e76b6bfdb4e27377e
> The code in question is:
> {code}
> /**
> * Sets multipart values within the request body
> *
> * @param name The name of the multipart
> * @param value The value of the multipart
> */
> void setProperty(String name, value) {
> if (value instanceof File) {
> value = new FileSystemResource(value)
> }
> else if (value instanceof URL) {
> value = new UrlResource(value)
> }
> else if (value instanceof InputStream) {
> value = new InputStreamResource(value)
> }
> else if (value instanceof GString) {
> value = value.toString()
> }
> if( mvm[name] ) {
> mvm[name].add value
> }
> else {
> mvm.put(name, [value]) // <--- FAILS COMPILATION HERE
> }
> }
> {code}
> No matter what I tried I could not get it into to compile. The method accepts
> `put(String, List)` but fails compilation with:
> {code}
> RequestCustomizer.groovy: 392: [Static type checking] - Cannot call
> org.springframework.util.MultiValueMap #put(java.lang.String,
> java.lang.Object) with arguments [java.lang.String, java.util.List
> ]
> @ line 392, column 13.
>mvm.put(name, [value])
>^
> {code}
> Altering the code to:
> {code}
>List values = [value]
>mvm.put(name, values)
> {code}
> Fails with:
> {code}
> RequestCustomizer.groovy: 392: [Static type checking] - Incompatible generic
> argument types. Cannot assign java.util.List to:
> java.util.List
> @ line 392, column 35.
>List values = [value]
> ^
> RequestCustomizer.groovy: 393: [Static type checking] - Cannot call
> org.springframework.util.MultiValueMap #put(java.lang.String,
> java.lang.Object) with arguments [java.lang.String, java.util.List
> ]
> @ line 393, column 13.
>mvm.put(name, values)
>^
> 2 errors
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GROOVY-8222) AsmClassGenerator does not set source positions on property expressions
[
https://issues.apache.org/jira/browse/GROOVY-8222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8222.
---
Resolution: Fixed
Assignee: John Wagenleitner
Fix Version/s: 2.4.13
Thanks for reporting the issue and providing a patch.
> AsmClassGenerator does not set source positions on property expressions
> ---
>
> Key: GROOVY-8222
> URL: https://issues.apache.org/jira/browse/GROOVY-8222
> Project: Groovy
> Issue Type: Bug
>Reporter: Eric Milles
>Assignee: John Wagenleitner
> Fix For: 2.4.13
>
>
> AsmClassGenerator.visitVariableExpression and
> AsmClassGenerator.processClassVariable can create a new PropertyExpression
> from a VariableExpression and the source position of the original is not
> transferred.
> Solution is pretty minimal:
> {code} // mid way through visitVariableExpression:
> if (variable == null) {
> // GRECLIPSE edit
> //processClassVariable(variableName);
> processClassVariable(expression);
> // GRECLIPSE end
> } else {
> {code}
> {code}
> // GRECLIPSE edit
> //private void processClassVariable(String name) {
> private void processClassVariable(VariableExpression expression) {
> String name = expression.getName();
> // GRECLIPSE end
> {code}
> {code} // end of processClassVariable:
> } else {
> // GRECLIPSE edit
> //PropertyExpression pexp = new
> PropertyExpression(VariableExpression.THIS_EXPRESSION, name);
> PropertyExpression pexp = new PropertyExpression(new
> VariableExpression("this", ClassHelper.DYNAMIC_TYPE), name);
> pexp.getObjectExpression().setSourcePosition(expression);
> pexp.getProperty().setSourcePosition(expression);
> // GRECLIPSE end
> pexp.setImplicitThis(true);
> visitPropertyExpression(pexp);
> }
> {code}
> I found this because I had a {{with}} expression that produced an error that
> was attributed to line -1.
> {code}
> import com.fasterxml.jackson.annotation.JsonInclude
> import com.fasterxml.jackson.databind.ObjectMapper
> import com.fasterxml.jackson.datatype.jsonorg.JsonOrgModule
> import org.springframework.http.converter.json.Jackson2ObjectMapperFactoryBean
> @groovy.transform.CompileStatic
> final class CustomObjectMapper extends ObjectMapper
> {
> CustomObjectMapper()
> {
> super(mimicSpring())
> }
> private static ObjectMapper mimicSpring()
> {
> /* Formerly in SpringDispatcherContext.xml:
> * class="org.springframework.http.converter.json.Jackson2ObjectMapperFactoryBean"
> *
> p:modulesToInstall="com.fasterxml.jackson.datatype.jsonorg.JsonOrgModule"
> *p:serializationInclusion="NON_NULL"
> p:failOnUnknownProperties="false"
> *p:autoDetectFields="false" p:autoDetectGettersSetters="true">
> *
> */
> new Jackson2ObjectMapperFactoryBean().with {
> modulesToInstall = JsonOrgModule // Joda module is auto-discovered
> serializationInclusion = JsonInclude.Include.NON_NULL
> defaultViewInclusion = true // include w/o view tag
> failOnUnknownProperties = false
> autoDetectGettersSetters = true
> autoDetectFields = false
> afterPropertiesSet()
> return object // error on this line; this.object is the
> PropertyExpression that is created by AsmClassGenerator
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GROOVY-8253) Groovy console fails to launch
[
https://issues.apache.org/jira/browse/GROOVY-8253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8253.
---
Resolution: Fixed
Assignee: John Wagenleitner
Fix Version/s: 2.6.0-alpha-1
3.0.0-alpha-1
Should be fixed by
https://github.com/apache/groovy/commit/35aba7c0cf710b1337935f266ac6e6e6bef82c92
> Groovy console fails to launch
> --
>
> Key: GROOVY-8253
> URL: https://issues.apache.org/jira/browse/GROOVY-8253
> Project: Groovy
> Issue Type: Bug
> Components: Groovy Console
>Affects Versions: 3.0.0-alpha-1
>Reporter: Daniel Sun
>Assignee: John Wagenleitner
> Fix For: 3.0.0-alpha-1, 2.6.0-alpha-1
>
>
> The issue can be reproduced by executing
> {{me.sunlan.groovyconsole.GroovyConsole#main}} at
> https://github.com/danielsun1106/groovyconsole
> *Fails to launch(groovy 3.0.0 snapshot)*
> https://github.com/danielsun1106/groovyconsole/releases/tag/0.0.1
> *Launch successfully(groovy 2.4.12)*
> https://github.com/danielsun1106/groovyconsole/releases/tag/0.0.2
> *Error messages:*
> {code:java}
> Exception in thread "main" groovy.lang.MissingMethodException: No signature
> of method: javax.swing.JMenu.setMnemonic() is applicable for argument types:
> (String) values: [F]
> Possible solutions: setMnemonic(char), setMnemonic(int), getMnemonic()
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:60)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:66)
> at
> org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:81)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:52)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:174)
> at
> groovy.ui.view.BasicMenuBar$_run_closure1.doCall(BasicMenuBar.groovy:26)
> at groovy.ui.view.BasicMenuBar$_run_closure1.doCall(BasicMenuBar.groovy)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:989)
> at groovy.lang.Closure.call(Closure.java:415)
> at groovy.lang.Closure.call(Closure.java:409)
> at
> groovy.util.FactoryBuilderSupport.dispatchNodeCall(FactoryBuilderSupport.java:889)
> at
> groovy.util.FactoryBuilderSupport.doInvokeMethod(FactoryBuilderSupport.java:781)
> at
> groovy.util.FactoryBuilderSupport.invokeMethod(FactoryBuilderSupport.java:501)
> at
> groovy.util.FactoryInterceptorMetaClass.invokeMethod(FactoryBuilderSupport.java:1312)
> at
> groovy.lang.GroovyObjectSupport.invokeMethod(GroovyObjectSupport.java:46)
> at groovy.lang.Script.invokeMethod(Script.java:80)
> at
> org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:75)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:52)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:166)
> at groovy.ui.view.BasicMenuBar.run(BasicMenuBar.groovy:25)
> at
> groovy.util.FactoryBuilderSupport.build(FactoryBuilderSupport.java:1171)
> at
> groovy.util.FactoryBuilderSupport.build(FactoryBuilderSupport.java:1154)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:384)
> at
>
[jira] [Commented] (GROOVY-8253) Groovy console fails to launch
[
https://issues.apache.org/jira/browse/GROOVY-8253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079273#comment-16079273
]
John Wagenleitner commented on GROOVY-8253:
---
Looks like after [commit
23e6093921e06|https://github.com/apache/groovy/commit/23e6093921e06fcd73dabe67ce5be549a6cd63f9]
the extension modules are not being written in the groovy-all jar. The
missing method should be added by the {{SwingGroovyMethods}} class.
{code:title=groovy-all-3.0.0-SNAPSHOT.jar:META-INF/services/ExtensionModule}
# This is a generated file, do not edit
moduleName=groovy-all
moduleVersion=3.0.0-SNAPSHOT
extensionClasses=
staticExtensionClasses=
{code}
> Groovy console fails to launch
> --
>
> Key: GROOVY-8253
> URL: https://issues.apache.org/jira/browse/GROOVY-8253
> Project: Groovy
> Issue Type: Bug
> Components: Groovy Console
>Affects Versions: 3.0.0-alpha-1
>Reporter: Daniel Sun
>
> The issue can be reproduced by executing
> {{me.sunlan.groovyconsole.GroovyConsole#main}} at
> https://github.com/danielsun1106/groovyconsole
> *Fails to launch(groovy 3.0.0 snapshot)*
> https://github.com/danielsun1106/groovyconsole/releases/tag/0.0.1
> *Launch successfully(groovy 2.4.12)*
> https://github.com/danielsun1106/groovyconsole/releases/tag/0.0.2
> *Error messages:*
> {code:java}
> Exception in thread "main" groovy.lang.MissingMethodException: No signature
> of method: javax.swing.JMenu.setMnemonic() is applicable for argument types:
> (String) values: [F]
> Possible solutions: setMnemonic(char), setMnemonic(int), getMnemonic()
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:60)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:66)
> at
> org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:81)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:52)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:174)
> at
> groovy.ui.view.BasicMenuBar$_run_closure1.doCall(BasicMenuBar.groovy:26)
> at groovy.ui.view.BasicMenuBar$_run_closure1.doCall(BasicMenuBar.groovy)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:989)
> at groovy.lang.Closure.call(Closure.java:415)
> at groovy.lang.Closure.call(Closure.java:409)
> at
> groovy.util.FactoryBuilderSupport.dispatchNodeCall(FactoryBuilderSupport.java:889)
> at
> groovy.util.FactoryBuilderSupport.doInvokeMethod(FactoryBuilderSupport.java:781)
> at
> groovy.util.FactoryBuilderSupport.invokeMethod(FactoryBuilderSupport.java:501)
> at
> groovy.util.FactoryInterceptorMetaClass.invokeMethod(FactoryBuilderSupport.java:1312)
> at
> groovy.lang.GroovyObjectSupport.invokeMethod(GroovyObjectSupport.java:46)
> at groovy.lang.Script.invokeMethod(Script.java:80)
> at
> org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:75)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:52)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:166)
> at groovy.ui.view.BasicMenuBar.run(BasicMenuBar.groovy:25)
> at
> groovy.util.FactoryBuilderSupport.build(FactoryBuilderSupport.java:1171)
> at
> groovy.util.FactoryBuilderSupport.build(FactoryBuilderSupport.java:1154)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at
>
[jira] [Commented] (GROOVY-8251) Implement withCloseable on AutoCloseable
[
https://issues.apache.org/jira/browse/GROOVY-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077004#comment-16077004
]
John Wagenleitner commented on GROOVY-8251:
---
My initial thought was sort of the same, just add a
{{withCloseable(AutoCloseable..) throws Exception}} method. I don't think
there is any limitation, other than the old {{withCloseable(Closeable..) throws
IOException}} method would probably need to be kept for binary compatibility.
The {{throws}} clause of the old method would probably need to change but don't
think that is a problem.
There may be some confusion with the name {{withCloseable}} taking either a
{{Closeable}} or {{AutoCloseable}}, given that {{AutoCloseable}} is the more
general type. But I like the concise name {{withCloseable}} more.
> Implement withCloseable on AutoCloseable
>
>
> Key: GROOVY-8251
> URL: https://issues.apache.org/jira/browse/GROOVY-8251
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Affects Versions: 2.5.0-beta-1
>Reporter: Henri Tremblay
>
> The Groovy implementation of try-with-resource is through
> {{withCloseable()}}. The problem is that {{withCloseable}} only exists for
> classes implementing the {{Closeable}} interface.
> But a try-with-resource works with the {{AutoCloseable}} interface. So
> {{withCloseable}} should probably be moved on step below to {{AutoCloseable}}
> (that {{Closeable}} extends).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (GROOVY-8251) Implement withCloseable on AutoCloseable
[
https://issues.apache.org/jira/browse/GROOVY-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16076827#comment-16076827
]
John Wagenleitner edited comment on GROOVY-8251 at 7/6/17 4:30 PM:
---
Looks like GROOVY-7572 added a {{withAutoCloseable}} method in the NIO
submodule and it's in 2.5. Since 2.5 is Java 7+ it may make more sense to move
the new method into core rather than NIO.
was (Author: jwagenleitner):
Looks like GROOVY-7572 added a {{withAutoCloseable}} method in the NIO
submodule and it's in 2.5. I don't know if there was a reason for the
different name, but I think it would make more sense to allow {{withCloseable}}
to take either a {{Closeable}} or {{AutoCloseable}}. I think to keep binary
compatibility a new {{withCloseable}} method would have to be added and not
changing the signature of the existing method. Since 2.5 is not out yet (still
in beta), depending on how others feel, I wonder if there's still time to make
a change.
> Implement withCloseable on AutoCloseable
>
>
> Key: GROOVY-8251
> URL: https://issues.apache.org/jira/browse/GROOVY-8251
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Affects Versions: 2.5.0-beta-1
>Reporter: Henri Tremblay
>
> The Groovy implementation of try-with-resource is through
> {{withCloseable()}}. The problem is that {{withCloseable}} only exists for
> classes implementing the {{Closeable}} interface.
> But a try-with-resource works with the {{AutoCloseable}} interface. So
> {{withCloseable}} should probably be moved on step below to {{AutoCloseable}}
> (that {{Closeable}} extends).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8251) Implement withCloseable on AutoCloseable
[
https://issues.apache.org/jira/browse/GROOVY-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16076827#comment-16076827
]
John Wagenleitner commented on GROOVY-8251:
---
Looks like GROOVY-7572 added a {{withAutoCloseable}} method in the NIO
submodule and it's in 2.5. I don't know if there was a reason for the
different name, but I think it would make more sense to allow {{withCloseable}}
to take either a {{Closeable}} or {{AutoCloseable}}. I think to keep binary
compatibility a new {{withCloseable}} method would have to be added and not
changing the signature of the existing method. Since 2.5 is not out yet (still
in beta), depending on how others feel, I wonder if there's still time to make
a change.
> Implement withCloseable on AutoCloseable
>
>
> Key: GROOVY-8251
> URL: https://issues.apache.org/jira/browse/GROOVY-8251
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Affects Versions: 2.5.0-beta-1
>Reporter: Henri Tremblay
>
> The Groovy implementation of try-with-resource is through
> {{withCloseable()}}. The problem is that {{withCloseable}} only exists for
> classes implementing the {{Closeable}} interface.
> But a try-with-resource works with the {{AutoCloseable}} interface. So
> {{withCloseable}} should probably be moved on step below to {{AutoCloseable}}
> (that {{Closeable}} extends).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GROOVY-8240) Compilation error in @CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8240.
---
Resolution: Fixed
Assignee: John Wagenleitner
Fix Version/s: 2.4.13
Thanks for reporting the issue and for the PR.
> Compilation error in @CompileStatic
> ---
>
> Key: GROOVY-8240
> URL: https://issues.apache.org/jira/browse/GROOVY-8240
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.5.0-alpha-1, 2.4.12
>Reporter: Alexey Afanasiev
>Assignee: John Wagenleitner
> Fix For: 2.4.13
>
>
> This should be compiled and executed normally
> {code:java}
> import groovy.transform.CompileStatic
> class Bar {
> void vararg(boolean flag = true, Class... classes) {}
> }
> @CompileStatic
> class Foo extends Bar{
> def test() {
> vararg(false, Foo)
> }
> }
> new Foo().test()
> {code}
> But the result of compilation is
> *[Static type checking] - Cannot call Foo#vararg(java.lang.Class
> []) with arguments [boolean, java.lang.Class ]*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (GROOVY-8240) Compilation error in @CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner updated GROOVY-8240:
--
Affects Version/s: 2.4.12
> Compilation error in @CompileStatic
> ---
>
> Key: GROOVY-8240
> URL: https://issues.apache.org/jira/browse/GROOVY-8240
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.5.0-alpha-1, 2.4.12
>Reporter: Alexey Afanasiev
>
> This should be compiled and executed normally
> {code:java}
> import groovy.transform.CompileStatic
> class Bar {
> void vararg(boolean flag = true, Class... classes) {}
> }
> @CompileStatic
> class Foo extends Bar{
> def test() {
> vararg(false, Foo)
> }
> }
> new Foo().test()
> {code}
> But the result of compilation is
> *[Static type checking] - Cannot call Foo#vararg(java.lang.Class
> []) with arguments [boolean, java.lang.Class ]*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8242) Javadoc for Newify is missing some attribute values
[
https://issues.apache.org/jira/browse/GROOVY-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16074068#comment-16074068
]
John Wagenleitner commented on GROOVY-8242:
---
As part of the PR for GROOVY-8245 I added a default for the {{value}} attribute.
> Javadoc for Newify is missing some attribute values
> ---
>
> Key: GROOVY-8242
> URL: https://issues.apache.org/jira/browse/GROOVY-8242
> Project: Groovy
> Issue Type: Bug
>Reporter: Eric Milles
>Priority: Minor
>
> I was looking at thw Newify AST transform. Some of the Javadoc appears
> incorrect since the annotation requires a value.
> {code}
> * or this ("Ruby-style"):
> *
> * {@code @Newify} class MyTreeProcessor { -- Is this supposed to be
> @Newify([Tree,Leaf])?
> * def myTree = Tree.new(Tree.new(Leaf.new("A"), Leaf.new("B")),
> Leaf.new("C"))
> * def process() { ... }
> * }
> *
> {code}
> {code}
> * An example showing how to use the annotation at different levels:
> *
> * {@code @Newify(auto=false, value=Foo)}
> * class Main {
> * {@code @Newify} // turn auto on for field -- Is this supposed to be
> @Newify(BigInteger)?
> * def field1 = java.math.BigInteger.new(42)
> * def field2, field3, field4
> *
> * {@code @Newify(Bar)}
> * def process() {
> * field2 = Bar("my bar")
> * }
> *
> * {@code @Newify(Baz)}
> * Main() {
> * field3 = Foo("my foo")
> * field4 = Baz("my baz")
> * }
> * }
> *
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8242) Javadoc for Newify is missing some attribute values
[
https://issues.apache.org/jira/browse/GROOVY-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16073882#comment-16073882
]
John Wagenleitner commented on GROOVY-8242:
---
Based on the docs and tests, I believe it's clear that the intent of {{Newify}}
is to allow the annotation without providing class values. Assuming that's
true then this issue should be about providing a default for that attribute in
order to avoid warnings.
> Javadoc for Newify is missing some attribute values
> ---
>
> Key: GROOVY-8242
> URL: https://issues.apache.org/jira/browse/GROOVY-8242
> Project: Groovy
> Issue Type: Bug
>Reporter: Eric Milles
>Priority: Minor
>
> I was looking at thw Newify AST transform. Some of the Javadoc appears
> incorrect since the annotation requires a value.
> {code}
> * or this ("Ruby-style"):
> *
> * {@code @Newify} class MyTreeProcessor { -- Is this supposed to be
> @Newify([Tree,Leaf])?
> * def myTree = Tree.new(Tree.new(Leaf.new("A"), Leaf.new("B")),
> Leaf.new("C"))
> * def process() { ... }
> * }
> *
> {code}
> {code}
> * An example showing how to use the annotation at different levels:
> *
> * {@code @Newify(auto=false, value=Foo)}
> * class Main {
> * {@code @Newify} // turn auto on for field -- Is this supposed to be
> @Newify(BigInteger)?
> * def field1 = java.math.BigInteger.new(42)
> * def field2, field3, field4
> *
> * {@code @Newify(Bar)}
> * def process() {
> * field2 = Bar("my bar")
> * }
> *
> * {@code @Newify(Baz)}
> * Main() {
> * field3 = Foo("my foo")
> * field4 = Baz("my baz")
> * }
> * }
> *
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8242) Javadoc for Newify is missing some attribute values
[
https://issues.apache.org/jira/browse/GROOVY-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16071780#comment-16071780
]
John Wagenleitner commented on GROOVY-8242:
---
I believe the javadoc code is valid. You can omit providing a value if using
the Ruby style, {{Integer.new(7)}}, unless {{auto=false}} is set. The value is
required when using the Python style, {{Integer(7)}} as noted in this line from
the javadoc:
{quote}The "Python-style" conversions require you to specify each class on
which you want them to apply.{quote}
> Javadoc for Newify is missing some attribute values
> ---
>
> Key: GROOVY-8242
> URL: https://issues.apache.org/jira/browse/GROOVY-8242
> Project: Groovy
> Issue Type: Bug
>Reporter: Eric Milles
>Priority: Minor
>
> I was looking at thw Newify AST transform. Some of the Javadoc appears
> incorrect since the annotation requires a value.
> {code}
> * or this ("Ruby-style"):
> *
> * {@code @Newify} class MyTreeProcessor { -- Is this supposed to be
> @Newify([Tree,Leaf])?
> * def myTree = Tree.new(Tree.new(Leaf.new("A"), Leaf.new("B")),
> Leaf.new("C"))
> * def process() { ... }
> * }
> *
> {code}
> {code}
> * An example showing how to use the annotation at different levels:
> *
> * {@code @Newify(auto=false, value=Foo)}
> * class Main {
> * {@code @Newify} // turn auto on for field -- Is this supposed to be
> @Newify(BigInteger)?
> * def field1 = java.math.BigInteger.new(42)
> * def field2, field3, field4
> *
> * {@code @Newify(Bar)}
> * def process() {
> * field2 = Bar("my bar")
> * }
> *
> * {@code @Newify(Baz)}
> * Main() {
> * field3 = Foo("my foo")
> * field4 = Baz("my baz")
> * }
> * }
> *
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (GROOVY-4018) Make the Groovy truth value of NaN be false
[
https://issues.apache.org/jira/browse/GROOVY-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner updated GROOVY-4018:
--
Labels: breaking (was: )
> Make the Groovy truth value of NaN be false
> ---
>
> Key: GROOVY-4018
> URL: https://issues.apache.org/jira/browse/GROOVY-4018
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Reporter: Steve Tekell
> Labels: breaking
> Fix For: 3.x
>
>
> Similar to null and empty-string, have Groovy evaluate NaN as false rather
> than true.
> {noformat}
> def result = a?.b?.calcX(...)
> if (result) {
> // now I have a valid non-null number
> }
> {noformat}
> This is how JavaScript treats NaN and like other Groovy design choices, it
> just makes sense.
> Discussed in this thread
> http://old.nabble.com/Shouldn't-the-Groovy-truth-value-of-NaN-be-false--tt27348256.html
> That is, if NaN was false the following should work:
> assert !(Double.NaN)
> assert !((Double.NaN as Boolean) == true)
> assert ((Double.NaN as Boolean) == false)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (GROOVY-4018) Make the Groovy truth value of NaN be false
[
https://issues.apache.org/jira/browse/GROOVY-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner updated GROOVY-4018:
--
Fix Version/s: 3.x
> Make the Groovy truth value of NaN be false
> ---
>
> Key: GROOVY-4018
> URL: https://issues.apache.org/jira/browse/GROOVY-4018
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Reporter: Steve Tekell
> Labels: breaking
> Fix For: 3.x
>
>
> Similar to null and empty-string, have Groovy evaluate NaN as false rather
> than true.
> {noformat}
> def result = a?.b?.calcX(...)
> if (result) {
> // now I have a valid non-null number
> }
> {noformat}
> This is how JavaScript treats NaN and like other Groovy design choices, it
> just makes sense.
> Discussed in this thread
> http://old.nabble.com/Shouldn't-the-Groovy-truth-value-of-NaN-be-false--tt27348256.html
> That is, if NaN was false the following should work:
> assert !(Double.NaN)
> assert !((Double.NaN as Boolean) == true)
> assert ((Double.NaN as Boolean) == false)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GROOVY-8197) Make JUnit3/4 GroovyRunners
[
https://issues.apache.org/jira/browse/GROOVY-8197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-8197.
---
Resolution: Fixed
Assignee: John Wagenleitner
Fix Version/s: 2.5.0-beta-2
> Make JUnit3/4 GroovyRunners
> ---
>
> Key: GROOVY-8197
> URL: https://issues.apache.org/jira/browse/GROOVY-8197
> Project: Groovy
> Issue Type: Brainstorming
> Components: groovy-runtime
>Affects Versions: 2.5.0-alpha-1, 2.4.11
>Reporter: John Wagenleitner
>Assignee: John Wagenleitner
>Priority: Minor
> Fix For: 2.5.0-beta-2
>
>
> Current {{GroovyShell}} currently has reflective methods to detect and run
> JUnit3 and JUnit4 classes. These methods might work god as {{GroovyRunner}}
> classes and they could be added to the RUNNER_REGISTRY in {{GroovySystem}}.
> Runners should be able to be registered during class loading (like most other
> things) rather than during Grape processing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GROOVY-8042) groovyConsole gets confused with a slashy string with an escaped forward slash
[ https://issues.apache.org/jira/browse/GROOVY-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Wagenleitner resolved GROOVY-8042. --- Resolution: Fixed Assignee: John Wagenleitner Fix Version/s: 2.4.13 Thanks for reporting the issue. > groovyConsole gets confused with a slashy string with an escaped forward slash > -- > > Key: GROOVY-8042 > URL: https://issues.apache.org/jira/browse/GROOVY-8042 > Project: Groovy > Issue Type: Bug > Components: Groovy Console >Affects Versions: 2.4.7 >Reporter: David M. Karr >Assignee: John Wagenleitner >Priority: Minor > Fix For: 2.4.13 > > > If I paste or enter the following into groovyConsole: > -- > def escapeSlash = /The character \/ is a forward slash/ > -- > What it displays is a little confusing. It renders in yellow starting at the > first forward slash. The intention is that this would show the entire > expression, including the terminating forward slash, in yellow. > What it actually does is terminate the "yellow" at the second forward slash, > which is escaped. > Fortunately, the expression does execute successfully, but the display makes > it seem to the user that there is a syntax error with the expression. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GROOVY-8220) GroovyCastException with CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner updated GROOVY-8220:
--
Affects Version/s: 2.4.12
> GroovyCastException with CompileStatic
> --
>
> Key: GROOVY-8220
> URL: https://issues.apache.org/jira/browse/GROOVY-8220
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.0-beta-1, 2.4.12
>Reporter: paolo di tommaso
>
> {code}
> @groovy.transform.CompileStatic
> class Foo {
> CharSequence makeEnv( env, StringBuilder result = new StringBuilder() ) {
> if( env instanceof File ) {
> env = env.toPath()
> }
> if( env instanceof String && env.contains('=') ) {
> result << 'export ' << env << ';'
> }
> return result.toString()
> }
> }
> assert new Foo().makeEnv('X=1') == 'export X=1;'
> Exception thrown
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object 'X=1' with class 'java.lang.String' to class 'java.lang.Iterable'
> at Foo.makeEnv(ConsoleScript5:10)
> at Foo.makeEnv(ConsoleScript5:4)
> at Foo$makeEnv.call(Unknown Source)
> at ConsoleScript5.run(ConsoleScript5:20)
> {code}
> Without CompileStatic it works as expected.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8220) GroovyCastException with CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062400#comment-16062400
]
John Wagenleitner commented on GROOVY-8220:
---
Fix for GROOVY-8157 seems to be the cause.
> GroovyCastException with CompileStatic
> --
>
> Key: GROOVY-8220
> URL: https://issues.apache.org/jira/browse/GROOVY-8220
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.0-beta-1
>Reporter: paolo di tommaso
>
> {code}
> @groovy.transform.CompileStatic
> class Foo {
> CharSequence makeEnv( env, StringBuilder result = new StringBuilder() ) {
> if( env instanceof File ) {
> env = env.toPath()
> }
> if( env instanceof String && env.contains('=') ) {
> result << 'export ' << env << ';'
> }
> return result.toString()
> }
> }
> assert new Foo().makeEnv('X=1') == 'export X=1;'
> Exception thrown
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object 'X=1' with class 'java.lang.String' to class 'java.lang.Iterable'
> at Foo.makeEnv(ConsoleScript5:10)
> at Foo.makeEnv(ConsoleScript5:4)
> at Foo$makeEnv.call(Unknown Source)
> at ConsoleScript5.run(ConsoleScript5:20)
> {code}
> Without CompileStatic it works as expected.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8237) Invalid type inference when using CompileStatic annotation
[
https://issues.apache.org/jira/browse/GROOVY-8237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062397#comment-16062397
]
John Wagenleitner commented on GROOVY-8237:
---
I tested and it looks like the fix for GROOVY-8157 causes this.
> Invalid type inference when using CompileStatic annotation
> --
>
> Key: GROOVY-8237
> URL: https://issues.apache.org/jira/browse/GROOVY-8237
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.12
>Reporter: paolo di tommaso
>
> With Groovy 2.4.12 the following snippet report an error
> {code}
> @groovy.transform.CompileStatic
> class Foo {
> String parse(Reader reader) {
> if ( reader == null ) {
> reader = new BufferedReader(reader)
> }
>
> def c
> while ((c = reader.read()) != -1)
>print c as char
> }
> }
> new Foo().parse( new StringReader('abc') )
> {code}
> The following exception is thrown
> {code}
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object 'java.io.StringReader@7a636960' with class 'java.io.StringReader' to
> class 'java.io.BufferedReader'
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-8139) GroovyScriptEngineImpl may not be thread safe
[
https://issues.apache.org/jira/browse/GROOVY-8139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062140#comment-16062140
]
John Wagenleitner commented on GROOVY-8139:
---
Since functions are global and described as:
{quote}top-level procedures and functions defined in scripts{quote}
The way this is working seems appropriate to me. I am not very knowledgeable
with JSR223, but the way I read it I would equate {{invokeFunction}} as if its
state were static and not associated with any object state. So in the case of
multiple threads creating the functions in the end only one state can be set
for {{ans}}.
To have per-thread context it seems like it would be appropriate to use
{{invokeMethod}} from an object returned from {{eval}} or to change the method
(function) to accept arguments for all state it requires that differs per
thread.
> GroovyScriptEngineImpl may not be thread safe
> -
>
> Key: GROOVY-8139
> URL: https://issues.apache.org/jira/browse/GROOVY-8139
> Project: Groovy
> Issue Type: Bug
> Components: GroovyScriptEngine
>Affects Versions: 2.4.10
>Reporter: Laurent Droin
>Priority: Minor
> Labels: GroovyScriptEngineImpl, invokeFunction, multithread,
> thread, threadsafe
> Attachments: InvokeFunctionTest.java
>
>
> I am wondering if I can safely share an instance of GroovyScriptEngineImpl
> across threads when each thread has a different Bindings AND i need to use
> InvokeFunction.
> I believe I need to call the eval method on the engine in every thread so as
> to establish the new context containing thread-specific Bindings. During the
> call to Eval, the functions in my script are turned into some 'method
> closure' objects containing (between other things) the thread-specific
> Bindings. However, those 'method closure' are kept in a map that is global to
> the script engine (this map is called 'globalClosures').
> I think that the "method closure" is added to the map twice, once for each
> thread, under the same key (the name of the function) and whatever thread
> updates the map last is the one that imposes its Bindings to the function.
> When later, the function is invoked in each thread, the same Bindings is used.
> I have attached a small sample of code demonstrating the issue.
> The output is sometimes:
> The task that should return 42 returned : 43
> The task that should return 43 returned : 43
> and sometimes:
> The task that should return 42 returned : 42
> The task that should return 43 returned : 42
> depending on what thread updates the globalClosures last.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GROOVY-8230) Deadlock in GroovyClassLoader
[ https://issues.apache.org/jira/browse/GROOVY-8230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Wagenleitner resolved GROOVY-8230. --- Resolution: Fixed Assignee: John Wagenleitner Fix Version/s: 2.5.0-beta-2 Thanks for reporting the issue. > Deadlock in GroovyClassLoader > - > > Key: GROOVY-8230 > URL: https://issues.apache.org/jira/browse/GROOVY-8230 > Project: Groovy > Issue Type: Bug >Affects Versions: 2.5.0-beta-1 >Reporter: Joel Bredeson >Assignee: John Wagenleitner > Fix For: 2.5.0-beta-2 > > Attachments: GroovyClassLoaderDeadlock.txt > > > The GroovyClassLoader.clearCache() method can deadlock when another thread is > creating a new instance of a class. The clearCache() method locks the > classCache, then when removing the class, through the InvokerHelper, locks > the ClassInfo object. When a new instance is created that instance can lock > the ClassInfo object first, then later request the lock for the classCache > (This happens when requesting the entry getClassCacheEntry). If the timing > between the two threads is unlucky a deadlock can occur. > Relevant stack trace attached. > Groovy: 2.4.10 groovy-all-2.4.10-indy.jar > Java: JRE 8u73_64 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GROOVY-8227) Allow to specify Groovysh (and GroovyShell) class loader different from TCCL
[
https://issues.apache.org/jira/browse/GROOVY-8227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062045#comment-16062045
]
John Wagenleitner commented on GROOVY-8227:
---
Looks like the issue with the {{VisitorClassLoader}} was addressed for
GROOVY-7562 in [commit
6b80966a4e|https://github.com/apache/groovy/commit/6b80966a4e50b0e24b86832eaa01be96d2dded3d]
which is in 2.5 beta.
> Allow to specify Groovysh (and GroovyShell) class loader different from TCCL
>
>
> Key: GROOVY-8227
> URL: https://issues.apache.org/jira/browse/GROOVY-8227
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime, Groovysh
>Affects Versions: 2.4.x, 2.5.x
> Environment: OSGi (Karaf 2.x, 3.X or 4.x)
>Reporter: Denis Jouvin
> Labels: classloader, groovysh, groovyshell
> Fix For: 2.4.x, 2.5.x
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> Allthough the Groovy API seem to allow one to specify the class loader when
> instanciating a Groovysh or GroovyShell, internally in some places Groovy
> will silently use the TCCL (thread context class loader) and there is no way
> to avoid that without hacking Groovy and chasing all the places where
> {{getThreadContextClassLoader()}} is used.
> This is problematic, especially in OSGi environement, since the TCCL is not
> compatible with OSGi principles (i.e. every bundle has its own class loader),
> and also with some modern modular containers similar to OSGi. When a class
> loader is specified in the GroovyShell or Groovysh creation, Groovy should
> propagate that class loader correctly (or instanciate children class loader
> of that specified class loader), and in no way use the TCCL.
> This may be a dupplicate of [Groovy
> 4895|https://issues.apache.org/jira/browse/GROOVY-4895]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-5227) AbstractHttpServlet should extend GenericServlet directly instead of HttpServlet
[
https://issues.apache.org/jira/browse/GROOVY-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16058363#comment-16058363
]
John Wagenleitner commented on GROOVY-5227:
---
I agree that {{AbstractHttpServlet}} should continue to extend from
{{HttpServlet}}. The class is public and looks to be designed to be extended,
so changing it to {{GenericServlet}} would break others code.
Whereas {{AbstractHttpServlet}} is designed to be extended, its implementing
classes {{GroovyServlet}} and {{TemplateServlet}} do not appear to be. Because
of this I like suggestion 2, adding a documentation note.
> AbstractHttpServlet should extend GenericServlet directly instead of
> HttpServlet
>
>
> Key: GROOVY-5227
> URL: https://issues.apache.org/jira/browse/GROOVY-5227
> Project: Groovy
> Issue Type: Improvement
> Components: Groovlet / GSP
>Affects Versions: 1.7.5
>Reporter: Benjamin Gandon
>Priority: Trivial
>
> The {{groovy.servlet.AbstractHttpServlet}} class overrides the
> {{service(HttpServletRequest, HttpServletResponse)}} method.
> Thus all the circuitry implemented in the {{javax.servlet.http.HttpServlet}}
> superclass is bypassed altogether, except the trivial
> {{service(ServletRequest, ServletResponse)}} method which only provides a
> convenient call to {{service(HttpServletRequest, HttpServletResponse)}},
> narrowing the request and response types to HTTP-dedicated subclasses.
> None of the doGet, getLastModified, doHead, doPost, doPut, doDelete,
> doOption, doTrace, is ever called. Are they relevant to any
> {{AbstractHttpServlet}} subclasses? I doubt so. The programming model of
> {{GroovyServlet}} currently implies re-implementing in Groovlets the way
> these HTTP methods should be answered.
> Then it might be a possible optimization to have {{AbstractHttpServlet}}
> extend {{GenericServlet}} directly, re-implementing in
> {{AbstractHttpServlet}} the trivial {{service(ServletRequest,
> ServletResponse)}} method of {{HttpServlet}}. This could prevent the
> unnecessary loading of the {{HttpServlet}} class in memory.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (GROOVY-8217) java.lang.ClassNotFoundException: java$lang$Enum
[ https://issues.apache.org/jira/browse/GROOVY-8217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Wagenleitner closed GROOVY-8217. - Resolution: Duplicate Assignee: John Wagenleitner Thanks for testing and reporting back. > java.lang.ClassNotFoundException: java$lang$Enum > > > Key: GROOVY-8217 > URL: https://issues.apache.org/jira/browse/GROOVY-8217 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 2.4.8 >Reporter: Radoslav Ivanov >Assignee: John Wagenleitner >Priority: Critical > > Hi guys > It looks like we are hitting pretty rare but severe problem [2]. Note that > restart fixed the problem as it was also suggested here [1]. > Regards > Rado > Details > 1. > https://stackoverflow.com/questions/40854472/java-lang-classnotfoundexception-java-langenum-in-jenkins-2-0-while-executing > 2. Caused by: java.lang.TypeNotPresentException: Type java$lang$Enum not > present > at > sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactory.java:117) > [rt.jar:1.8.0_112] > at > sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:125) > [rt.jar:1.8.0_112] > at > sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:49) > [rt.jar:1.8.0_112] > at > sun.reflect.generics.repository.ClassRepository.getSuperclass(ClassRepository.java:90) > [rt.jar:1.8.0_112] > at java.lang.Class.getGenericSuperclass(Class.java:777) > [rt.jar:1.8.0_112] > at > com.sun.beans.finder.MethodFinder.findAccessibleMethod(MethodFinder.java:151) > [rt.jar:1.8.0_112] > at > java.beans.Introspector.getPublicDeclaredMethods(Introspector.java:1344) > [rt.jar:1.8.0_112] > at java.beans.Introspector.getTargetMethodInfo(Introspector.java:1197) > [rt.jar:1.8.0_112] > at java.beans.Introspector.getBeanInfo(Introspector.java:426) > [rt.jar:1.8.0_112] > at java.beans.Introspector.getBeanInfo(Introspector.java:173) > [rt.jar:1.8.0_112] > at groovy.lang.MetaClassImpl$15.run(MetaClassImpl.java:3313) > [groovy-2.4.8.jar:2.4.8] > at java.security.AccessController.doPrivileged(Native Method) > [rt.jar:1.8.0_112] > at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:3311) > [groovy-2.4.8.jar:2.4.8] > at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:3288) > [groovy-2.4.8.jar:2.4.8] > at > org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:271) > [groovy-2.4.8.jar:2.4.8] > at > org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:313) > [groovy-2.4.8.jar:2.4.8] > at > org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.getMetaClass(MetaClassRegistryImpl.java:258) > [groovy-2.4.8.jar:2.4.8] > at > org.codehaus.groovy.runtime.ScriptBytecodeAdapter.selectConstructorAndTransformArguments(ScriptBytecodeAdapter.java:236) > [groovy-2.4.8.jar:2.4.8] > ... 11 more > Caused by: java.lang.ClassNotFoundException: java$lang$Enum > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > [rt.jar:1.8.0_112] > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > [rt.jar:1.8.0_112] > at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:677) > [groovy-2.4.8.jar:2.4.8] > at > groovy.lang.GroovyClassLoader$InnerLoader.loadClass(GroovyClassLoader.java:425) > [groovy-2.4.8.jar:2.4.8] > at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:787) > [groovy-2.4.8.jar:2.4.8] > at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:775) > [groovy-2.4.8.jar:2.4.8] > at java.lang.Class.forName0(Native Method) [rt.jar:1.8.0_112] > at java.lang.Class.forName(Class.java:348) [rt.jar:1.8.0_112] > at > sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactory.java:114) > [rt.jar:1.8.0_112] > ... 30 more -- This message was sent by Atlassian JIRA (v6.4.14#64029)
