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 Wed, 22 Jun 2016 16:55:46 GMT


On 06/22/2016 02:35 PM, Winnebeck, Jason wrote:
> I'd say the dynamic features of Groovy are the strongest case for Groovy right now, and
a fully static Groovy would be a mistake because there are already other solutions out there
for that. I'm not sure of any other language out there that can do what can be done with missingMethod
and Closure delegates. For example I just wrote a Groovy script with GroovyMBean, so the ability
to call methods that "don't exist" is very nice for integration cases.

We are talking about choice. Two jar versions, or a classpath option ( 
although I'd like to enforce it from the vendor).

Or a .sgroovy or .groosy or .groovys file ending for those that need it.

I think both these options should be relatively easy to implement on the 
current platform. Just add @CompileStatic on the preprocessing of each 
file.

If you decide to ship a a groovy that threats such files as static, then 
I would still also like a jar version that disallows normal .groovy 
files. @CompileDynamic has to be used in an .sgroovy file in such 
circumstances and it can easily be discovered, as in opposite stupid 
newbie developers start adding groovy files to the project and 2 years 
later some department sees this.

We, at our company can only ship groovy if it is fully static, no way to 
manipulate. It's difficult to hammer it through otherwise. Big 
enterprise JEE companies don't take risks, especially when the tools are 
handed over to 5 000 dev across the globe.

We have to know that nobody will start utility the crazy ( but neat ) 
features of the dynamic parts of Groovy, but we like that it is such a 
powerful language, and easy to learn for any java developer that it 
would be a smash hit.

Groovy's future depends on this. I used to code on Groovy all the time, 
starting with Grails over 10 years ago.

I had alot of useful code that I can never use or pull out, because it's 
just to dynamic. Over time one starts to realize how important it is to 
know at compile time that things will work.

Java is also dynamic in some aspects so the requirement is not 100%, but 
we do need a more statically typed Groovy.

I have been in love with this language, and even wrote my masters thesis 
about it.

It has so much potential, even to replace Java. It's power is it's 
syntax and it's closeness to Java syntax.
Adoption in the Java community would be massive if it were more static.

There would almost be no case for Scala or Kotlin. Add multiple 
inheritance support or traits and that's it.

I am not sure how well, performance wise Groovy does compared with Java, 
Scala, Kotlin, Ceylon and so on. If it is close, then I say just offer 
us a static version with what you have. You are so close now.

But I would still like to argue that maybe Groovy needs to be rewritten 
from scratch in order to perform even better. But I know little about 
this and have little experience with the @CompileStatic annotations  
because I have been away from this language for so long.

I would still hands down, pick this over Scala or any other language, if 
only it was static. Groovy's future depends on it and Groovy has been 
going down, and Scala and other languages up for a long time.
Also, Groovy does something that no one else is doing right now. 
Bridging the Java and Groovy calls like it's nothing, the others require 
a mess to do so.

Just win this battle once and for all. It's stupid that Kotlin devs 
decided to invent a new syntax, otherwise they might have gotten ahead 
of Scala by now.

Most people don't like these other language because no body wants to 
spend alot of time trying out a new language if it is an effort to do so.

I also know how talented and inventive some of the core Groovy devs and 
i think they have always been very open.

Groovy++ died, but at that time, the Israeli guy that pushed for it, 
didn't deliver to the end, because probably he tried to utilize the core 
groovy, but back then everyone was looking forward to it.
Eventually parts of it got absorbed into the Groovy core if iam not 
mistaken.

Ok, I rest my case :P







>
> 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:tibokruse@googlemail.com]
> Sent: Wednesday, June 22, 2016 3:59 AM
> To: users@groovy.apache.org
> 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 <mr.andersson.002@gmail.com> 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: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>:
>>
>> 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>:
>>
>>
>>
>> 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:cedric.champeau@gmail.com]
>> Sent: Tuesday, June 21, 2016 8:29 AM
>> To: 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_compila
>> tion_by_default
>>
>>
>>
>> 2016-06-21 14:24 GMT+02:00 Mr Andersson <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.
>>
>>
>>
>>
>>
>>
>>
>>
> ----------------------------------------------------------------------
> 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