On 06/22/2016 09:59 AM, Thibault Kruse wrote:
I don't think the dynamic nature of Groovy is in general regarded as
the weakest point of Groovy right now.

I do think that's the biggest problem. Groovy was the second largest JVM language in 2010, but it is not really that big anymore, mostly of competition by static languages such as Scala and Kotlin.

People want to be able to refactor without risking of the code eventually breaking totally, and that's the problem with Groovy. Code will eventually become stale and stop working if it is put on layway for a while. No compile time checks is a problem for anyone interested in code quality.

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 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-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]
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]>:

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.









Reply via email to