ZeroTurnaround.com

Screencast: Speedy Struts 1 and Struts2 with JRebel

2009-10-28T12:10:44Z

On September 30th, 2009, Apache released Struts 2.1.8 for general availability. Though we couldn’t find much info on the differences between 2.1.6 and 2.1.8, here’s what Musachy Barroso said about “Why web developers should choose Struts 2″, in his interview on InfoQ.

“Struts 2 is probably the most loosely-coupled framework available. Out of the box, many features are usable with little or no customization and it is easy to learn. The same knowledge can then be applied to add plugins to override default behaviors. The loose coupling also allows business logic to be written with no knowledge of the existence of Struts. Despite this, Struts scales up really well and is currently powering some very high-traffic sites.”

We like the evolution of Struts, and wanted to do our part to help minimize the time between writing Struts code & seeing the changes, so with the release of JRebel 2.1, we are proud to present extended support for Struts 1.x & 2.x, with full support for reloading action mappings. Combined with JRebel’s previously released features (skipping redeploys by reloading changes to Java classes in the running application, and skipping builds by mapping the project workspace to the deployed WARs or EARs), JRebel is now an even more potent time-saving tool for Struts 1 and Struts 2 users.

See the screencast for a demonstration of coding with Struts 2 and JRebel:

If you’re not familiar with JRebel, catch up in under 3 mins with this screencast, which shows other JRebel features, including support for the Spring framework (or take a look at the feature list):

We’re glad to see the success of the Struts 2 framework, and happy to support the community. Did you know that on average there are more than 2 million project downloads of Struts per month, since March of 2008?

The Build Tool Report: Turnaround Times using Ant, Maven, Eclipse, IntelliJ, and NetBeans

2009-10-21T16:05:29Z

The Build Tool Report: Turnaround Times using Ant, Maven, Eclipse, IntelliJ, and NetBeans

Some time ago we ran a survey asking a few questions about the build process, specifically the tools that are used to do incremental builds and how much time those builds take. We had over 600 responses, so now it’s time to count the results.

This is the first time that we’ve published results on the incremental build process, so the information is more likely to serve as a guide than an authoritative information source. That being said, the information is still quite interesting, and if it serves to start a conversation that improves the process of even one team, then we’re proud to have helped out. If you haven’t answered the 3-question survey yet, take two minutes and go for it – and do let your community know about it – as more answers trickle in we’ll update this post with the new data. If you’d like to play with the results on your own we‘ve provided all the data and our calculations in a handy Excel sheet that you can download here.

The first question in the survey was “What build tool do you use for incremental builds on your largest current project?” The breakdown follows:

Chart 1: “Which build tool is used most often for incremental builds?”

This does not include tools that scored less than 10 answers in the survey. Those are:

Buildr
Shell scripts
javac
Make
NAnt
Savant
Hudson
PHP

Maven and Ant are responsible for over half of the incremental builds in the wild. It also seems that Maven has overtaken Ant by popularity, although you should take it with a grain of salt as the questions were not phrased for this purpose. Unfortunately I couldn’t find any external data to confirm or contradict these results. Please do let us know if you know of other surveys on this topic.

The other half of incremental builds are done inside IDEs. Although some of those are just driving Ant or Maven inside the IDE, there is also a large number of developers that use the IDE as the primary build tool during development (we’ll analyze this in detail in the end of the report).

It might be valuable to reiterate here that this is a poll where respondents are self-selecting, and therefore it may not accurately reflect the actual marketplace when it comes to determining market share. Since we’re more interested in the incremental build process itself, that’s something we can live with. That being said, there is a chance that people who have fast (or slow) builds may be more likely to complete a poll like this. Since we’re not sure if this is serious enough to sway any results, we’ll just display the data, and let you decide. So, while 53% of developers are using Ant or Maven for their incremental builds, everyone else uses their IDEs: Eclipse is dominating the IDE landscape with 32% , followed by IntelliJ IDEA at 10% and NetBeans at 5%.

With that in mind, we asked, “How long does an incremental build take?”

Chart 2: “How long does an incremental build take?”

This is relatively good news. Nearly half of our respondents (44%) indicated that their incremental build process takes less than 30 seconds. 40% of respondents have incremental builds lasting from 1 to 3 minutes. Only 16% of incremental builds last over 4 minutes.

