groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mr Andersson <mr.andersson....@gmail.com>
Subject Re: Is it possible to enable CompileStatic for an entire project
Date Tue, 21 Jun 2016 21:31:26 GMT


On 06/21/2016 08:08 PM, Winnebeck, Jason wrote:
>
> 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.
>

Exactly my point. I do not want to switch to Kotlin or Scala because you 
would have to learn a new language. Groovy's power is that it is so 
similar to Java "yet as powerful".

If groovy were to make a compilestatic jar file, then it will be more 
attractive to many requiring and liking a statically typed language.

This is the weakest point of groovy right now, and it would win the last 
argument and become a choice for those choosing a statically typed JVM 
language, yet can go into dynamic mode on demand.
>
> Jason
>
> *From:*Mario Garcia [mailto:mario.ggar@gmail.com]
> *Sent:* Tuesday, June 21, 2016 1:03 PM
> *To:* users@groovy.apache.org
> *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 { 
> it.name.endsWith('Spec') } }) {
>
>         ast(CompileStatic)
>
>     }
>
> }
>
> my two cents
>
> Mario
>
> 2016-06-21 18:44 GMT+02:00 Cédric Champeau <cedric.champeau@gmail.com 
> <mailto:cedric.champeau@gmail.com>>:
>
>     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
>     <mr.andersson.002@gmail.com <mailto:mr.andersson.002@gmail.com>>:
>
>         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
>             https://github.com/groovy/GMavenPlus/wiki/Examples#configuration-script
>             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 maven.
>
>         *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.
>
>
>
>
>             Jason
>
>             *From:*Cédric Champeau [mailto:cedric.champeau@gmail.com]
>             *Sent:* Tuesday, June 21, 2016 8:29 AM
>             *To:* users@groovy.apache.org <mailto:users@groovy.apache.org>
>             *Subject:* Re: Is it possible to enable CompileStatic for
>             an entire project
>
>             It's in the docs:
>             http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default
>
>             2016-06-21 14:24 GMT+02:00 Mr Andersson
>             <mr.andersson.002@gmail.com
>             <mailto:mr.andersson.002@gmail.com>>:
>
>                 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.
>


Mime
View raw message