• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Groovy won't replace Java - Why not?

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
ok but is the same if i precompile the groovy code ?
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
author
Posts: 5856
7
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
#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.)
 
pie sneak
Posts: 4727
Mac VI Editor Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).
 
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Groovy uses reflection under the hood thereby slowing down the performance.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 4727
Mac VI Editor Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Rancher
Posts: 110
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I stand corrected. Thanks Matthew. Good to know.
 
Marc Peabody
pie sneak
Posts: 4727
Mac VI Editor Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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)
 
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Pradeep bhatt
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 4727
Mac VI Editor Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Villains always have antidotes. They're funny that way. Here's an antidote disguised as a tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic