groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Winnebeck, Jason" <>
Subject RE: Is it possible to enable CompileStatic for an entire project
Date Tue, 21 Jun 2016 18:08:33 GMT
I would say that if you use the config script, then it would mean you’d want to use @CompileDynamic
on every class where you don’t want static. It’s a default. I would think once you start
adding logic into a compiler config script like that you’ll get into trouble with users
being confused.

I’m going to say something a little radical: if you want to use static compilation all the
time, you may want to consider Kotlin, which is 1.0 now and similar to Groovy but is static
compiled all the time. No offense to Jochen and other’s amazing work that I think brought
new life to Groovy (I’d probably not be using it all were it not for CompileStatic), I’ve
encountered a handful of compiler bugs unfortunately and still do from time to time, enough
that I’ve learned how to read Java bytecode. I still like the language features of Groovy
better and I haven’t found any solution other than dynamic Groovy to reasonably process
web services/documents though, so I still like Groovy better until it’s possible to combine
Kotlin+Groovy or Kotlin adds dynamic features. If you do use Groovy static compile then make
sure definitely to go with the latest 2.4.7.


From: Mario Garcia []
Sent: Tuesday, June 21, 2016 1:03 PM
Subject: Re: Is it possible to enable CompileStatic for an entire project

If I'm not wrong, projects like Spock doesn't like @CompileStatic so in case I would like
to statically compile my project, at least I should be telling the compiler not to compile
statically my specifications. Something like:

withConfig(configuration) {
    source(unitValidator: { unit -> !unit.AST.classes.any {'Spec') }
}) {

my two cents

2016-06-21 18:44 GMT+02:00 Cédric Champeau <<>>:
A strong -1 for both options. We already have 2 variants of Groovy today, indy and non indy,
and in practice *nobody uses the invokedynamic version* because it's impractical to use. Typically
projects depend on `groovy.jar` or `groovy-all.jar`, not their invokedynamic version. Adding
a new dimension, which is orthogonal to invokedynamic makes it even more complicated. Don't
forget that the Groovy compiler is also mixed in its runtime (which is a problem of its own).
We should solve that first.

Second, IDEs need to know whether a file is statically compiled or not. The `@CompileStatic`
annotation makes it very clear, and the default is the standard dynamic mode that has been
in Groovy for more than 10 years. IDEs know about it, and it's simple to infer. Any alternative
solution, like the config script, or an alternate compiler (!) makes it impossible for the
IDE to guess. The only IDE-pragmatic solution is to have a distinct file extension for statically
compiled Groovy files (say, .sgroovy instead of .groovy). So far this has been ruled out,
but I think it's the most pragmatic, and IDE friendly, solution.

2016-06-21 18:37 GMT+02:00 Mr Andersson <<>>:

On 06/21/2016 02:38 PM, Winnebeck, Jason wrote:
Tying Cédric’s advice to your previous question about gmavenplus and joint compilation,
per you add the configuration
tag with a reference to your groovy script.
I also mentioned that I could not get Gmavenplus to work, but maybe i did something wrong.
But I literally copied and pasted that section.

Actually about 90+% of our code base in Groovy is CompileStatic I wonder if we should use
that. Cédric, if we use the config script method, is it still possible to use the “skip”
annotation to switch back to dynamic mode? Even if it worked, I highly doubt IntelliJ IDEA
would know about it and think all files are dynamic typing so probably it’s still best for
us to add @CompileStatic everywhere, but sometimes we forget where we wanted it. The performance
difference is extreme when we forget it, on a certain class we missed recently it took our
page rendering times from about 4ms to 52ms, so for us it’s an actual “bug” to forget
to add @CompileStatic.

The problem with  the ANT task is that I don't think I can set classpath argumetns to the
actual so passing the config location is a problem that needs be resolved. Not that easy with

Groovy should instead provide a default GroovyStatic-2.4.4.jar file that enables this by default.
That way everybody wins, and Groovy could join the club of static languages and not get rejected
by those that needs to get Groovy.

It is also messy to set up config files for every maven module, although I am not sure. The
code in that config file is also not dynamic.

withConfig(configuration) { ast(groovy.transform.CompileStatic) } and a simple option -compileStatic
that uses an internal version of that file is preferable and SIMPLER.

groovyc -configscript src/conf/config.groovy src/main/groovy/MyClass.groovy
Is not needed here.


From: Cédric Champeau []
Sent: Tuesday, June 21, 2016 8:29 AM
Subject: Re: Is it possible to enable CompileStatic for an entire project

It's in the docs:

2016-06-21 14:24 GMT+02:00 Mr Andersson <<>>:
Is it possible to enable CompileStatic for an entire project?

Or do you have to do it on a per class basis?

I like Groovy for some of it's features, and mostly for it's close to Java syntax but I would
really like it to be a static language.

I've heard about Groovy++ but I believe that's dead by now, no?

Question is wether you can tell the Groovy compiler with a flag to treat all Groovy classes
on certain paths as static?

Preferable doable from ANT too.

This email message and any attachments are for the sole use of the intended recipient(s).
Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all copies of the
original message and any attachments.

View raw message