[jira] [Updated] (GROOVY-10690) dump() method produces errors
[
https://issues.apache.org/jira/browse/GROOVY-10690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Veit updated GROOVY-10690:
Description:
Groovy GDK method {{dump()}} produces errors at least since Jave version 16.
Example:
{code:java}
println(new File("foo").dump())
{code}
produces
{noformat}
{noformat}
To me the best solution would be to respect Java's access modifiers.
was:
Groovy GDK method {{dump()}} produces errors at least since Jave version 16.
Example:
{code:java}
println(new File("foo").dump())
{code}
produces
{noformat}
{noformat}
To me the best solution would be to respect Java's access modifiers.
> dump() method produces errors
> -
>
> Key: GROOVY-10690
> URL: https://issues.apache.org/jira/browse/GROOVY-10690
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Affects Versions: 4.0.3
> Environment: java --version
> openjdk 17.0.3 2022-04-19
> OpenJDK Runtime Environment Temurin-17.0.3+7 (build 17.0.3+7)
> OpenJDK 64-Bit Server VM Temurin-17.0.3+7 (build 17.0.3+7, mixed mode,
> sharing)
>Reporter: Alexander Veit
>Priority: Major
>
> Groovy GDK method {{dump()}} produces errors at least since Jave version 16.
> Example:
> {code:java}
> println(new File("foo").dump())
> {code}
> produces
> {noformat}
> org.codehaus.groovy.runtime.DefaultGroovyMethods
> cannot access a member of class java.io.File (in module java.base) with
> modifiers "private final"
> status=java.lang.IllegalAccessException: class
> org.codehaus.groovy.runtime.DefaultGroovyMethods cannot access a
> member of class java.io.File (in module java.base) with modifiers "private
> transient" prefixLength=java.lang.IllegalAccessException:
> class org.codehaus.groovy.runtime.DefaultGroovyMethods cannot access a
> member of class java.io.File (in module java.base)
> with modifiers "private final transient"
> filePath=java.lang.IllegalAccessException: class
> org.codehaus.groovy.runtime.DefaultGroovyMethods
> cannot access a member of class java.io.File (in module java.base) with
> modifiers "private transient volatile">
> {noformat}
> To me the best solution would be to respect Java's access modifiers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GROOVY-10690) dump() method produces errors
Alexander Veit created GROOVY-10690:
---
Summary: dump() method produces errors
Key: GROOVY-10690
URL: https://issues.apache.org/jira/browse/GROOVY-10690
Project: Groovy
Issue Type: Bug
Components: groovy-jdk
Affects Versions: 4.0.3
Environment: java --version
openjdk 17.0.3 2022-04-19
OpenJDK Runtime Environment Temurin-17.0.3+7 (build 17.0.3+7)
OpenJDK 64-Bit Server VM Temurin-17.0.3+7 (build 17.0.3+7, mixed mode, sharing)
Reporter: Alexander Veit
Groovy GDK method {{dump()}} produces errors at least since Jave version 16.
Example:
{code:java}
println(new File("foo").dump())
{code}
produces
{noformat}
{noformat}
To me the best solution would be to respect Java's access modifiers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-10470) Update from Groovy 3 to 4.0.0 breaks existing code
[
https://issues.apache.org/jira/browse/GROOVY-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487190#comment-17487190
]
Alexander Veit commented on GROOVY-10470:
-
Sorry, I didn't see the information about changed default includes. But I agree
that the way you have shown is more preferable than implicitly importing
classes like AntBuilder in advance.
> Update from Groovy 3 to 4.0.0 breaks existing code
> --
>
> Key: GROOVY-10470
> URL: https://issues.apache.org/jira/browse/GROOVY-10470
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 4.0.0
>Reporter: Alexander Veit
>Priority: Major
>
> After updating from Groovy 3 to 4.0.0 scripts that use {{AntBuilder}} without
> an {{import}} statement no longer work.
> This is probably caused by missing default includes for {{groovy.ant.*}} or
> {{groovy.ant.AntBuilder}}.
> The same problem exists for {{XmlSlurper}} and {{XmlParser}}.
> Example: The script below works with Groovy 3.0.9 but not with 4.0.0.
> {code:java}
> new AntBuilder()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GROOVY-10214) Update from Groovy 3.0.8 to 3.0.9 breaks category class
[
https://issues.apache.org/jira/browse/GROOVY-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Veit updated GROOVY-10214:
Affects Version/s: 4.0.0
> Update from Groovy 3.0.8 to 3.0.9 breaks category class
> ---
>
> Key: GROOVY-10214
> URL: https://issues.apache.org/jira/browse/GROOVY-10214
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.9, 4.0.0
> Environment: java --version
> openjdk 16.0.2 2021-07-20
> OpenJDK Runtime Environment Temurin-16.0.2+7 (build 16.0.2+7)
> OpenJDK 64-Bit Server VM Temurin-16.0.2+7 (build 16.0.2+7, mixed mode,
> sharing)
>Reporter: Alexander Veit
>Priority: Major
>
> We have a category class as part of our product's Groovy API that breaks
> after the update from Groovy 3.0.8 (indy) to 3.0.9 (indy).
> Scripts that call the category class with Integer of Long arguments throw an
> exception. E.g.
> {code:java}
> use (org.example.Convert)
> {
> assert '1234' == 1234.canonicalLexicalRepresentation
> }
> {code}
> throws
> {noformat}
> java.lang.IllegalArgumentException: argument type mismatch
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at
> org.codehaus.groovy.runtime.metaclass.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:54)
> at
> org.codehaus.groovy.runtime.metaclass.NewInstanceMetaMethod.invoke(NewInstanceMetaMethod.java:54)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
> at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1956)
> at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3843)
> at
> org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:199)
> at
> org.codehaus.groovy.runtime.callsite.PojoMetaClassGetPropertySite.getProperty(PojoMetaClassGetPropertySite.java:36)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:329)
> at
> org.example.test.testInteger$_run_closure1.doCall(testInteger.groovy:5)
> at org.example.test.testInteger$_run_closure1.doCall(testInteger.groovy)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:274)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1035)
> at groovy.lang.Closure.call(Closure.java:412)
> at groovy.lang.Closure.call(Closure.java:406)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:123)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.access$300(GroovyCategorySupport.java:72)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:258)
> at
> org.codehaus.groovy.runtime.DefaultGroovyMethods.use(DefaultGroovyMethods.java:568)
> at org.codehaus.groovy.runtime.dgm$880.invoke(Unknown Source)
> at
> org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoMetaMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:226)
> at
> org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:61)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:51)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:171)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:194)
> at org.example.test.testInteger.run(testInteger.groovy:3)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:427)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:470)
> {noformat}
> The categoy class is implemented in Java and looks something like
> {code:java}
> public final class Convert
> {
> private Convert()
> {
> }
> public static final String
> getCanonicalLexicalRepresentation(CharSequence
[jira] [Commented] (GROOVY-10214) Update from Groovy 3.0.8 to 3.0.9 breaks category class
[
https://issues.apache.org/jira/browse/GROOVY-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486560#comment-17486560
]
Alexander Veit commented on GROOVY-10214:
-
The error also exists in Groovy 4.0.0.
See https://github.com/veita/groovy-10214
> Update from Groovy 3.0.8 to 3.0.9 breaks category class
> ---
>
> Key: GROOVY-10214
> URL: https://issues.apache.org/jira/browse/GROOVY-10214
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.9
> Environment: java --version
> openjdk 16.0.2 2021-07-20
> OpenJDK Runtime Environment Temurin-16.0.2+7 (build 16.0.2+7)
> OpenJDK 64-Bit Server VM Temurin-16.0.2+7 (build 16.0.2+7, mixed mode,
> sharing)
>Reporter: Alexander Veit
>Priority: Major
>
> We have a category class as part of our product's Groovy API that breaks
> after the update from Groovy 3.0.8 (indy) to 3.0.9 (indy).
> Scripts that call the category class with Integer of Long arguments throw an
> exception. E.g.
> {code:java}
> use (org.example.Convert)
> {
> assert '1234' == 1234.canonicalLexicalRepresentation
> }
> {code}
> throws
> {noformat}
> java.lang.IllegalArgumentException: argument type mismatch
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at
> org.codehaus.groovy.runtime.metaclass.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:54)
> at
> org.codehaus.groovy.runtime.metaclass.NewInstanceMetaMethod.invoke(NewInstanceMetaMethod.java:54)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
> at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1956)
> at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3843)
> at
> org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:199)
> at
> org.codehaus.groovy.runtime.callsite.PojoMetaClassGetPropertySite.getProperty(PojoMetaClassGetPropertySite.java:36)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:329)
> at
> org.example.test.testInteger$_run_closure1.doCall(testInteger.groovy:5)
> at org.example.test.testInteger$_run_closure1.doCall(testInteger.groovy)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:274)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1035)
> at groovy.lang.Closure.call(Closure.java:412)
> at groovy.lang.Closure.call(Closure.java:406)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:123)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.access$300(GroovyCategorySupport.java:72)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:258)
> at
> org.codehaus.groovy.runtime.DefaultGroovyMethods.use(DefaultGroovyMethods.java:568)
> at org.codehaus.groovy.runtime.dgm$880.invoke(Unknown Source)
> at
> org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoMetaMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:226)
> at
> org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:61)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:51)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:171)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:194)
> at org.example.test.testInteger.run(testInteger.groovy:3)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:427)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:470)
> {noformat}
> The categoy class is implemented in Java and looks something like
> {code:java}
> public final class Convert
> {
> private Convert()
> {
> }
>
[jira] [Updated] (GROOVY-10470) Update from Groovy 3 to 4.0.0 breaks existing code
[
https://issues.apache.org/jira/browse/GROOVY-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Veit updated GROOVY-10470:
Description:
After updating from Groovy 3 to 4.0.0 scripts that use {{AntBuilder}} without
an {{import}} statement no longer work.
This is probably caused by missing default includes for {{groovy.ant.*}} or
{{groovy.ant.AntBuilder}}.
The same problem exists for {{XmlSlurper}} and {{XmlParser}}.
Example: The script below works with Groovy 3.0.9 but not with 4.0.0.
{code:java}
new AntBuilder()
{code}
was:
After updating from Groovy 3 to 4.0.0 scripts that use {{AntBuilder}} without
an {{import}} statement no longer work.
This is probably caused by missing default includes for {{groovy.ant.*}} or
{{groovy.ant.AntBuilder}}.
The same problem exists for {{XmlSlurper}} and {{XmlParser}}.
> Update from Groovy 3 to 4.0.0 breaks existing code
> --
>
> Key: GROOVY-10470
> URL: https://issues.apache.org/jira/browse/GROOVY-10470
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 4.0.0
>Reporter: Alexander Veit
>Priority: Major
>
> After updating from Groovy 3 to 4.0.0 scripts that use {{AntBuilder}} without
> an {{import}} statement no longer work.
> This is probably caused by missing default includes for {{groovy.ant.*}} or
> {{groovy.ant.AntBuilder}}.
> The same problem exists for {{XmlSlurper}} and {{XmlParser}}.
> Example: The script below works with Groovy 3.0.9 but not with 4.0.0.
> {code:java}
> new AntBuilder()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GROOVY-10470) Update from Groovy 3 to 4.0.0 breaks existing code
Alexander Veit created GROOVY-10470:
---
Summary: Update from Groovy 3 to 4.0.0 breaks existing code
Key: GROOVY-10470
URL: https://issues.apache.org/jira/browse/GROOVY-10470
Project: Groovy
Issue Type: Bug
Components: groovy-runtime
Affects Versions: 4.0.0
Reporter: Alexander Veit
After updating from Groovy 3 to 4.0.0 scripts that use {{AntBuilder}} without
an import statement no longer work.
This is probably caused by missing default includes for {{groovy.ant.*}} or
{{groovy.ant.AntBuilder}}.
The same problem exists for {{XmlSlurper}} and {{XmlParser}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GROOVY-10470) Update from Groovy 3 to 4.0.0 breaks existing code
[
https://issues.apache.org/jira/browse/GROOVY-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Veit updated GROOVY-10470:
Description:
After updating from Groovy 3 to 4.0.0 scripts that use {{AntBuilder}} without
an {{import}} statement no longer work.
This is probably caused by missing default includes for {{groovy.ant.*}} or
{{groovy.ant.AntBuilder}}.
The same problem exists for {{XmlSlurper}} and {{XmlParser}}.
was:
After updating from Groovy 3 to 4.0.0 scripts that use {{AntBuilder}} without
an import statement no longer work.
This is probably caused by missing default includes for {{groovy.ant.*}} or
{{groovy.ant.AntBuilder}}.
The same problem exists for {{XmlSlurper}} and {{XmlParser}}.
> Update from Groovy 3 to 4.0.0 breaks existing code
> --
>
> Key: GROOVY-10470
> URL: https://issues.apache.org/jira/browse/GROOVY-10470
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 4.0.0
>Reporter: Alexander Veit
>Priority: Major
>
> After updating from Groovy 3 to 4.0.0 scripts that use {{AntBuilder}} without
> an {{import}} statement no longer work.
> This is probably caused by missing default includes for {{groovy.ant.*}} or
> {{groovy.ant.AntBuilder}}.
> The same problem exists for {{XmlSlurper}} and {{XmlParser}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (GROOVY-10469) Groovy 4.0.0 BSF module does not have a release version in central Maven repository
[ https://issues.apache.org/jira/browse/GROOVY-10469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485225#comment-17485225 ] Alexander Veit edited comment on GROOVY-10469 at 2/1/22, 12:47 PM: --- OK, didn't hear about it, and the release notes say nothing about it. BTW, personally I'm fine with it, and I don't think that our customers actually have use cases for BSF. So I think this issue could be closed. was (Author: veita): OK, didn't hear about it, and the release notes say nothing about it. BTW, personally I'm fine with it, and I don't think that our customers actually have use cases for BSF. > Groovy 4.0.0 BSF module does not have a release version in central Maven > repository > --- > > Key: GROOVY-10469 > URL: https://issues.apache.org/jira/browse/GROOVY-10469 > Project: Groovy > Issue Type: Bug > Components: groovy-bsf >Affects Versions: 4.0.0 >Reporter: Alexander Veit >Priority: Major > > The 4.0.0 version is missing. > See https://repo.maven.apache.org/maven2/org/apache/groovy/groovy-bsf/ -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GROOVY-10469) Groovy 4.0.0 BSF module does not have a release version in central Maven repository
[ https://issues.apache.org/jira/browse/GROOVY-10469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485225#comment-17485225 ] Alexander Veit commented on GROOVY-10469: - OK, didn't hear about it, and the release notes say nothing about it. BTW, personally I'm fine with it, and I don't think that our customers actually have use cases for BSF. > Groovy 4.0.0 BSF module does not have a release version in central Maven > repository > --- > > Key: GROOVY-10469 > URL: https://issues.apache.org/jira/browse/GROOVY-10469 > Project: Groovy > Issue Type: Bug > Components: groovy-bsf >Affects Versions: 4.0.0 >Reporter: Alexander Veit >Priority: Major > > The 4.0.0 version is missing. > See https://repo.maven.apache.org/maven2/org/apache/groovy/groovy-bsf/ -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GROOVY-10469) Groovy 4.0.0 BSF module does not have a release version in central Maven repository
Alexander Veit created GROOVY-10469: --- Summary: Groovy 4.0.0 BSF module does not have a release version in central Maven repository Key: GROOVY-10469 URL: https://issues.apache.org/jira/browse/GROOVY-10469 Project: Groovy Issue Type: Bug Components: groovy-bsf Affects Versions: 4.0.0 Reporter: Alexander Veit The 4.0.0 version is missing. See https://repo.maven.apache.org/maven2/org/apache/groovy/groovy-bsf/ -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (GROOVY-10214) Update from Groovy 3.0.8 to 3.0.9 breaks category class
[
https://issues.apache.org/jira/browse/GROOVY-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423598#comment-17423598
]
Alexander Veit edited comment on GROOVY-10214 at 10/2/21, 7:59 PM:
---
Hi Paul, sorry for the late reply.
I finally managed to create a minimal project that reproduces the problem. It
is located at
[https://github.com/veita/groovy-10214|https://github.com/veita/groovy-10214].
With Groovy 3.0.9 the problem occurs. When you switch to Groovy 3.0.8 (e.g. in
{{build.gradle}}) it disappears.
HTH
was (Author: veita):
Hi Paul, sorry for the late reply.
I finally managed to create a minimal project that reproduces the problem. It
is located at
[https://github.com/veita/groovy-10214|https://github.com/veita/groovy-10214].
With Groovy 3.0.9 the problem occurs. When you switch to Groovy 3.0.0 (e.g. in
{{build.gradle}}) it disappears.
HTH
> Update from Groovy 3.0.8 to 3.0.9 breaks category class
> ---
>
> Key: GROOVY-10214
> URL: https://issues.apache.org/jira/browse/GROOVY-10214
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.9
> Environment: java --version
> openjdk 16.0.2 2021-07-20
> OpenJDK Runtime Environment Temurin-16.0.2+7 (build 16.0.2+7)
> OpenJDK 64-Bit Server VM Temurin-16.0.2+7 (build 16.0.2+7, mixed mode,
> sharing)
>Reporter: Alexander Veit
>Priority: Major
>
> We have a category class as part of our product's Groovy API that breaks
> after the update from Groovy 3.0.8 (indy) to 3.0.9 (indy).
> Scripts that call the category class with Integer of Long arguments throw an
> exception. E.g.
> {code:java}
> use (org.example.Convert)
> {
> assert '1234' == 1234.canonicalLexicalRepresentation
> }
> {code}
> throws
> {noformat}
> java.lang.IllegalArgumentException: argument type mismatch
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at
> org.codehaus.groovy.runtime.metaclass.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:54)
> at
> org.codehaus.groovy.runtime.metaclass.NewInstanceMetaMethod.invoke(NewInstanceMetaMethod.java:54)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
> at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1956)
> at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3843)
> at
> org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:199)
> at
> org.codehaus.groovy.runtime.callsite.PojoMetaClassGetPropertySite.getProperty(PojoMetaClassGetPropertySite.java:36)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:329)
> at
> org.example.test.testInteger$_run_closure1.doCall(testInteger.groovy:5)
> at org.example.test.testInteger$_run_closure1.doCall(testInteger.groovy)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:274)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1035)
> at groovy.lang.Closure.call(Closure.java:412)
> at groovy.lang.Closure.call(Closure.java:406)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:123)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.access$300(GroovyCategorySupport.java:72)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:258)
> at
> org.codehaus.groovy.runtime.DefaultGroovyMethods.use(DefaultGroovyMethods.java:568)
> at org.codehaus.groovy.runtime.dgm$880.invoke(Unknown Source)
> at
> org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoMetaMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:226)
> at
> org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:61)
> at
>
[jira] [Commented] (GROOVY-10214) Update from Groovy 3.0.8 to 3.0.9 breaks category class
[
https://issues.apache.org/jira/browse/GROOVY-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423598#comment-17423598
]
Alexander Veit commented on GROOVY-10214:
-
Hi Paul, sorry for the late reply.
I finally managed to create a minimal project that reproduces the problem. It
is located at
[https://github.com/veita/groovy-10214|https://github.com/veita/groovy-10214].
With Groovy 3.0.9 the problem occurs. When you switch to Groovy 3.0.0 (e.g. in
{{build.gradle}}) it disappears.
HTH
> Update from Groovy 3.0.8 to 3.0.9 breaks category class
> ---
>
> Key: GROOVY-10214
> URL: https://issues.apache.org/jira/browse/GROOVY-10214
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.9
> Environment: java --version
> openjdk 16.0.2 2021-07-20
> OpenJDK Runtime Environment Temurin-16.0.2+7 (build 16.0.2+7)
> OpenJDK 64-Bit Server VM Temurin-16.0.2+7 (build 16.0.2+7, mixed mode,
> sharing)
>Reporter: Alexander Veit
>Priority: Major
>
> We have a category class as part of our product's Groovy API that breaks
> after the update from Groovy 3.0.8 (indy) to 3.0.9 (indy).
> Scripts that call the category class with Integer of Long arguments throw an
> exception. E.g.
> {code:java}
> use (org.example.Convert)
> {
> assert '1234' == 1234.canonicalLexicalRepresentation
> }
> {code}
> throws
> {noformat}
> java.lang.IllegalArgumentException: argument type mismatch
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at
> org.codehaus.groovy.runtime.metaclass.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:54)
> at
> org.codehaus.groovy.runtime.metaclass.NewInstanceMetaMethod.invoke(NewInstanceMetaMethod.java:54)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
> at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1956)
> at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3843)
> at
> org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:199)
> at
> org.codehaus.groovy.runtime.callsite.PojoMetaClassGetPropertySite.getProperty(PojoMetaClassGetPropertySite.java:36)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:329)
> at
> org.example.test.testInteger$_run_closure1.doCall(testInteger.groovy:5)
> at org.example.test.testInteger$_run_closure1.doCall(testInteger.groovy)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:274)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1035)
> at groovy.lang.Closure.call(Closure.java:412)
> at groovy.lang.Closure.call(Closure.java:406)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:123)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.access$300(GroovyCategorySupport.java:72)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:258)
> at
> org.codehaus.groovy.runtime.DefaultGroovyMethods.use(DefaultGroovyMethods.java:568)
> at org.codehaus.groovy.runtime.dgm$880.invoke(Unknown Source)
> at
> org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoMetaMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:226)
> at
> org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:61)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:51)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:171)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:194)
> at org.example.test.testInteger.run(testInteger.groovy:3)
> at
[jira] [Comment Edited] (GROOVY-10214) Update from Groovy 3.0.8 to 3.0.9 breaks category class
[
https://issues.apache.org/jira/browse/GROOVY-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17413216#comment-17413216
]
Alexander Veit edited comment on GROOVY-10214 at 9/10/21, 2:34 PM:
---
A colleague of mine tried to reproduce the issue in a simple standalone
project, but without success so far.
However, the error occurs consistently in our test environment with 3.0.9 while
all works with 3.0.8.
was (Author: veita):
A colleague of mine tried to reproduce the issue in a simple standalone
project, but without success so far.
However, the error occurs consistently in our test environment with 3.0.9 and
all works with 3.0.8.
> Update from Groovy 3.0.8 to 3.0.9 breaks category class
> ---
>
> Key: GROOVY-10214
> URL: https://issues.apache.org/jira/browse/GROOVY-10214
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.9
> Environment: java --version
> openjdk 16.0.2 2021-07-20
> OpenJDK Runtime Environment Temurin-16.0.2+7 (build 16.0.2+7)
> OpenJDK 64-Bit Server VM Temurin-16.0.2+7 (build 16.0.2+7, mixed mode,
> sharing)
>Reporter: Alexander Veit
>Priority: Major
>
> We have a category class as part of our product's Groovy API that breaks
> after the update from Groovy 3.0.8 (indy) to 3.0.9 (indy).
> Scripts that call the category class with Integer of Long arguments throw an
> exception. E.g.
> {code:java}
> use (org.example.Convert)
> {
> assert '1234' == 1234.canonicalLexicalRepresentation
> }
> {code}
> throws
> {noformat}
> java.lang.IllegalArgumentException: argument type mismatch
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at
> org.codehaus.groovy.runtime.metaclass.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:54)
> at
> org.codehaus.groovy.runtime.metaclass.NewInstanceMetaMethod.invoke(NewInstanceMetaMethod.java:54)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
> at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1956)
> at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3843)
> at
> org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:199)
> at
> org.codehaus.groovy.runtime.callsite.PojoMetaClassGetPropertySite.getProperty(PojoMetaClassGetPropertySite.java:36)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:329)
> at
> org.example.test.testInteger$_run_closure1.doCall(testInteger.groovy:5)
> at org.example.test.testInteger$_run_closure1.doCall(testInteger.groovy)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:274)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1035)
> at groovy.lang.Closure.call(Closure.java:412)
> at groovy.lang.Closure.call(Closure.java:406)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:123)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.access$300(GroovyCategorySupport.java:72)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:258)
> at
> org.codehaus.groovy.runtime.DefaultGroovyMethods.use(DefaultGroovyMethods.java:568)
> at org.codehaus.groovy.runtime.dgm$880.invoke(Unknown Source)
> at
> org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoMetaMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:226)
> at
> org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:61)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:51)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:171)
> at
>
[jira] [Commented] (GROOVY-10214) Update from Groovy 3.0.8 to 3.0.9 breaks category class
[
https://issues.apache.org/jira/browse/GROOVY-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17413216#comment-17413216
]
Alexander Veit commented on GROOVY-10214:
-
A colleague of mine tried to reproduce the issue in a simple standalone
project, but without success so far.
However, the error occurs consistently in our test environment with 3.0.9 and
all works with 3.0.8.
> Update from Groovy 3.0.8 to 3.0.9 breaks category class
> ---
>
> Key: GROOVY-10214
> URL: https://issues.apache.org/jira/browse/GROOVY-10214
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.9
> Environment: java --version
> openjdk 16.0.2 2021-07-20
> OpenJDK Runtime Environment Temurin-16.0.2+7 (build 16.0.2+7)
> OpenJDK 64-Bit Server VM Temurin-16.0.2+7 (build 16.0.2+7, mixed mode,
> sharing)
>Reporter: Alexander Veit
>Priority: Major
>
> We have a category class as part of our product's Groovy API that breaks
> after the update from Groovy 3.0.8 (indy) to 3.0.9 (indy).
> Scripts that call the category class with Integer of Long arguments throw an
> exception. E.g.
> {code:java}
> use (org.example.Convert)
> {
> assert '1234' == 1234.canonicalLexicalRepresentation
> }
> {code}
> throws
> {noformat}
> java.lang.IllegalArgumentException: argument type mismatch
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at
> org.codehaus.groovy.runtime.metaclass.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:54)
> at
> org.codehaus.groovy.runtime.metaclass.NewInstanceMetaMethod.invoke(NewInstanceMetaMethod.java:54)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
> at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1956)
> at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3843)
> at
> org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:199)
> at
> org.codehaus.groovy.runtime.callsite.PojoMetaClassGetPropertySite.getProperty(PojoMetaClassGetPropertySite.java:36)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:329)
> at
> org.example.test.testInteger$_run_closure1.doCall(testInteger.groovy:5)
> at org.example.test.testInteger$_run_closure1.doCall(testInteger.groovy)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:274)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1035)
> at groovy.lang.Closure.call(Closure.java:412)
> at groovy.lang.Closure.call(Closure.java:406)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:123)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.access$300(GroovyCategorySupport.java:72)
> at
> org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:258)
> at
> org.codehaus.groovy.runtime.DefaultGroovyMethods.use(DefaultGroovyMethods.java:568)
> at org.codehaus.groovy.runtime.dgm$880.invoke(Unknown Source)
> at
> org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoMetaMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:226)
> at
> org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:61)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:51)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:171)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:194)
> at org.example.test.testInteger.run(testInteger.groovy:3)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:427)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:470)
> {noformat}
> The categoy class is
[jira] [Created] (GROOVY-10214) Update from Groovy 3.0.8 to 3.0.9 breaks category class
Alexander Veit created GROOVY-10214:
---
Summary: Update from Groovy 3.0.8 to 3.0.9 breaks category class
Key: GROOVY-10214
URL: https://issues.apache.org/jira/browse/GROOVY-10214
Project: Groovy
Issue Type: Bug
Affects Versions: 3.0.9
Environment: java --version
openjdk 16.0.2 2021-07-20
OpenJDK Runtime Environment Temurin-16.0.2+7 (build 16.0.2+7)
OpenJDK 64-Bit Server VM Temurin-16.0.2+7 (build 16.0.2+7, mixed mode, sharing)
Reporter: Alexander Veit
We have a category class as part of our product's Groovy API that breaks after
the update from Groovy 3.0.8 (indy) to 3.0.9 (indy).
Scripts that call the category class with Integer of Long arguments throw an
exception. E.g.
{code:java}
use (org.example.Convert)
{
assert '1234' == 1234.canonicalLexicalRepresentation
}
{code}
throws
{noformat}
java.lang.IllegalArgumentException: argument type mismatch
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at
org.codehaus.groovy.runtime.metaclass.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:54)
at
org.codehaus.groovy.runtime.metaclass.NewInstanceMetaMethod.invoke(NewInstanceMetaMethod.java:54)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1956)
at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3843)
at
org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:199)
at
org.codehaus.groovy.runtime.callsite.PojoMetaClassGetPropertySite.getProperty(PojoMetaClassGetPropertySite.java:36)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:329)
at
org.example.test.testInteger$_run_closure1.doCall(testInteger.groovy:5)
at org.example.test.testInteger$_run_closure1.doCall(testInteger.groovy)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
at
org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:274)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1035)
at groovy.lang.Closure.call(Closure.java:412)
at groovy.lang.Closure.call(Closure.java:406)
at
org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:123)
at
org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.access$300(GroovyCategorySupport.java:72)
at
org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:258)
at
org.codehaus.groovy.runtime.DefaultGroovyMethods.use(DefaultGroovyMethods.java:568)
at org.codehaus.groovy.runtime.dgm$880.invoke(Unknown Source)
at
org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoMetaMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:226)
at
org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:61)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:51)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:171)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:194)
at org.example.test.testInteger.run(testInteger.groovy:3)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:427)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:470)
{noformat}
The categoy class is implemented in Java and looks something like
{code:java}
public final class Convert
{
private Convert()
{
}
public static final String
getCanonicalLexicalRepresentation(CharSequence p_chseq)
{
return "foo";
}
public static final String getCanonicalLexicalRepresentation(Boolean
p_bool)
{
return "foo";
}
public static final String getCanonicalLexicalRepresentation(Byte
p_byte)
{
return "foo";
[jira] [Created] (GROOVY-9818) JSP-API license seems to be missing
Alexander Veit created GROOVY-9818: -- Summary: JSP-API license seems to be missing Key: GROOVY-9818 URL: https://issues.apache.org/jira/browse/GROOVY-9818 Project: Groovy Issue Type: Bug Components: release Affects Versions: 3.0.6 Reporter: Alexander Veit The license for the JSP-API (jsp-api-2.0.jar, CDDL) seems to be missing in the Groovy binary distribution (licenses directory and JAR itself). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GROOVY-9795) Update or remove Guava dependency
Alexander Veit created GROOVY-9795: -- Summary: Update or remove Guava dependency Key: GROOVY-9795 URL: https://issues.apache.org/jira/browse/GROOVY-9795 Project: Groovy Issue Type: Improvement Affects Versions: 3.0.5 Reporter: Alexander Veit The Groovy binary distribution comes with a quite old and insecure (e.g. CVE-2018-10237) `guava-19.0.jar`. It should be updated or removed if it is not actually needed as a transitive dependency. Groovy itself seems to have the only dependency to Guava in `CommandChainsTest.groovy` and `Groovy6786Bug.class`. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-8768) Unable to add Groovy indy JARs as dependency in Gradle
[ https://issues.apache.org/jira/browse/GROOVY-8768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595026#comment-16595026 ] Alexander Veit commented on GROOVY-8768: Thank you. I also think a brief hint should suffice. > Unable to add Groovy indy JARs as dependency in Gradle > -- > > Key: GROOVY-8768 > URL: https://issues.apache.org/jira/browse/GROOVY-8768 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 2.5.0, 2.5.1, 2.5.2 >Reporter: Alexander Veit >Priority: Major > > After searching for two hours I could not find a way to reference Groovy indy > JARs in Gradle build scripts. Even [Invoke dynamic > support|http://groovy-lang.org/indy.html] on the Groovy website does not tell > how to do it. > Please add the necessary documentation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-8768) Unable to add Groovy indy JARs as dependency in Gradle
[ https://issues.apache.org/jira/browse/GROOVY-8768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595021#comment-16595021 ] Alexander Veit edited comment on GROOVY-8768 at 8/28/18 2:09 PM: - Paul, thank you very much for your quick reply. I already had found classifier: 'indy' in another SO post. Unfortunately I tried it with groovy-all pom only which, as you said, does not work. I'm fine with specifying each Groovy dependency explicitly since this is what we actually need. was (Author: veita): Paul, thank you very much for your quick reply. I already had found classifier: 'indy' in another SO post. Unfortunately I tried it with groovy-all pom only which, as you said, does not work. I'm fine with specifying each Groovy dependency explicitly since this is what we actually need. I't would be nice to document it on [http://groovy-lang.org/indy.html] since other users also might run into this problem, and [http://mvnrepository.com/] seems to be unaware of Groovy indy, too. > Unable to add Groovy indy JARs as dependency in Gradle > -- > > Key: GROOVY-8768 > URL: https://issues.apache.org/jira/browse/GROOVY-8768 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 2.5.0, 2.5.1, 2.5.2 >Reporter: Alexander Veit >Priority: Major > > After searching for two hours I could not find a way to reference Groovy indy > JARs in Gradle build scripts. Even [Invoke dynamic > support|http://groovy-lang.org/indy.html] on the Groovy website does not tell > how to do it. > Please add the necessary documentation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GROOVY-8768) Unable to add Groovy indy JARs as dependency in Gradle
Alexander Veit created GROOVY-8768: -- Summary: Unable to add Groovy indy JARs as dependency in Gradle Key: GROOVY-8768 URL: https://issues.apache.org/jira/browse/GROOVY-8768 Project: Groovy Issue Type: Bug Components: groovy-runtime Affects Versions: 2.5.2, 2.5.1, 2.5.0 Reporter: Alexander Veit After searching for two hours I could not find a way to reference Groovy indy JARs in Gradle build scripts. Even [Invoke dynamic support|http://groovy-lang.org/indy.html] on the Groovy website does not tell how to do it. Please add the necessary documentation. -- 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=16522257#comment-16522257
]
Alexander Veit commented on GROOVY-8649:
John, thank you for this clarification!
If the runtime class loading hierarchy is not affected by ASM resolving I would
no longer consider this an issue. The compiler option is fine. Additionally I
will look at the ClassNodeResolver mechanism for future use.
> 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-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=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] [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)
[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=16513660#comment-16513660 ] Alexander Veit commented on GROOVY-8644: This info helps a lot. Thank you very much Paul. > 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] [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=16513455#comment-16513455 ] Alexander Veit commented on GROOVY-8644: Our problem is that we have to choose exactly the split JARs that provide at least the functionality of the former groovy-all.jar but preferably nothing more. >From looking at the POM or the lib directory it is difficult to decide which >libraries to select and which third party dependencies are missing >(unfortunately Maven's or Gradle's automatic dependency resolution is not an >option for us). Therefore it would be nice if there was some documentation >about how to migrate. > 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] [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=16512524#comment-16512524 ] Alexander Veit commented on GROOVY-8644: Is the a documentation how to migrate existing applications from groovy-all.jar to the split JARs? > 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] [Updated] (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:all-tabpanel ] Alexander Veit updated GROOVY-8644: --- Summary: Groovy 2.5 binary JARs not available at Maven Central (was: Groovy 2.5 binary JARS not available at Maven Central) > 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-8644) Groovy 2.5 binary JARS not available at Maven Central
Alexander Veit created GROOVY-8644: -- Summary: 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 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-8141) Maven metadata announce non-release versions (alpha, beta, rc) as release version
Alexander Veit created GROOVY-8141: -- Summary: Maven metadata announce non-release versions (alpha, beta, rc) as release version Key: GROOVY-8141 URL: https://issues.apache.org/jira/browse/GROOVY-8141 Project: Groovy Issue Type: Bug Components: release Affects Versions: 2.5.0-alpha-1 Reporter: Alexander Veit http://repo1.maven.org/maven2/org/codehaus/groovy/groovy-all/maven-metadata.xml contains 2.5.0-alpha-1. According to http://maven.apache.org/ref/3.3.1/maven-repository-metadata/repository-metadata.html this is not correct. We have to manually handle this case in our automatic build processes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
