Where-to-not use Groovy

Hi Scott!

Where would you NOT use Groovy? Ignoring when you're working with pre-existing Java code or legacy stuff, are there, in your experience, areas where Java is still the better choice?

Thanks, looking forward to the book (free or not

)!

In Groovy, method calls are dynamically dispatched. In Java, they are statically determined at compile-time. This is going to make Groovy slower in every case, although we are talking milliseconds here. If you are doing "real-time" Java (is there such a thing?), or some huge gagillion iteration loop of computationally intensive stuff, I'd look to Groovy. Of course, if Java isn't fast enough, I'd use C via JNI. If C wasn't fast enough, I'd use Assembly.

You can find micro-benchmarks that can prove anything that you'd like. In my experience as a web developer, the two long poles in my tent are DB access and HTTP response times. Hibernate tries to cache like mad on the DB side, and Apache HTTPD tries to cache like mad on the web side. Groovy has always been plenty fast enough for me in the middle -- I might be able to shave off a millisecond or two here or there, but nothing compared to the pain at the edges of the app.

FWIW, they are making huge performance gains in Groovy 1.6 (the next major release). They are caching dynamic calls so that they can be reused and presumably JIT'ed by the JVM. As I said, Groovy's already quite fast enough for my needs, so it'll be interesting to see what it's like after the next major rev.