Last year, we published a report on turnaround time, tools and application containers in the Java ecosystem. Over 1300 Java developers ending up sharing info about their development environment, and over 40,000 people found these results helpful.
This year we expanded on that, asking more and better questions to give you better and more accurate information. This preliminary release of our data includes 946 responses that were analyzed to create this report. The raw data, including all calculations, will be made available for download when the final version of the report is issued in December 2010. We want to discover:
- What is more popular, Ant or Maven?
- What Java IDE is the most popular?
- What Java EE standards are used the most?
- Which Java Framework are most prevalent?
- What Java Container / App Server is used the most?
- How much development time is spent redeploying Java containers?
The survey is still live. It’s 6 questions (slightly different than those above), and takes 2 minutes. Take the survey.
Build Tools and IDEs – Setting the scene
We asked everyone to mark the tools they use for building applications. The only two build systems to receive more than 1 vote were Maven and Ant:
As you can see Maven and Ant are used almost equally and some respondents chose both. Clearly they are each useful in certain ways.
The IDE chart is more interesting:
Eclipse has emerged here as the clear leader (in terms of # of users at least), with only one-third of respondents using IntelliJ IDEA (#2) and Netbeans (#3).
Servers & Frameworks – Who are the popular kids at school?
Compared to the last year’s chart we see % gains for the open source containers. We can also see that Jetty and Tomcat have a bigger share than last year, while Glassfish is sliding a bit. Oracle Weblogic and IBM Websphere have lost a total of 8% of the market to the open source containers compared to the last year (according to this sample of developers at least. A larger sample = better results. Contribute here :) ).
As far as Java EE standards are concerned we have the following picture:
JSP keeps the throne as the most popular Java EE standard (along with Servlets and JDBC not present here). JPA is amazingly popular, having over a third of the market. EJB versions altogether have 39%, which would make them the most popular standard, but there’s likely some overlap between EJB2 and EJB3 users, so the total is likely a bit smaller.
Let’s take a look at the framework chart:
Spring and Hibernate are by the most popular and in fact are still used more than standards. However, as far as web frameworks go JSF looks like a popular choice with 24% of answers. Unfortunately, we haven’t separated Spring MVC from Spring, but it’s likely at least as popular as JSF. The rest of the frameworks hold a share of 10% or less (GWT is barely over that and is the third most popular).
Turnaround times – How does your environment compare?
This year we asked questions about the time it takes to redeploy the application and number of redeploys per hour. We also asked those who don’t have to redeploy to comment why this happens. We were glad to see the development in this area since last year – these were some of the responses we received:
- “I wait till I have enough changes to warrant a redeploy”
- “We use tests (unit tests, integration tests, etc)”
- “We use Eclipse/Sysdeo/Intellij IDEA/etc HotDeploy”
- “We use HotSwap/Eclipse Debugger Session/etc”
- “We use OSGi”
- “We use Grails, Play! or Tapestry 5″
- “We use JRebel” :)
(Commentary on these responses, provided by ZeroTurnaround Founder & CTO Jevgeni Kabanov, will appear elsewhere and in different forums).
We originally did not include a “30sec” answer to the question “How long does take to redeploy your application?” However, we have since received a few comments about that – and to compensate for that, we will use a “45sec” value for the answer “1 minute” answer. But you can see that 30 sec has since been added to the survey.
The first Turnaround question was “How long does it take to restart your container and redeploy your app?” The answers are distributed like this:
We didn’t ask with such accuracy last year, which makes it harder to compare, but it seems the trends have remained the same.
Last year’s average redeploy time was 2.5 minutes, and this year the average redeploy time is 3.1 minutes. But with a standard deviation of 2.8, which means that the redeploy time varies greatly. It can be noted that a statistically significant segment of respondents chose answers over 10 minutes.
The next question was “In an hour of coding, how many times do you redeploy?”:
The average frequency is 4 times an hour with a standard deviation of 3.2. Last year, our average frequency for redeploys was 5 times per hour.
To calculate the total time spent redeploying in an hour we first removed those who “don’t redeploy” at all and those that reported redeploying “more than 45 minutes” of every hour (woah!). Calculating the total we get:
Average respondent spends about 9.7 minutes an hour redeploying with a standard deviation of 8. This is about 16.1% of total coding time.
As with last year, we took the assumption that the average Java developer spends about 5 hours of every day coding. The other 3 hours of each day we assume are spent answering emails, having meetings, drinking coffee, swordfighting, and doing other tasks.
Taking into account this 5-hour coding day and 4 weeks a year of vacation [some get], we get about 4.8 work-weeks each year spent redeploying. So, even a lucky developer that gets 4 weeks a year of vacation time will spend on average even more time than that waiting for redeploys.
Finally, we can also see how the choice of container correlates to the time spent redeploying. Note that it doesn’t mean that bigger containers are that much slower, rather bigger apps influence the choice of container:
Compared to last year, not many application servers changed, with the exception of Glassfish v3, which is apparently faster than before.
Stay tuned for the final report in December. More good stuff (including analysis) to come.
Remember, this survey is still open and the more developers that come to share their Java environments, the better and more applicable our results will be! Did we mention that before? ;-)