The average length of a build is 1.9 minutes with the standard deviation of 2.8.

To finish up, we asked, “In an hour of coding, how many times do you run an incremental build?”

Chart 3: “How often do Java developers run incremental builds?”

A healthy 31% of respondents don’t have to run the build at all (e.g. it’s run automatically on save). The rest of the numbers are all over the place, so we’ll wait with the analysis until we can put them in context.

The average number of incremental builds an hour is 3.9 times, with a standard deviation of 4.1.

It’s time to crunch some data. We assigned numeric values to each of the intervals (e.g. “2.5″ for the “2-3″ interval) and multiplied the number of incremental builds an hour by the amount of time one incremental build takes (basically, Chart 2 times Chart 3), thus finding the approximate amount of time respondents spend building in each hour of development. This was done per respondent, so if someone said that their build takes 4-5 minutes and they build twice an hour, we’d see a result of 9 minutes per hour. We broke down the data into the following intervals:

Chart 4: “Time spent on incremental builds during an hour of coding”

The average total time taken by incremental builds in an hour is exactly 6 minutes, but the standard deviation is 10.1, rendering this number unreliable. We can, however, divide the respondents in three quite well defined groups:

Less than 1 minute an hour. 34% of respondents basically don’t spend any time on the incremental build process.
1 to 5 minutes an hour. 34% of respondents spend a “reasonable” amount of time on incremental builds – under 5 minutes an hour. This group spends an average of 3 minutes an hour on incremental builds, which corresponds to about 5% of total development time.
Over 5 minutes an hour. 32% of respondents spend over 5 minutes an hour on incremental builds. The weighted average in this group is over 13 minutes an hour. This group of developers is spending about 22% of their development time on incremental builds.

Chart 5: “Time spent on incremental builds, per hour, by build tool”

It is clear from this chart that Ant and Maven take significantly more time than IDE builds. Both take about 8 minutes an hour, which corresponds to 13% of total development time. There seems to be little difference between the two, perhaps because the projects where you have to use Ant or Maven for incremental builds are large and complex.

Eclipse is definitely the fastest with 2.9 minutes an hour, which corresponds to about 5% of total development time. Eclipse is the only IDE supporting true incremental build on save using a fast embedded compiler, so these results are expected. It is likely that the true number is even lower, as some of the respondents use Eclipse to launch the Ant or Maven builds (we’ll return to this with the next chart).

IntelliJ IDEA falls in between with 5.7 minutes an hour and about 10% of total development time. It does not have true background compilation and often the IDE builds just launch Ant or Maven behind the scenes.

Chart 6: “Incremental build length breakdown per build tool”

This final chart shows the proportion of respondents in one of the three groups we defined with Chart 4 broken down per build tool.

Finally some things become clear. About 61% of Eclipse builds happen instantly (taking less than 1 minute per hour). We can assume that those are the respondents using compile-on-save, whereas the rest use Eclipse to launch Ant or Maven builds. Considering that 32% of respondents are using Eclipse (see Chart 1), this means that about 20% of all of the respondents use Eclipse with compile-on-save and thus benefit from the instant incremental builds.

The breakdowns of Ant and Maven times are quite similar, with Maven being slightly slower. Moreover the breakdown for IntelliJ IDEA is also similar, supporting the hypotheses that IntelliJ IDEA builds launch Ant or Maven in the background. The proportion itself likely corresponds to the size and complexity of projects, with smaller ones building quickly and larger ones taking build time of over 5 minutes and hour.

It is hard to draw any simple conclusions from this survey, as different groups have different problems, so instead let’s put together the most interesting and reliable numbers we got:

56% of respondents have builds that last over half a minute, each.
20% of respondents use Eclipse with compile-on-save and thus benefit from the instant incremental builds.
34% of respondents spend an average of 3 minutes an hour on incremental builds, which corresponds to about 5% of total development time, or 1.5 weeks per year (40-hour weeks).
32% of respondents spend more than 5 minutes per hour on incremental builds. Of the developers spending more than 5 mins per hour, 13 minutes per hour is the average amount of time spent. 13 mins per hour equals 22% of total development time, or 6.5 weeks per year (40 hour workweeks).
Weeks spent on incremental builds are calculated by assuming 48 work weeks per year (minus vacation) and an average of 5 hours of development time per day.
Java developers spend 1.5 to 6.5 work weeks a year (with an average of 3.8 work weeks, or 152 hours, annually) waiting for builds, unless they are using Eclipse with compile-on-save.

