Deployment or Distractment?

I was discussing with a fellow java-head the other day about the odds of Java EE life. Us javaneers take quite some pride on what we do, on the frameworks we have, on the solidness as scalability of the Java EE platform, so on and so forth, but still we hate do admit one single thing: Deployment in Java sucks.

If you have ever used a Java EE server such as BEA Weblogic or JBoss you know the pain. Change something in your app, compile, package it up – a quick cycle that takes no longer than 30 seconds running ant – and then wait up to 5 minutes for the thing to be deployed!

Although some tools do help, like Eclipse WTP or server-specific ant tasks, to automatically deploy your app, you still can’t help that it takes forever to get it deployed.

I am quite fond of the RIA interface + EJB 3.0 Facades exposed as Web Services + JPA persistence triad, but having to redeploy my webapp whenever I change a single line in a JavaScript file is overkill.

Even worse, having to wait for deployment cycles knocks you out of “the zone” and leads you to distraction. Waiting for a build/deploy cycle is the perfect time for you to reach for your RSS reader or favorite social networking website and spending something from 15 minutes to hours distracted.

What can we do to get our productivity back to its heels and stay focused? Well there a few options you could try:

  1. Pair Programming;
  2. Copy changes to the deployed application directory straight up;
  3. Use a scripting language and maybe get groovier.

I’ve witnessed the power of keeping people in focus with pair programming. Two people working at one screen, with the same codebase, and frequently changing who’s steering the wheel are commited to one another in making things happen. Even with the deployment times, it’s a good time for some discussion around the code, to call a customer and check if you’re sailing to the right direction, or start writing new unit tests.

Going with the forceps approach and sticking stuff into the deployed app path could work for a few scenarios, but if you change something in a Java EE component, you’re out of luck. Without redeployment your Servlets, Seesion and Message-driven beans won’t get reloaded because they’re already classloaded. Your JSP pages will be already compiled and won’t get loaded again.

Or you could use something with a scripting language, like groovy. I happen to have liked Grails and how it still uses the Java infrastructure under the hood while giving you the same agility you’d get from using CakePHP or Ruby on Rails. They even have a service facility. Now if only those services could be made into Session EJBs… oh well guess you can’t have everything all the time. Still, Grails allow you to change anything in your app while it’s running and see changes instantly, as can be seen on this screencast.

I by no means endorse the use of Grails, or think it’s the definitive solution to all problems, but it surely has a point. I will look into it for my next personal project, and the odds are I’m gonna be hooked. If you too got interested on it, you may want to read this nice book from InfoQ.

One thought on “Deployment or Distractment?”

Leave a Reply

Your email address will not be published. Required fields are marked *