Use other groovyc compiler

Hi all,

I'm using IJ13.1

I run into an issue where the provided groovy compiler can not handle the code. I'm not sure whether it is due to the use of the static compilation feature or not. Until now it was not a problem. No matter the reason, now compilation breaks down with a StackOverflowError :( But compilation with the eclipse groovy compiler through maven work just fine.

Right now I replaced the "make" in the "Before launch" property for my run configuration with a maven goal. That works. But I'd like to IJ's compiler. I did not find a Setting to replace groovyc like it exists for javac (eclipse/javac/ajc). Is there a way to replace the groovy version that comes with IJ? Like replacing the jars in the lib for instance?

Regards,

Johan

8 comments
Comment actions Permalink

Hi, Johan.

Unfortunately there's no way to use another Groovy compiler (apart from using another version of it, which you can control by placing it in your classpath). You can vote/watch http://youtrack.jetbrains.com/issue/IDEA-52379

We could try to fix the underlying issue instead. Are you using static extensions via org.codehaus.groovy.runtime.ExtensionModule?

0
Comment actions Permalink

Hi Peter,

Ok, let's try to fix it that would be nice. I can try to create a minimalistic version that reproduces the issue. I'll post it here

Johan

0
Comment actions Permalink

That would be very nice. Please check if it's the same as http://youtrack.jetbrains.com/issue/IDEA-120443 (just fixed)

0
Comment actions Permalink

Well, I'm having a hard creating a minimal example that could give you for the moment. I guess the devil is in the details :(

But to answer your last question in the thread: I don't use ExtensionModule of my own. I do use @CompileStatic and generics quite a bit. In that sense it is a bit like the case you referred to.

In case it is the same problem, how could I give things a try? Pulling IJ CE code from github is not an option for me here @job. The connection is way too slow :(

A pruned version of the stacktrace in case it would ring a bell. I'll try some more reproduce it with a smaller case

Information:Groovyc: java.lang.reflect.InvocationTargetException
 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:606)
 at org.jetbrains.groovy.compiler.rt.GroovycRunner.main(GroovycRunner.java:100)
 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:606)
 at com.intellij.rt.execution.CommandLineWrapper.main(CommandLineWrapper.java:121)
Caused by: java.lang.StackOverflowError
 at org.codehaus.groovy.ast.ClassNode.getText(ClassNode.java:1462)
 at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:678)
 at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:675)
 at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1157)
 at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1134)
....
 at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1160)
 at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1134)
 at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1120)
 at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1139)
 at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1160)
 at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1134)
 at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1120)
 at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1139)
 at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1160)

0
Comment actions Permalink

The stacktrace looks like a bug in Groovy compiler. I'm not sure if we can work around it in IDEA. A similar http://stackoverflow.com/questions/22226931/stackoverflowerror-on-groovy-while-passing-a-generic-class-argument-to-method suggests there might be a type error which groovyc fails to report. A reproducible sample would still be nice to understand whether this should be filed to Groovy developers and if a workaround is possible.

0
Comment actions Permalink

Yes, submitting to the groovy devs make sense to me. The thing is with the more recent groovyc provided through the maven build things work. That's why I was wondering how I could replace the groovyc version used with IJ.

Can you explain how IJ determine which groovyc to use since there is not explicit settings for that? You mentioned using the classpath to replace groovy. Where does the "default" groovy come from? There is a GroovycRunner class where the magic happens but figuring it all out is leading me a bit too far. Many thanks

0
Comment actions Permalink

There is no "default" Groovyc. IDEA searches for Groovy jars in your module dependencies and uses Groovy compiler from them. GroovycRunner is IDEA's internal class that launches Groovy compiler classes.

0
Comment actions Permalink

Ok that's clear. Thank you

0

Please sign in to leave a comment.