Announcing JRebel 3.0 M1 — The Next Generation

2009-10-15T14:34:02Z

While finishing the polish on the 2.1 release we were also preparing for you a glance at what’s to come in the longer term. Without further ado, allow us to introduce the JRebel 3.0 M1 release features:

Support for adding static fields and changing enums. Previously when you added a static field to your class you’d see a discouraging warning in the console and get an exception when trying to access the field. Now JRebel will happily print “Reinitialized class” and your application will continue working as if nothing happened. To top it off you can also now change Java 1.5 enums in any way you like and they should just continue working. This feature is still a tad experimental, so please help us out to smooth it out!
Full JSP <scriptlet> support. Now when you change your Java code (e.g. add a method) it can be immediately used in the Java code snippets in the JSP.
25%-30% less memory use. It is not uncommon to need a lot of PermGen heap with JRebel enabled. Now we optimized the memory use and will continue to drive it down in the upcoming milestones.
No more classloader leaks. JRebel no longer holds any references to class loaders a second longer than necessary. This should help to get less OutOfMemoryErrors on application redeploys with JRebel enabled.

There are also quite a few changes to the API that will enabled more features in the upcoming milestones.

Note that since we don’t charge for upgrades, it is not our goal to put all the cool features in the 3.0 release. Rather we’ll continue to add features to the 2.x branch (expect at least a 2.2 release this year) and only put large or risky changes that require a lot of testing or feedback in the 3.x branch.

Download the release.

ZeroTurnaround’s OSS projects overview

2009-10-14T10:08:50Z

This post serves as a quick introduction to the open source projects that we develop and host on our site. They are either accompanying QA software, integrations with different frameworks or our IDE plugins. All described projects are hosted at http://repos.zeroturnaround.com/svn/.

If you’ve written plugins that you would like us to host just contact support@zeroturnaround.com. If you have patches to current projects just let us know and we’ll take a look and try to get them integrated.

jr-autotest/

JRebel testing is not that simple. For example, say we want to test changing a protected field to a private static. We need to have a test that first compiles a source file with a protected field and then lets a JVM load it. Then we need to make the changes to the source, compile and make JRebel reload it. Then asserts follow :) It sounds easier said than done. This sub project hosts all the tests and a groovy script to control them all.

jr-servlettest/

See jr-autotest and think of servlets. These tests run on arbitary containers and besides testing JRebel functionality it tests the integration with different containers. The control script this time makes requests to URLs and compares the output to some predefined output.

jr-autotest-hudsonplugin/

Legacy. A year ago we were so dumb that we wrote a Hudson plugin that was able to read the output of the ANT script of the autotest and produce nice red/green buttons about which test failed/passed. Now this is quite obsolete as we have moved on to JUnit output instead.

jr-ide-support/

idea-old-plugin – source code for the Intellij debugger plugin for IDEA ver < 8
idea-plugin – our current up-to date plugin for IDEA 8+
eclipse – all eclipse plugins/features
nb-6.5-plugin – NetBeans 6.5 specific plugin
nb-6.7-plugin – NetBeans 6.7 specific plugin

jr-javassist/

We bundle javassist to javarebel.jar. This is so that we don’t have it in the classpath as an external dependency. This project generates a javassist archive for us where all the classes are in packages with a predefined prefix.

jr-root/

Here are all our integrations with different frameworks and our plugin architecture. You can see the whole list under trunk.

As of this post, we have integrations with:

JRebel 2.1 Released – Strolling with Struts

2009-10-06T11:46:49Z

We are proud to present JRebel 2.1, the “Struts” edition. The main features of this release are the reworked Struts 2.x plugin and the brand new Struts 1.x plugin that reload changes to Struts action mappings on-the-fly both from XML and Java 5 annotations. Developing Struts applications with JRebel is now easier than ever, as no restarts are necessary anymore.

This release also includes support for GlassFish v3 and the Felix OSGi container it is based on. According to this survey developers spend 13% of development time or 4.3 full-time weeks every year redeploying on the GlassFish v2 container. GlassFish v3 boasts improved startup time, but with JRebel you can take the cost of making a change down to zero.

