On 06/21/2016 11:34 PM, Winnebeck, Jason wrote:
I can say as someone who writes Groovy on a daily basis for about a
year now on a project that uses CompileStatic by default on a team of
6-10 that we haven’t had many problems forgetting @CompileStatic or
been too annoyed with it. Although as I’ve said in earlier post, we
have forgotten once or twice and that did have a substantial impact.
In your IDE you can even create a file template for Groovy class to
add @CompileStatic for you. It’s not bad and IDE support follows.
Therefore, I would say current Groovy support is good enough for those
looking for a static language. For us using something like compiler
configuration would just confuse things, especially since it is likely
invisible to IDE.
Ok, 6-10 people. But in companies such as Volvo, Mercedes, Boeing,
Walmart, UPS, FedEX, DHL they have a department that specifically
chooses what they can and cannot use, because those tools once allowed,
will be totally out of their control.
Some projects could then live in silence for years and you have no way
of knowing what they are using and not using.
Handing a potentially lethal weapon to so many devs, many of whom only
have basic programming skills, then you will end up having a serious
problem eventually. Especially when that code gets handed over to
someone else, then someone else and it keeps piling up.
Groovy's problem has always been it's lack of adoption in the
enterprise. Nobody would code Java to begin if it wasn't so big in the
enterprise world. There are other languages to choose from. Now imagine
a replacement. Once I started in one of these companies, I had to code
in Java.
I pushed really hard for Groovy and Grails and it actually were adopted
to be used for smaller applications, but not many ended up going that
route and today I don't think that was a good recommendation.
Now I code as a consultant and I demand a static language personally,
because I value that my code will continue to work and be refactorable,
extensiable 10 years from now, even when I forget how to even setup the
project. My personal experience is that groovy code is too fragile, like
Javascript. It has to much global access and there is no control over
anything. Anyone can override things. Even Javascript is moving to
static, and we have TypeScript and other languages popping up getting
traction.
The dynamic features are also so nice to use that it is hard to resist
using them. I know this when I've even tried.
If we can be lazy we will be. Especially when we are tired.
I double rest my case now :P
Jason
*From:*Mr Andersson [mailto:[email protected]]
*Sent:* Tuesday, June 21, 2016 5:31 PM
*To:* [email protected]
*Subject:* Re: Is it possible to enable CompileStatic for an entire
project
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:[email protected]]
*Sent:* Tuesday, June 21, 2016 1:03 PM
*To:* [email protected] <mailto:[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] <mailto:[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] <mailto:[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-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:[email protected]]
*Sent:* Tuesday, June 21, 2016 8:29 AM
*To:* [email protected]
<mailto:[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_compilation_by_default
2016-06-21 14:24 GMT+02:00 Mr Andersson
<[email protected]
<mailto:[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.
