What’s new in Groovy 2.0?(infoq.com)
infoq.com
What’s new in Groovy 2.0?
http://www.infoq.com/articles/new-groovy-20
13 comments
Clojure is really quite a remarkable language.
The macros and concurrency features are quite stunning, and if they really work as advertised will truly put to rest the last remnants of my interest in Groovy.
I would love to see some more direct support for doing a pure functional style of programming, but what is there is close enough and so much easier to grok than Haskell, to be honest.
The macros and concurrency features are quite stunning, and if they really work as advertised will truly put to rest the last remnants of my interest in Groovy.
I would love to see some more direct support for doing a pure functional style of programming, but what is there is close enough and so much easier to grok than Haskell, to be honest.
I really don't disagree with anything you've said :-)
However a big point of difference is that Groovy's syntax, being 90% compatible with Java, is orders of magnitude more accessible than Clojure to the vast majority of developers.
However a big point of difference is that Groovy's syntax, being 90% compatible with Java, is orders of magnitude more accessible than Clojure to the vast majority of developers.
What's the current state of Groovy? Has it seen much adoption, compared to something like Jython or JRuby? Does it have any commonly-acknowledged flaws?
I looked at it years ago, around when it first came out, and it gave me a negative impression as being sloppily done and a bit amateurish, so I went with Jython. My impression is that they cleaned up their act and saw decent adoption, but I don't know any more than that. It seems eclipsed these days in favor of Clojure and Scala.
I looked at it years ago, around when it first came out, and it gave me a negative impression as being sloppily done and a bit amateurish, so I went with Jython. My impression is that they cleaned up their act and saw decent adoption, but I don't know any more than that. It seems eclipsed these days in favor of Clojure and Scala.
Yeah, the adoption is pretty good, definitely compared to Jython / JRuby. Multiple conferences dedicated primarily to groovy / grails (gr8conf US coming up on Minneapolis on 30-31).
I think Grails is driving a lot of adoption, but I also see it popping up in vendor products that need a scripting language or DSL that integrates with Java easily. Neo4J and Cloudify (Gigaspaces product) come to mind as recent examples.
I think Grails is driving a lot of adoption, but I also see it popping up in vendor products that need a scripting language or DSL that integrates with Java easily. Neo4J and Cloudify (Gigaspaces product) come to mind as recent examples.
Yep. A lot of groovy adoption is "under the radar" precisely because it blends so seamlessly with Java. It may just be a build script or used in unit tests, but it is popping up all over the place.
This is very wrong:
"It seems eclipsed these days in favor of Clojure and Scala."
Your view of reality is being warped by the Hacker News bubble. Consider the results of Google Trend:
http://www.google.com/trends/?q=grails,+clojure&ctab=0&#...
Mind you, I'm comparing Clojure, the whole language, to Grails, which is just one framework. While it is true that most Groovy work involves Grails, there is also some Groovy work that does not, so the results of this comparison, if anything, understate the gap between Groovy and Clojure.
"It seems eclipsed these days in favor of Clojure and Scala."
Your view of reality is being warped by the Hacker News bubble. Consider the results of Google Trend:
http://www.google.com/trends/?q=grails,+clojure&ctab=0&#...
Mind you, I'm comparing Clojure, the whole language, to Grails, which is just one framework. While it is true that most Groovy work involves Grails, there is also some Groovy work that does not, so the results of this comparison, if anything, understate the gap between Groovy and Clojure.
Virtually all Groovy work involved Grails. There's no other reason to adopt Groovy. If you need standalone scripts in an IDE, it's easier to use, say, Eclipse Xtend (http://www.infoq.com/news/2012/06/xtend-release-10)
Your statement is reductive. You can replace xtend by all the new jvm language. In fact these languages haven't proove anything. On the contrary of groovy.
On my own experience I use groovy not only for grails :
- virtually all java classes can be replaced by groovy classes. Groovy is far more concise. eg. I use groovy for spring/backed bean.
- SwingBuilder
- gpars
On my own experience I use groovy not only for grails :
- virtually all java classes can be replaced by groovy classes. Groovy is far more concise. eg. I use groovy for spring/backed bean.
- SwingBuilder
- gpars
All your examples are controlled by the Groovy/Grails business in some way. Groovy bundles both gpars and Swingbuilder in its distro, and Spring is bundled in Grails.
The Not-Invented-Here mentality has always been prevalent in the VMWare-funded "Gr8te" ecosystem. If someone independently builds something using Groovy or Grails, such as Alex Tkachman, Roshan Dawrani, et al building Groovy++, VMWare make excuses to reject it, then build their own version, Groovy 2's static compilation, probably copying plenty of code out of Groovy++ along the way.
This mentality results from VMWare wanting to control as much of Grails's constituent technologies as possible. The reason behind Gradle becoming the build tool for Groovy/Grails, Spring, and Hibernate was for Gradleware to pitch their control of Hibernate's build, knowing they'll be targeted for a buyout by VMWare. Rocher's probably hard-balling the Gradleware execs right now, trying to screw them for as much as possible.
The Not-Invented-Here mentality has always been prevalent in the VMWare-funded "Gr8te" ecosystem. If someone independently builds something using Groovy or Grails, such as Alex Tkachman, Roshan Dawrani, et al building Groovy++, VMWare make excuses to reject it, then build their own version, Groovy 2's static compilation, probably copying plenty of code out of Groovy++ along the way.
This mentality results from VMWare wanting to control as much of Grails's constituent technologies as possible. The reason behind Gradle becoming the build tool for Groovy/Grails, Spring, and Hibernate was for Gradleware to pitch their control of Hibernate's build, knowing they'll be targeted for a buyout by VMWare. Rocher's probably hard-balling the Gradleware execs right now, trying to screw them for as much as possible.
Remenber, your primary statement was :
"Virtually all Groovy work involved Grails. There's no other reason to adopt Groovy."
There are plenty other reasons to adopt Groovy, other than Grails
Your other statement are opinion, not fact.
There are plenty other reasons to adopt Groovy, other than Grails
Your other statement are opinion, not fact.
No, Groovy is used in many other places than Grails.
One can think of the Gradle build automation tool (http://gradle.org/), for instance, which uses Groovy as a DSL.
But actually, one of the very big use cases for Groovy outside of Grails is as an embedded DSL, for business-oriented languages, to further customize the business rules of an application, for configuring it, etc.
Groovy's used in many sectors: healthcare, insurance, banking, travel, scientific simulations, biomedical, etc.
> No, Groovy is used in many other places than Grails. One can think of the Gradle build automation tool (http://gradle.org/), for instance, which uses Groovy as a DSL.
Gradle's the only provable specific example you gave of Groovy being used as a DSL. But is Gradle used for much more than building Groovy, Grails, and Griffon?
Gradle's the only provable specific example you gave of Groovy being used as a DSL. But is Gradle used for much more than building Groovy, Grails, and Griffon?
Unfortunately, I cannot give some of the real-world DSLs that I know of or that I've worked on, as my customers request that we don't publicize that information.
Just to give you a couple examples which are more or less public, I can mention the Amadeus travel company (whose services are used by 80% of airlines and travel agencies in Europe) or the European Patent Office who did presentations at conferences about their usage of Groovy for DSLs.
The various sectors I mentioned earlier are sectors for which I know companies that are using Groovy for such DSL purposes, although I'm not in a position to publicly speak about them unfortunately :-(
As for Gradle, yes, of course, it's used beyond the Groovy ecosystem. For example, the Spring project (and other related Spring projects) is built with Gradle, as well as Hibernate. Some major projects have switched to Gradle from Maven.
Just to give you a couple examples which are more or less public, I can mention the Amadeus travel company (whose services are used by 80% of airlines and travel agencies in Europe) or the European Patent Office who did presentations at conferences about their usage of Groovy for DSLs.
The various sectors I mentioned earlier are sectors for which I know companies that are using Groovy for such DSL purposes, although I'm not in a position to publicly speak about them unfortunately :-(
As for Gradle, yes, of course, it's used beyond the Groovy ecosystem. For example, the Spring project (and other related Spring projects) is built with Gradle, as well as Hibernate. Some major projects have switched to Gradle from Maven.
Gradle builds Groovy, Spring, and Hibernate, all software bundled inside Grails. Sounds like Rocher's been busy consolidating the package.
For me, Groovy always have this feeling that's quite the opposite of Scala: it seems that it was a language that wasn't very thoroughly implemented and has all of these bolt-on stuff on top of it. Scala seems more solid to me because of the academic background (to think that a type system can be turing complete..), and it seems that Clojure found a place on its own.
In general terms, one of the flaws for me is that I can't quite decide what's the direction that Groovy's going. For example, the 2.0v is introducion static features, but AFAIK I never noticed any interest on static features (of course the groovy team should have much more to say on this). Other thing that I didn't like was the stack traces when an exception ocurred: due to the nature of the MOP, the stack traces were always very full of 'garbage' (this was some time ago, I don't know what's the story now). Another example is on the link: if you want to enable invokedynamic, you have to switch some flag on the compiler. If you compare to jRuby (which I know is not directly comparable but as an end user I really don't care) it's alread turned on if you are using the proper jRuby and JDK versions.
OTOH, I think Groovy nailed the Java interop spot on (flawless Java invocation/interop, integration with Ant, maven, etc) which is probably one of the good reasons to use Groovy.
If you consider SO to give a reasonable feedback on popularity, here's the nr of tagged questions:
In general terms, one of the flaws for me is that I can't quite decide what's the direction that Groovy's going. For example, the 2.0v is introducion static features, but AFAIK I never noticed any interest on static features (of course the groovy team should have much more to say on this). Other thing that I didn't like was the stack traces when an exception ocurred: due to the nature of the MOP, the stack traces were always very full of 'garbage' (this was some time ago, I don't know what's the story now). Another example is on the link: if you want to enable invokedynamic, you have to switch some flag on the compiler. If you compare to jRuby (which I know is not directly comparable but as an end user I really don't care) it's alread turned on if you are using the proper jRuby and JDK versions.
OTOH, I think Groovy nailed the Java interop spot on (flawless Java invocation/interop, integration with Ant, maven, etc) which is probably one of the good reasons to use Groovy.
If you consider SO to give a reasonable feedback on popularity, here's the nr of tagged questions:
* scala 549
* jruby 342
* groovy 599
* clojure 120
* ruby (for comparison) 7,115
The static features in Groovy 2.0 look like they were integrated from the Groovy++ project. Seeing as how there was an entire side-project created by the community I'd say there was a big interest in adding static type checking to Groovy.
http://code.google.com/p/groovypptest/wiki/Welcome
http://code.google.com/p/groovypptest/wiki/Welcome
The static features were not integrated from the Groovy++ project, as it differed in various ways compared to what we had in mind for Groovy. But Groovy++'s definitely been a great inspiration for us when we developed those features, and the project clearly showed the interest of the community for that.
This is my impression, too. I think Groovy's "static" features are a reaction to a lot of developers realizing that "statically typed" doesn't necessarily mean that the language has to be as cumbersome and verbose as Java.
Imho, there is just no reason for building/using/preferring a dynamically typed language, except when the language designer lacks the necessary abilities to build a sound and coherent type system.
Scala has none of Groovy's drawbacks, a lot of benefits combined with a clear roadmap -- and most importantly: The determination to not only get something working, but also to get it right.
Meanwhile, the language gets more consistent and polished with every release.
Imho, there is just no reason for building/using/preferring a dynamically typed language, except when the language designer lacks the necessary abilities to build a sound and coherent type system.
Scala has none of Groovy's drawbacks, a lot of benefits combined with a clear roadmap -- and most importantly: The determination to not only get something working, but also to get it right.
Meanwhile, the language gets more consistent and polished with every release.
The static features of Groovy 2.0 are actually a reaction to users demand and wishes.
You can read the article to have a more elaborate explanation of this, but in a nutshell, our users want to be able to type check their code especially when Groovy's used as a kind of "scripted Java" as they expect the same feedback as the java compiler provides. Especially when Groovy is used "à la" Java rather than to rely on its useful dynamic features. And our users are also interested about pure raw speed for computations, or avoid being subject of monkey patching, hence why static compilation matter in some situations.
I don't want to enter into polemical arguments here, as I have nothing against Scala, on the contrary. But your arguments about type systems vs dynamicity or supposed Groovy's drawbacks don't really seem to be factual and backed by any concrete claims or analysis. So I won't comment on that.
You can read the article to have a more elaborate explanation of this, but in a nutshell, our users want to be able to type check their code especially when Groovy's used as a kind of "scripted Java" as they expect the same feedback as the java compiler provides. Especially when Groovy is used "à la" Java rather than to rely on its useful dynamic features. And our users are also interested about pure raw speed for computations, or avoid being subject of monkey patching, hence why static compilation matter in some situations.
I don't want to enter into polemical arguments here, as I have nothing against Scala, on the contrary. But your arguments about type systems vs dynamicity or supposed Groovy's drawbacks don't really seem to be factual and backed by any concrete claims or analysis. So I won't comment on that.
In terms of some of the organizations I know that are using it: IEEE, NetFlix uses it for many internal apps, Target, one of the largest hedge funds in NY area, LiquidNet. I think there are less publisized stories about it because it is more focused on enterprise, which naturally is less open about what they use. However, the community is great, there are a ton of plugins, and VMWare has done a good job continuing to support it as parts of SpringSource ecosystem.
It's the same way that there are so many Spring / Java apps being written out there (including in startups), but they rarely come up on HN as opposed to some of the newer kids on the block, ala node.js or rails.
It's the same way that there are so many Spring / Java apps being written out there (including in startups), but they rarely come up on HN as opposed to some of the newer kids on the block, ala node.js or rails.
Banner, the software quite a few universities use for student record management and other things, has migrated from PL/SQL to a Groovy on Grails system in their next version so that will push a bunch of people to learn Groovy.
As far as I know they still lack even a language spec.
YAM (Yet another myth). It is in the JCP.
You created a Hacker News account just to comment on this? Was it this comment (http://groovy.329449.n5.nabble.com/ANN-Groovy-2-0-is-release...) on the Groovy mailing list urging people to "spread the word" at Hacker News?
You mean the dormant one from 2004 which was never finished?
http://jcp.org/en/jsr/detail?id=241
Or the "Groovy specification" which is almost completely empty? http://groovy.codehaus.org/jsr/spec/
Or the "Groovy specification" which is almost completely empty? http://groovy.codehaus.org/jsr/spec/
To those who knock groovy, just give it a try.
As a long time java user, i was very reluctant to learn groovy and it took grails for me to really tune into groovy. Now it's really hard for me to go back to java. :)
I also personally feel that static compilation is more of a marketing sop to the hard-core java crowd to help move them over to the dark side but what the hey, if it works, it's good for groovy.
As a long time java user, i was very reluctant to learn groovy and it took grails for me to really tune into groovy. Now it's really hard for me to go back to java. :)
I also personally feel that static compilation is more of a marketing sop to the hard-core java crowd to help move them over to the dark side but what the hey, if it works, it's good for groovy.
I'd heard that groovy 2 would be respecting public/protected/private, as they could be bypassed with metaclass programming in groovy 1, but haven't kept up with that in a bit. For example, adding a new method to 'String', in the example given, looks a bit more work than it used to be, and doesn't reference the metaclass.
I've got a vested interest in seeing continual uptake of Groovy, but am wondering what's holding back adoption from those of you who do Java work but haven't integrated Groovy in to your toolset.
I've got a vested interest in seeing continual uptake of Groovy, but am wondering what's holding back adoption from those of you who do Java work but haven't integrated Groovy in to your toolset.
I've used groovy in the past on grails projects but haven't adopted it more because its dynamically typed and slower than java. I have adopted scala as my main language however, since it can be used as a direct replacement for java.
So would the static compilation / type checking features have made a difference to you in your choice of language?
I'm sort of half in love with the idea, half in horror - I can pick and choose which parts of my code I want to be static and which parts dynamic - is it the best of all worlds or a dogs breakfast of incomprehensible and conflicting paradigms? I don't know, but I think it's one of the first popular and well established languages to offer this so I consider it really intriguing to see how it plays out.
I'm sort of half in love with the idea, half in horror - I can pick and choose which parts of my code I want to be static and which parts dynamic - is it the best of all worlds or a dogs breakfast of incomprehensible and conflicting paradigms? I don't know, but I think it's one of the first popular and well established languages to offer this so I consider it really intriguing to see how it plays out.
I'm pretty excited about this, personally. Our startup[1] is building mostly in Groovy and using Grails, and we've been very happy with the decision so far. To my mind, one of the biggest knocks on Groovy has been performance, so it's good to see them moving forward aggressively with taking advantage of invokedynamic and working to improve performance.
The JRuby guys got quite an improvement out of using invokedynamic, IIRC, so hopefully this bodes well for the future of Groovy. As others have said, Groovy is quite remarkable. To date, it remains my favorite JVM language (not to take anything away from Clojure, Scala, JRuby, Fantom, Nice, Beanshell, Jython, Kotlin, Fortress, Joy, Ceylon, etc).
[1]: Fogbeam Labs, the up-and-coming Open Source collaboration/knowledge-management company. http://www.fogbeam.com Go there now and sign up for our newsletter. It's not necessary for you to spend the rest of your day thinking about how cool Fogbeam Labs are, and how much you want to email all your friends and tell them about us too. But if you can remember a time when you were really excited about a company like Fogbeam Labs, then think back to those feelings and how that made you feel, and do the right thing.
The JRuby guys got quite an improvement out of using invokedynamic, IIRC, so hopefully this bodes well for the future of Groovy. As others have said, Groovy is quite remarkable. To date, it remains my favorite JVM language (not to take anything away from Clojure, Scala, JRuby, Fantom, Nice, Beanshell, Jython, Kotlin, Fortress, Joy, Ceylon, etc).
[1]: Fogbeam Labs, the up-and-coming Open Source collaboration/knowledge-management company. http://www.fogbeam.com Go there now and sign up for our newsletter. It's not necessary for you to spend the rest of your day thinking about how cool Fogbeam Labs are, and how much you want to email all your friends and tell them about us too. But if you can remember a time when you were really excited about a company like Fogbeam Labs, then think back to those feelings and how that made you feel, and do the right thing.
Agreed. I also chose Grails for my startup 3 years ago, and have been very happy with decision. Allowed us to deliver a huge amount of functionality quickly. And Grails 2.0 has been out for six months, that's been great. 2.1 has some nice things in it (about to come out imminently), and I think they are going to try to get Groovy 2.0 into Grails in 2.2, which will be awesome!
and I think they are going to try to get Groovy 2.0 into Grails in 2.2, which will be awesome!
Definitely. I'm very much looking forward to Groovy 2 support in Grails. We're just about to migrate our project to the Grails 2.x series, to start getting ready for the new hotness.
Definitely. I'm very much looking forward to Groovy 2 support in Grails. We're just about to migrate our project to the Grails 2.x series, to start getting ready for the new hotness.
Key highlights as stated by Guillaume:
- a static type checker to let the compiler tell you about the correctness of your code,
- static compilation for the performance of the critical parts of your application,
- modularity, splitting the Groovy JAR into smaller feature-oriented JARs and letting you create your own extension modules,
- JDK 7 Project Coin syntax enhancements, so that Groovy is still as friendly as possible with its Java cousin,
- and JDK 7 Invoke Dynamic integration to benefit from the support of the JVM for dynamic languages.
- a static type checker to let the compiler tell you about the correctness of your code,
- static compilation for the performance of the critical parts of your application,
- modularity, splitting the Groovy JAR into smaller feature-oriented JARs and letting you create your own extension modules,
- JDK 7 Project Coin syntax enhancements, so that Groovy is still as friendly as possible with its Java cousin,
- and JDK 7 Invoke Dynamic integration to benefit from the support of the JVM for dynamic languages.
Exciting. As a long-time Groovy / Grails user, can't wait to dig in. I think the new static features make more people coming in from static languages more comfortable getting into the language. .
I've been monitoring adoption for some time. There was a (roughly) three+ year period where Groovy was the fastest growing language in the world. Scala has seen more growth over the past year, but IMHO it will never challenge Groovy. Why? Functional languages have been around for years and have never owned more than a niche market due to their complexity. Groovy is more readable than Java, and much more readable then Scala or Closure.
Remember COBOL dominated the US for many years due to it's simplicity. PowerBuilder beat a more comprehensive competitor (SQL Windows) due to it's simplicity. It seems likely that functional languages may find a niche where they fit well (e.g. business rules) but languages like Groovy seem most likely to achieve wide adoption. IMHO of course!
Remember COBOL dominated the US for many years due to it's simplicity. PowerBuilder beat a more comprehensive competitor (SQL Windows) due to it's simplicity. It seems likely that functional languages may find a niche where they fit well (e.g. business rules) but languages like Groovy seem most likely to achieve wide adoption. IMHO of course!
> Functional languages have been around for years and have never owned more than a niche market due to their complexity
I think the problem is that writing in a functional way almost requires a purist approach, so the only way in is to completely buy into the "dogma" of it. That makes adoption hard to impossible.
Groovy is almost completely the opposite - every practical whim is catered for, almost to a fault - there's all kinds of crazy stuff shoved into it. But boy is it easy to adopt. It's a quite stunning achievement how much is in Groovy and yet still - it remains almost source compatible with Java.
I think the problem is that writing in a functional way almost requires a purist approach, so the only way in is to completely buy into the "dogma" of it. That makes adoption hard to impossible.
Groovy is almost completely the opposite - every practical whim is catered for, almost to a fault - there's all kinds of crazy stuff shoved into it. But boy is it easy to adopt. It's a quite stunning achievement how much is in Groovy and yet still - it remains almost source compatible with Java.
It's funny how that "functional" name calling appears so convenient if it fits the own argumentation. (Not considering that Scala is foremost an object-oriented language.)
Groovy is trying to play catch-up with Java currently (typing-wise) and I don't see how they will implement a modern type system in the next decade with the amount of cruft they have accumulated since Groovy's inception.
Additionally, Java 8 will ship with closures, so I'm not seeing where a niche for Groovy will remain.
Groovy is trying to play catch-up with Java currently (typing-wise) and I don't see how they will implement a modern type system in the next decade with the amount of cruft they have accumulated since Groovy's inception.
Additionally, Java 8 will ship with closures, so I'm not seeing where a niche for Groovy will remain.
As for scala.
Yet another step towards massive adoption of Groovy as an alternative to Ruby and JS for startups. I can't wait to try this out with Vert.x and hopefully get away with never doing JS on the server.
The language has matured and so has the implementation. Static type checking will reassure those "programming in the large".
Static compilation will help those "programming for the fast lane".
A bunch of syntactic simplifications will help those creating DSL for the so called "business user".
Groovy, Grails, Griffon, Gradle, all on playing well in the JVM ecosystem : this is exciting !
I might finally have to take a look at Grails now that there's static type checking. Do I need to wait for a new release of Grails to use Grovvy 2.0 with it or can I do that now? Also, I'm curious if it can be turned on globally when calling the compiler instead of having to annotate all of my classes with @CompileStatic?
Looks like it'll be in Grails 2.2: http://jira.grails.org/browse/GRAILS-9225
Groovy and Grails are both amazing, been doing development for quite sometime and have tried various languages. Can honestly for a new web based application I would chose Grails over the others.
This is a great news. Groovy becomes more and more mature and efficient.
The static compilation and type checking features are quite stunning, and if they really work as advertised will truly put to rest the last remnants of my interest in Scala.
I would love to see some more direct support for doing a pure functional style of programming, but what is there is close enough and so much easier to grok than Scala, to be honest.