Starting with this release JRebel will report some anonymous usage statistics to our servers (including jvm name and version, container name and version, frameworks you use and redeploy stats). You can see all of the data in the jrebel.info text file created next to jrebel.jar This data will be used to help us prioritize development, but if you wouldn’t like to send it please add -Drebel.usage_reporting=false to the JVM command line.

Finally this release includes a multitude of fixes that were found since the 2.0.3 release. A lot of them concern the Spring plugin, though a few bugs were also found in the JRebel core.

BIG NOTE: We have renamed “javarebel.jar” to “jrebel.jar” and you’ll have to update your installation command line accordingly.

Proceed to download or view the full changelog.

How to install and use JRebel with Glassfish and Eclipse IDE

2009-10-06T10:58:27Z

How to install and use JRebel (formerly JavaRebel) in GlassFish with Eclipse IDE

In the recently published Java EE Container Restart & Redeploy Report, the GlassFish v2 application container was the best of the fully fledged Java EE containers in the terms of time spent redeploying. That’s the good news. The not so good news is that on average respondents report spending 14% of their coding time waiting for server redeploys/restarts. That’s just over 170 hours annually, per developer – approximately 4.3 full weeks of development time. JRebel eliminates the need to redeploy in about 80% of redeploy situations – and it’s easy to get started. This tutorial explains how to install and use it step-by-step.

Here we assume that you are using Eclipse 3.x with GlassFish v2. Most of the steps will be applicable to other versions as well, but it may look different from the screenshots included.

NOTE: Although GlassFish is tightly integrated with NetBeans, the JRebel support for that IDE is in Beta at the moment – for now, we recommend using Eclipse or IntelliJ IDEA instead. We’ll make sure to announce when better NetBeans support is available (it’s coming soon).

First, take a quick look at how coding looks when using JRebel (formerly JavaRebel).

Contents:

STEP 1: Install JRebel
STEP 2: Installing JRebel Eclipse IDE plugin
STEP 3: Make a rebel.xml for your application
STEP 4: Configuring the Eclipse WTP IDE
STEP 5: Configuring Eclipse IDE
STEP 6: Configuring GlassFish
STEP 7: Success!

STEP 1: Install JRebel

The latest stable version of JRebel can be downloaded here. Unpack it to a directory of your choice.

STEP 2: Installing JRebel Eclipse IDE plugin

The JRebel Eclipse IDE plugin was introduced with JRebel 2.0 and makes configuring and using JRebel considerably easier. You can install the plugin by going to Help » Software updates » Available software » Add site and use the http://www.zeroturnaround.com/update-site/ URL as the update site.

STEP 3: Make a rebel.xml for your application

In order to do it’s magic, JRebel needs to know where your classes and resources are. We’ll use a rebel.xml configuration file to tell it. This is mandatory when you deploy your app as a WAR/EAR. You’ll need to have one rebel.xml file per module. This includes both web and EJB modules. The rebel.xml configuration file should be placed in your WEB-INF/classes directory in the case of a web module and in the jar root in the case of an ejb module. Put it in the root of a source or resource folder in your project (the same place where the .properties files are).

If you use Maven you can use the JRebel Maven plugin that will generate the rebel.xml in accordance with the module pom.xml as described in the Maven Plugin configuration manual.

In 99% of cases, people tend to use one module per project. In these cases, the JRebel Eclipse IDE plugin can generate the rebel.xml file for you, on a per project basis. If your project is one of the exceptions, edit the file manually as described in the Installation manual, otherwise generate the rebel.xml like this:

Click on your project and pick Generate rebel.xml

STEP 4: Configuring the Eclipse WTP IDE

You may skip this step if you run GlassFish outside of the Eclipse IDE.

Open the Servers View and double click the GlassFish v2 that your application is deployed to (if you don’t see the Servers View go to Window » Show View » Servers).

Open Publishing and choose Never publish automatically.

It may seem wrong to disable automatic publishing, but as JRebel will take care of updates from now on it will just slow you down.

STEP 5: Configuring Eclipse IDE

Go to Window » Preferences and from there to Java » Debug » Step Filtering. Check Use Step Filters and Filter synthetic methods and Step through filters. Now check all the default filters and use the Add Filter button to add com.zeroturnaround.* and org.zeroturnaround.*.

