ast transformation doesn't work in groovy-java project

[originalrusyn]

Can't compile my project

https://github.com/originalrusyn/mix/tree/greclipse

➜  mix git:(greclipse) ✗ mvn clean install
[INFO] Scanning for projects...
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building mix 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ mix ---
[INFO] Deleting /Users/m/git_repo/mix/target
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ mix ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO] 
[INFO] --- maven-compiler-plugin:3.5.1:compile (default-compile) @ mix ---
[INFO] Changes detected - recompiling the module!
[INFO] Using Groovy-Eclipse compiler to compile both Java and Groovy files
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR : 
[INFO] -------------------------------------------------------------
[ERROR] /Users/m/git_repo/mix/src/main/java/B.java:[7,1] 1. ERROR in /Users/m/git_repo/mix/src/main/java/B.java (at line 7)
        F.FBuilder builder = F.builder();
        ^^^^^^^^^^
F.FBuilder cannot be resolved to a type

[ERROR] /Users/m/git_repo/mix/src/main/java/B.java:[7,24] 2. ERROR in /Users/m/git_repo/mix/src/main/java/B.java (at line 7)
        F.FBuilder builder = F.builder();
                               ^^^^^^^
The method builder() is undefined for the type F
[ERROR] Found 2 errors and 0 warnings.
[INFO] 3 errors 
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.532 s
[INFO] Finished at: 2016-05-11T09:13:09+02:00
[INFO] Final Memory: 13M/76M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.5.1:compile (default-compile) on project mix: Compilation failure: Compilation failure:
[ERROR] /Users/m/git_repo/mix/src/main/java/B.java:[7,1] 1. ERROR in /Users/m/git_repo/mix/src/main/java/B.java (at line 7)
[ERROR] F.FBuilder builder = F.builder();
[ERROR] ^^^^^^^^^^
[ERROR] F.FBuilder cannot be resolved to a type
[ERROR] 
[ERROR] /Users/m/git_repo/mix/src/main/java/B.java:[7,24] 2. ERROR in /Users/m/git_repo/mix/src/main/java/B.java (at line 7)
[ERROR] F.FBuilder builder = F.builder();
[ERROR] ^^^^^^^
[ERROR] The method builder() is undefined for the type F
[ERROR] 
[ERROR] Found 2 errors and 0 warnings.
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException

[eric-milles]

This type of interoperability is not possible with current Groovy. Even if you compiled with bare groovyc it should fail. AST transforms that add methods late (I think after semantic analysis phase) like @builder, @TupleConstructor, @singleton and many others can only be used within the same project by Groovy sources. Your example would work if you split the builder into a separate project, so the Java source was forced to work with the .class of the builder.

[Blacktiger]

@eric-milles the groovy docs for @builder indicate that this is supposed to work so should this be considered a compiler bug or a documentation bug?

But if you need Java integration or in some cases improved type safety, the @builder transform might prove very useful.

[eric-milles]

A lot of transforms like @builder are described in a purely Groovy context. They do certainly work as described Groovy to Groovy. But Groovy to Java interoperability does not work as you may intuit it does. I wish it worked as you described. And there is certainly a path in Groovy-Eclipse to make it work that way. The trouble is if we did something that the vanilla groovyc did not support, there would be a lot of problems.

[Blacktiger]

@eric-milles thanks, I guess I'll open an issue against the groovy project to fix the documentation then since it specifically suggests using the @builder transform for Java interop.

[eric-milles]

If you want to use it today interoperably, you can create a separate project to hold the types that you want to use @builder or @immutable or whatnot on. Full compilation on the separate project allows the project you are in now to see complete class files instead of incomplete stub representations.

[Blacktiger]

Thanks @eric-milles, that is one of the options we were considering.

[blackdrag]

@eric-milles when you say "The trouble is if we did something that the vanilla groovyc did not support, there would be a lot of problems." then I say that it depends if that is trouble or not. I am working, with very low priority, on a compiler that can solve this kind of issue, but this would be also more than pure groovyc can do. And just because of that I don´t consider that compiler trouble.

[eric-milles]

What I mean by that is if something works within Eclipse but fails as part of an Ant or Gradle or whatever build that leverages Groovyc, I consider that a problem. Certainly I understand the push for better compilers. At this time, if I find a difference between the Eclipse compiler and Groovyc, my instinct is to makes changes to ensure parity. Within my workplace, we use Eclipse for Java/Groovy development and Ant for CI builds/deploys. So we look to have a consistent experience between how a project runs in the IDE and how it will compile and test on the CI server.

[blackdrag]

The problem is that our current joint compilation approach solves a lot of problems, but it is not a satisfying solution to me at all.

• We have to create stubs in which we write unresolved class names for example. It could happen, that Groovy and Java disagree about the meaning here for example.
• Sometimes the stubs fail compilation because the stubs cannot always contain enough information to make javac happy. Which means the user has to adapt perfectly valid groovy files to satisfy a downstream javac.
• And the biggest point is the ast transforms issue of course.

All of those I see as solvable doing a tighter integration with something that understands Java source code or can teach a Java compiler some Groovy. So really, if the differing feature is that groovy-eclipse supports transforms better than groovyc for joint compilation I am more than happy... of course only as long the compiler is also supported outside the IDE, yes.

[eric-milles]

I don't like the current state of joint compilation and would very much like to see it improved. All the nicities that drew me to Groovy like @builder, @TupleConstructor, traits and so forth have a hard time playing with Java in the same project. If they worked as they are described in the groovydocs and demoed in a pure Groovy environment, the case for Groovy would be much stronger (around my workplace). If groovy-eclipse can be a part of the move towards better joint compliation, that's great. I do see some bits of code that have been disabled because they offer more in terms of joint compilation support than groovyc does. I am reluctant to enable them without hearing from Andy Clement why exactly they were disabled. Similarly, retaining any functional difference from groovyc without some kind of compiler options seems dangerous as I described previously.