[jira] [Commented] (GROOVY-7966) Change in source order changes output in Java+Groovy joint compilation

["Jochen Theodorou (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GROOVY-7966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563908#comment-15563908 ] 

Jochen Theodorou commented on GROOVY-7966:
------------------------------------------

I assume AbstractThing does in both cases implement GroovyObject. The probable reason is that in your first case the super class information for AbstractThing in Thing got proper resolving information, while in case 2 joint compilation prevented this. Maybe it is the joint compilation resolve visitor marking the super class as resolved, even though it is not. What is supposed to happen is that resolving fails but the error is ignored. A later second resolving will set the proper information for the Groovy side. Ah yes, from the compiler output  version 1 should be the only output.

> Change in source order changes output in Java+Groovy joint compilation
> ----------------------------------------------------------------------
>
>                 Key: GROOVY-7966
>                 URL: https://issues.apache.org/jira/browse/GROOVY-7966
>             Project: Groovy
>          Issue Type: Bug
>    Affects Versions: 2.4.7
>            Reporter: Lóránt Pintér
>
> When compiling these three classes
> AbstractThing.groovy:
> {code}
> class AbstractThing {}
> {code}
> Thing.groovy:
> {code}
> class Thing extends AbstractThing {}
> {code}
> JavaThing.java:
> {code}
> public class JavaThing {}
> {code}
> Two different results are produced for {{Thing.class}} based on the order of the source files provided to the Groovy compiler:
> {code}
> $ groovyc -d output -j AbstrctThing.groovy Thing.groovy JavaThing.java
> $ javap output/Thing.class
> Compiled from "Thing.groovy"
> public class Thing extends AbstractThing {
>   public static transient boolean __$stMC;
>   public Thing();
>   protected groovy.lang.MetaClass $getStaticMetaClass();
>   public groovy.lang.MetaClass super$2$$getStaticMetaClass();
> }
> $ groovyc -d output -j Thing.groovy AbstrctThing.groovy JavaThing.java
> $ javap output/Thing.class
> Compiled from "Thing.groovy"
> public class Thing extends AbstractThing implements groovy.lang.GroovyObject {
>   public static transient boolean __$stMC;
>   public Thing();
>   protected groovy.lang.MetaClass $getStaticMetaClass();
>   public groovy.lang.MetaClass super$2$$getStaticMetaClass();
> }
> {code}
> Notice that when the source for the abstract superclass follows the source of the concrete class, the concrete class ends up implementing {{GroovyObject}}, but not if the order of the two source files is reversed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)