Now go to Project » Build automatically and make sure it is checked.

STEP 6: Configuring GlassFish

Start the GlassFish server and open the Admin Console.

In the Administration Console open Application Server » JVM Settings » JVM Options

Use the Add JVM Option button to insert the following two new options:

-noverify
-javaagent:%REBEL_HOME%\javarebel.jar

NB! Unfortunately GlassFish will not expand the environment variable (even if you define it) so you have to substitute %REBEL_HOME% with the actual path!

Press Save and restart the server.

STEP 7: Success!

To check that the installation was successful access a page that uses a class, change that class in the IDE, press Save, access the page again and look for the following message in the console:

Now that you’re up and running, it’s time to enjoy coding without the need to redeploy. If you have any specific questions JRebel, the Forum is the best place to ask, so that other people get to hear the answer as well. Otherwise, you can contact us at support@zeroturnaround.com.

If you like what you see, please give us a quick mention on your blog or twitter (you can even follow us here).

Have a great day!

Find out more:

How to Install and Use JRebel with WebLogic and Eclipse

2009-09-30T10:07:24Z

How to install and use JRebel in WebLogic with Eclipse IDE

In a recently conducted survey (with 1100+ respondents), WebLogic users estimated spending approximately 21% of all their coding time on the redeployment process. To extrapolate a bit, that’s ~13 minutes per hour of coding, adding up to ~256 hours or 6.4 full work weeks annually. JRebel reduces this time by 80%, so it’s worth taking a few minutes to try it out. In this tutorial we explain how to install and use it step-by-step.

First, take a quick look at how coding looks when using JRebel (formerly JavaRebel).

This tutorial assumes that you are using Eclipse 3.x (with Oracle Enterprise Pack for Eclipse installed) with WebLogic 9.x or later. Most of the steps will be applicable to other versions as well, but it may look different from the screenshots included.

Contents:

STEP 1: Install JRebel
STEP 2: Installing JRebel Eclipse IDE plugin
STEP 3: Make a rebel.xml for your application
STEP 4: Configuring the Eclipse WTP IDE
- Configuring the Eclipse WTP IDE workaround
STEP 5: Configuring Eclipse IDE
STEP 6: Success!

STEP 1: Install JRebel

The latest stable version of JRebel can be downloaded here. Unpack it to a directory of your choice.

STEP 2: Installing JRebel Eclipse IDE plugin

STEP 3: Make a rebel.xml for your application

If you use Maven you can use the JRebel Maven plugin that will generate the rebel.xml in accordance with the module pom.xml as described in the Maven Plugin configuration manual.

Click on your project and pick Generate rebel.xml

STEP 4: Configuring the Eclipse WTP IDE

You may skip this step if you run Weblogic outside of the Eclipse IDE.

Open the Servers View and double click the BEA WebLogic Server that your application is deployed to (if you don’t see the Servers View go to Window » Show View » Servers).

Open Publishing and choose Never publish automatically.

It may seem wrong to disable automatic publishing, but as JRebel will take care of updates from now on, it would just slow you down.

Open JRebel Integration and check Enable JRebel agent.

NB! With the current version of the Eclipse JRebel plugin checking the checkbox does NOT WORK. See the workaround in the next step.

STEP 4a: Configuring the Eclipse WTP IDE workaround

Until we update our JRebel Eclipse plugin you have to manually enable JRebel for the Weblogic Server. You would need to manually edit the startup script of the server. Luckily it is quite easy and the startup script can be opened for editing from the server view from the last step.

A text file will open. You will need to copy the following line as the first line of the file

set JAVA_OPTIONS=-noverify -javaagent:C:\javarebel.jar %JAVA_OPTIONS%

Make sure to change the C:\javarebel.jar to the correct location.

STEP 5: Configuring Eclipse IDE

Go to Window » Preferences and from there to Java » Debug » Step Filtering. Check Use Step Filters and Filter synthetic methodsand Step through filters. Now check all the default filters and use the Add Filter button to add com.zeroturnaround.* andorg.zeroturnaround.*.

Now go to Project » Build automatically and make sure it is checked.

STEP 6: Success!

To check that the installation was successful access a page that uses a class, change that class in the IDE, press Save, access the page again and look for the following message in the console:

