[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&focusedCommentId=16516716#comment-16516716 ] Alexander Veit commented on GROOVY-8649: Thank you John, your suggested workaround seems to work. However, I doubt that it is a good idea to turn on {{asmResolving}} by default. Classes in a JVM are supposed to be loaded by a class loader in a reasonable hierarchy. If Groovy deviates from this rule it will probably break all sorts of things like object equality, {{instanceof}} checks, security mechanisms etc.. Especially in Java applications that use Groovy as an embedded language. > 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] [Commented] (GROOVY-8637) @NamedVariant processing error
[ https://issues.apache.org/jira/browse/GROOVY-8637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16516663#comment-16516663 ] ASF GitHub Bot commented on GROOVY-8637: Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/758 > @NamedVariant processing error > -- > > Key: GROOVY-8637 > URL: https://issues.apache.org/jira/browse/GROOVY-8637 > Project: Groovy > Issue Type: Bug > Components: Compiler >Reporter: Alexey Afanasiev >Priority: Critical > > Example about @NamedVariant from > http://groovy-lang.org/releasenotes/groovy-2.5.html works perfectly well as > far as all @NamedDelegate type are compiling in the same compilation unit. > {code:java} > class Animal { > String type, name > } > @ToString(includeNames=true) > class Color { > Integer r, g, b > } > @NamedVariant > String foo(String s1, @NamedParam String s2, >@NamedDelegate Color shade, >@NamedDelegate Animal pet) { > "$s1 $s2 ${pet.type?.toUpperCase()}:$pet.name $shade" > } > {code} > But let's modify this example. If you have Animal an Color classes compiled > beforehand and passed to the compiler with classpath, you will receive 'Error > during @NamedVariant processing. Duplicate property 'metaClass' found.' > NamedVariantASTTransformation treats 'setMetaClass' method as set method of > some property with ''metaClass' name. Obviously these names are clashed at > compile time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] groovy pull request #758: GROOVY-8637: @NamedVariant processing error
Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/758 ---
[jira] [Commented] (GROOVY-8627) Compile error using NamedParam with value
[ https://issues.apache.org/jira/browse/GROOVY-8627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16516655#comment-16516655 ] ASF GitHub Bot commented on GROOVY-8627: Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/759 > Compile error using NamedParam with value > - > > Key: GROOVY-8627 > URL: https://issues.apache.org/jira/browse/GROOVY-8627 > Project: Groovy > Issue Type: Bug >Affects Versions: 2.5.0 >Reporter: Eric Milles >Priority: Major > > {{NamedVariantASTTransformation}} has bug checking for presence of {{value}} > member. > {code:java} > for (Parameter fromParam : fromParams) { > if (AnnotatedNodeUtils.hasAnnotation(fromParam, > NAMED_PARAM_TYPE)) { > AnnotationNode namedParam = > fromParam.getAnnotations(NAMED_PARAM_TYPE).get(0); > boolean required = memberHasValue(namedParam, "required", > true); > if (getMemberValue(namedParam, "name") == null) { > namedParam.addMember("value", > constX(fromParam.getName())); > } > String name = getMemberStringValue(namedParam, "value"); > {code} > Check here is for {{name}} and if not found, fill in {{value}} from name of > annotated param. There are 2 problems with this: > 1. {{NamedParam}} has no {{name}} member > 2. {{NamedParam}} indicates {{value}} as required (no default value provided > in declaration) > Example that produces error: > {code:groovy} > import groovy.transform.* > @ToString(includeNames=true) > class Color { > Integer r, g, b > } > @NamedVariant > String m(@NamedDelegate Color color, @NamedParam(value='a', required=true) > int alpha) { > return [color, alpha].join(' ') > } > print m(r:1, g:2, b:3, a: 0) > {code} > Compiling this script results in this error because the {{@NamedParam}} > annotation already has a {{value}} member when this line from the transform > is executed: {{namedParam.addMember("value", constX(fromParam.getName()));}}. > {code} > 1. ERROR in Script.groovy (at line 1)\r\n > import groovy.transform.*\r\n > ^\n > Groovy:Groovy compiler error: exception in phase 'semantic analysis' in > source unit 'Script.groovy' Annotation member value has already been added @ > line 1, column 0. > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] groovy pull request #759: GROOVY-8627: Compile error using NamedParam with v...
Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/759 ---
[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)
[GitHub] groovy pull request #756: GROOVY-8614: Invalid reference generated in InnerC...
Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/756 ---
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=16516475#comment-16516475 ] ASF GitHub Bot commented on GROOVY-8614: Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/756 > 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 >Priority: Minor > > 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-8224) Stubs for classes implementing traits with fields don't include getters/setters
[ https://issues.apache.org/jira/browse/GROOVY-8224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16516393#comment-16516393 ] Paul King commented on GROOVY-8224: --- This is a known short-coming of the stub approach we use. Stubs are generated early on so that the resulting Java classes can be made available when needed for resolving. TraitComposer runs slightly later. The same problem occurs for numerous AST transformations. In general, this is hard to solve without quite a bit of re-engineering work but on a case-by-case basis, some of the work that TraitComposer and indeed some other transforms could be done earlier for inclusion in the stubs. > Stubs for classes implementing traits with fields don't include > getters/setters > --- > > Key: GROOVY-8224 > URL: https://issues.apache.org/jira/browse/GROOVY-8224 > Project: Groovy > Issue Type: Bug > Components: Stub generator / Joint compiler >Reporter: Keegan Witt >Priority: Major > > As an example, the stubs generated for _GroovyXImpl_ for the Groovy below > doesn't include {{int getFoo()}} or {{void setFoo(int value)}}. > {code:java} > trait GroovyXTrait { > int foo > } > class GroovyXImpl implements GroovyXTrait { } > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GROOVY-8651) Method override weaker access check does not fully account for package-private visibility
Eric Milles created GROOVY-8651: --- Summary: Method override weaker access check does not fully account for package-private visibility Key: GROOVY-8651 URL: https://issues.apache.org/jira/browse/GROOVY-8651 Project: Groovy Issue Type: Bug Reporter: Eric Milles If override method is package-private (via {{PackageScope}}) and super method is public (or protected?), no error is produced. If protected is indeed more visible than package-private, there may be some additional cases uncovered below. org.codehaus.groovy.classgen.ClassCompletionVerifier: {code:java} private void checkMethodForWeakerAccessPrivileges(MethodNode mn, ClassNode cn) { if (mn.isPublic()) return; Parameter[] params = mn.getParameters(); for (MethodNode superMethod : cn.getSuperClass().getMethods(mn.getName())) { Parameter[] superParams = superMethod.getParameters(); if (!hasEqualParameterTypes(params, superParams)) continue; if ((mn.isPrivate() && !superMethod.isPrivate()) || (mn.isProtected() && superMethod.isPublic())) { addWeakerAccessError(cn, mn, params, superMethod); return; } } } {code} I think that this is the proper set of checks: {code:java} if ((mn.isPrivate() && !superMethod.isPrivate()) || (mn.isProtected() && !superMethod.isProtected() && !superMethod.isPrivate()) || (!mn.isPrivate() && !mn.isProtected() && !mn.isPublic() && (superMethod.isPublic() || superMethod.isProtected( { addWeakerAccessError(cn, mn, params, superMethod); ... // also the error message need some change to indicate default/package-private private void addWeakerAccessError(ClassNode cn, MethodNode method, Parameter[] parameters, MethodNode superMethod) { StringBuilder msg = new StringBuilder(); msg.append(method.getName()); appendParamsDescription(parameters, msg); msg.append(" in "); msg.append(cn.getName()); msg.append(" cannot override "); msg.append(superMethod.getName()); msg.append(" in "); msg.append(superMethod.getDeclaringClass().getName()); msg.append("; attempting to assign weaker access privileges; was "); // GRECLIPSE edit //msg.append(superMethod.isPublic() ? "public" : "protected"); msg.append(superMethod.isPublic() ? "public" : (superMethod.isProtected() ? "protected" : "package-private")); // GRECLIPSE end addError(msg.toString(), method); } {code} For these tests, 1b and 2a are failing: {code:java} @Test public void testOverriding_ReducedVisibility1() { runNegativeTest(new String[] { "Bar.groovy", "class Bar { public def baz() {} }\n", "Foo.groovy", "class Foo extends Bar { private def baz() {}\n }\n", }, "--\n" + "1. ERROR in Foo.groovy (at line 1)\n" + "\tclass Foo extends Bar { private def baz() {}\n" + "\t\n" + "Groovy:baz() in Foo cannot override baz in Bar; attempting to assign weaker access privileges; was public\n" + "--\n"); } @Test public void testOverriding_ReducedVisibility1a() { runNegativeTest(new String[] { "Bar.groovy", "class Bar { public def baz() {} }\n", "Foo.groovy", "class Foo extends Bar { protected def baz() {}\n }\n", }, "--\n" + "1. ERROR in Foo.groovy (at line 1)\n" + "\tclass Foo extends Bar { protected def baz() {}\n" + "\t^^\n" + "Groovy:baz() in Foo cannot override baz in Bar; attempting to assign weaker access privileges; was public\n" + "--\n"); } @Test public void testOverriding_ReducedVisibility1b() { runNegativeTest(new String[] { "Bar.groovy", "class Bar { public def baz() {} }\n", "Foo.groovy", "class Foo extends Bar { @groovy.transform.PackageScope def baz() {}\n }\n", }, "--\n" + "1. ERROR in Foo.groovy (at line 1)\n" + "\tclass Foo extends Bar { @groovy.transform.PackageScope def baz() {}\n" + "\t ^^^\n" + "Groovy:baz() in Foo cannot override baz in Bar; attempting to assign weaker access privileges; was public\n" + "--\n"); } @Test public void testOverriding_ReducedVisibility2() { runNegativeTest(new String[] { "Bar.groovy", "class Bar { protected def baz() {} }\n",
[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&focusedCommentId=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] [Commented] (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:comment-tabpanel&focusedCommentId=16516103#comment-16516103 ] ASF GitHub Bot commented on GROOVY-8008: Github user jwagenleitner commented on a diff in the pull request: https://github.com/apache/groovy/pull/757#discussion_r196172656 --- Diff: src/main/java/org/codehaus/groovy/vmplugin/v5/Java5.java --- @@ -405,6 +408,32 @@ public void configureClassNode(CompileUnit compileUnit, ClassNode classNode) { } } +/** + * Synthetic parameters such as those added for inner class constructors may not be + * included in the parameter annotations array. This is the case when at least one + * parameter of an inner class constructor is annotated with a RUNTIME retention + * policy. This method will normalize the annotation array so that it contains the + * same number of elements as the array returned from {@link Constructor#getParameterTypes()}. + * + * If adjustment is required, the adjusted array will be pre-pended will zero-length --- End diff -- Fixed, thanks. > @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 >Priority: Major > > 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.visitClas
[GitHub] groovy pull request #757: GROOVY-8008: AIOOB inner class ctor params with ru...
Github user jwagenleitner commented on a diff in the pull request: https://github.com/apache/groovy/pull/757#discussion_r196172656 --- Diff: src/main/java/org/codehaus/groovy/vmplugin/v5/Java5.java --- @@ -405,6 +408,32 @@ public void configureClassNode(CompileUnit compileUnit, ClassNode classNode) { } } +/** + * Synthetic parameters such as those added for inner class constructors may not be + * included in the parameter annotations array. This is the case when at least one + * parameter of an inner class constructor is annotated with a RUNTIME retention + * policy. This method will normalize the annotation array so that it contains the + * same number of elements as the array returned from {@link Constructor#getParameterTypes()}. + * + * If adjustment is required, the adjusted array will be pre-pended will zero-length --- End diff -- Fixed, thanks. ---
[jira] [Created] (GROOVY-8650) New line between prefix operator and operand
Daniil Ovchinnikov created GROOVY-8650: -- Summary: New line between prefix operator and operand Key: GROOVY-8650 URL: https://issues.apache.org/jira/browse/GROOVY-8650 Project: Groovy Issue Type: Bug Components: parser Affects Versions: 3.0.0-alpha-2 Reporter: Daniil Ovchinnikov The following code is parsed properly in previous versions, but fails in 3.0: {code:java} def c = -- 1 println c // 0{code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8627) Compile error using NamedParam with value
[ https://issues.apache.org/jira/browse/GROOVY-8627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16515959#comment-16515959 ] Eric Milles commented on GROOVY-8627: - Thanks for the patch. This {{NamedVariant}} stuff is very interesting and gives back some oomph to the case for named parameters. > Compile error using NamedParam with value > - > > Key: GROOVY-8627 > URL: https://issues.apache.org/jira/browse/GROOVY-8627 > Project: Groovy > Issue Type: Bug >Affects Versions: 2.5.0 >Reporter: Eric Milles >Priority: Major > > {{NamedVariantASTTransformation}} has bug checking for presence of {{value}} > member. > {code:java} > for (Parameter fromParam : fromParams) { > if (AnnotatedNodeUtils.hasAnnotation(fromParam, > NAMED_PARAM_TYPE)) { > AnnotationNode namedParam = > fromParam.getAnnotations(NAMED_PARAM_TYPE).get(0); > boolean required = memberHasValue(namedParam, "required", > true); > if (getMemberValue(namedParam, "name") == null) { > namedParam.addMember("value", > constX(fromParam.getName())); > } > String name = getMemberStringValue(namedParam, "value"); > {code} > Check here is for {{name}} and if not found, fill in {{value}} from name of > annotated param. There are 2 problems with this: > 1. {{NamedParam}} has no {{name}} member > 2. {{NamedParam}} indicates {{value}} as required (no default value provided > in declaration) > Example that produces error: > {code:groovy} > import groovy.transform.* > @ToString(includeNames=true) > class Color { > Integer r, g, b > } > @NamedVariant > String m(@NamedDelegate Color color, @NamedParam(value='a', required=true) > int alpha) { > return [color, alpha].join(' ') > } > print m(r:1, g:2, b:3, a: 0) > {code} > Compiling this script results in this error because the {{@NamedParam}} > annotation already has a {{value}} member when this line from the transform > is executed: {{namedParam.addMember("value", constX(fromParam.getName()));}}. > {code} > 1. ERROR in Script.groovy (at line 1)\r\n > import groovy.transform.*\r\n > ^\n > Groovy:Groovy compiler error: exception in phase 'semantic analysis' in > source unit 'Script.groovy' Annotation member value has already been added @ > line 1, column 0. > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8644) Groovy 2.5 binary JARs not available at Maven Central
[ https://issues.apache.org/jira/browse/GROOVY-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16515953#comment-16515953 ] Eric Milles commented on GROOVY-8644: - Is there a groovy-all.pom for the "indy" variants? We are using {{groovy-all-2.4.x-indy.jar}}. > Groovy 2.5 binary JARs not available at Maven Central > - > > Key: GROOVY-8644 > URL: https://issues.apache.org/jira/browse/GROOVY-8644 > Project: Groovy > Issue Type: Bug > Components: release >Affects Versions: 2.5.0 >Reporter: Alexander Veit >Priority: Critical > > See [http://central.maven.org/maven2/org/codehaus/groovy/groovy-all/2.5.0/] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GROOVY-8649) Class loading in Groovy 2.5 breaks class loading hierarchy
Alexander Veit created GROOVY-8649: -- Summary: 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 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)