Steven Devijver writes a bold article on DZone, saying that Groovy will replace Java as the dominant language. You would expect Graeme Rocher of G2One, the company created to shepherd Groovy and Grails, to be rah-rah about this, and violently agree. But his response is very tempered and level-headed, as he provides reasons for why that will likely not happen. I summarize here.

Steven’s reasons for 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 vendors have to adapt with it. This is a slow process, and the closure proposals I’ve seen are not nearly as powerful as closures in other languages, including Groovy. 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.

Steven’s reasons for why Groovy should become everybody’s favorite, even though Sun officially supports JRuby:

• Sun supports Groovy too. Some of their employees are working hard on the Groovy plugin for the NetBeans IDE.
• 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, 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 - more and more frameworks for Java will be written - at least in part - in Groovy. This is already happening. 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.

Steven concludes:

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.

Graeme’s tempered responses:

Graeme Rocher replied on Wed, 2008/02/13 - 7:37am

Interesting article, but as project lead of Grails and Groovy core committer, I don’t agree with you

I anticipate Groovy will enter the top 10 languages world wide next year and will be closing in on the top 5 at the end of 2010, but replace? no.

Groovy (and Grails) is designed from the ground up to be used in conjunction with Java, it is not a binary choice. You use Groovy where it makes sense and Java when it makes sense.

Each language has their respective strengths. I see a future where Groovy is used more and more for various aspect of software development on the JVM where it makes sense. Sometimes you might find an entire Grails application written in Groovy without a line of Java, but the majority of cases I believe will see them used together.

Tags: Groovy Grails