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

Groovy will replace the Java language as dominant language

02.13.2008
| 50011 views |
  • 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.)

Comments

Serge Bureau replied on Fri, 2008/02/15 - 12:04pm in response to: phil swenson

When you have millions of Java coders available, having a similar syntax is an overwhelming plus.

As far as waiting for Sun's blessing, let's be real.

I have defended Sun's decisions for years, but it is now incredibly slow to get anything done.

2 years between releases is much too long, where are closures? where is AOP support ? ...?

Not in Java 7, so le'ts wait 3 years and maybe ...

Sorry but I am fed up, it seems more to me that the success from Ruby and Groovy are forcing the hand of Sun, otherwise nothing would have happened.

So I do not want to loose Java's good points, but I also want more.

Groovy provides it, in spite of Sun's.

Where is the Netbeans support for Groovy ? Are you still waiting for Sun ? I am done defending their decisions, there lethargic. 

phil swenson replied on Fri, 2008/02/15 - 12:36pm in response to: Serge Bureau

>As far as waiting for Sun's blessing, let's be real.

>I have defended Sun's decisions for years, but it is now incredibly slow to get anything done.

You have a point... Microsoft seems much faster and more agile than Sun when it comes to updating the platform/language.  Perhaps all the ceremony and bueracracy of the JCP is to blame?

> Not in Java 7, so le'ts wait 3 years and maybe ...

Ya, and Java 7 still hasn't been speced out I think.  So add 2 years from whenever they settle on the features.   

> Groovy provides it, in spite of Sun's.

>Where is the Netbeans support for Groovy ? Are you still waiting for Sun ? I am done defending their decisions, there lethargic.

I like Groovy.   Feature wise, it's great IMO.  They keep cranking about 10x faster than Sun.  Groovy has huge perf probs though...when a language is outperformed by Ruby, you know you have problems!

 

 

John Wilson replied on Fri, 2008/02/15 - 12:56pm in response to: phil swenson

"They keep cranking about 10x faster than Sun.  Groovy has huge perf probs though...when a language is outperformed by Ruby, you know you have problems!"

I think you may have that back to front. I think it's an achievable goal for a dynamic language like Groovy to be less 10 *slower* than Java on current JVM implementations and have said so repeatedly on the Groovy list. I have never heard anybody say that any dynamic language on the JVM would be faster than Java it's just not a credible statement.

If you follow the Groovy list you will see that some progress is being made on improving performance but there are still substantial issues to be addressed.