If you like what you see, please give us a quick mention on your blog or twitter (you can even follow us here).

Have a great day!

Find out more:

How to install and use JRebel in IBM WebSphere with Rational Application Developer or Eclipse

2009-09-24T09:22:09Z

The IBM WebSphere application container features one of the longest startup and redeploy times in J2EE development. In a survey we conducted (with 1100+ developer-respondents), WebSphere users estimated spending approximately 23% of their coding time (approximately 276 hours per year — or 6.9 full, 40-hour workweeks) waiting for applications to redeploy. JRebel eliminates 80% of redeploy situations, and it’s easy to get started. In the embedded video you can take a quick look at how coding looks when using JRebel (formerly JavaRebel).

This guide assumes that you are using Eclipse 3.x or Rational Application Developer 7.x with WebSphere 6.x or later. Most of the steps will be applicable to other versions as well, but it may look different from the screenshots included.

Contents:

STEP 1: Install JRebel
STEP 2: Installing JRebel Eclipse/RAD IDE plugin
STEP 3: Make a rebel.xml for your application
STEP 4: Configuring IBM Rational Application Developer
STEP 5: Configuring Eclipse/RAD IDE
STEP 6: Configuring IBM WebSphere
STEP 7: Success!

STEP 1: Install JRebel

The latest stable version of JRebel can be downloaded here. Unpack it to a directory of your choice.

It is useful to define an environment variable called REBEL_HOME pointing to the directory you choose. In Windows you can do this by going to Control Panel » System » Advanced » Environment Variables » System Variable » New.

Now navigate to the directory where Java is bundled with IBM WebSphere. If you have a standalone installation it’s %IBM_HOME%\WebSphere\AppServer\java\bin. If you have it installed as part of RAD7 it should be %IBM_HOME%\SDP\runtimes\base_v61\java\bin. Run the following line in the console:

java -jar %REBEL_HOME%\javarebel.jar

STEP 2: Installing JRebel Eclipse/RAD IDE plugin

STEP 3: Make a rebel.xml for your application

If you use Maven you can use the JRebel Maven plugin that will generate the rebel.xml in accordance with the module pom.xml as described in the Maven Plugin configuration manual.

Click on your project and pick Generate rebel.xml

Done.

Repeat this for all projects that you’d like to update with JRebel.

If you’d like to use one rebel.xml for your whole team, start with the generated rebel.xml, then replace the absolute paths to your workspace with a system property. JRebel will expand expressions like “${myProject.root}” in rebel.xml to a system property that you can pass to the application container as -DmyProject.root=c:/myWorkspace/myProject. This allows to you to use a single configuration for everyone and then customize it when starting the server.

STEP 4: Configuring IBM Rational Application Developer

You may skip this step if you use the Eclipse IDE or run IBM WebSphere outside the RAD IDE.

Open the Servers View and double click the WebSphere Application Server that your application is deployed to (if you don’t see the Servers View go to Window » Show View » Servers).

Open Publishing and choose Never publish automatically.

Open Publishing settings for WebSphere Application Server and choose Run server with resources on server.

It may seem wrong to disable automatic publishing, but as JRebel will take care of updates from now on it would just slow you down.

STEP 5: Configuring Eclipse/RAD IDE

Now go to Project » Build Automatically and make sure it is checked.

STEP 6: Configuring IBM WebSphere

Start the IBM WebSphere server and run the Administrative Console.

In the Administration Console open Servers » Application Servers and select the server your app is deployed to.

Select Java and Process Management » Process Definition.

Select Java Virtual Machine.

Insert the following line into Generic JVM arguments:

-noverify -Xshareclasses:none -Xbootclasspath/p:%REBEL_HOME%\javarebel-bootstrap.jar;%REBEL_HOME%\javarebel.jar

NB! Unfortunately WebSphere will not expand the environment variable so you have to substitute %REBEL_HOME% with the actual path!

Press OK, when asked, Save the master configuration and restart the server.

STEP 7: Success!

To check that the installation was successful access a page that uses a class, change that class in the IDE, press Save, access the page again and look for the following message in the console:

If you like what you see, please give us a quick mention on your blog or twitter (you can even follow us here).

Have a great day!

Find out more:

