To quote the website Groovy is...
"An agile dynamic language for the Java Platform with many features that are inspired by languages like Python, Ruby and Smalltalk, making them available to Java developers using a Java-like syntax."
It has found its way into a number of practical applications such as Ant Scripting, Spring configuration, and as the foundation for the Grails web application framework.
InfoQ sat down with Groovy Project Manager Guillaume Laforge to discuss the RC1 release. The conversation started out with a discussion on the new Meta-Object Protocol:
This improved and re-implemented Meta-Object Protocol is at the core of Groovy. The MOP is a cornerstone in the behavior of the language. It doesn't change fundamentally what Groovy is. Rather, it paves the way for more flexibility in the future of Groovy, and it also cleans up the design of the core of the runtime. The changes won't affect developers too much, but we now have a finer-grained control of the method dispatch and attributes and properties access through the improvements provided to the central part of those mechanisms through Groovy's MetaClass system.
Laforge was then asked what he thought the biggest contributor was to Groovy having the best start of all of the Java-based scripting languages.
When Groovy saw the light of day, the other scripting languages for the JVM were somewhat stagnant. No significant progress was made, and they had the burden of their "parent" language. JRuby & Jython had to follow the official Ruby & Python languages. If you're used to these languages, it certainly makes sense to use them. They have progressed a lot since 2003 when Groovy was born, particularly JRuby. But we felt that those languages didn't provide the best learning curve for a Java developer and it wasn't offering a good enough integration with Java. Groovy offers a seamless integration with Java, because it's been designed with that aim in mind. That's certainly why Groovy has often been chosen over other languages when the need of integrating a scripting language arose.
The conversation then shifted to the popular Grails web application framework which uses Groovy. Laforge was asked how he saw the two evolving together in the future:
There is a symbiotic influence between Groovy and Grails. Groovy obviously influenced Grails a lot, thanks to all its dynamic capabilities. Without them, Grails wouldn't be able to provide the nice Spring bean configuration builder, or all the dynamic finder methods relegating the DAO to a past age. But Grails also influenced Groovy positively, for instance by suggesting an alternative proposal for properties, or by suggesting improvements to the dynamic mixin capabilities of the internals of Groovy for injecting methods or properties at compile-time. So both projects influence and benefit each other, technically speaking, as well as "marketing-ly" speaking, and help us move forward.Shifting gears InfoQ brought up the topic of the growing popularity of JRuby:
Ruby on Rails definitely have an impact on Grails, since it was a source of inspiration for the project. But I don't feel that JRuby on Rails has a particular impact. JRuby on Rails will soon be a way to make a Rails app run on Glassfish. That's really nice, and I see that the JRuby guys are doing a great job there! But Grails and JRuby on Rails are two different ways of developing web applications nowadays, and when you need tight integration with Java, with libraries, with application servers, with enterprise resources relying on Java, Groovy definitely has the edge and offers more advantages over a mixed Ruby and Java application. Moreover, you can rely on legacy Hibernate mappings, or Spring configured beans and services that you can easily incorporate in your Grails app.Furthermore, Groovy doesn't provide a radical paradigm shift in programming, and Grails won't be hard to master by Java developers. So if you have a proficient team of Ruby hackers in your company but wish to run a Rails app on a proven Java app server, you might prefer JRuby on Rails, but if you're a Java shop and prefer a smoother path of evolution towards improved and faster application development, you'd better consider Grails and Groovy.
Also, Grails is not about just providing a scripting environment, it is about leverage scripting where effective, but allowing a mix of approaches. So you can develop your domain model with Java as usual and use said domain model from your Java services, but still be able to switch over to a RAD-scripting environment that Grails offers with dynamic finders, persistence methods and so forth. You get the best of both worlds!
Next InfoQ asked Laforge to highlight some of the uses of Groovy currently in the industry in terms of internal tools, production use, etc.
Groovy is used in various settings and environments. A US Fortune 500 insurance company has been using Groovy in production for over a year for their mission-critical risk computation application. A hosted wiki farm (powered by the XWiki second-generation wiki engine) is hosting thousands of wikis sporting Groovy templates and plugins, and Groovy is heavily used in the online e-commerce website bestventes.com. The eXo Platform CMS, with a few high-traffic portals deployed, is also using Groovy under the hood. Groovy can as well be used for small automation tasks, code generation tools, shell-script replacement, but Groovy is also for real serious business-critical applications, and several businesses already rely on Groovy in production with great success so far.Laforge then commented on the future of dynamic languages and the JVM:
It's obvious that dynamic languages have a great future ahead of them. At JavaOne, for instance, we already felt that hot moment taking shape: 6 sessions were about or were using Groovy! With mission-critical apps showing their trust in those languages, and particularly in Groovy, we can forsee a bright future. Sun also believes that scripting and dynamic languages are an important part of the future Java platform, by adding special APIs supporting scripting engines in JDK 6, and they have started working on new bytecode instructions which should help dynamic languages' special dynamic method dispatch. We'll see more and more integration use cases where dynamic languages will second Java where it makes sense, for example in writing expressive business rules, or custom Domain-Specific Languages for which Groovy is perfectly well adapted.Finally Laforge was asked what the future holds for Groovy. He indicated that some time will be spent forking the test suites to create the TCK for JSR-241, as well as for writing a proper Groovy Language Specification. The third Groovy Developer Conference will be held in January or February to discuss the roadmap of features. There will certainly be one or two maintenance releases numbered 1.x. The team will also move forward focusing on Groovy 2.0 with full annotation support and other features.