Blog

The Tools & Tech Leaderboard for 2012 shows…

We’re not much for fanfare here at ZeroTurnaround, but this is our most ambitious report that we’ve ever created. This year, over 1800 respondents shared their take on “the developer life” with us, with 1100 Java-focused surveys completed.

Want to know how much uptake Java SE 7 has seen since its release? Which IDE has grown most in user base since last year? Which application server has jumped 300% in popularity by Java developers since 2011? You’ll also get the latest numbers on Oracle WebLogic, IBM WebSphere, Eclipse, JBoss, Jenkins/Hudson, Maven, Subversion and Tomcat (alert: shameless SEO plug). It’s all in there!

In addition, we take a shot at questions like, “How do Java developers spend their work week?” and “What aspects of the coding life increase or decrease efficiency at work?” Sound good? Then sign up to get the full report!

Digging into data searching for insights is always an exciting activity. Last year’s Java EE Productivity Report 2011 was focused on tools/technologies/standards in use (exclusive selections) and turnaround time in Java (i.e. how much time is spent per hour redeploying/restarting).

This year, you will find in the full version of the Developer Productivity Report 2012 expanded coverage on technologies and tools used by Java development teams.

We also focused more on the abstract side of development. We wanted to know “What makes developers tick?” and learned a lot more about how the developer lifestyle. Our results include a lot of interesting trends and insights, so we broke them down into 4 parts:

  • Part I: Developer Tools & Technologies Usage Report – coverage of Java versions, JVM languages, IDEs, Build Tools, Application Servers (containers), Web Frameworks, Application (server-side) Frameworks, JVM Standards, Continuous Integration Servers, Front End Technology, Code Quality Tools, Version Control Systems
  • Part II: Developer Timesheet – How do devs spend their work week?
  • Part III: Developer Efficiency – What aspects of your job make devs more/less efficient?
  • Part IV: Developer Stress – What keeps devs awake at night?

Get the complete Developer Productivity Report 2012

It’s probably best to sign up to get the full Developer Productivity Report 2012, which includes the complete Developer Tools & Technologies Report, the Developer Timesheet Report, Developer Stress Report and the Developer Efficiency Report.


JavaRebel 2.0.2 was released today, and with it we’ve got a few announcements:

  1. It’s time to find a new name for JavaRebel – check out “Renaming JavaRebel” to learn more.
  2. Our Java EE Containers: Heaven or Hell survey has received more than 1000 responses, and it’s still open.  If you haven’t answered the 3 questions, do so here — and check out the results here.
  3. We’re collecting quotes from people who are already using JavaRebel.  We’re happy to hear anything you want to share!  Send it here.

And now for the release itself. Some improvements almost demand a more significant update number than a x.x.1… or perhaps announcements of their own…  To that we say – You are absolutely correct :-)  Stay tuned.

JavaRebel 2.0.2 Improvements Include:

  • Property resource bundles now reflect the changes to the property files. This should work without any special configuration from your part, just change the property file and see the changes reflected in your application.
  • Startup performance improvements.
  • SAP NetWeaver 7.0 and 7.1 are now fully supported.
  • Resin 3.1, 3.2 and 4.0 are now fully supported.
  • Preliminary support for Google App Engine. It should work, but let us know if it doesn’t, we’re not quite ready to vouch for it yet.
  • Spring plugin is now considered stable and enabled by default.
  • Spring plugin will now refresh XML files even when no classes were changed and no Spring MVC is used
  • Spring plugin will now instantiate and initialize new singletons eagerly (even if they are not referenced elsewhere)
  • You can now use -Xbootclasspath install option with Java 5+ (it works better on some older JVM versions and JRockit JVM)

There’s also a ton of fixes in this release:

  • Directories defined in rebel.xml are now also case sensitive on Windows
  • Fixed a deadlock in resource lookup (could cause infinite startup on JBoss)
  • Fixed a problem with enums being “X is not an enum type”
  • Fixed an issue that caused “Class (x) was removed” messages
  • Fixed an issue with backslashes in include/exclude elements of rebel.xml
  • Fixed an issue that caused NullPointerException on JBoss 5
  • Fixed an issue with @Deprecated annotation and AspectJ
  • Fixed an issue that caused NoSuchMethodError on some (otherwise valid) reloads
  • Fixed an issue with wrong class redefinition causing e.g. problems with JBoss 5 (http://www.zeroturnaround.com/forum/topic.php?id=303)
  • Fixed an issue that caused DuplicateMemberException on Jetty
  • Fixed an issue in Spring plugin that could cause an infinite loop when reloading a bean

You can pick up the new version on our download page, by clicking the standard download.

Enjoy!

These results are preserved for comparison, but see the later report for a full analysis of the completed survey.

Last week we asked a few questions regarding Java EE development, containers and redeploy and restart times. It was surprising to see how quickly people responded — I suppose it’s becoming a hot topic!

We had to draw the line for our analysis somewhere, so we took the first 700 responses and created the charts below. If there is a significant change in the number of responses, we’ll update these charts with new results. The 2 minute survey is still running here.  Feel free to fill it out if you haven’t already.

If you’d like to analyze the results for yourself, we have provided a copy of the data. This data may be updated as new responses come in. Email addresses have been removed from this data set.

We hope this info provides interesting insights into the world of Java EE containers and development productivity! Since we’re not professional surveyors there may be some flaws in the data and in our interpretation — so we mention some of them below, and you’re welcome to analyze the data yourself :-)

