This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Groovy and the fly likes Groovy won't replace Java - Why not? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Languages » Groovy
Bookmark "Groovy won Watch "Groovy won New topic
Author

Groovy won't replace Java - Why not?

Jim Knowlton
Greenhorn

Joined: Jul 11, 2008
Posts: 5
I know it's been said often that Groovy is not a replacement for Java...but why not? If it uses the same JVM, compiles to the same bytecode, and is easier, more concise and more fun to code in, why the heck WOULDN'T it eventually replace Java? What am I missing?
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Originally posted by Jim Knowlton:
I know it's been said often that Groovy is not a replacement for Java...but why not? If it uses the same JVM, compiles to the same bytecode, and is easier, more concise and more fun to code in, why the heck WOULDN'T it eventually replace Java? What am I missing?


The first thing that comes to my mind is performance. Whatever they do Groovy will never be able to perform as fast as pure Java. There's just too much byte code manipulation and other shenanigans (in a good way) going on.

The second thing is Groovy is written in Java. So, if Groovy replaced Java what would they port Groovy to in order to maintain it?
[ November 18, 2008: Message edited by: Gregg Bolinger ]

GenRocket - Experts at Building Test Data
pino astarita
Greenhorn

Joined: Nov 14, 2006
Posts: 15
ok but is the same if i precompile the groovy code ?
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Originally posted by pino astarita:
ok but is the same if i precompile the groovy code ?


No. We know this because the groovy jar files are required to execute any groovy code, precompiled or not. There are still things done at runtime by groovy.
Jim Knowlton
Greenhorn

Joined: Jul 11, 2008
Posts: 5
So, as I understand it:

1. Java accesses the JVM directly - in other words, it is the language the JVM directly supports.

2. Groovy is a layer on top of Java - in other words, Groovy constructs are converted to Java, then run by the JVM. So, it adds a layer of processing.

Is this right?
Peter Johnson
author
Bartender

Joined: May 14, 2008
Posts: 5811
    
    7

#2 is correct, but I prefer to think of Groovy as a means to write(?) some very complicated Java code using a very simple and elegant syntax. I know that 'write' is not the correct term because the Groovy code I write is very simple, but the Java code generated for it is often fairly complex.

Here's and analogy. Back in the days of the infancy of C++ there were were no native C++ compilers. Instead there were C++ translators that converted the C++ code into C code, which C compilers then compiled into machine code. I think that the relationship between Groovy and Java is much like the relationship between those early C++ translators and C.

And as for #1, it would be more correct to say that the JVM directly supports byte-code. Thus any language that has a compiler that compiles source into byte-code can be considered to be a "native" JVM language. Of course, some languages, such as the Java language, translate far easier(?) into byte-code than other languages, such as Ruby. (I don't think that "far easier" is the correct term either; rather the byte-code more closely resembles the Java source than say the Ruby source.)


JBoss In Action
Marc Peabody
pie sneak
Sheriff

Joined: Feb 05, 2003
Posts: 4727

Some very good points here.

No matter what, Java is not going away any day soon and certainly not due to another JVM language replacing it.

More practically, one could ask "Would my next project benefit by writing some or all of it in Groovy rather than Java?"

If short development/maintenance time is more important than performance/SLAs, you might have a good case for Groovy (and perhaps Grails).


A good workman is known by his tools.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8903

Groovy uses reflection under the hood thereby slowing down the performance.


Groovy
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Originally posted by Prad Dip:
Groovy uses reflection under the hood thereby slowing down the performance.


Um, not really. Groovy uses reflection but so does nearly every non-groovy java based framework, API, library etc. Groovy is slower than Java for much more important reasons. Important because these are the things that make Groovy groovy baby.
Marc Peabody
pie sneak
Sheriff

Joined: Feb 05, 2003
Posts: 4727

Originally posted by Gregg Bolinger:
Um, not really. Groovy uses reflection but so does nearly every non-groovy java based framework, API, library etc. Groovy is slower than Java for much more important reasons. Important because these are the things that make Groovy groovy baby.

Do you know of any examples where Grooviness is achieved by means other than reflection or places where something in Groovy is slow for a reason other than reflection?

My understanding is that Groovy is extremely reflection intensive. Recent versions hide the reflection garbage from stack traces but the reflection is still there.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Originally posted by Marc Peabody:

