[jira] [Updated] (GROOVY-8872) Decompiled parameter names don't reflect the names in the bytecode
[ https://issues.apache.org/jira/browse/GROOVY-8872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Kleeh updated GROOVY-8872: Affects Version/s: (was: 2.5.1) 2.5.4 > Decompiled parameter names don't reflect the names in the bytecode > -- > > Key: GROOVY-8872 > URL: https://issues.apache.org/jira/browse/GROOVY-8872 > Project: Groovy > Issue Type: Improvement > Components: bytecode, Compiler >Affects Versions: 2.5.4 >Reporter: James Kleeh >Priority: Critical > Attachments: groovy-bug.tar.gz > > > org.codehaus.groovy.ast.Parameter names do not reflect what is stored in the > bytecode. > In this example project, I have 3 projects. > api - Has a single interface that is compiled with parameters=true > app - Has a single interface that extends the one in api and is compiled with > parameters=true > processor - Has a single ast transform that fails compilation if any method > parameters start with "param" > > The parameter names for the interface in the api project do not reflect the > bytecode when compiling the app project > > The runnable example is available here and I've attached it below > https://github.com/jameskleeh/groovy-ast-bug -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8872) Decompiled parameter names don't reflect the names in the bytecode
[ https://issues.apache.org/jira/browse/GROOVY-8872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16680877#comment-16680877 ] ASF GitHub Bot commented on GROOVY-8872: GitHub user jameskleeh opened a pull request: https://github.com/apache/groovy/pull/820 GROOVY-8872: Populate parameter names from byte code when available I'm not sure how to create a test for this. I verified the change works locally in the example project I linked and uploaded in the jira issue. I think adding or modifying a test in AsmDecompilerTest would be the best thing, but I'm not sure how to inform Groovy to compile the Java source with parameters. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jameskleeh/groovy decompiled_param_names Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/820.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #820 commit b2c31ff4f3a4038d6fbd16a89e2a14e6af4f83c2 Author: jameskleeh Date: 2018-11-09T04:44:59Z Populate the parameter names from the byte code when available > Decompiled parameter names don't reflect the names in the bytecode > -- > > Key: GROOVY-8872 > URL: https://issues.apache.org/jira/browse/GROOVY-8872 > Project: Groovy > Issue Type: Improvement > Components: bytecode, Compiler >Affects Versions: 2.5.1 >Reporter: James Kleeh >Priority: Critical > Attachments: groovy-bug.tar.gz > > > org.codehaus.groovy.ast.Parameter names do not reflect what is stored in the > bytecode. > In this example project, I have 3 projects. > api - Has a single interface that is compiled with parameters=true > app - Has a single interface that extends the one in api and is compiled with > parameters=true > processor - Has a single ast transform that fails compilation if any method > parameters start with "param" > > The parameter names for the interface in the api project do not reflect the > bytecode when compiling the app project > > The runnable example is available here and I've attached it below > https://github.com/jameskleeh/groovy-ast-bug -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] groovy pull request #820: GROOVY-8872: Populate parameter names from byte co...
GitHub user jameskleeh opened a pull request: https://github.com/apache/groovy/pull/820 GROOVY-8872: Populate parameter names from byte code when available I'm not sure how to create a test for this. I verified the change works locally in the example project I linked and uploaded in the jira issue. I think adding or modifying a test in AsmDecompilerTest would be the best thing, but I'm not sure how to inform Groovy to compile the Java source with parameters. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jameskleeh/groovy decompiled_param_names Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/820.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #820 commit b2c31ff4f3a4038d6fbd16a89e2a14e6af4f83c2 Author: jameskleeh Date: 2018-11-09T04:44:59Z Populate the parameter names from the byte code when available ---
[jira] [Updated] (GROOVY-8872) Decompiled parameter names don't reflect the names in the bytecode
[ https://issues.apache.org/jira/browse/GROOVY-8872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Kleeh updated GROOVY-8872: Summary: Decompiled parameter names don't reflect the names in the bytecode (was: AST Parameter names don't reflect the names in the bytecode) > Decompiled parameter names don't reflect the names in the bytecode > -- > > Key: GROOVY-8872 > URL: https://issues.apache.org/jira/browse/GROOVY-8872 > Project: Groovy > Issue Type: Bug > Components: bytecode, Compiler >Affects Versions: 2.5.1 >Reporter: James Kleeh >Priority: Major > Attachments: groovy-bug.tar.gz > > > org.codehaus.groovy.ast.Parameter names do not reflect what is stored in the > bytecode. > In this example project, I have 3 projects. > api - Has a single interface that is compiled with parameters=true > app - Has a single interface that extends the one in api and is compiled with > parameters=true > processor - Has a single ast transform that fails compilation if any method > parameters start with "param" > > The parameter names for the interface in the api project do not reflect the > bytecode when compiling the app project > > The runnable example is available here and I've attached it below > https://github.com/jameskleeh/groovy-ast-bug -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GROOVY-8872) Decompiled parameter names don't reflect the names in the bytecode
[ https://issues.apache.org/jira/browse/GROOVY-8872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Kleeh updated GROOVY-8872: Priority: Critical (was: Major) > Decompiled parameter names don't reflect the names in the bytecode > -- > > Key: GROOVY-8872 > URL: https://issues.apache.org/jira/browse/GROOVY-8872 > Project: Groovy > Issue Type: Improvement > Components: bytecode, Compiler >Affects Versions: 2.5.1 >Reporter: James Kleeh >Priority: Critical > Attachments: groovy-bug.tar.gz > > > org.codehaus.groovy.ast.Parameter names do not reflect what is stored in the > bytecode. > In this example project, I have 3 projects. > api - Has a single interface that is compiled with parameters=true > app - Has a single interface that extends the one in api and is compiled with > parameters=true > processor - Has a single ast transform that fails compilation if any method > parameters start with "param" > > The parameter names for the interface in the api project do not reflect the > bytecode when compiling the app project > > The runnable example is available here and I've attached it below > https://github.com/jameskleeh/groovy-ast-bug -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GROOVY-8872) Decompiled parameter names don't reflect the names in the bytecode
[ https://issues.apache.org/jira/browse/GROOVY-8872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Kleeh updated GROOVY-8872: Issue Type: Improvement (was: Bug) > Decompiled parameter names don't reflect the names in the bytecode > -- > > Key: GROOVY-8872 > URL: https://issues.apache.org/jira/browse/GROOVY-8872 > Project: Groovy > Issue Type: Improvement > Components: bytecode, Compiler >Affects Versions: 2.5.1 >Reporter: James Kleeh >Priority: Major > Attachments: groovy-bug.tar.gz > > > org.codehaus.groovy.ast.Parameter names do not reflect what is stored in the > bytecode. > In this example project, I have 3 projects. > api - Has a single interface that is compiled with parameters=true > app - Has a single interface that extends the one in api and is compiled with > parameters=true > processor - Has a single ast transform that fails compilation if any method > parameters start with "param" > > The parameter names for the interface in the api project do not reflect the > bytecode when compiling the app project > > The runnable example is available here and I've attached it below > https://github.com/jameskleeh/groovy-ast-bug -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] groovy pull request #779: GROOVY-8726: Store the method node reference in Pa...
Github user jameskleeh closed the pull request at: https://github.com/apache/groovy/pull/779 ---
[jira] [Commented] (GROOVY-8726) Parameter lacks a reference to the MethodNode it belongs to
[ https://issues.apache.org/jira/browse/GROOVY-8726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16680789#comment-16680789 ] ASF GitHub Bot commented on GROOVY-8726: Github user jameskleeh closed the pull request at: https://github.com/apache/groovy/pull/779 > Parameter lacks a reference to the MethodNode it belongs to > --- > > Key: GROOVY-8726 > URL: https://issues.apache.org/jira/browse/GROOVY-8726 > Project: Groovy > Issue Type: Improvement > Components: Compiler >Affects Versions: 2.5.1 >Reporter: James Kleeh >Priority: Major > > The Parameter class lacks a reference to it's method node. This is important > to find arguments that have been "overridden". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (GROOVY-8866) Implement `GProperties` to handle properties file smartly
[ https://issues.apache.org/jira/browse/GROOVY-8866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun reopened GROOVY-8866: > Implement `GProperties` to handle properties file smartly > - > > Key: GROOVY-8866 > URL: https://issues.apache.org/jira/browse/GROOVY-8866 > Project: Groovy > Issue Type: New Feature >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 3.0.0-alpha-4 > > > The `GProperties` supports interpolating in the values and importing other > properties in classpath -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GROOVY-8871) Long Constants Defined in Groovy 2.5.3 Under OpenJDK 11 Cause an IllegalAccessError
[
https://issues.apache.org/jira/browse/GROOVY-8871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-8871:
--
Priority: Critical (was: Blocker)
> Long Constants Defined in Groovy 2.5.3 Under OpenJDK 11 Cause an
> IllegalAccessError
> ---
>
> Key: GROOVY-8871
> URL: https://issues.apache.org/jira/browse/GROOVY-8871
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.3
> Environment: OpenJDK11 on MacOSX 10.14 and Debian Linux (through
> docker)
>Reporter: Kevin Brown
>Priority: Critical
> Attachments: example-for-groovy-long-bug.zip
>
>
> The following groovy code:
> {code:java}
> class SomeBadClass {
> SomeBadClass() {
> Long a = 1_457_366_400_000L
> }
> }
> new SomeBadClass(){code}
> causes the following exception to be thrown:
> {code:java}
> java.lang.IllegalAccessError: Update to static final field
> com.example.SomeBadClass.$const$0 attempted from a different method
> (__$swapInit) than the initializer method
>at com.example.SomeBadClass.__$swapInit(SomeBadClass.groovy)
>at com.example.SomeBadClass.(SomeBadClass.groovy)
>at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
>at
> org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:83)
>at
> org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
>at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:59)
>at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:237)
>at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:241)
>at
> com.example.SomeClassFailsTest_3.testSomething(SomeClassFailsTest_3.groovy:37)
>at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>at org.junit.runners.Suite.runChild(Suite.java:128)
>at org.junit.runners.Suite.runChild(Suite.java:27)
>at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
>at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
>at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
>at
>
[jira] [Commented] (GROOVY-8866) Implement `GProperties` to handle properties file smartly
[ https://issues.apache.org/jira/browse/GROOVY-8866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16680443#comment-16680443 ] Paul King commented on GROOVY-8866: --- It would be interesting to see whether we could implement this feature using GStringTemplateEngine and some smart binding. Parsing and IDE support for GStringTemplates is well understood. Refactoring and IDE follow-through of property names may or may not automatically work but would be no worse than existing GStringTemplate scenarios. > Implement `GProperties` to handle properties file smartly > - > > Key: GROOVY-8866 > URL: https://issues.apache.org/jira/browse/GROOVY-8866 > Project: Groovy > Issue Type: New Feature >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > > The `GProperties` supports interpolating in the values and importing other > properties in classpath -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GROOVY-8871) Long Constants Defined in Groovy 2.5.3 Under OpenJDK 11 Cause an IllegalAccessError
[
https://issues.apache.org/jira/browse/GROOVY-8871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-8871.
---
Resolution: Fixed
Assignee: Paul King
Fix Version/s: 2.5.4
3.0.0-alpha-4
Your example works fine with 2.5.4-SNAPSHOT with the change I made. I'll close
this off to include in the 2.5.4 release. I have more test coverage to add but
I can create a separate issue for that.
> Long Constants Defined in Groovy 2.5.3 Under OpenJDK 11 Cause an
> IllegalAccessError
> ---
>
> Key: GROOVY-8871
> URL: https://issues.apache.org/jira/browse/GROOVY-8871
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.3
> Environment: OpenJDK11 on MacOSX 10.14 and Debian Linux (through
> docker)
>Reporter: Kevin Brown
>Assignee: Paul King
>Priority: Critical
> Fix For: 3.0.0-alpha-4, 2.5.4
>
> Attachments: example-for-groovy-long-bug.zip
>
>
> The following groovy code:
> {code:java}
> class SomeBadClass {
> SomeBadClass() {
> Long a = 1_457_366_400_000L
> }
> }
> new SomeBadClass(){code}
> causes the following exception to be thrown:
> {code:java}
> java.lang.IllegalAccessError: Update to static final field
> com.example.SomeBadClass.$const$0 attempted from a different method
> (__$swapInit) than the initializer method
>at com.example.SomeBadClass.__$swapInit(SomeBadClass.groovy)
>at com.example.SomeBadClass.(SomeBadClass.groovy)
>at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
>at
> org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:83)
>at
> org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
>at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:59)
>at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:237)
>at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:241)
>at
> com.example.SomeClassFailsTest_3.testSomething(SomeClassFailsTest_3.groovy:37)
>at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>at org.junit.runners.Suite.runChild(Suite.java:128)
>at org.junit.runners.Suite.runChild(Suite.java:27)
>at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>at
>
[jira] [Commented] (GROOVY-8871) Long Constants Defined in Groovy 2.5.3 Under OpenJDK 11 Cause an IllegalAccessError
[
https://issues.apache.org/jira/browse/GROOVY-8871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16680470#comment-16680470
]
Paul King commented on GROOVY-8871:
---
May not mean much without context:
https://github.com/apache/groovy/commit/7a41f0efd6
> Long Constants Defined in Groovy 2.5.3 Under OpenJDK 11 Cause an
> IllegalAccessError
> ---
>
> Key: GROOVY-8871
> URL: https://issues.apache.org/jira/browse/GROOVY-8871
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.3
> Environment: OpenJDK11 on MacOSX 10.14 and Debian Linux (through
> docker)
>Reporter: Kevin Brown
>Assignee: Paul King
>Priority: Critical
> Fix For: 3.0.0-alpha-4, 2.5.4
>
> Attachments: example-for-groovy-long-bug.zip
>
>
> The following groovy code:
> {code:java}
> class SomeBadClass {
> SomeBadClass() {
> Long a = 1_457_366_400_000L
> }
> }
> new SomeBadClass(){code}
> causes the following exception to be thrown:
> {code:java}
> java.lang.IllegalAccessError: Update to static final field
> com.example.SomeBadClass.$const$0 attempted from a different method
> (__$swapInit) than the initializer method
>at com.example.SomeBadClass.__$swapInit(SomeBadClass.groovy)
>at com.example.SomeBadClass.(SomeBadClass.groovy)
>at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
>at
> org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:83)
>at
> org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
>at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:59)
>at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:237)
>at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:241)
>at
> com.example.SomeClassFailsTest_3.testSomething(SomeClassFailsTest_3.groovy:37)
>at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>at org.junit.runners.Suite.runChild(Suite.java:128)
>at org.junit.runners.Suite.runChild(Suite.java:27)
>at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
>at
>
[jira] [Commented] (GROOVY-8871) Long Constants Defined in Groovy 2.5.3 Under OpenJDK 11 Cause an IllegalAccessError
[
https://issues.apache.org/jira/browse/GROOVY-8871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16680423#comment-16680423
]
Kevin Brown commented on GROOVY-8871:
-
Thanks [~paulk]. For reference can you point me to the commit that fixed this
so I can learn what is going on here?
> Long Constants Defined in Groovy 2.5.3 Under OpenJDK 11 Cause an
> IllegalAccessError
> ---
>
> Key: GROOVY-8871
> URL: https://issues.apache.org/jira/browse/GROOVY-8871
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.3
> Environment: OpenJDK11 on MacOSX 10.14 and Debian Linux (through
> docker)
>Reporter: Kevin Brown
>Assignee: Paul King
>Priority: Critical
> Fix For: 3.0.0-alpha-4, 2.5.4
>
> Attachments: example-for-groovy-long-bug.zip
>
>
> The following groovy code:
> {code:java}
> class SomeBadClass {
> SomeBadClass() {
> Long a = 1_457_366_400_000L
> }
> }
> new SomeBadClass(){code}
> causes the following exception to be thrown:
> {code:java}
> java.lang.IllegalAccessError: Update to static final field
> com.example.SomeBadClass.$const$0 attempted from a different method
> (__$swapInit) than the initializer method
>at com.example.SomeBadClass.__$swapInit(SomeBadClass.groovy)
>at com.example.SomeBadClass.(SomeBadClass.groovy)
>at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
>at
> org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:83)
>at
> org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
>at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:59)
>at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:237)
>at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:241)
>at
> com.example.SomeClassFailsTest_3.testSomething(SomeClassFailsTest_3.groovy:37)
>at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>at org.junit.runners.Suite.runChild(Suite.java:128)
>at org.junit.runners.Suite.runChild(Suite.java:27)
>at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
>at
>
[jira] [Comment Edited] (GROOVY-8871) Long Constants Defined in Groovy 2.5.3 Under OpenJDK 11 Cause an IllegalAccessError
[
https://issues.apache.org/jira/browse/GROOVY-8871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16679165#comment-16679165
]
Paul King edited comment on GROOVY-8871 at 11/8/18 10:13 AM:
-
This is to do with the {{targetCompatibility}} setting you have in your build
file. Can you set that version to an earlier one while still running on JDK11?
Also what happens when using primitive 'long'?
was (Author: paulk):
I am wondering if we are seeing the right error. Compiling and using your class
under JDK11 and Groovy2.5.3 works fine in the GroovyConsole. I noticed in your
build file you have sourceCompatibility and targetCompatibility set to
JavaVersion.VERSION_11. We don't support that in 2.5.3 even though running is
fine. What happens if you set those to JavaVersion.VERSION_1_10 but still run
under JDK11 obviously? Also what happens when using primitive 'long'?
> Long Constants Defined in Groovy 2.5.3 Under OpenJDK 11 Cause an
> IllegalAccessError
> ---
>
> Key: GROOVY-8871
> URL: https://issues.apache.org/jira/browse/GROOVY-8871
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.3
> Environment: OpenJDK11 on MacOSX 10.14 and Debian Linux (through
> docker)
>Reporter: Kevin Brown
>Priority: Blocker
> Attachments: example-for-groovy-long-bug.zip
>
>
> The following groovy code:
> {code:java}
> class SomeBadClass {
> SomeBadClass() {
> Long a = 1_457_366_400_000L
> }
> }
> new SomeBadClass(){code}
> causes the following exception to be thrown:
> {code:java}
> java.lang.IllegalAccessError: Update to static final field
> com.example.SomeBadClass.$const$0 attempted from a different method
> (__$swapInit) than the initializer method
>at com.example.SomeBadClass.__$swapInit(SomeBadClass.groovy)
>at com.example.SomeBadClass.(SomeBadClass.groovy)
>at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
>at
> org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:83)
>at
> org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
>at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:59)
>at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:237)
>at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:241)
>at
> com.example.SomeClassFailsTest_3.testSomething(SomeClassFailsTest_3.groovy:37)
>at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>at org.junit.runners.Suite.runChild(Suite.java:128)
>at org.junit.runners.Suite.runChild(Suite.java:27)
>at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>at
[jira] [Commented] (GROOVY-8849) Provide a way to change property names when converting Pojo to JSON
[
https://issues.apache.org/jira/browse/GROOVY-8849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16679379#comment-16679379
]
Paul King commented on GROOVY-8849:
---
Are you happy with my suggestions? Should I close the issue?
> Provide a way to change property names when converting Pojo to JSON
> ---
>
> Key: GROOVY-8849
> URL: https://issues.apache.org/jira/browse/GROOVY-8849
> Project: Groovy
> Issue Type: New Feature
> Components: JSON
>Affects Versions: 2.5.0
>Reporter: Raviteja Lokineni
>Priority: Minor
>
> I want to be able to override with something like the annotation JsonProperty
> to override how a property name should be serialized to Json. If the feature
> is already there then please add documentation. For example:
> {code:java}
> @JsonProperty("test_one")
> int testOne
> @JsonProperty("test_two")
> int testTwo{code}
> More information on the example:
> [Jackson-Annotations|https://github.com/FasterXML/jackson-annotations/wiki/Jackson-Annotations]
>
> h1. Reproducible Code
> h2. Pojo.groovy
> {code:java}
> class Pojo {
> int testOne
> int testTwo
> }{code}
> h2. Sample Run:
> {code:java}
> JsonOutput.toJson(new Pojo(testOne: 1, testTwo: 1))
> // Output
> // ===> {"testTwo":1,"testOne":1}
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-8871) Long Constants Defined in Groovy 2.5.3 Under OpenJDK 11 Cause an IllegalAccessError
[
https://issues.apache.org/jira/browse/GROOVY-8871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16680049#comment-16680049
]
Kevin Brown edited comment on GROOVY-8871 at 11/8/18 5:27 PM:
--
[~paulk]
When I set targetCompatibility to JavaVersion.VERSION_1_10 everything works
fine while still running under JDK11 (both osx and linux/docker).
Using the primitive long seems to have the same behavior:
Doesn't work:
{code}
long doesntWork1 = 1_000L
long doesntWork2 = 1_457_366_400_000L
long doesntWork3 = 1_457_366_400_000
{code}
Does work:
{code}
long doesWork1 = 1_000
long doesWork2 = new Long("145736640")
{code}
Another note: if you notice creating the long from the string seems to work and
could be a viable workaround for now (it worked in my actual code).
was (Author: silentkevin):
[~paulk]
When I set targetCompatibility to JavaVersion.VERSION_1_10 everything works
fine while still running under JDK11 (both osx and linux/docker).
Using the primitive long seems to have the same behavior:
Doesn't work:
{code}
long doesntWork1 = 1_000L
long doesntWork2 = 1_457_366_400_000L
long doesntWork3 = 1_457_366_400_000
{code}
Does work:
{code}
long doesWork1 = 1_000
long doesWork2 = new Long("145736640")
{code}
> Long Constants Defined in Groovy 2.5.3 Under OpenJDK 11 Cause an
> IllegalAccessError
> ---
>
> Key: GROOVY-8871
> URL: https://issues.apache.org/jira/browse/GROOVY-8871
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.3
> Environment: OpenJDK11 on MacOSX 10.14 and Debian Linux (through
> docker)
>Reporter: Kevin Brown
>Priority: Critical
> Attachments: example-for-groovy-long-bug.zip
>
>
> The following groovy code:
> {code:java}
> class SomeBadClass {
> SomeBadClass() {
> Long a = 1_457_366_400_000L
> }
> }
> new SomeBadClass(){code}
> causes the following exception to be thrown:
> {code:java}
> java.lang.IllegalAccessError: Update to static final field
> com.example.SomeBadClass.$const$0 attempted from a different method
> (__$swapInit) than the initializer method
>at com.example.SomeBadClass.__$swapInit(SomeBadClass.groovy)
>at com.example.SomeBadClass.(SomeBadClass.groovy)
>at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
>at
> org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:83)
>at
> org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
>at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:59)
>at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:237)
>at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:241)
>at
> com.example.SomeClassFailsTest_3.testSomething(SomeClassFailsTest_3.groovy:37)
>at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>at
[jira] [Issue Comment Deleted] (GROOVY-8866) Implement `GProperties` to handle properties file smartly
[ https://issues.apache.org/jira/browse/GROOVY-8866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun updated GROOVY-8866: --- Comment: was deleted (was: Fixed by https://github.com/apache/groovy/commit/5de34ce58417ec48f0e1cdedfe78cb2600e9c913) > Implement `GProperties` to handle properties file smartly > - > > Key: GROOVY-8866 > URL: https://issues.apache.org/jira/browse/GROOVY-8866 > Project: Groovy > Issue Type: New Feature >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > > The `GProperties` supports interpolating in the values and importing other > properties in classpath -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GROOVY-8866) Implement `GProperties` to handle properties file smartly
[ https://issues.apache.org/jira/browse/GROOVY-8866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun updated GROOVY-8866: --- Fix Version/s: (was: 3.0.0-alpha-4) > Implement `GProperties` to handle properties file smartly > - > > Key: GROOVY-8866 > URL: https://issues.apache.org/jira/browse/GROOVY-8866 > Project: Groovy > Issue Type: New Feature >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > > The `GProperties` supports interpolating in the values and importing other > properties in classpath -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8871) Long Constants Defined in Groovy 2.5.3 Under OpenJDK 11 Cause an IllegalAccessError
[
https://issues.apache.org/jira/browse/GROOVY-8871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16679165#comment-16679165
]
Paul King commented on GROOVY-8871:
---
I am wondering if we are seeing the right error. Compiling and using your class
under JDK11 and Groovy2.5.3 works fine in the GroovyConsole. I noticed in your
build file you have sourceCompatibility and targetCompatibility set to
JavaVersion.VERSION_11. We don't support that in 2.5.3 even though running is
fine. What happens if you set those to JavaVersion.VERSION_1_10 but still run
under JDK11 obviously? Also what happens when using primitive 'long'?
> Long Constants Defined in Groovy 2.5.3 Under OpenJDK 11 Cause an
> IllegalAccessError
> ---
>
> Key: GROOVY-8871
> URL: https://issues.apache.org/jira/browse/GROOVY-8871
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.3
> Environment: OpenJDK11 on MacOSX 10.14 and Debian Linux (through
> docker)
>Reporter: Kevin Brown
>Priority: Blocker
> Attachments: example-for-groovy-long-bug.zip
>
>
> The following groovy code:
> {code:java}
> class SomeBadClass {
> SomeBadClass() {
> Long a = 1_457_366_400_000L
> }
> }
> new SomeBadClass(){code}
> causes the following exception to be thrown:
> {code:java}
> java.lang.IllegalAccessError: Update to static final field
> com.example.SomeBadClass.$const$0 attempted from a different method
> (__$swapInit) than the initializer method
>at com.example.SomeBadClass.__$swapInit(SomeBadClass.groovy)
>at com.example.SomeBadClass.(SomeBadClass.groovy)
>at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
>at
> org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:83)
>at
> org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
>at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:59)
>at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:237)
>at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:241)
>at
> com.example.SomeClassFailsTest_3.testSomething(SomeClassFailsTest_3.groovy:37)
>at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>at org.junit.runners.Suite.runChild(Suite.java:128)
>at org.junit.runners.Suite.runChild(Suite.java:27)
>at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>at
[jira] [Created] (GROOVY-8872) AST Parameter names don't reflect the names in the bytecode
James Kleeh created GROOVY-8872: --- Summary: AST Parameter names don't reflect the names in the bytecode Key: GROOVY-8872 URL: https://issues.apache.org/jira/browse/GROOVY-8872 Project: Groovy Issue Type: Bug Components: bytecode, Compiler Affects Versions: 2.5.1 Reporter: James Kleeh Attachments: groovy-bug.tar.gz org.codehaus.groovy.ast.Parameter names do not reflect what is stored in the bytecode. In this example project, I have 3 projects. api - Has a single interface that is compiled with parameters=true app - Has a single interface that extends the one in api and is compiled with parameters=true processor - Has a single ast transform that fails compilation if any method parameters start with "param" The parameter names for the interface in the api project do not reflect the bytecode when compiling the app project The runnable example is available here and I've attached it below https://github.com/jameskleeh/groovy-ast-bug -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8871) Long Constants Defined in Groovy 2.5.3 Under OpenJDK 11 Cause an IllegalAccessError
[
https://issues.apache.org/jira/browse/GROOVY-8871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16680049#comment-16680049
]
Kevin Brown commented on GROOVY-8871:
-
[~paulk]
When I set targetCompatibility to JavaVersion.VERSION_1_10 everything works
fine while still running under JDK11 (both osx and linux/docker).
Using the primitive long seems to have the same behavior:
Doesn't work:
{code}
long doesntWork1 = 1_000L
long doesntWork2 = 1_457_366_400_000L
long doesntWork3 = 1_457_366_400_000
{code}
Does work:
{code}
long doesWork1 = 1_000
long doesWork2 = new Long("145736640")
{code}
> Long Constants Defined in Groovy 2.5.3 Under OpenJDK 11 Cause an
> IllegalAccessError
> ---
>
> Key: GROOVY-8871
> URL: https://issues.apache.org/jira/browse/GROOVY-8871
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.3
> Environment: OpenJDK11 on MacOSX 10.14 and Debian Linux (through
> docker)
>Reporter: Kevin Brown
>Priority: Critical
> Attachments: example-for-groovy-long-bug.zip
>
>
> The following groovy code:
> {code:java}
> class SomeBadClass {
> SomeBadClass() {
> Long a = 1_457_366_400_000L
> }
> }
> new SomeBadClass(){code}
> causes the following exception to be thrown:
> {code:java}
> java.lang.IllegalAccessError: Update to static final field
> com.example.SomeBadClass.$const$0 attempted from a different method
> (__$swapInit) than the initializer method
>at com.example.SomeBadClass.__$swapInit(SomeBadClass.groovy)
>at com.example.SomeBadClass.(SomeBadClass.groovy)
>at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
>at
> org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:83)
>at
> org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
>at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:59)
>at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:237)
>at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:241)
>at
> com.example.SomeClassFailsTest_3.testSomething(SomeClassFailsTest_3.groovy:37)
>at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>at org.junit.runners.Suite.runChild(Suite.java:128)
>at org.junit.runners.Suite.runChild(Suite.java:27)
>at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>at
