Hear me out. In 2 to 3 years from now there we will see strong indications that Groovy is replacing the Java language as the dominant language on the JVM. Actually outnumbering the Java language will be very hard, given its 10+ years of history. But the trend will be clearly with Groovy.

I realize this sounds like an extra-ordinary claim, maybe even sounds baseless. But it's not. I've recently come to terms with the increased adaptation of Groovy as a programming language myself. Before laying out my arguments to support the increasingly important role of Groovy, let me first lay out some of the history of the Groovy language.

The Groovy project for a long time has been a wild dream. Groovy is the dream child of James Strachan, extravagant open-source developer and visionary. While waiting for a delayed flight he was playing with Python and found it such a cool language that he decided the JVM needed to have a language like this too.

Groovy has always been closely related to the Java language. Not only is the Groovy syntax similar to and often identical to the Java syntax, Groovy is the only language together with Scala and of course Java that always compiles to true Java byte-code. This means that Groovy classes are always true Java classes.

But Groovy has known a rough history. I'm sure many people would prefer not to be remembered, but Groovy was on the brink of failure in 2003/2004. It got a lot of bad press back then and was written off by many people, including people that were involved in the project. Groovy made it through this storm thanks to the hard work of a team of very dedicated people. At the start of 2007 Groovy 1.0 was released and now we're looking forward for Groovy 1.6 and Groovy 2.0.

From the period of Groovy's near failure I remember that everybody had an opinion of what Groovy had to be like. Most people liked the Groovy language, but it had to be more like Perl, or more like Ruby, more functional, less Java, more Java. Every week there were enormous discussion on the mailing lists about which features Groovy had to support. This chapter in Groovy's history is behind us.

Since 2005 the Groovy team has regrouped and been working hard to improve the language. They've incorporated many suggestions and continue to do so until this day. But you won't find many discussions today on which direction Groovy should take. We're past 1.0, the language is stable.

Groovy is a dynamic language, meaning Groovy does not do type checking on variables if you don't want it. Groovy can do type checking but its optional. Here's an example of Groovy code that does not do type checking:

def list = []
assert list.empty

Here's the same code with type checking:

List list = []
assert list.empty

In a way, the Java language is a non-dynamic language that always does type checking.

So, why do I think Groovy will replace the Java language as dominant language? I'll break down my arguments in two categories.

First, why the Java language won't remain the dominant language:

• The Java language community is sinking into a deep crisis over change. There's the row over whether or not closures have to be added to the Java language, and which proposal should be selected. This reminds me of Groovy's history. With each change to the Java language tool [1] vendors [2] have [3] to [4] adapt [5] with [6] it [7]. This is a slow process, and the closure [8] proposals [9] I've seen [10] are not nearly as powerful as closures in other [11] languages [12], including Groovy [13]. Adding this kind of features can happen a couple of times. The pressure to consolidate will however increase. By the time this happens we're 2011. The Java language will have new features at the expense of several massive investments by many parties who will grow increasingly impatient.
• Java language changes are driven by Sun and marketing. C# gets annotations, Java need to have annotations. C# gets closures, Java needs to have closures. See the pattern? This does not serve the Java user community. Actually, we're completely shut out.
• The Java language will be forked. As some people will grow more frustrated with the way the Java language is managed there's a very real possibility that the Java language will be forked, even if it's only for the sake of creating prototypes or making a point. This may be conceived as dangerous or at least make some people nervous, re-enforcing the point for the design-by-committee culture even more.
• Static typing is a great feature and every object-oriented language needs it. It's not so great when there is no alternative. For example, it's unlikely that new methods will be added to the java.util.Collection interface to support closures. For Groovy dealing with new methods on java.util.Collection would be a non-issue. This feeling of being stuck with certain types will increase the sentiment that the Java language may be at a dead end.

So, then why should Groovy become everybody's favorite, especially now that Sun officially supports JRuby? And what about Scala?

• Sun supports Groovy too. Some of their employees are working hard on the Groovy plugin for the NetBeans IDE [14].
• Of Groovy, JRuby, Scala it is Groovy that comes closest to the original Java syntax.
• Java should always have been a dynamic language. Groovy gives us a glimpse of what the Java language could have been.
• IDE support for Groovy will be very impressive in one year from now or less, making its integration into projects much more likely.
• Dynamic languages can have very good IDE support like type detection and code completion. If Visual Studio can have excellent integration for F# then the same is possible for JRuby and Groovy as well. In fact, the NetBeans IDE plugin for JRuby is already impressive.
• Groovy offers joint Java compilation [15], meaning that .java and .groovy files get compiled at the same time. Java classes can thus extend Groovy classes without a glitch.
• As Groovy IDE support improves - which is already decent for IntelliJ [16] - more and more frameworks for Java will be written - at least in part - in Groovy. This is already happening [17]. Don't expect the same to happen for JRuby. It could happen for Scala.
• Two to three years from now the performance of dynamic languages like JRuby and Groovy will be equivalent to pure Java code.
• Grails 1.0 is a huge step for the Grails and Groovy communities, but it's a small step compared to what's ahead of us. Both in terms of Grails and in terms of new ideas.
• As Groovy starts to play an increasing role in software development an increasing number of developers will be touched. Think Grails, think easyb, think of some novel new use of Groovy yourself.
• There's genuine interest in Groovy and Grails, and it's growing. Now is our moment to seize these opportunities and make it easier for people to start using Groovy. The trend is with us, let's make it stronger.

It's going to be a very interesting 2 years for Groovy and Grails. The moment is ours and the demise of the Java language has to be Groovy's stepping stone.

Happy coding!

Note: as Graeme Rocher points out in the comments, Groovy won't compete with Java anytime soon on mobile devices.