Bug in Joint Compiler?

View: New views
5 Messages — Rating Filter:   Alert me  

Bug in Joint Compiler?

by David Clark-9 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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?

by Jochen Theodorou :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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?

by David Clark-9 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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?

by Jochen Theodorou :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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?

by David Clark-9 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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


LightInTheBox - Buy quality products at wholesale price