Griffon is based on the Grails foundations and extends Groovy's own Swing builder system to let you create complex and rich desktop applications in Swing. Griffon is really to Swing development what Grails is for web development.
In the testing space, Easyb brings developers a DSL for Behavior-Driven-Development testing, and Spock provides some advanced testing and mocking techniques to unit testing. Let me also mention Gradle, which is a very nice and advanced build system.
What are the biggest tasks you are currently working on with the language development?
We always have two ongoing efforts at the same time: maintaining and evolving the current stable branch, as well as working and innovating on the development branch.
For instance, we've just released a minor version of Groovy 1.6 which solves some bugs and has some minor enhancements, and we have also just released a preview of the upcoming Groovy 1.7 full of new features.
Groovy 1.7 will make it easier for extending the language through compile-time metaprogramming capabilities. It will also provide better assertion messages for unit tests, the ability to use annotations in more places in your programs and lots more.
Why did you choose an Apache License over other free and /or open licences?
We felt that the Apache License was a great and open licence to use, so that anybody is free to embed, reuse, or even fork the language in whatever they see fit for their own needs, and integrate it in their own applications. The choice was also easy with some of the original committers coming from the Apache Software Foundation.
As it is in some ways a superset of Java, it would be easy for Java developers to learn, but what is the learning curve for developers without a Java background?
Of course Groovy is easy to learn for Java developers, but thanks to its "scripting" aspects, it's still rather easy to learn for users coming from a different background.
As long as you're somewhat familiar with a language with a C-like syntax, it's simple to comprehend. There are of course some APIs to learn, as with any language and platform, but you can learn them as you need them without any upfront cost of learning. So even without a Java background, the learning curve isn't that stiff.
What is your favourite Groovy feature?
This is a tricky question! There are really many aspects of the language that I love!
I guess if I had to choose just one, that would be Groovy's support for closures. With closures, you can start thinking differently about how you solve your everyday problems, or create complex algorithms. Closures give you an additional layer of abstraction for encapsulating code and behaviour, and even data (thanks to Groovy builders). Also, with various helper methods added to Java collections, in combination with closures, you've got the power of functional languages at your disposal.
What has been the greatest challenge in developing Groovy and how did you work around this?
I would say that the two main challenges have been about a total seamless interoperability and integration with Java, as well as performance.
The former has always been part of our design goals, so we've always done our best to take care of all the bugs and keep up with the pace of Java itself (for instance when Java 5 introduced annotations, enums, and generics).
For the latter, we made sure that Groovy would be the fastest dynamic language available (both in and outside of the JVM). We used various techniques, such as 'call site caches' and related techniques. We're also very enthusiastic and optimistic about the upcoming JSR-292 'invokedynamic' bytecode instructions coming soon into the Java Virtual Machine, which should bring very significant performance boosts.
Do developers in corporate environments have trouble using non-standadised and relatively new languages like Groovy in the workplace?
It depends, [but this can happen] in some cases. Groovy is an easy sell, as after all it's just another library to put on the classpath, and in some other cases it's more problematic as certain companies are really strict and avoid adding any other dependency in their projects, trying to mitigate any additional risk. Usually though, the various advantages Groovy brings help sell it to more conservative organisations.
Until recently, the tooling wasn't ideal either, but JetBrains with their incredible Groovy and Grails support in IntelliJ IDEA paved the way. We also have great support in NetBeans, and thanks to the SpringSource Eclipse team, the Eclipse plugin for Groovy is going to progressively catch up with the competitors. Groovy is now a much easier sell than it was a few years ago and a lot of companies trust Groovy for their advanced needs.
A Slashdot reader has said in a post months ago that Groovy is poised to convert the enterprise crowd. Do you agree with this statement?
More and more companies are relying on Groovy for doing business — even critical apps dealing with large amounts of money. So clearly, Groovy is now a key asset to such companies and businesses. And the fact Groovy is very easy to learn and use, and is so well integrated with Java, makes it a nice fit for bringing more agility and power in your applications.
Where do you see Groovy heading in the future?
This is a very good question! After each major release, we're wondering whether we will be able to add some new innovative and useful features to the language. And in the end, we always find something!
As I mentioned already, there are areas where we continue to innovate, like our compile-time metaprogramming techniques and our extended annotation support.
We're also considering certain features we find interesting in other languages and their respective APIs, for instance Erlang's actor concurrency model, pattern matching like in functional languages such as OCaml, or parser combinators from Haskel.
We always try to find new features that bring real value and benefits to our users.