[jira] [Commented] (GROOVY-10197) java.lang.VerifyError using property inside enum's constant
[
https://issues.apache.org/jira/browse/GROOVY-10197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17397974#comment-17397974
]
Ivan Kuznetsov commented on GROOVY-10197:
-
This is very similar to GROOVY-9524
> java.lang.VerifyError using property inside enum's constant
> ---
>
> Key: GROOVY-10197
> URL: https://issues.apache.org/jira/browse/GROOVY-10197
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 3.0.8
>Reporter: Ivan Kuznetsov
>Priority: Major
>
> I'm facing with this strange error after script compiles successfully but
> fails to load using groovy 3.0.8:
> {noformat}
> java.lang.VerifyError: Bad type on operand stack
> Exception Details:
> Location:
> E$1.(Ljava/lang/String;ILjava/util/LinkedHashMap;)V @50:
> invokevirtual
> Reason:
> Type 'E$1' (current frame, stack[0]) is not assignable to
> 'groovy/lang/Closure'
> Current Frame:
> bci: @50
> flags: { }
> locals: { 'E$1', 'java/lang/String', integer, 'java/util/LinkedHashMap',
> integer }
> stack: { 'E$1' }
> Bytecode:
> 000: 2a2b 1c2d 01b7 0012 0436 0415 042a 5fb5
> 010: 0014 1504 572d c700 0704 a700 0403 9900
> 020: 13bb 0016 5912 18b7 001b c000 1dbf
> 030: bf2a b600 23c0 0004 c000 2512 26b6 002a
> 040: 9900 1a2d 1226 b900 3002 003a 0519 05b8
> 050: 0036 2a5f b500 1419 0557 2a2d b800 3c01
> 060: 57b1
> Stackmap Table:
> full_frame(@29,{Object[#2],Object[#69],Integer,Object[#37],Integer},{})
> same_locals_1_stack_item_frame(@30,Integer)
> full_frame(@46,{},{Object[#29]})
> full_frame(@49,{Object[#2],Object[#69],Integer,Object[#37],Integer},{})
> same_frame(@90)
> same_frame(@97) at E.(ideaGroovyConsole.groovy)
> at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native
> Method)
> at
> java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1155)
> at
> java.base/jdk.internal.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:42)
> at
> java.base/jdk.internal.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:186)
> at
> java.base/java.lang.reflect.Field.acquireFieldAccessor(Field.java:1126)
> at java.base/java.lang.reflect.Field.getFieldAccessor(Field.java:1107)
> at java.base/java.lang.reflect.Field.get(Field.java:419)
> at
> org.codehaus.groovy.reflection.CachedField.getProperty(CachedField.java:68)
> at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1900)
> at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3874)
> at
> org.codehaus.groovy.runtime.callsite.ClassMetaClassGetPropertySite.getProperty(ClassMetaClassGetPropertySite.java:50)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:329)
> at ideaGroovyConsole.run(ideaGroovyConsole.groovy:110) {noformat}
> Here is the reproducing script:
> {code:java}
> @CompileStatic
> enum E {
> E1{
> //int value = 1
> int getValue() { 1 }
> }
> int getValue() { -1 }
> }
> {code}
> If you use an overriding method, all is working fine. But replacing method
> with local field causes an error above. I think it is
> {{@CompileStatic}}-specific error, because without this annotation both
> versions are loaded successfully.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GROOVY-10197) java.lang.VerifyError using property inside enum's constant
Ivan Kuznetsov created GROOVY-10197:
---
Summary: java.lang.VerifyError using property inside enum's
constant
Key: GROOVY-10197
URL: https://issues.apache.org/jira/browse/GROOVY-10197
Project: Groovy
Issue Type: Bug
Affects Versions: 3.0.8
Reporter: Ivan Kuznetsov
I'm facing with this strange error after script compiles successfully but fails
to load using groovy 3.0.8:
{noformat}
java.lang.VerifyError: Bad type on operand stack
Exception Details:
Location:
E$1.(Ljava/lang/String;ILjava/util/LinkedHashMap;)V @50: invokevirtual
Reason:
Type 'E$1' (current frame, stack[0]) is not assignable to
'groovy/lang/Closure'
Current Frame:
bci: @50
flags: { }
locals: { 'E$1', 'java/lang/String', integer, 'java/util/LinkedHashMap',
integer }
stack: { 'E$1' }
Bytecode:
000: 2a2b 1c2d 01b7 0012 0436 0415 042a 5fb5
010: 0014 1504 572d c700 0704 a700 0403 9900
020: 13bb 0016 5912 18b7 001b c000 1dbf
030: bf2a b600 23c0 0004 c000 2512 26b6 002a
040: 9900 1a2d 1226 b900 3002 003a 0519 05b8
050: 0036 2a5f b500 1419 0557 2a2d b800 3c01
060: 57b1
Stackmap Table:
full_frame(@29,{Object[#2],Object[#69],Integer,Object[#37],Integer},{})
same_locals_1_stack_item_frame(@30,Integer)
full_frame(@46,{},{Object[#29]})
full_frame(@49,{Object[#2],Object[#69],Integer,Object[#37],Integer},{})
same_frame(@90)
same_frame(@97) at E.(ideaGroovyConsole.groovy)
at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native
Method)
at
java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1155)
at
java.base/jdk.internal.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:42)
at
java.base/jdk.internal.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:186)
at
java.base/java.lang.reflect.Field.acquireFieldAccessor(Field.java:1126)
at java.base/java.lang.reflect.Field.getFieldAccessor(Field.java:1107)
at java.base/java.lang.reflect.Field.get(Field.java:419)
at
org.codehaus.groovy.reflection.CachedField.getProperty(CachedField.java:68)
at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1900)
at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3874)
at
org.codehaus.groovy.runtime.callsite.ClassMetaClassGetPropertySite.getProperty(ClassMetaClassGetPropertySite.java:50)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:329)
at ideaGroovyConsole.run(ideaGroovyConsole.groovy:110) {noformat}
Here is the reproducing script:
{code:java}
@CompileStatic
enum E {
E1{
//int value = 1
int getValue() { 1 }
}
int getValue() { -1 }
}
{code}
If you use an overriding method, all is working fine. But replacing method with
local field causes an error above. I think it is {{@CompileStatic}}-specific
error, because without this annotation both versions are loaded successfully.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9283) Nested closures run on wrong delegate
[
https://issues.apache.org/jira/browse/GROOVY-9283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956377#comment-16956377
]
Ivan Kuznetsov commented on GROOVY-9283:
Eric Milles, thank you! Setting strategy in annotation worked on 2.5.8. Where
can I get snapshots?
I missed one important thing: static compiler uses {{DelegatesTo}} annotation,
but I thought that it is enough to set same strategy on closure itself when it
is called inside java.
So... The wrong behaviour is not current but previous? This issue can be closed
as not a bug?
> Nested closures run on wrong delegate
> -
>
> Key: GROOVY-9283
> URL: https://issues.apache.org/jira/browse/GROOVY-9283
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.5.7, 3.0.0-beta-3
> Environment: CentOS Linux release 7.7.1908 (Core), openjdk 12.0.2
> 2019-07-16
>Reporter: Ivan Kuznetsov
>Priority: Critical
>
> We use Groovy to write DSL scripts for our project, and the only version we
> can use now is 2.5.6 because of bug with {{\@CompileStatic}} wich is
> reproducible with the following code:
> {code:java}
> package test;
> import groovy.lang.Closure;
> import groovy.lang.DelegatesTo;
> import groovy.lang.GroovyClassLoader;
> import groovy.transform.CompileStatic;
> import org.codehaus.groovy.control.CompilerConfiguration;
> import org.codehaus.groovy.control.customizers.ASTTransformationCustomizer;
> import org.codehaus.groovy.runtime.InvokerHelper;
> public class Main {
> private static final String script = "" +
> "import test.Main\n" +
> "\n" +
> "new Main().enter {\n" +
> "nest {\n" +
> "nest {\n" +
> "nest {\n" +
> "println(\"REACHED\")\n" +
> "}\n" +
> "}\n" +
> "}\n" +
> "}\n";
> public static void main(String[] args) {
> CompilerConfiguration config = new CompilerConfiguration();
> config.addCompilationCustomizers(new
> ASTTransformationCustomizer(CompileStatic.class));
> GroovyClassLoader loader = new
> GroovyClassLoader(Main.class.getClassLoader(), config);
> Class cls = loader.parseClass(script, "file");
> InvokerHelper.runScript(cls, new String[0]);
> }
> public void enter(@DelegatesTo(Root.class) Closure closure) {
> Root scope = new Root();
> closure.setDelegate(scope);
> closure.run();
> }
> public static class Outer extends Main {
> private final Main parent;
> Outer() {
> this.parent = null;
> }
> Outer(Outer parent) {
> this.parent = parent;
> }
> public void nest(@DelegatesTo(Inner.class) Closure closure) {
> closure.setDelegate(new Inner(this));
> closure.run();
> System.out.println(this + ": " + parent);
> }
> }
> public static class Inner extends Outer {
> public Inner(Outer parent) {
> super(parent);
> }
> }
> public static class Root extends Outer {
> Root() {
> }
> }
> }
> {code}
> till version 2.5.6 it prints:
> {noformat}
> REACHED
> test.Main$Inner@7582ff54: test.Main$Inner@67545b57
> test.Main$Inner@67545b57: test.Main$Root@6c2c1385
> test.Main$Root@6c2c1385: null
> {noformat}
> but starting with 2.5.7 it prints:
> {noformat}
> REACHED
> test.Main$Root@2f67b837: null
> test.Main$Root@2f67b837: null
> test.Main$Root@2f67b837: null
> {noformat}
> The workaround is to turn off static compilation, but it degrades performance
> because some handles are defined using this DSL and they are called very
> often.
> Thanks in advance!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GROOVY-9283) Nested closures run on wrong delegate
Ivan Kuznetsov created GROOVY-9283:
--
Summary: Nested closures run on wrong delegate
Key: GROOVY-9283
URL: https://issues.apache.org/jira/browse/GROOVY-9283
Project: Groovy
Issue Type: Bug
Components: Static compilation
Affects Versions: 3.0.0-beta-3, 2.5.7
Environment: CentOS Linux release 7.7.1908 (Core), openjdk 12.0.2
2019-07-16
Reporter: Ivan Kuznetsov
We use Groovy to write DSL scripts for our project, and the only version we can
use now is 2.5.6 because of bug with {{\@CompileStatic}} wich is reproducible
with the following code:
{code:java}
package test;
import groovy.lang.Closure;
import groovy.lang.DelegatesTo;
import groovy.lang.GroovyClassLoader;
import groovy.transform.CompileStatic;
import org.codehaus.groovy.control.CompilerConfiguration;
import org.codehaus.groovy.control.customizers.ASTTransformationCustomizer;
import org.codehaus.groovy.runtime.InvokerHelper;
public class Main {
private static final String script = "" +
"import test.Main\n" +
"\n" +
"new Main().enter {\n" +
"nest {\n" +
"nest {\n" +
"nest {\n" +
"println(\"REACHED\")\n" +
"}\n" +
"}\n" +
"}\n" +
"}\n";
public static void main(String[] args) {
CompilerConfiguration config = new CompilerConfiguration();
config.addCompilationCustomizers(new
ASTTransformationCustomizer(CompileStatic.class));
GroovyClassLoader loader = new
GroovyClassLoader(Main.class.getClassLoader(), config);
Class cls = loader.parseClass(script, "file");
InvokerHelper.runScript(cls, new String[0]);
}
public void enter(@DelegatesTo(Root.class) Closure closure) {
Root scope = new Root();
closure.setDelegate(scope);
closure.run();
}
public static class Outer extends Main {
private final Main parent;
Outer() {
this.parent = null;
}
Outer(Outer parent) {
this.parent = parent;
}
public void nest(@DelegatesTo(Inner.class) Closure closure) {
closure.setDelegate(new Inner(this));
closure.run();
System.out.println(this + ": " + parent);
}
}
public static class Inner extends Outer {
public Inner(Outer parent) {
super(parent);
}
}
public static class Root extends Outer {
Root() {
}
}
}
{code}
till version 2.5.6 it prints:
{noformat}
REACHED
test.Main$Inner@7582ff54: test.Main$Inner@67545b57
test.Main$Inner@67545b57: test.Main$Root@6c2c1385
test.Main$Root@6c2c1385: null
{noformat}
but starting with 2.5.7 it prints:
{noformat}
REACHED
test.Main$Root@2f67b837: null
test.Main$Root@2f67b837: null
test.Main$Root@2f67b837: null
{noformat}
The workaround is to turn off static compilation, but it degrades performance
because some handles are defined using this DSL and they are called very often.
Thanks in advance!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GROOVY-8698) Double class initialization using groovy.lang.GroovyClassLoader
Ivan Kuznetsov created GROOVY-8698: -- Summary: Double class initialization using groovy.lang.GroovyClassLoader Key: GROOVY-8698 URL: https://issues.apache.org/jira/browse/GROOVY-8698 Project: Groovy Issue Type: Bug Affects Versions: 2.5.0, 2.4.15, 2.3.4 Environment: OS: Windows 7, JVM: OpenJDK 10.0.1, Groovy: 2.5.0 Reporter: Ivan Kuznetsov Attachments: output.txt, test.zip I'm integrating Groovy DSL into developing java application, and I'm faced with this issue when did test runs. What I'm trying to do: 1. GroovyClassLoader reads and parses all .groovy scripts from file system; some of these scripts - real scripts (class Script), others - real classes/enums; 2. instantiates and runs only Script classes, others are left as is in class loader. I'm expecting that all scripts will use the same instances (in static fields or enums) of common classes to which they refer and which located in outer scripts. But, first created Script instance loads its own class from outer script, initializes it and uses it, but all other Script instances use loaded classes and its static instances on step 1. This is reproducible on specified 'affected' versions, so I suppose that it affects all versions. I've created sample project and attached to this issue to show what's going on. This application does above steps. Scripts 'model.concrete1.ConcreteModel1.groovy' and 'model.concrete2.ConcreteModel2.groovy' are shared classes, other files are scripts that refer to these shared classes and print class'es hash code. When you run application, you will see output in which FirstScript refers to its own ConcreteModel class and other scripts refer to ConcreteModel class that holds GroovyClassLoader. If you rename FirstScript.groovy to WFirstScript.groovy, order will change and, at this moment, MainScript.groovy instead of FirstScript.groovy will use its own class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
