Why is "Zero turnaround time" so important? I will try to elaborate on the subject and give a broader picture about the activities performed during the Java EE application development cycle.
What is this stuff all about? It is about developing as fast as you can. And I do not mean typing as fast as you can, because you are good at that anyway. Nor do I mean compilation time – modern IDEs all have incremental compilation models, which work blazingly fast.
I mean the root of all evil: the deployment time. Have you ever watched you fellow PHP/Ruby/Python developers at work? They make a change in the source code, hit CTRL+S to save the source code, press ALT+TAB switching to the browser window where only a refresh is needed and voilà – they can see the result in their browser within milliseconds.
Now think about the titans you are wrestling at the same time. Maybe you perform some kind of build activities with Ant or Maven? Maybe you are using administration utilities of your application servers to initiate the deployment procedure? And even if you are not doing any of the above I can bet that whatever you are doing it will take at least 30 seconds more than it takes your scripting colleague. Most of this time goes into the mystical deployment phase, which you most likely take as something you cannot affect. But hey - now you can – with the help of a new tool called JavaRebel.
Building
First let’s take a look at the build cycle. It usually consists of some kind of preprocessing of the source files, copying environment-specific configuration files, downloading dependencies, compiling source code, creating distribution, etc. It is relatively easy to get lost in your building procedure and start applying different kinds of magic. I have seen build scripts written in Ant larger than 10 000 lines. It was abnormal. Build procedure should be as easy as possible. And what is most important – you should use your build scripts only when checking out a new version from your version control repository. All your activities after the first build should be carried out only using your favorite IDE's incremental compiling possibilities. There should be no need to touch your build script again.
What does it mean to you as a developer? First you should configure your Java EE development to use an exploded format. For those who are not familiar with the term – you should not create WAR nor EAR files for deployment, but instead keep the WAR/EAR content exploded in the file system. Why – you might ask. But can you imagine anything weirder than first zipping the content of some directory and then telling some java process (your application server) to unzip it. That is exactly what application servers do with your nicely packaged WARs and EARs.
State preserving
As you might have noticed the first part of this article had nothing to do with the JavaRebel, it was only a precondition for the JavaRebel to have the exploded development model in place. Now let’s check something more interesting – state preserving.
If you are anything like me you have a lot of state in your application. And yet again – if you are anything like me you are keeping most of the state in HttpSession. Well it does not actually even matter – you could keep it in stateful session beans or in some kind of homegrown solution – I am pretty sure you have stateful objects. And you have business processes operating on this state – something like “select a customer, create an order, add order details, select transport, select payment, etc”. It is usually a long and complex process with a lot of state management going around under the hood. And you hate these processes because each and every time you have to debug them it will take forever – you add a fix, you change something and voila – you have to start the whole process all over again because the state was lost during the redeployment.
Some of you might now be proud of either their application server which supports persistent HttpSessions or of themselves if they have added a support for such a feature. But all these solutions I have seen are still complex and slower than the possibilities JavaRebel offers you. You will not think about those kinds of things any more.
Caching
Now let’s take a peek on other aspect of the state preservation – caching. Most likely you have found some part of your domain model to be relatively static, so it could be worthwhile to cache the instances. So you apply caching and pick a solution for loading the caches which can be either lazy or eager. If you choose lazy loading all first hits to your application are darned slow. It affects you in two ways – your development slows down and your customer could get wrong impression about the application on the first couple of clicks – you have to wait the caches to warm up. And since it is usually the customer who is going to check the application first with the empty caches who will decide whether you have made a good job or a lousy one, you will end up with an angry customer.
So you pick eager loading. Now everything is nearly OK, except that … your caches grow beyond all initial estimates. And the initial loading will start taking time. A lot of time – I have seen this exceeding several minutes. And boom – your development cycle is even slower than it would have been with lazy loading applied. Now you start experimenting by serializing the content of your caches to some kind of external medium when undeploying (usually your development environment hard drive) and deserializing it when deploying. And– you have to manage another dimension of complexity in both your build scripts and caching solution. With JavaRebel applied you will not even notice that you have made an operation which would have required the caches to be reloaded.
Author's Note: You can download JavaRebel from ZeroTurnaround.com and give it
a try. Disclaimer: JavaRebel is commercial software with a free trial for 14
days and developer seat cost at 99$.
About Ivo Mägi Ivo Mägi is Chief Development Manager, Webmedia AS - the largest software development company in Estonia with over 250 employees under Webmedia Group. The company operates in Estonia, Finland, Lithuania, Romania and Serbia.
"Have you ever watched your fellow PHP/Ruby/Python developers at work? They make a change in the source code, hit CTRL+S to save the source code, press ALT+TAB.."
Actually that's the only way I (and many I know) develop with Java (in fact we avoid the ALT+TAB since most IDEs have internal browsers). So it's not really an innovation. For EJB development, use OpenEJB and Tomcat and develop in any IDE (with zero deployment).
#2
Dave Lauta commented on 24 Oct 2007
Big Deal, I do the same thing with Eclipse J2EE, Struts, and JSP's at least 10,000 times everyday. Without regard to source code file type, I hit save, eclipse compiles all dependancies and hot deploys to the Websphere AS. Alt tab to the browser and F5 refresh, Only difference is that in my development environment, I plan my changes before I throw code at the current situation.
#1
Reloader Jasper commented on 22 Oct 2007
Shouldn;t an innovation like this have come from Sun? Not from an indie shop? What an oversight!
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
Click to Add our RSS Feeds to the Service of Your Choice:
.gif)
Why is "Zero turnaround time" so important? I will try to elaborate on the subject and give a broader picture about the activities performed during the Java EE application development cycle.