“Most Often Used Java EE Containers”

Most Often Used Java EE Containers (based on 700 respondents)

We asked, “What container do you use on your largest current Java EE project?”, which is slightly different than the chart title. Unfortunately, we didn’t clarify the difference between containers used for development and production, so answers here may be mixed – we’ll do better next time.

As usual, there was a long tail of answers. Any answer that did not receive at least 7 votes (1% of the total votes in the survey) was not put on the pie chart. The omitted containers were:

  • Tmaxsoft JEUS- 4
  • SAP NetWeaver- 3
  • Iona/Progress Artix- 1
  • zeus 4.x- 1
  • Sybase EAServer- 1
  • Impala- 1
  • Adobe JRun- 1
  • Jonas 4.x- 1
  • Assorted earlier versions of containers listed in the chart- 13

“How long is the average container redeploy + app restart?”

Actual question asked: “How long does it take to restart your container and redeploy your app?” Now, you would think that folks who answered “I never redeploy” in the next question would have had a challenge with this one, since, well… they never redeploy. Apparently they overcame that challenge. They may have answered randomly, or, if they are JavaRebel users, answered with the amount of time that it used to take to redeploy/restart, before they eliminated redeploys.

“How often do Java EE developers redeploy, per hour?”

How often do Java EE developers redeploy in an average hour of coding?

Actual question asked: “In an hour of coding, how many times do you redeploy?” Unfortunately, we made an error here. When choosing how many times you redeploy, folks who know for a fact that they redeploy exactly seven (7) times per hour faced a dilemma. Hopefully they were able to overcome this and err on the side that felt more reasonable to them: 5-7 or 7-10.

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

  1. “I’m not the guy that does the redeploys”
  2. “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.”
  3. “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”
  4. “We use JavaRebel and it’s awesome” – which led me to believe that I should have asked people if they use JavaRebel right up front, since that may bias the numbers somewhat.

Java EE Container Specific Productivity Information
For the next few container-specific charts, there is the potential for a slight error when it comes to Jetty, Oracle, and Caucho’s containers, for the simple reason that there were not a lot of people in our survey reporting numbers for them. Jetty was used by only 27 respondents, Oracle 20, and Resin had 10. With numbers like these it’s easy to sway results. Of course, the 207 results from Tomcat users isn’t a HUGE number, but at least averages are more accurate. Solution: more respondents. The survey is still live, here.

How long does container X take to redeploy?
How long is the average redeploy using a specific container

Does container X affect incremental development?
Average Number of Redeploys per hour of coding

We thought that containers that redeploy quickly would lead to more incremental development – and this was generally true, but there were exceptions.

Time spent on redeploys, per hour, with container X
How much time is spent on redeploys in an average hour of coding

Calculated like this:
Time spent redeploying in an average hour = Average number of redeploys per hour of coding x Average length of redeploy (see “How long is the average redeploy” chart).

Percentage of development time spent redeploying with container X
Percentage of coding time Java EE developers spend redeploying v2 update

Calculated like this:
Percentage of coding time spent redeploying = Time spent redeploying in an average hour of coding divided by 60 (mins)

“Annually, How much time do Java EE developers spend redeploying containers & restarting apps?” (in hours)

Annually How much time do Java EE developers spend redeploying containers restarting apps v2 update

We wanted to estimate this number quite conservatively, so we took the amount of time spent redeploying in an average hour of coding and added that up over a year, based on these assumptions:

  1. A developer rarely actually codes for 8 full hours per day. We should account for non-coding days, meetings, coffee breaks, foosball, email, twitter, etc. We assumed an average of 4 hours of coding per day, 5 days per week.
  2. We also assumed that some people get (and use) holidays and vacations, and have other reasons why they don’t code everyday. These reasons would a) reduce the amount of full weeks in the year, and b) reduce the average # of hours of coding per day. To account for these, we based a year on 40 work weeks instead of 52. Those 12 weeks should account for almost anything else you can throw in here to reduce avg weekly/daily coding hours. We figure that if you’re not coding 4 hours per day, 5 days per week, for at least 40 weeks a year, then you probably didn’t answer this survey. If we’re off here, or this is not conservative enough, let us know.
  3. It would be interesting to know what this costs, in terms of development team budget. You can estimate it for your team here.

Survey Round-up: We were impressed to receive over 700 responses so quickly and are curious to know what you think of the results!  To start – we’re curious about the folks who spend an average of 81 to 309 hours per year redeploying… Is this something that is considered acceptable in terms of development time used?

I don’t want to do anything TOO “marketingy” here, but I do have to mention that JavaRebel eliminates the need to redeploy in most redeployment situations (see Container Support and the Comparison to HotSwap and Hot Redeploy).  From these survey results, that looks like an an extra 2 to 8 weeks of development time per year, or reducing the time spent coding on a project by 3.8% to 15.4%.    <cough> And it’s easy on the wallet. Download the Free 30 Day Eval <endcough> (see Pricing if interested)

Ok, I mentioned it.  Let me know if I can improve this survey in any way.

Dave

Join the Rebellion Facebook Twitter RSS feed