Survey Results: The Java EE Container Redeploy & Restart Report – measuring Turnaround Time

2009-09-28T12:50:01Z

A couple of months ago we ran a survey asking a few questions about Java EE development, containers and redeploy times. Now that over 1100 people have responded it’s time to update the results. Since we’ve had more time to analyze them we also hope to provide a few insights into the data including a more detailed container breakdown.

If you’d like to play with the results on your own we‘ve provided all the data and our calculations in a handy Excel sheet that you can download here. As a note, if you haven’t answered the 3-question survey yet, take two minutes and go for it. As more answers trickle in we’ll update this post with the new data.

The first question in the survey was “What container do you use on your largest current project?”. The breakdown follows:

Chart 1: Which Container is used most often?

We didn’t include the containers that scored less than 10 answers in the survey. These included:

(2) Adobe JRun
(1) Geronimo
(1) Iona
(7) TmaxSoft JEUS
(5) JONAS
(1) Pramati Server
(4) SAP NetWeaver
(2) Sybase EAServer

Unsurprisingly Apache Tomcat holds the lead, closely followed by JBoss. Together the OSS servers total over 70% of the responses. Although I wouldn’t go as far as to translate these numbers directly into market share, we did find studies that found similar results, courtesy of SD Times – Slight differences though: we asked which ONE container you use for your largest projects, and theirs appear to allow people to choose multiple containers.

The 2nd question we asked was, “How long does it take to restart your container and redeploy your app?”. The breakdown follows (the horizontal axis is in minutes):

Chart 2: “How long does it take to restart your container and redeploy your app?”

We previously assumed that the redeploy/restart phase lasted approximately 1 minute. Though 38% of respondents agreed or said it was quicker than 1 minute, 62% suggested that this process lasts around 2 or more minutes. The calculated average is approximately 2.5 minutes –indicating that we underestimated the amount of time spent on the redeploy phase.

Moving along, we asked, “In an hour of coding, how many times do you redeploy?”. The breakdown follows:

Chart 3: “How Many Times do you Redeploy in an Hour of Coding?”

The distribution seems to be close to normal, excepting the jump in the end. The average is slightly over five times an hour, which coincides with the measurements we did before.

For those who answered, “I never redeploy”, we asked some of them how they did this. Responses were:

“I’m not the guy that does the redeploys”
“We develop on embedded jetty & activemq & atomikos in debug mode instead of nearly unusable target OracleAS. So of course we need redeploy or restart jetty as usual, but not the OAS.”
“I’m in the very early stages of a project so a lot of out time is spent coding and testing without redeploying – typically I redeploy 3-4 times per hour”
“We use JavaRebel and it’s awesome” (this obviously came from someone trying to charm our development team – who are still blushing. Note – it’s now called JRebel.)

Next we did some data crunching. We assigned numeric values to each of the intervals (e.g. “3.5″ for the “3-4″ interval) and multiplied the number of redeploys an hour by the amount of time one redeploy takes (basically, Chart 2 times Chart 3), thus finding the approximate amount of time respondents spend redeploying in each hour of development. We broke down the data into five minute intervals:

Chart 4: How Much Time Does a Java Developer Spend Redeploying in an Hour of Coding? (using raw data before improving accuracy)

The average is about twelve and a half minutes per hour, accounting for more than 20% of total development time. However, the standard deviation is over 14, which means that the actual per cent varies greatly. We wanted to show more accurate data, so by looking closely and grouping results, we found this:

Less than 5 minutes an hour. Looking into this group we see that it is slightly skewed by the respondents who indicated that they never redeploy. We asked the people who “never redeploy” how they do it (see comments above), and they indicated that their responses were often not effective for tracking the actual redeploy time that we are trying to measure. Therefore, it makes sense to remove that data from the chart.
5 to 15 minutes an hour. 45% of respondents fall into this category.
20 to 25 minutes an hour.
Over 30 minutes an hour. Looking closer at the data we see that some of the respondents indicated that they redeploy over 60 minutes an hour (choosing both “More than 10 redeploys per hour” and “More than 5 minutes per redeploy” for Charts 2 and 3). This is quite impossible. In fact, we believe any number over 40 minutes per hour seems to be against reason. It makes sense to remove all this data from the chart too.

The chart with the updated data looks as follows:

