Steven has posted 36 posts at DZone. View Full User Profile

Groovy will replace the Java language as dominant language

  • submit to reddit

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 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.

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.
  • 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.

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.

Published at DZone with permission of its author, Steven Devijver.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Arek Stryjski replied on Wed, 2008/02/13 - 1:07pm

There is one advantage Scala has over Groovy which is not mention so often. Scala promise platform independence. (I mean platform not OS independence.)
It is kind of "learn once, use anywhere" ;)

I don't know how important this will be, however it is interesting perspective for me (as Java developer) what if I learn Scala I could use it in both Java and .Net/Mono pojects. Maybe it will also even more important for new programmers...
I don't know how it will work in practice, but it just make lerning Scala little bit more "sexy".


It looks like current version of Scala works only on Java :(

Graeme Rocher replied on Wed, 2008/02/13 - 1:06pm in response to: Steven Devijver


Graeme, I feel I have to respond before this gets out of hand. Does my article say Groovy will replace Java?


[/quote] I know your intentions are good Steven, but to be fair it says this in the title of the post, I would say 99% of people would have the same interpretation as I did. You and I both know that its real strength is its ability to seamlessly integrate with Java, I don't think the word "replace" should be in a Groovy developers vocabulary

Markus Jais replied on Wed, 2008/02/13 - 2:39pm in response to: Serge Bureau



Now as far as being with Graeme, please look at my reply to him. Groovy is Java ! So where do you see we lose the framework ?





about the frameworks: I know I can use Java frameworks with Groovy. But I wasn't only talking about Java and Groovy.

I also see Rails as a framework or Django or Turbogears. I would rather use Ruby with a good framework than another language with a bad framework. Groovy and Grails are great too and I am currently reading the Grails docs.

But Groovy wouldn't nearly be as popular as it is right now without Grails. The same for Ruby and Ruby on Rails. It's the framework that counts.



Rick Hightower replied on Wed, 2008/02/13 - 2:45pm in response to: Graeme Rocher

Along these lines... I was just talking to a recent Groovy "convert". He had a problem, I suggested a library I wrote... His response: "Is that written in Groovy?". I said no but it works really well and it is written in Java. His response: "It seems like the Groovy version of that would be more terse"... I did not offer to rewrite it in Groovy.

At this point, I thought to myself "Oh know... here we go again" and then I politely excused myself from the conversation. The point is... Java and Groovy work well together. It will be a long time, if ever, when Groovy replaces Java. 

There would be a lot more Groovy growth if Groovy could be positioned as something other than a replacement for Java. Java + Groovy is more appealing than Java vs. Groovy.

There is a long history of folks using Python to augment C/C++ development (as a driving language), and as organizations use Python... more and more code gets written in Python and less and less in C++/C.

rick hightowercto of arcMindbloglinkedin

Mats Henricson replied on Wed, 2008/02/13 - 3:03pm


I'm disappointed at your style of writing. I think the way you labeled your piece is overly assertive - nobody knows for sure what language will raise to prominance in the future. It shows that you are betting on Groovy, and that is OK. I hope it will be Scala, and that is OK too, but please note the way I phrase it: *I* *think* Scala will be the next big thing. I don't pretend to speak for anyone else, and I don't pretend to know.

I really hope the editors of JavaLobby will restrain themself from this kind of sensationalist fatalist style in the future.



Mats Henricson replied on Wed, 2008/02/13 - 3:42pm

BTW, why wasn't this article filed under Opinion/Editorial? Or simply dumped into the Groovy Zone?



Mats Henricson replied on Wed, 2008/02/13 - 4:14pm

Also, what about Grrovy performance?


ff aaa replied on Wed, 2008/02/13 - 5:13pm in response to: Steven Devijver


Graeme, I feel I have to respond before this gets out of hand. Does my article say Groovy will replace Java?


Well read your title. Think twice.

Alex(JAlexoid) ... replied on Wed, 2008/02/13 - 5:38pm

@Steven Devijver: To say the truth, your articles are the biggest reasons why I don't go back to groovy... So much fanboyism...

My personal idea is that major changes in programming languages come not as a result of BETTER languages, but as a result of changes to the idea of what programming is all about.

  1. Programming is for scientists (Pascal, Fortran, Ada and such)
  2. Programming is for big companies (COBOL...)
  3. Programming is for programmers (C, C++ and so on)
  4. Programming is for your business and needs efficiency (Java)
  5. Programming is for everyone ???

Some of the stages were overlapping and sometimes in paralell. Remember that dynamic languages have been there though all stages.

So will Groovy change Java? Nope. Enchance it? Yes. Be the dominant languageon Java platform along with Java? I really doubt it.

I am still searching for the NEXT language to develop in. Still haven't found a single that would drag me away from Java/Scala/Ruby/C#, by having major DIFFERENCES.


PS: Please correct me if you think I am wrong on facts, not my opinions.

Mark Haniford replied on Wed, 2008/02/13 - 7:24pm

F# isn't a dynamically typed language, so the IDE comparison isn't really valid. But F# does have really cool VS support, with a cool REPL and the ability highlight and evaluate code on the fly.

On to Groovy...I really like Groovy. It just feels and looks natural, but if Groovy were to become the dominant language on the JVM, then I fear that the Java platform will fall further behind .NET.

Somebody should take a serious look at porting Boo to the JVM. That's a very readable, and arguably more powerful language (Macros), along with dynamic typing when you want it.

Fred Grott replied on Wed, 2008/02/13 - 8:45pm in response to: Steven Devijver

Steven, a better chocie of article title might have helped clear the confusion..:)


