| By Ivo Mägi |
Article Rating: |
|
| October 23, 2007 11:30 AM EDT |
Reads: |
10,457 |
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.
CachingNow 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$.
Subscribe to JAVA Developer's Journal Email News Alerts
Subscribe via RSS
