A Groovy Decision

Note: This post was actually written at the beginning of the year, just never quite completed & posted until now.

When I started at the company we had 2 big process that were running in cobol ( well pretty much any way, the team had started rewritting large portions of the first project in Java before I joined ). Over the 3 years that I have been here we have completely removed the cobol from the first process. Now I am working on removing the cobol from the second process. The first thing that we relalized is that the heart of the 2 applications is exactly the same, of course it was litterally 2 copies of the same files with different names in the cobol code. So we want to reuse the heart of Project A that has already been rewritten, I'm not about to go copying and pasting the files like the cobol was. So we decided that we would create Project C which is nothing more than refactoring out the chunk of A that will be reused by B.

Project A was written when Java was first starting to be used here at the company and used a homegrown framework for Database connections, logging, and most importantly our Domain/Entity objects. This framework is a very slow memory hog that is difficult to work with from a coding perspecitive. All of the new code we currently write is using EJB 3 ( Hibernate for batch proccesses like these ) along with a little bit of our own framework that is more just a wrapper for the actual frameworks we use instead of all of our own crap code.

So that left us a few options:

1. Write Project B using the old framework ( framework is so out-dated that this was quickly ruled out.
2. Rewrite Project A using our new framework ( this is an eventual goal, but this would take at least 3-4 months with no customer benifit, so this was also quickly ruled out )
3. Write Project C as a webservice running somewhere that could be called by both A & B ( These proccess take roughly 1 hour to run today, and would make roughly 60-70 million times, sounds like a preformance problem to me )
4. Copy & Paste all the "reusable" code into project B and modify it to use our new framework. ( do I even need to say why we ruled this out )
   
5. Use a dynamically typed Language ( groovy was my preference going in ).

I got together with my team leader and his manager, to discuss our options. At first there was some resistance to something as new ( as in new to the company ) as groovy. Over the course of our discussion we seriously weighed all the costs and benefits of each option. I think at some point in our talks we had thought that each one of these was the best solution. However in the end the biggest reasons against a dynamic language were performance and training. Performance seams to be constantly debated and we eventually agreed that without writing the code and seeing what happens there is no way we would ever be able to trust any benchmarks. And as for training, well at some point every team's technologies need to progress otherwise our team would still be writing in COBOL.

So Groovy it is. Everything I read talks about Groovy being completely compatible with Java, so we'll start with renaming all of the files from .java to .groovy and go from there. I anticipate that this will not be as smooth as I dream, but hopefully not too bad. Stay tuned.