Fred Grott(aka shareme) sometimes a JavaZone(JavaLobby) and EclipseZone contributor. Top visited blog on at:

Jeroen Wenting replied on Thu, 2008/02/14 - 1:31am

Groovy will not become "very popular", Steven.
It's had years to do that and still hardly anyone is using it (except a few like yourself and you guys seem to do more talking/propaganda about it than actual use).


Jeroen Wenting replied on Thu, 2008/02/14 - 1:35am

[quote]Does my article say Groovy will replace Java?[/quote]

From the first paragraph of your article, Steven:

[quote] 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. [/quote]

 So yes, you say that Groovy will replace Java, relegate it to the status Groovy has today.

Serge Bureau replied on Thu, 2008/02/14 - 4:52am in response to: Markus Jais



I am sorry but there are hundreds of frameworks, most of them are useless and do not live very long compared to a language lifespan.

I do not use Grails, I do not know or care about Django or Turbogears.

I was more referring to all the tools and library available to Java, they automatically become available to Groovy.

Frameworks are not at all important to me, development tools are. Ease of modifications are, syntax and easy readability is.

You can have the framework you want in Ruby, I will never use it as the language is unreadable to me and does not mix well with my current projects. Groovy has none of those issue.

It is the right mix, even more than Java was when it came out ! 

Serge Bureau replied on Thu, 2008/02/14 - 5:00am in response to: Mihai Campean



You said, ¨Sure, Groovy is much lighter, helps in faster development and it is very much integrated on the JVM, it also suceeds where Java seems to fail because of the change crisis you mentioned, but I still think it would take some time for it to replace Java, if that ever will come to pass."

I do not see where there is a need to "replace" Java since Groovy transparently mix with Java, no replacement needed.


You use the features you need from both when you need it, Groovy is a Java extension, a very nice and powerful one .

None of the other languages really fit the bill, as they mix with Java as oil with water. 

Serge Bureau replied on Thu, 2008/02/14 - 5:06am in response to: Rick Ross


as you pointed out, "Maybe "replace" isn't the right verb? Perhaps it is "enhance" or something more positive that incorporates the best of Java's solid foundation and adds valuable new semantics and paradigms?" 

That is indeed the point, Groovy is made of Java libraries, so it is an extension.

But you could say the same of JPython or JRuby, but Groovy is much more as it fits the Java syntax and it truely mix with Java, the others mix as oil and water.

There is no such interaction with the other languages, this is why Groovy is a natural choice, not Scala or Ruby or Python.


Serge Bureau replied on Thu, 2008/02/14 - 5:11am in response to: Sultan Rehman



I disagree

Groovy is the only language that is integrating naturally.

That you have hundreds of language running on the JVM does not change this, Ruby or Python are totally foreign to Java, that they run on the JVM will never feel right mixed with Java code.

That you add to the mix Fortran or Cobol would be irrelevant , Groovy feels like Java, none of the others even come close.

