groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: Is it possible to enable CompileStatic for an entire project
Date Wed, 22 Jun 2016 17:45:23 GMT
On 22.06.2016 18:55, Mr Andersson wrote:
> 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.

yeah, I have a lot of plans in a direction that allows more control 
about the runtime meta programming and actually allows classes to 
immunize themselves against meta class changes. The basic concept and 
the ideas are there, the detail work and a good plan to migrate current 
Groovy to that version is very difficult to do.

> 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.

do you have a different Java than I have? No seriously, even with the 
infamous Haskell I would not assume that my program is correct just 
because it compiles.

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

really?about what exactly?

> 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.

And you tell that a person that did hear about people not accepting the 
language already just because of the name. I know about cases in which a 
company did not use a library because it is written in Groovy... just 
because it is written in Groovy. All that would not change with static 
compilation by default at all.

> 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.

static Groovy is on par most of the time, dynamic Groovy depends, but I 
think it is more in the range of being 2.5 times java (100ms runtime 
becomes 250ms). I think that is close enough.... and there is still some 

> 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.

For better performance of dynamic Groovy we need to rework the MOP. For 
example not using exceptions for missing properties and such. But I say 
this for too long already.

> 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.

Alex is a bright guy, good for new concepts, good for prototypes, but no 
man for the detail work. That´s why groovy++ died. At no point did we 
include source code from Groovy++. Concept wise the static compilation 
we have now is not inspired by Groovy++. Groovy++ simply tried to apply 
the static type system of Java, that was something we always did feel is 
not good enough. In Groovy we are now using a limited form of inference 
types, based on flow typing. Also an old concept, but normally not used 
in that way. Of course Groovy++ had more to offer than just static 
compilation. But again our traits are for example similar to what 
Groovy++ had back then, but the concept is much more worked out and 
actually based on what Scala did. I for example would also like to bring 
the async/await concept from C# to Groovy... copying the juicy parts 
from other languages is always something we did, if they fit.

bye Jochen

View raw message