|
View:
New views
5 Messages
—
Rating Filter:
Alert me
|
|
|
Bug in Joint Compiler?My code is failing in odd ways and it looks like it is a problem in the joint
compiler. If this is a known problem please let me know. If this is something I am doing wrong, please let me know. The problem I am seeing is this: 1) I do a clean build on my source tree which rebuilds all groovy files and java files. 2) I run my application and one of the groovy classes has trouble accessing properties in one of it's ancestor classes (throws a GroovyCastException). 3) If I now force recompilation of only the offending groovy file by using "touch" and do a recompile the code works fine in my application. 4) If I don't use groovy style properties but use the underlying get/set methods the problem never appears. Any suggestions or ideas? I have attached code which replicates this problem. The dobug.groovy file runs the whole process, the build.xml is a standard ant build file, and the Base and Derived files are the source code. You may have to play with the paths in build.xml and dobug.groovy to match the setup on your machine. My environment: OS: Kubuntu 8.04 (Hardy Heron) Architecture: x86 JVM: java version "1.6.0" OpenJDK Runtime Environment (build 1.6.0-b09) OpenJDK Server VM (build 1.6.0-b09, mixed mode) Groovy: Groovy Version: 1.5.6 JVM: 1.6.0-b09 The original problem showed up on a Sun JDK/JVM. -- David [Base.java] public class Base { private String var; public void setVar(String var) { this.var = var; } public String getVar() { return var; } } <project name="Joint Compiler Test" default="compile" basedir="."> <description>Joint Compiler Test</description> <target name="compile"> <taskdef name="groovyc" classname="org.codehaus.groovy.ant.Groovyc" classpath="lib/groovy-all-1.5.6.jar"/> <groovyc destdir="." srcdir="." classpath="lib/groovy-all-1.5.6.jar"> <javac debug="${debug.symbols}" deprecation="${deprecation.warnings}" /> </groovyc> </target> <target name="clean"> <delete> <fileset dir="." includes="**/*.class"/> </delete> </target> </project> [Derived.groovy] public class Derived extends Base { public void task() { ["SUCCESSFULLY ASSIGNED VAR"].each { var = it; }; //tries to cast it to Base, GroovyCastException //["SUCCESSFULLY ASSIGNED VAR"].each { setVar(it); }; //correctly finds method and invokes it println(var); } public static void main(String[] args) { new Derived().task(); } } def javaCmd = "java -cp .:lib/groovy-all-1.5.6.jar Derived"; def antCmd = "ant compile"; def antClean = "ant clean"; def exec(def cmd) { def p = cmd.execute(); p.consumeProcessOutput(System.out, System.err); p.waitFor(); } def touch(def names) { names.each { new File(it).lastModified = System.currentTimeMillis(); }; } println("******GENERATE CLASS FILES ******"); exec(antClean) exec(antCmd); sleep(2000) println(); println("****** FIRST PASS, SHOULD FAIL WITH GroovyCastException ******"); touch(["Base.java", "Derived.groovy"]); exec(antCmd); exec(javaCmd); sleep(2000); println(); println("****** SECOND PASS ******"); touch(["Derived.groovy"]); exec(antCmd); exec(javaCmd); --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Bug in Joint Compiler?David Clark schrieb:
> My code is failing in odd ways and it looks like it is a problem in the joint > compiler. If this is a known problem please let me know. If this is > something I am doing wrong, please let me know. > > The problem I am seeing is this: > > 1) I do a clean build on my source tree which rebuilds all groovy files and > java files. > > 2) I run my application and one of the groovy classes has trouble accessing > properties in one of it's ancestor classes (throws a GroovyCastException). what does the GroovyCastException say? "tries to cast it to Base" is usually not the full story... there should be two types mentioned > 3) If I now force recompilation of only the offending groovy file by > using "touch" and do a recompile the code works fine in my application. > > 4) If I don't use groovy style properties but use the underlying get/set > methods the problem never appears. that indeed looks strange... bye blackdrag -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ http://www.g2one.com/ --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Bug in Joint Compiler?On Monday 30 June 2008, Jochen Theodorou wrote:
> what does the GroovyCastException say? "tries to cast it to Base" is > usually not the full story... there should be two types mentioned Exception in thread "main" org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'SUCCESSFULLY ASSIGNED VAR' with class 'java.lang.String' to class 'Base' Base is the name of the base class. Full stack trace: at org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:340) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.castToType(ScriptBytecodeAdapter.java:635) at Derived$_task_closure1.doCall(Derived.groovy) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86) at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:230) at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:248) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:756) at groovy.lang.Closure.call(Closure.java:292) at groovy.lang.Closure.call(Closure.java:305) at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:1079) at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:1056) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.codehaus.groovy.runtime.metaclass.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:51) at org.codehaus.groovy.runtime.metaclass.NewInstanceMetaMethod.invoke(NewInstanceMetaMethod.java:54) at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:230) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:912) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:756) at org.codehaus.groovy.runtime.InvokerHelper.invokePojoMethod(InvokerHelper.java:766) at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:754) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:170) at Derived.task(Derived.groovy:4) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86) at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:230) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:912) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:756) at org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:778) at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:758) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:170) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethod0 (ScriptBytecodeAdapter.java:198) at Derived.main(Derived.groovy:10) -- David --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Bug in Joint Compiler?David Clark schrieb:
> On Monday 30 June 2008, Jochen Theodorou wrote: >> what does the GroovyCastException say? "tries to cast it to Base" is >> usually not the full story... there should be two types mentioned > > Exception in thread "main" > org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast > object 'SUCCESSFULLY ASSIGNED VAR' with class 'java.lang.String' to > class 'Base' > > Base is the name of the base class. So a String is used where Base should be used. I reduced the trace to this: > at > org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:340) > at > org.codehaus.groovy.runtime.ScriptBytecodeAdapter.castToType(ScriptBytecodeAdapter.java:635) > at Derived$_task_closure1.doCall(Derived.groovy) > at groovy.lang.Closure.call(Closure.java:292) > at > org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:1079) > at Derived.task(Derived.groovy:4) > at Derived.main(Derived.groovy:10) that means the cast happens inside the compiler generated doCall method... most likely before the real doCall method would be called... so it should be the line: ["SUCCESSFULLY ASSIGNED VAR"].each { var = it; }; The only reason I can imagine that this happens is because there is somewhere a side effect which changes the type "it"... or "var"... If it is "var", then we should take a look at why the line numer does not show up... well, might be related to the problem. Anyway "var"is of type String and it somehow gets changed to Base... hmm... Frankly, I have no idea why this happens. Clear is, it should not... no... it must not.... can you please fill a bug report for this... I will try to adress this problem soon. bye blackdrag -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ http://www.g2one.com/ --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Bug in Joint Compiler?On Tuesday 01 July 2008, Jochen Theodorou wrote:
> that means the cast happens inside the compiler generated doCall > method... most likely before the real doCall method would be called... > so it should be the line: > > ["SUCCESSFULLY ASSIGNED VAR"].each { var = it; }; I agree. The generated code should simply be calling setVar(String var) in Base using "it" as the argument. > The only reason I can imagine that this happens is because there is > somewhere a side effect which changes the type "it"... or "var"... If it > is "var", then we should take a look at why the line numer does not show > up... well, might be related to the problem. Anyway "var"is of type > String and it somehow gets changed to Base... hmm... Frankly, I have no > idea why this happens. Clear is, it should not... no... it must not.... > can you please fill a bug report for this... I will try to adress this > problem soon. I created GROOVY-2935, the bug was automatically assigned to you. -- David --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
| Free Forum Powered by Nabble | Forum Help |