In principle Groovy should be quite a bit faster than JRuby (because it's a better fit  for the JVM not because the JRuby people are not competent, they are very competent) at the moment it isn't and that's because the Groovy run time system has a bunch of crud in it because it was developed along with the language whist JRuby and Jython had the advantage of starting with an existing language.

The Groovy team may or may not be able to evolve the existing runtime system into one with good performance. My view is that they will not be able to do this via evolution (i.e. they can make it faster but not dramatically faster). However they have already done better than I expected and I may well be wrong about this. 

Tim Goeke replied on Fri, 2008/02/15 - 2:20pm

Overall, this has been an amazing discussion.  I have a question - why do any of the languages have to defeat the other?  If I am writing an application, might I not choose Java, Groovy, Scala, bash script, perl, or Ruby for different aspects of the same project?

 

I'm not sure why I need to be a Groovy programmer or a ____ (fill in the blank) programmer.  Why am I not just a programmer and trying to resolve issue using the best approach I can find and understand?

I certainly seems that the Groovy folks are seeking peaceful co-existence with others.

It may seem to be hard but many people such as Martin Fowler and Joel Spolsky seem to believe in a multi-lingual future.

If Ruby has the best ATOM library but Groovy has the best GUI framework, wouldn't I possibly choose both Ruby and Groovy as the implementation for these different responsibilities? 

Serge Bureau replied on Fri, 2008/02/15 - 3:19pm in response to: Tim Goeke

@Tim

 

In my experience, mixing language in a project is a VERY bad idea.

The reason I put Groovy as an exception is that in fact Java is "included" in Groovy. So programming in Groovy does not impair the Java part.

 

All the other's cannot claim that. This is why I agree with the statement that Groovy looks more like a Java 2.0.

In general mixing languages in a project produces a mess, very difficult to debug and maintain, not forgetting difficult to read. 

Alex(JAlexoid) ... replied on Fri, 2008/02/15 - 3:38pm in response to: Serge Bureau

@Serge

If you say  "only a look"

You could have noticed that Scala integrates with Java. It is stated in the first paragraph on http://www.scala-lang.org/.

Alex(JAlexoid) ... replied on Fri, 2008/02/15 - 3:43pm in response to: Serge Bureau

@Serge

Man.... You are pi**ed with Sun... Don't like Netbeans? Use Eclipse, use IntelliJ... Not like Sun owes to create th best IDE....

And the decisions are not lethargic, but conservative... This is what happens when there are a LOT of parties with vested interests and HUDGE investments. 

Alex(JAlexoid) ... replied on Fri, 2008/02/15 - 3:49pm in response to: Serge Bureau

@Serge

Ever heard of SOA? SCA? Maybe Layered Architechture or MVC rings a bell?

I have a fairly large project in production witch has WEB UI in RoR and backend in Java... Works FINE. Frontend developers only have the interfaces and noone cares that it is considered ONE project, that we have 2 disticnt teams and use 2 languages.

So your "VERY bad idea" becomes a beautiful, productive team of specialists...

Sridhar Gopalak... replied on Thu, 2009/12/17 - 2:35pm

Other than scripting needs, I have never ever tried using dynamic programming languages. Javascript is a good example for the constructs that you see in other strictly dynamic or scripting languages, ofcourse some are object oriented.

The core of Java was never to wander into areas already tried and tested by other OO and scripting languages, but to arrive at a community consensus ( corporate and developer ) in terms of where general purpose languages should move towards. There were/are some very clear directions conceived/followed from the onset of Java. We are able to see the maturity of enterprise software development in a phenomenal way in this regard.
Even dire contradictors to Java as a paradigm shift would find it hard to reject the fact that it has created more confidence in the community about the ultimate purpose of programming languages. We could talk about this purpose issue in sometime.

The significant question which has come up with the emergence of Ruby, Groovy, Spring about simplicity and ofcourse, the mild emergence of Smalltalk in the developer community has instilled a confidence with pro-dynamic theorists that Java would eventually become a dynamic / dynamic typed language and would accept more and more scripting features as a dire need from the community.
Java world has always been accepting in terms of popular demand. Has been the strength and trumpcard for the langauge and platform all along.
Dynamic programming as a result would become applicable in concepts and implementation would so surely evolve from there into other constructs which are today forbidden in the Java World. But, to what extent is the question.

Even in the non-enterprise scenario, the issues of maintainability, predictable code are pivotal. Purists might argue against to some level in this regard. But mainstream programming would surely agree.
Prototyping, test scripts are places where there is already a clear need for dynamic constructs. Here, the static approach of Java creates Havoc. Anyone who has tried out agile/XP or a decent amount of test scripting would agree with this.

One of the reasons why the much talked about XP is still a dream even in Java world ( with powerful theoritical acceptance for the idea) is because of this. How many applications lack consistent coverage ( particularly products with enough business logic content/rules) of test scripting in mainstream. Where is the convincing argument for this from the community till date for management approval. Should XP be in books or be practiced only in Show-Off projects?

Many of these questions would open up the need for dynamic scripting within the Java world in similar areas. But the necessity for static typed code for enterprise applications is too strong an argument to be thrown down by whimsical statements...

Off-late, I am trying my hand at Smalltalk which is more OO than Java and in some sense can be called its Guru. This statement gives due credit to smalltalk for its strong OO fundamentals ( even primitives are Objects), concept of JVM and others.
There are other features of simpler coding style, image based rather than source code based development, dynamic typing and many others areas where they contrast. Having originated from the same stem ( if i can call it) they have branched out in areas very clearly. Where smalltalk allows for scripting as an important need of a powerful language and maintains it till date, Java wanted to create a consensus and was more sure about static typing, sensible developer comfort, maintainable code.

How much does smalltalk wants to allow bare scripting inside its OO code. Does anyone see a logical anamoly here. How much freedom is enough? As a smalltalker when u script in workspace you feel procedural and suddenly when you shift into OO coding, dont you feel that you are doing something else with the language (which is fine). What I am pointing out here is, the contradiction in approach visible here is the root idea behind Java all along and is not an easy argument to trash.

Who will draw the line and where for simplicity? Who will enforce discipline into coding style and purpose here?

Being a general purpose language, Is the crux really about safety or developer convenience?

Why cant Java atleast be bit dynamic and let the architect decide where to draw the line.

And dynamic language proponents understand the fact that as long as its dynamic it might remain niche and not completely general purpose.
What can the smalltalk purists say about this?

Can we conclude that dynamic typing and scripting is just a matter of convenience and surely not a dire argument to conclude on the general purpose / enterprise software development debate?

What I told about smalltalk above is more than significant for groovy which is smalltalk conceptually over Java JVM, if i can say so....

 

Mark Haniford replied on Sun, 2010/02/21 - 4:38pm

Nope, didn't happen two years later. But with Groovy++, things might change.

Petruch Johnathan replied on Mon, 2012/06/04 - 3:02pm

Hows this coming along.  The timeline for the predictions has passed?

James Ong replied on Mon, 2012/08/27 - 6:33am in response to: Mark Haniford

Now, Groovy 2.0 has static compilation, it's aware of the limitation in a dynamic language. I still skeptical about Groovy since it going to make significant changes in the latest version.

Yay, wonder what the author's prediction over 4 years? Absolutely, thing has been slow for Groovy when Scala+Akka has been making huge improvements already, I would anytime consider Scala with commercial support over other JVM languages.

Quoted from someone's comment in stackoverflow:
Probably go for Scala - It's rapidly gaining a reputation as the heir apparent to Java, tool support is currently stronger and you'll be in a large community of others who made the same transition, so there are plenty of blogs/tutorials already available.

and Groovy? Groovy is almost never the right choice nowadays..

Comment viewing options

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