Serge Bureau replied on Thu, 2008/02/14 - 5:20am in response to: cowwoc


I am sorry but you seem to have more an emotional problem than a technical one.

Values are carried by the people using the tools, not by the tools themselves.

Minimalistic language you said ?

Groovy is in a way more minimalistic than Java, but minimalistic does not mean less flexible.

That you do not like the way closure is done in Groovy without an example of what you would like is irrelevant. I do like their closure implementation. Where is the Java one ? 

Graeme Rocher replied on Thu, 2008/02/14 - 5:30am in response to: Jeroen Wenting


Groovy will not become "very popular", Steven.
It's had years to do that and still hardly anyone is using it (except a few like yourself and you guys seem to do more talking/propaganda about it than actual use).



Groovy has been around for 4 years now and 1.0 has only been out a year and a bit. Ruby took over 10 years to become mildly popular and that was due to Rails and it is still no where near as popular as Java and other mainstream languages. So which has been around for years? 

 As for no one using it, well take a look at any poll that asks the question "What alternative language are you using for the JVM?" and Groovy will come out on top way above JRuby, Scala or anything else. Of course that doesn't mean its as big as Ruby/Python etc. it just means as far as driving Java developers to adopt other languages, Groovy is currently the most successful.

Serge Bureau replied on Thu, 2008/02/14 - 5:30am in response to: Rick Hightower


you said, "There is a long history of folks using Python to augment C/C++ development (as a driving language), and as organizations use Python... more and more code gets written in Python and less and less in C++/C." 

I am sorry but it is totally different, as Python and C++ mix like oil and water, they basically do not mix.

Your code must look like an awful JSP page.

Groovy is really a Java extension, and it feels Java, you do not feel like you use a different language but more like an added feature. Python or Ruby are not at all close to that.

I never could stomach JRuby or JPython or Scala, but Groovy feels like I am not switching language, and it mices impeccably. 

Serge Bureau replied on Thu, 2008/02/14 - 5:38am in response to: Alex(JAlexoid) Panzin


You are so totally wrong.

Except for very old languages, most modern languages  are multi-purpose.

Java for business you say ? Totally ridiculous.

Maybe the martian rover software would convince you otherwise ? Plus what is programming for business ? It means a big fat NOTHING.

It is not Java or Groovy it is Java and Groovy, if you do not see that as much better than your  Java/Scala/Ruby/C# by themselves then I am afraid your totally missing the point.

Mihai Campean replied on Thu, 2008/02/14 - 6:20am in response to: Serge Bureau

I agree with you Serge, I said "replace" in the context of the initial post. It is just great that Groovy integrates so well with Java and I also think that is it's geatest strenght.

Rainer Eschen replied on Thu, 2008/02/14 - 11:27am

Wow. I think this is the right subject. Many, many comments ;-).

Ok. I understand that you talk about the next step in Java development: scriptable applications. But, why not JavaScript? Why not language x? The most interesting thing to all this is the JVM support. You can have PHP on the Application Server to run your PHP in a reliable environment. So, for me it's like in the past: the languages are exchangeble, but the concepts stay.

If you've a look at Spring there's AOP on the horizon. Why not talk about AspectJ and shift to a new model of thinking? The most of the new stuff is based on 3rd generation (back to Fortran and others) stuff. Nothing new, except from the ideas in Smalltalk from the PARC days.

I can't see advantages in language details. And from the architects point of view the risk is too high for me. Enough developers on the market? Patterns that really work? Integration aspects?

Springsteam Blog - Next Generation Java Development

Jan Van Bulck replied on Thu, 2008/02/14 - 12:03pm in response to: Steven Devijver

I'm surprised that nobody mentioned the "Java - next generation" scenario: Java2, Groovy and other influences will replace themselves...

Java is going through a tough period... there are plenty of good idea's, the community is as vital as ever, but the body is getting tired and doesn't support big changes anymore. The never ending discussions on closures indicate that we've learned our lesson well: instead of adding new features sloppily, it might be better to *not* introduce these features at all. At Javapolis, the BOF on Closures was next to the BOF on Groovy. Both talked about closures, but the atmosphere was very different...

