Is Java slow for web development? Code, compile, deploy is a necessary evil, but not for development

Is Java slow for web development? Code, compile, deploy is a necessary evil, but not for development. We want just to change and test.

Even those that decide to go with interpreted languages at some point need to compile and deploy for scalability purposes. This is not rocket science. As an oversimplified explanation, if the runtime application code needs to be interpreted every time it runs then resources are used inefficiently.

When Java Servlet specification appeared in the market at the end of the 90's we were already coding web dynamic pages using CGI (C and even unsafe unix power tools), Perl and PHP. We were developing fast indeed, Why did we move towards Java? There is no simple answer but for one Java scaled to way more concurrent users.

And yet we were coding Model 1 at the beginning. That meant we could put the code in the infamous JSP scriptlets and see the results immediately in the browser just as PHP did.

Then several papers convinced us that separation of concerns were needed and we moved to Model 2 where the application logic was now in compiled servlets and the presentation code was in JSP. At that point the JVM should have had what it didn't have for years: Dynamic Code reloading.

In the early 00's Sun shipped JDK 1.4 with Hotswap to address the issue, but only partially. Only changes in methods would be dynamically reloaded so if you change anything from a simple method name to a new class you will need to recompile and redeploy.

In 2000 though JUnit hit the market and many Java developers have relied on tools like automated compilation and test run from CLI or IDE. This technique has allowed us to rapidly develop functionality while providing automated test cases. Of course when the time comes to test in the application server fast code replacement is a must have. The pain continues when not only dynamic languages like python and ruby are more developer friendly but on top of them new frameworks appear offering rapid code generation.

At the end of 2007 jrebel hit the market. Since its inception it has been free for Open Source Projects but Commercial for the enterprise. Clearly still an issue for small companies like startups where you want to save every penny.

In the early 10's Sun engaged in a research partnership called Dynamic Code Evolution VM (DCEVM) which has been recently forked and actively maintained so far.

Concentrated on the efficiencies of the runtime the JVM has not evolved as we all would have expected. Instead the JVM has become the foundation to run more dynamic languages like ruby and scala for example.

Many people have moved to languages like Groovy, others have moved to use frameworks like Play but the common denominator has been the lack of an effective Hotswap engine.

Enough of history. It is 2014 and here is how you patch the latest version of jdk 1.7 ( Once we conclude our java 8 migration I will be posting instructions in this blog ) to allow in place class reloading. In addition I am including how to deploy HotSwapAgent for your typical MVC java application. HotswapAgent supports Spring, Hibernate and more. I have tested this with jdk1.7.0_6 (jdk-7u60-linux-x64.tar.gz):