[jira] [Commented] (GROOVY-7764) Joint compilation does not work with AST-transformed Groovy
[
https://issues.apache.org/jira/browse/GROOVY-7764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16604316#comment-16604316
]
Christopher Smith commented on GROOVY-7764:
---
This is a blocker for some of my use cases as well. I have a minimal
demonstrable use case [with my
{{@GbtVersion}}|https://github.com/chrylis/groovybeans-toolkit] transform,
which is essentially the same as {{@Slf4j}} but adds an externally visible
{{@Version}} property. Stubs don't include the version accessors (and, more
crucially, the ID accessors). The transformation runs during SEMANTIC_ANALYSIS.
> Joint compilation does not work with AST-transformed Groovy
> ---
>
> Key: GROOVY-7764
> URL: https://issues.apache.org/jira/browse/GROOVY-7764
> Project: Groovy
> Issue Type: Bug
> Components: Stub generator / Joint compiler
>Affects Versions: 2.4.6
>Reporter: O. Reißig
>Priority: Major
> Attachments: foo.zip
>
>
> When using AST transformations together with joint compilation the generated
> stubs don't mind the transformations, which may yield invalid classes, that
> javac will fail to compile.
> Example:
> {code}
> [...]
> class GroovyTest implements Callable {
> @Delegate
> private final Callable c = { println "Hello World" }
> }
> {code}
> will get compiled into the following stub:
> {code}
> [...]
> public class GroovyTest
> extends java.lang.Object implements
> java.util.concurrent.Callable,groovy.lang.GroovyObject {
> ;
> public groovy.lang.MetaClass getMetaClass() { return
> (groovy.lang.MetaClass)null;}
> public void setMetaClass(groovy.lang.MetaClass mc) { }
> public java.lang.Object invokeMethod(java.lang.String method,
> java.lang.Object arguments) { return null;}
> public java.lang.Object getProperty(java.lang.String property) { return
> null;}
> public void setProperty(java.lang.String property, java.lang.Object value) {
> }
> }
> {code}
> which claims to implement {{Callable}}, but lacks a {{call}} method.
> I don't know if this is specific to {{@Delegate}}, but noticed similar
> behaviour with {{@InheritConstructors}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-7764) Joint compilation does not work with AST-transformed Groovy
[
https://issues.apache.org/jira/browse/GROOVY-7764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16170630#comment-16170630
]
Jochen Theodorou commented on GROOVY-7764:
--
ResolveVisitor will fail compilation if a class cannot be resolved.
ResolveVisitor is the first thing being done in Semantic Analysis. For stub
compilation we do this actually a little bit different. We first start
resolving in an no-error mode, which means all the errors found by
ResolveVisitor will not be reported. And we do this already in the step
Conversion. So in theory a transform could run in Conversion already.
There are problems with this though:
* Not all classes will be resolved, the transform would require special handling
* ResolveVisitor is one of the most expensive steps during compilation, doing
it twice will make compilation take almost twice as long
* This early resolving step introduces unstable semantics.
With unstable semantics I mean...
Assume you have import a.* and b.* and there is a class a.Foo and b.Foo and you
use the vanilla Foo. Then this is supposed to fail compilation, because it is
unclear if you did mean a.Foo or b.Foo. But with early resolving and one of the
Foo classes being written in Java, it is possible that the compilation will
succeed, because the compiler sees only one Foo and there is nothing unclear
for the compiler what Foo you mean. But if both are Groovy or Java, it would
fail. And in an incremental compilation step based on files this could also
work one time and one time not.
Another example would be the vanilla name Script and import a.*, with an
a.Script written in Java. Because default imports are shadowed by explicit
imports this now does not fail compilation if the compiler does see a.Script.
But the problem is that the vanilla name Script will be compiled to
groovy.lang.Script if a.Script is not known at this point. Obviously you get
this problem in stub generation today already. But it can be fixed by an
explicit import. Here the compiler knows then the full name, without having to
resolve the class.
Of course other information of the resolve step could be also very important.
static imports, variables scopes, resolving inner classes, knowing if something
that might be a class or variable is actually a variable and so on. I am
ignoring this here, but they are potentially important too.
This can be all fixed by throwing away all the resolving information from the
early resolve and resolve again of course, but that will probably about double
compilation time.
Then there is of course the minimal variant... we try to resolve only the
annotations, to see if they are actually describing transforms and then
applying the transforms. This basically has the same shadowing problems, they
are just happening in a smaller scope, with less possibility for collisions,
thus will not happen so often. We would still not get a correct compilation
from this of course. And conversion means what conversion means, which is that
there is only the raw AST.
Then what transforms would work in this mode?
could work:
* ToString
* EqualsAndHashCode
* TupleConstructor
* Canonical
* IndexedProperty
* Lazy
* Sortable
* Buildere
* Memoized
* Singleton
* Log
* Synchronized
* WithReadLock
* WithWriteLock
* AutoClone
* AutoExternalize
* Field
* PackageScope
* CompileDynamic
* Bindable
* ListenerList
* Vetoable
* NotYetImplemented
* ASTTest
* Grab and related, but it will not actually provide anything
cannot work reliably:
* InheritConstructors
* Category
* Newify
* Delegate
* Immutable
* Mixin
* ThreadInterrupt, TimedInterrupt, ConditionalInterrupt
* TypeChecked
Yes, the list is pretty long
> Joint compilation does not work with AST-transformed Groovy
> ---
>
> Key: GROOVY-7764
> URL: https://issues.apache.org/jira/browse/GROOVY-7764
> Project: Groovy
> Issue Type: Bug
> Components: Stub generator / Joint compiler
>Affects Versions: 2.4.6
>Reporter: O. Reißig
> Attachments: foo.zip
>
>
> When using AST transformations together with joint compilation the generated
> stubs don't mind the transformations, which may yield invalid classes, that
> javac will fail to compile.
> Example:
> {code}
> [...]
> class GroovyTest implements Callable {
> @Delegate
> private final Callable c = { println "Hello World" }
> }
> {code}
> will get compiled into the following stub:
> {code}
> [...]
> public class GroovyTest
> extends java.lang.Object implements
> java.util.concurrent.Callable,groovy.lang.GroovyObject {
> ;
> public groovy.lang.MetaClass getMetaClass() { return
> (groovy.lang.MetaClass)null;}
> public void setMetaClass(groovy.lang.MetaClass mc) { }
> public java.lang.Object invokeMethod(java.lang.String method,
> java.lang.Object arguments)
[jira] [Commented] (GROOVY-7764) Joint compilation does not work with AST-transformed Groovy
[
https://issues.apache.org/jira/browse/GROOVY-7764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169304#comment-16169304
]
Eric Milles commented on GROOVY-7764:
-
I'm guessing that the Java stub is created for a Groovy source just after
Conversion. Is it possible to bump this up to Semantic Analysis or
Canonicalization? At least then some of the basic transforms would have been
applied. Or would this be creating the reverse dependency on the Java sources
as you just described?
> Joint compilation does not work with AST-transformed Groovy
> ---
>
> Key: GROOVY-7764
> URL: https://issues.apache.org/jira/browse/GROOVY-7764
> Project: Groovy
> Issue Type: Bug
> Components: Stub generator / Joint compiler
>Affects Versions: 2.4.6
>Reporter: O. Reißig
> Attachments: foo.zip
>
>
> When using AST transformations together with joint compilation the generated
> stubs don't mind the transformations, which may yield invalid classes, that
> javac will fail to compile.
> Example:
> {code}
> [...]
> class GroovyTest implements Callable {
> @Delegate
> private final Callable c = { println "Hello World" }
> }
> {code}
> will get compiled into the following stub:
> {code}
> [...]
> public class GroovyTest
> extends java.lang.Object implements
> java.util.concurrent.Callable,groovy.lang.GroovyObject {
> ;
> public groovy.lang.MetaClass getMetaClass() { return
> (groovy.lang.MetaClass)null;}
> public void setMetaClass(groovy.lang.MetaClass mc) { }
> public java.lang.Object invokeMethod(java.lang.String method,
> java.lang.Object arguments) { return null;}
> public java.lang.Object getProperty(java.lang.String property) { return
> null;}
> public void setProperty(java.lang.String property, java.lang.Object value) {
> }
> }
> {code}
> which claims to implement {{Callable}}, but lacks a {{call}} method.
> I don't know if this is specific to {{@Delegate}}, but noticed similar
> behaviour with {{@InheritConstructors}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-7764) Joint compilation does not work with AST-transformed Groovy
[
https://issues.apache.org/jira/browse/GROOVY-7764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169025#comment-16169025
]
Jochen Theodorou commented on GROOVY-7764:
--
The only way I see to fix this is to give up on stubbed compilation. In that
way the groovy compiler needs to be fed with all the information it needs for
compilation, which includes information about java files. In an environment
like eclipse I see this having the possibility to work. Independent of an IDE
we would need a java parser, that creates an at least partially filled AST. I
am actually working on something like that, but progress is slow, since I do
not have enough time to get something really done here these days. IF somebody
knows an alternative solution, any idea is welcome.
But maybe I explain one more time the technical reason why things are as they
are.. To compile a class "class Foo extends Bar" I need to know what Bar means.
If Bar is a java class and maybe Bar depends on a Groovy class again, then the
Groovy compiler alone cannot get this information anymore. So we do a trick
here. We create a stub for all Groovy classes and call the java compiler to
compile everything for us. After that we have a Bar class file we can inspect
and extract the exact information from. With this information we can then
compile the Groovy classes.
Transforms that act after the phase we use to generate the stubs in cannot be
reflected in the stubs. That is basically for everything that depends on
classes. The normal local transform is triggered by the class of the
annotation. So for those it is always after stub generation. That is why the
problem is so annoying.
> Joint compilation does not work with AST-transformed Groovy
> ---
>
> Key: GROOVY-7764
> URL: https://issues.apache.org/jira/browse/GROOVY-7764
> Project: Groovy
> Issue Type: Bug
> Components: Stub generator / Joint compiler
>Affects Versions: 2.4.6
>Reporter: O. Reißig
> Attachments: foo.zip
>
>
> When using AST transformations together with joint compilation the generated
> stubs don't mind the transformations, which may yield invalid classes, that
> javac will fail to compile.
> Example:
> {code}
> [...]
> class GroovyTest implements Callable {
> @Delegate
> private final Callable c = { println "Hello World" }
> }
> {code}
> will get compiled into the following stub:
> {code}
> [...]
> public class GroovyTest
> extends java.lang.Object implements
> java.util.concurrent.Callable,groovy.lang.GroovyObject {
> ;
> public groovy.lang.MetaClass getMetaClass() { return
> (groovy.lang.MetaClass)null;}
> public void setMetaClass(groovy.lang.MetaClass mc) { }
> public java.lang.Object invokeMethod(java.lang.String method,
> java.lang.Object arguments) { return null;}
> public java.lang.Object getProperty(java.lang.String property) { return
> null;}
> public void setProperty(java.lang.String property, java.lang.Object value) {
> }
> }
> {code}
> which claims to implement {{Callable}}, but lacks a {{call}} method.
> I don't know if this is specific to {{@Delegate}}, but noticed similar
> behaviour with {{@InheritConstructors}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-7764) Joint compilation does not work with AST-transformed Groovy
[
https://issues.apache.org/jira/browse/GROOVY-7764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169018#comment-16169018
]
David Kron commented on GROOVY-7764:
I cannot agree more with Eric Miles. We have some Groovy/Grails projects which
rely heavily on AST transformations to simplify our business domain layer. But
because of this, we are unable to use some awesome annotation processing
libraries like Dagger, Immutables or MapStruct.
In the end, we had to decide for each project what was more important and had
to either miss out on a useful library or port some code back to Java.
> Joint compilation does not work with AST-transformed Groovy
> ---
>
> Key: GROOVY-7764
> URL: https://issues.apache.org/jira/browse/GROOVY-7764
> Project: Groovy
> Issue Type: Bug
> Components: Stub generator / Joint compiler
>Affects Versions: 2.4.6
>Reporter: O. Reißig
> Attachments: foo.zip
>
>
> When using AST transformations together with joint compilation the generated
> stubs don't mind the transformations, which may yield invalid classes, that
> javac will fail to compile.
> Example:
> {code}
> [...]
> class GroovyTest implements Callable {
> @Delegate
> private final Callable c = { println "Hello World" }
> }
> {code}
> will get compiled into the following stub:
> {code}
> [...]
> public class GroovyTest
> extends java.lang.Object implements
> java.util.concurrent.Callable,groovy.lang.GroovyObject {
> ;
> public groovy.lang.MetaClass getMetaClass() { return
> (groovy.lang.MetaClass)null;}
> public void setMetaClass(groovy.lang.MetaClass mc) { }
> public java.lang.Object invokeMethod(java.lang.String method,
> java.lang.Object arguments) { return null;}
> public java.lang.Object getProperty(java.lang.String property) { return
> null;}
> public void setProperty(java.lang.String property, java.lang.Object value) {
> }
> }
> {code}
> which claims to implement {{Callable}}, but lacks a {{call}} method.
> I don't know if this is specific to {{@Delegate}}, but noticed similar
> behaviour with {{@InheritConstructors}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-7764) Joint compilation does not work with AST-transformed Groovy
[
https://issues.apache.org/jira/browse/GROOVY-7764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16164843#comment-16164843
]
Eric Milles commented on GROOVY-7764:
-
I know this issue is old, but this is one of the biggest cross-compatibility
issues for us. We really like all the new stuff that Groovy offers and we want
to mix it into our Java project where appropriate. However, we have has to
restrain ourselves from using @Delegate, @Immutable, @Builder, @Sortable,
@TupleConstructor, @InheritConstructors and several others that add methods or
interfaces implemented. We have to hold back only because joint compilation of
Java and Groovy fails to account for these additions in the generated stubs.
The end goal is to be able to read the Groovy documentation, find an
interesting transform like @Delegate or @Sortable, and apply it to a pojo to
make a much simpler pogo that lives in the same package (and source folder) as
before. Having to move converted Java classes to another source folder or
project so that AST transforms works as described is a non-starter for us.
> Joint compilation does not work with AST-transformed Groovy
> ---
>
> Key: GROOVY-7764
> URL: https://issues.apache.org/jira/browse/GROOVY-7764
> Project: Groovy
> Issue Type: Bug
> Components: Stub generator / Joint compiler
>Affects Versions: 2.4.6
>Reporter: O. Reißig
> Attachments: foo.zip
>
>
> When using AST transformations together with joint compilation the generated
> stubs don't mind the transformations, which may yield invalid classes, that
> javac will fail to compile.
> Example:
> {code}
> [...]
> class GroovyTest implements Callable {
> @Delegate
> private final Callable c = { println "Hello World" }
> }
> {code}
> will get compiled into the following stub:
> {code}
> [...]
> public class GroovyTest
> extends java.lang.Object implements
> java.util.concurrent.Callable,groovy.lang.GroovyObject {
> ;
> public groovy.lang.MetaClass getMetaClass() { return
> (groovy.lang.MetaClass)null;}
> public void setMetaClass(groovy.lang.MetaClass mc) { }
> public java.lang.Object invokeMethod(java.lang.String method,
> java.lang.Object arguments) { return null;}
> public java.lang.Object getProperty(java.lang.String property) { return
> null;}
> public void setProperty(java.lang.String property, java.lang.Object value) {
> }
> }
> {code}
> which claims to implement {{Callable}}, but lacks a {{call}} method.
> I don't know if this is specific to {{@Delegate}}, but noticed similar
> behaviour with {{@InheritConstructors}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-7764) Joint compilation does not work with AST-transformed Groovy
[
https://issues.apache.org/jira/browse/GROOVY-7764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159533#comment-15159533
]
O. Reißig commented on GROOVY-7764:
---
Sorry, I just saw another issue related to this.
Any update on the matter?
> Joint compilation does not work with AST-transformed Groovy
> ---
>
> Key: GROOVY-7764
> URL: https://issues.apache.org/jira/browse/GROOVY-7764
> Project: Groovy
> Issue Type: Bug
> Components: Stub generator / Joint compiler
>Affects Versions: 2.4.6
>Reporter: O. Reißig
> Attachments: foo.zip
>
>
> When using AST transformations together with joint compilation the generated
> stubs don't mind the transformations, which may yield invalid classes, that
> javac will fail to compile.
> Example:
> {code}
> [...]
> class GroovyTest implements Callable {
> @Delegate
> private final Callable c = { println "Hello World" }
> }
> {code}
> will get compiled into the following stub:
> {code}
> [...]
> public class GroovyTest
> extends java.lang.Object implements
> java.util.concurrent.Callable,groovy.lang.GroovyObject {
> ;
> public groovy.lang.MetaClass getMetaClass() { return
> (groovy.lang.MetaClass)null;}
> public void setMetaClass(groovy.lang.MetaClass mc) { }
> public java.lang.Object invokeMethod(java.lang.String method,
> java.lang.Object arguments) { return null;}
> public java.lang.Object getProperty(java.lang.String property) { return
> null;}
> public void setProperty(java.lang.String property, java.lang.Object value) {
> }
> }
> {code}
> which claims to implement {{Callable}}, but lacks a {{call}} method.
> I don't know if this is specific to {{@Delegate}}, but noticed similar
> behaviour with {{@InheritConstructors}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