Imho, I'd prefer that the smart guys start working on a new generation of Java. Java3 has been coined before. The Javaposse talks about it from time to time as well. Forget about backward compatibility. Use JDK 7 as a start. Fix whatever doesn't smell right. And most importantly, add the good ideas from Ruby, Groovy, Scala, etc in an uncompromised fashion. This could/should add a new dimension to Java - dare I to say: somehow similar to evolution from C to C++ ?....

True, to a large extend, the result might be very Groovy-like... it wouldn't be called Groovy, though. Just Java3 or Java** or Java-whatever. If Groovy wants to grow its acceptance dramatically, it needs to change its name anyway. A wanna-be enterprise standard called 'Groovy' is just too hard to sell.

I admire the work done by the guys behind JRuby, Groovy and Scala, but I don't think they are going to beat todays Java all by themselves. I hope that at least one of them participates in creating the new Java.

Ed Smith replied on Fri, 2008/02/15 - 7:43am

This post is UTTER GARBAGE. Groovy is a pathetically slow and ugly language.

If any langauge is worthy of succeeding Java it is Scala.

It is statically typed and offers the performance of Java with syntax more elegant than Ruby. 


I and every other java developer I know have ZERO interest in Groovy. Scala is an obvious choice.

Graeme Rocher replied on Fri, 2008/02/15 - 8:13am in response to: Ed Smith


This post is UTTER GARBAGE. Groovy is a pathetically slow and ugly language.

If any langauge is worthy of succeeding Java it is Scala.

It is statically typed and offers the performance of Java with syntax more elegant than Ruby.


I and every other java developer I know have ZERO interest in Groovy. Scala is an obvious choice.



Although the post is extreme and I don't agree with the "replace" assertion, your above comments also fall into the garbage catagory. Groovy is currently the most popular alternative language for the JVM by a long way, so your friends are probably living in a hole.

 The fact that you think Groovy is ugly is subjective and your opinion, as is your assertion that Scala is more elegant than Ruby. Many find Scala's syntax very cryptic, again their opinions are subjective, each to his own.

 As for performance dynamic languages will always be slower than statically typed languages,  but the Groovy team is working on optimisations now and hope to achieve C Python speeds.

Serge Bureau replied on Fri, 2008/02/15 - 9:19am in response to: Ed Smith



I had a look at Scala, and it will remain only a look. I totally hate the syntax.

As far as static versus dynamic, it is the same debate as interpreted vs compiled, the advancement in optimizers make those not that relevant points.

So you can keep Scala.

Synthax might be a matter of taste, but integration with actual language is nuch more important, and this is where Groovy is impeccable. 



phil swenson replied on Fri, 2008/02/15 - 11:14am

> had a look at Scala, and it will remain only a look. I totally hate the syntax.

...and similar rants about ruby syntax.

 I coded in nothing but Ruby for 8 months a couple years ago... at first I found the syntax a bit weird, but then learned to really like it (for the most part anyway).  I think syntax should be driven by what makes sense, not legacy.  People have the ability to learn new things, esp programmers who's jobs probably are in flux more than any other career.

Everyone keeps saying Groovy is so much more like Java.... but I have to say I find Groovy more like Ruby than Java.

The arrays and hashes are much closer than the java equiv.  The closure syntax is very very close.  Reg ex language syntax is close.  Builders are very similar.  Both have properties.  I see a lot of influence in Groovy from Ruby.

Anyway, as to the original topic I think for a language to supplant Java on the JVM Sun will have to get behind it and proclaim it the successor.

John Wilson replied on Fri, 2008/02/15 - 11:15am in response to: Ed Smith

"I and every other java developer I know have ZERO interest in Groovy. Scala is an obvious choice."

Perhaps you should widen your circle of acquaintances :)

Groovy and Scala are not really competitors. Scala is a high performance statically typed language. The target of Scala is Java not dynamic languages like Groovy/JRuby/Jython. 

Saying that Scala is  superior to Groovy makes about as much sense as saying that a bicycle is superior to a rowing boat. I.E. it's committing a category error.

John Wilson replied on Fri, 2008/02/15 - 11:19am in response to: phil swenson

Certainly Groovy took elements from Ruby. However, Builders were taken by Ruby from Groovy (and the Groovy developers were very happy to give something back to Ruby).



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.