Chart 5: How Much Time Does a Java Developer Spend Redeploying in an Hour of Coding? (more accurate data)

The average is now ten and a half minutes per hour with a standard deviation of 8, which is more trustworthy. This translates to about 17.5% of total development time, which is considerably more than we expected. We will use this “cleaned up data” for the rest of the post.

Later we’ll describe how to calculate this over a year, but here are some quick figures:

5 mins per coding hour becomes 6000 minutes annually (2.5, 40-hour workweeks)
9 mins per coding hour becomes 10800 minutes annually (4.5 weeks)
14 mins per coding hour becomes 16800 mins annually (7 weeks)
21% of respondents report spending more than 14 mins per hour on redeploys
71% of respondents report spending more than 2.5 full weeks per year, redeploying.

After looking at this issue in general, we investigated the data on a per-container basis. This is what we found:

Chart 6: Organized By Container, How Much Time is Spent Redeploying?

There are few surprises here. Jetty is leading the pack with only 5.8 minutes per hour spent redeploying and IBM WebSphere is trailing with more than twice more — 13.8 minutes per hour. One thing to note is that although Jetty startup is undoubtedly faster than IBM WebSphere it is likely that most of the difference is due to the size of the applications deployed and the technologies used in them.

Next we have the same chart, but numbers displayed as a percent of development time (time spent per hour divided by 60). Perhaps it’s useful to describe how we define “Development Time”. For us, Development time is what you spend actually writing code, with an IDE, running your server and the Java language. This doesn’t include meetings, gathering requirements, smoking or any other activities that don’t involve a compiler. We’ve asked around, and it sounds like the industry assumes that 5 hours per day are spent coding.

Chart 7: Organized by Container, What Percent of Development Time is Spent Redeploying?

To put those numbers in perspective we can also calculate the amount of time spent redeploying a year. To do that, we’ll make some assumptions:

We assume 48 work weeks per year. If you’re lucky enough to get more than 4 weeks of vacation, don’t rub it in.
We assume that 5 hours per day is spent doing development. The other 3 hours are reserved for non-development activities.

The following chart displays the number of 40-hour work weeks a year spent redeploying:

Chart 8: How many 40-hour work weeks are spent on the redeploy phase, over a year?

Depending on the container, we’re looking at 3 to 7 work weeks per year, spent exclusively on the redeploy phase. The average over all of the data is slightly over 5 work weeks a year, but the standard deviation of 4 makes the range of 3-7 more reliable.

Our final graph shows the amount of time spent redeploying per container in more detail. Instead of using averages, we break down the proportion of respondents that redeploy into groups: less than 5 minutes an hour, 5 to 14 minutes and hour, 15 to 29 minutes and hour and over 30 minutes an hour. We expect that this may show the size of projects that use different containers, and potentially shed light on the time your project spends redeploying.

Chart 9: Java EE container market penetration.

We interpret this chart as:

Jetty is only used in projects that redeploy quickly. This makes all kind of sense, considering that Jetty doesn’t even support redeployment and instead has extremely fast container startup.
Apache Tomcat and GlassFish are used in same types of project. Both are posed as fully functional yet lightweight alternatives to the classic heavy application servers. Although Tomcat is much more popular today, GlassFish is growing in popularity in the same market share.
JBoss, Oracle Weblogic and IBM WebSphere compete for pretty much the same market segment. The majority of their projects are large and complex, and the redeploy times reflect that.
Another interesting fact is that the proportion of projects in the 5-14 group is pretty stable for all containers. This likely corresponds to medium-sized projects that are not actively contested by either lightweight or classical application servers. The only exception is Jetty, which is heavily skewed to the lightweight side.

Coming up next: We’re taking a look at incremental build times and comparing Ant, Maven, Eclipse, IntelliJ, and NetBeans. If you’re interested, take a minute to participate here. Thanks!

Ant vs Maven vs Eclipse, IntelliJ, NetBeans – Exploring Incremental Builds

2009-09-21T11:49:58Z

We’re looking into incremental builds — trying to document the differences in popularity & productivity between using tools like Ant and Maven versus IDEs. We haven’t seen a study like this before, so thanks for taking a minute to fill this out. If you’re interested in winning a free license of JRebel (formerly JavaRebel), include your email address in the optional email section.

For the study, click here.

Thanks,

Dave