Do you know of any examples where Grooviness is achieved by means other than reflection or places where something in Groovy is slow for a reason other than reflection?

My understanding is that Groovy is extremely reflection intensive. Recent versions hide the reflection garbage from stack traces but the reflection is still there.


Well, I was under the impression that there was quite a bit of bytecode manipulation going on as well as reflection. I'll do a bit more research and see what I come up with.
Matthew Taylor
Rancher

Joined: Jun 13, 2004
Posts: 110
The primary slow-down is reflection. In Groovy, everything is a GroovyObject, even primitives. When you write code like this:



Groovy transforms the primitive ints into BigInteger objects. Then it recognizes the '+' operator as a synonym for the 'plus()' method, and starts looking for a 'plus()' method to call somewhere within the first BigInteger's metaClass structure. There is no plus() method on BigInteger, but it finds one on Number that will take another Number, so this method is called to execute the addition.

You can start to understand why things slow down quickly. Nothing is ever primitive, and you can add and remove methods to any class at any time. Groovy deals with this by dynamically searching through the metaClass hierarchy at runtime, attempting to find the signature of the method being called. If it doesn't find one, you'll get the infamous MethodMissingException (which usually means you made a typo).

Reflection makes Groovy dynamic, flexible, powerful, and slow.

As far as bytecode manipulation, there is none of that going on. Method calls are intercepted on the fly at runtime, behavior is changed, etc. But all of this is done without changing existing bytecode. Sometimes bytecode is generated at runtime, however, to enable more efficient call site caching. But I think this is all a part of the MOP.


Grails Consultant
http://dangertree.net
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

I stand corrected. Thanks Matthew. Good to know.
Marc Peabody
pie sneak
Sheriff

Joined: Feb 05, 2003
Posts: 4727

Originally posted by Matthew Taylor:
... Nothing is ever primitive, and you can add and remove methods to any class at any time. Groovy deals with this by dynamically searching through the metaClass hierarchy at runtime, attempting to find the signature of the method being called. If it doesn't find one, you'll get the infamous MethodMissingException (which usually means you made a typo).

Unless you've implemented the methodMissing method. (I know you know all about this, MT, I just wanted to point it out to everyone else.) Utilizing it allows you to do some neato things like the MarkupBuilder. The MarkupBuilder internally has a methodMissing that takes virtually any series of nested method calls you send it and converts each method name into an XML tag. (see the example in the link)
Josh Brown
Ranch Hand

Joined: Oct 09, 2007
Posts: 35
Back to the original question - another reason that Groovy won't ever replace Java is that it's different. Java has static typing, and even though Groovy has (optional) static typing, it doesn't really work the same as Java. For example (try running this in the groovyConsole):


Java wouldn't allow you to assign the String literal "1" to x, since x is declared as an int. It would break at compile time. Groovy allows it - it just converts the String to its ASCII value.

I'm guessing there are lots of people out there who are firm believers in static typing and therefore would never use Groovy.
[ December 07, 2008: Message edited by: Josh Brown ]

Josh
Inside the Machine
Lison Wei
Greenhorn

Joined: Dec 08, 2008
Posts: 3
As a son ,Groovy inherited Java most features.but a son can replace father?
So ,I think the relation is more similar to jsp and servlet.


You know more, the less you will believe.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8903

Good discussion. Lot of valuable info posted by members. Since reflection is the bottleneck I am sure that experts will find out a way to make it faster in the future

I am not a fan of dynamic typing.
Marc Peabody
pie sneak
Sheriff

Joined: Feb 05, 2003
Posts: 4727

I found a blog entry by Charles Nutter, JRuby core contributor, explaining the performance gains made in Groovy 1.6, specifically with the call site cache that JRuby also uses. It was written back in May.

Near the end, he also talks about JSR-292, a proposal to change the JVM to allow more flexibility for dynamic languages. The hope is that the JSR will be implemented in Java SE 7, assuming it gets approved.

Charles has also written more recently about his direct experiences with JSR-292 in JRuby and explains lengthily the need for JSR-292 and its most juicy components.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Groovy won't replace Java - Why not?
 
Similar Threads
why should one count on groovy and grails rather than java
Spring in Action - other programming languages?
The benefits of using Groovy
Groovy / Grails vs Java / Restful
Which is better Groovy or Scala?