When you are not careful about how you develop your software, it’s easy to do this in an inefficient way. The last couple of weeks I’ve been streamlining the developers their workstation, to become as efficient as possible. I’ll talk about some of the measures I took, how it was done and what the final benefits were. Also, I’d like to talk about some of the possible drawbacks.

Shorten the build cycle for developers

The length of the build-cycle is critical for developers.

Exploded development

With the release of JBoss Tools for eclipse, I finally managed to get a very good exploded development going on. I tested the beta 3 as well as the beta 4. In both cases, exploded wars didn’t function as I wanted. Didn’t remember quite what didn’t work, but with the the GA release, everything worked out fine.

The main benefit of exploded development is the powerful option to edit JSP files live! This is a serious advantage. Our team started out without this, but as the project exploded in size, the start-up time was increasing drastically. Would not ever want to do another project without this ability!

Another great benefit is the possibility for incremental publishing (standard behavior with the plug-in). Packing a war is something that can take half a minute or longer using eclipse, with incremental publishing only the changed files are submitted, resulting in mere seconds.

The last benefit is a faster start-up, since the server doesn’t have to unpack the war. Our war is about 45Mb large, which took 10-15 seconds to unpack.

There is one setback! When using this, there is a bug when you have breakpoints in eclipse. The breakpoints sometimes (and this is rather frequent, say 1 in 5) cause the server to start up really slow. And slow is like 1h to start… The workaround here is to restart the server and disable the breakpoints on start-up, enabling them once the server is started. It’s a common bug when you Google for it, so I’m confident this will get resolved soon.

Hot-code replacement

Learning how to use hot-code replacement can save some restarts of the server. With hot code replacement, you can alter any Java code, as long as you stay within the method where your breakpoint currently hangs. This is perfect for adjusting 1 line of code, since most bugs are exactly one small thing that was wrong.

There is a little more to it. Sometimes eclipse complains about the failure of the hot code replace. What we do is following: we let the thread run until it’s finished. Then we start the code again (refresh the page, submit a form…) and let it stop on the same breakpoint. Then we add 1 space and save it. This never fails!

No Hibernate Cache

Another great way to speedup the start time during development, is to disable the Hibernate cache (second level cache, query cache) during development. With a maven profile, this is done very easy.

We have about 25 classes that are non-strict read/write cached. This takes about 12 seconds to start-up, every class that is cached has it’s own thread started by Hibernate (I think this is for timeout of the cache).

No premature loading of cached items

Many applications start by eager fetching some data this is cached then. I believe this is completely useless in a development environment. Again with Maven this ain’t hard to set up.

A word about Spring configuration

One could argue that the Spring configuration could also be completely lazy. Indeed, this would be a tremendous start-up gain, in our 100 beans large project, it takes 20 seconds to set up the beans. It’s the single most time consuming event in our application start-up.

We don’t do this, since it posses a real danger. With lazily initiated beans you lose the dependency checks at start-up

Shorten the setup time

Setting up eclipse is something we needed to do quite a lot of times. When switching branches, when added dependencies etc.

We used to use the maven eclipse plug-in. Lately I found out that this plug-in is absolutely unnecessary. With the proper maven setup, the simple command mvn eclipse:eclipse does the trick. Actually you need two things:

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-eclipse-plugin</artifactId>
                <configuration>
                    <wtpversion>1.5</wtpversion>
                </configuration>
            </plugin>

Above is a plugin in the web module (pom.xml).

<jboss-web>
    <context-root>mistral</context-root>
</jboss-web>

Above is the content of the file webapp/WEB-INF/jboss-web.xml , which sets the context-root with jboss. If you don’t do this, it’ll default to the war filename.

Other optimizations

In order to have the best possible environment, other optimizations are in order. But I’ll keep those for my follow-up. Things that can be improved:

• Use of the continuous integration.
• A (good) project wiki
• How to manage multiple databases efficiently(database independence per developer)
• Office instant messaging

Conclusion

Pretty long post. There is a lot to say about development optimizations. My experience in it is that there is a lot to gain. There are some key concerns however:

• KISS, Keep It Simple Stupid.  An optimization should never be something that has to be explained. Optimizations are only good optimizations when they feel natural, they should also make things simpler almost never more complex.
• A very important one: a team should work all in the same manner. It’s too hard when multiple ways of developing have to be supported.
• Don’t be afraid to change your development manners. Sometimes a change can be a little investment, but large gains on longer terms.

As always, I’m open for debate and questions.

Regards,
Andries