I might see an argument that it could be possible to enhance Groovy static that
preserves much of what Groovy dynamic offers in practice. I would say that I've
never really used runtime metaprogramming, although I can see the case for that
when using Groovy as a scripting engine. I've used duck typing only in one
project before and in that case it was extraordinarily useful and I couldn't
see another way to solve the problem (two very large independently generated
JAXB models that had essentially the same tags). But, for almost all of the
other cases I could see the possibility of an extension to CompileStatic that
says if the compile-time type implements some interface X, then allow any
method call on that, routing to a real method if exists, and invokeMethod (or
maybe missingMethod) if it doesn't. As a test, I tried a CompileStatic program
with GroovyInterceptable and saw that I could not call undefined methods on a
GroovyInterceptable with CompileStatic. Anyway, in these cases I just use
dynamic Groovy today, but if such a static compile feature existed in Groovy I
bet it would cover the majority of cases. More precisely I am thinking about
types like XmlSlurper's return implementing the new marker interface, and
builders as well.
Jason
-----Original Message-----
From: Thibault Kruse [mailto:[email protected]]
Sent: Wednesday, June 22, 2016 3:59 AM
To: [email protected]
Subject: Re: Is it possible to enable CompileStatic for an entire project
I don't think the dynamic nature of Groovy is in general regarded as the
weakest point of Groovy right now. However, I believe a fully static Groovy may
still be preferrable than the dynamic Groovy, mostly from the point of view of
maintaining and extending Groovy in the future, without financial sponsoring.
I would also be wary of shipping more variants of Groovy, the question to me is
whether Groovy should just drop runtime dynamics. It would kind of stop being
Groovy, but it might still be great.
On Tue, Jun 21, 2016 at 11:31 PM, Mr Andersson <[email protected]>
wrote:
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
Kotlin+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:[email protected]]
Sent: Tuesday, June 21, 2016 1:03 PM
To: [email protected]
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 <[email protected]>:
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 <[email protected]>:
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-scrip
t 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:[email protected]]
Sent: Tuesday, June 21, 2016 8:29 AM
To: [email protected]
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_compila
tion_by_default
2016-06-21 14:24 GMT+02:00 Mr Andersson <[email protected]>:
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.
----------------------------------------------------------------------
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.
