Groovy embedded in Java and maintenance

Won't maintenance become a problem if part of the code is implemented using Groovy? Suddenly you have to have programmers that know Groovy as well as Java working with maintenance?

Hello Morten,

This is true if you put your groovy code inside your java classes (which is basically the same as putting your HTML in the servlets, or putting java code in JSPs). It will be a maintenance nightmare. This has a really simple solution, and that is put your groovy code in it's own class files, and load those files from inside your java code. You can have something like this

It's a good question, but allow me to twist it a bit: what if your project uses Struts 1.x and you decide to switch to Tapestry. There is two ways that you could look at this:

1. We are staffed with sharp Java developers. Even though the keystrokes are going to change, with a little bit of training they should be able to make the transition without a problem.

2. People here are afraid of change. They learn keystroke instead of concepts. Even the upgrade from Struts 1.x to 2.x would throw them for a loop. It's best that we continue to do things the way we always have.

Here's the rub -- with Struts 1.x, you are dealing with a page-centric MVC framework. With Tapestry, you are dealing with a component-oriented framework. I'd argue that this is closer to the Java/Groovy example. Java is statically typed, and Groovy is a dynamic language. But here's the neat part: you can use Groovy as if it was statically typed. So you truly get the best of both worlds.

Adding Groovy to your project is literally adding a single JAR to your classpath. IDEA IntelliJ, Eclipse, and NetBeans all have Groovy plugins that make the transition no-brainer for Java developers used to autocompletion, debugging, and refactoring support.

But adding any new technology to a project, be it Groovy, Hibernate, Spring, or anything else will be a "maintenance nightmare" if someone has never worked with it before and doesn't want to learn new things. They'll have to learn Hibernate instead of iBatis, Spring instead of Guice, etc. The good news is that Groovy syntax can be so much like Java that most folks wouldn't bat an eye.

[S]: But here's the neat part: you can use Groovy as if it was statically typed. So you truly get the best of both worlds.

I don't suppose Groovy has any rough equivalent of Perl's "use strict"? E.g., some setting you could use to require stricter programming practices? I suppose that relates to the very conflict between static and dynamic typing, and "scripting" vs "programming" languages. (Of course you can do real programming in any scripting language, hence the quotes.) Some shops may want some of the benefits of Groovy, but may still want to enforce stricter typing. I guess they can just establish a coding standard and expect people to follow it. But in some shops, Groovy might be an easier sell if there were a way to require this programmatically rather than through convention.
[ February 19, 2008: Message edited by: Jim Yingst ]

what if your project uses Struts 1.x and you decide to switch to Tapestry.

Wow, out of the frying pan and into the fire.

Sorry, couldn't resist.

Originally posted by Gregg Bolinger:
Wow, out of the frying pan and into the fire. Sorry, couldn't resist.

It seems that there are a lot of people bashing tapestry wherever I turn. I really wish Alexander Kolesnikov luck on the 4th of March book promotion

Gregg is a recovering Tapestryholic.