Archive for the ‘blog’ Category

Survey Results: Java EE Containers – Heaven or Hell?

Thursday, July 2nd, 2009

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

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

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 – is it acceptable that every developer spends an average of 81 to 319 hours per year redeploying?

Just as a note, 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 would give your team an extra 2 to 8 weeks of development time per year, or you would cut development time on a project by 3.8% to 15.4%.

Is that worth $149?  (see Pricing)

Java EE Container Heaven/Hell

Thursday, June 25th, 2009

We’re collecting info on the amount of time it takes Java EE developers to restart and redeploy when you want to see changes that you’ve made to your code. In return, we’re giving away 5 Personal Licenses of JavaRebel to some lucky people, and we’ll share these answers on our blog ( http://www.zeroturnaround.com/blog/ ) in about a week.

The 3 multiple choice questions will definitely take less than a minute, and your answers will help people choose containers wisely.

http://spreadsheets.google.com/viewform?formkey=cm1rMHVOZEZBMjdSSUZ2eFJCTXFCT1E6MA..

Thanks,

Dave

JavaONE 2009 raffle licenses have been sent out

Monday, June 15th, 2009

JavaONE 2009 raffle licenses have been sent out. All license winners be sure to check your SPAM folder if you don’t have the license email in your inbox. The lucky winners were:

  • Cliff Janson
  • Mahesh Purushothaman
  • Ashok Mudgapalli
  • Kartik Lakshminarayanan
  • Ove Scheel
  • Jordan Laughlin
  • Jesper Hasselström
  • Dewayne Johnson
  • Jonathan Hair
  • Prasanna Gopinath

The raffled license is a personal unrestricted annual license, meaning that you may use JavaRebel on as many machines as you’d like, but you may not share/transfer the license with/to anyone else. You can check out the license terms at http://www.zeroturnaround.com/javarebel-license/

JavaRebel JavaONE 2nd batch of license winners

Saturday, June 6th, 2009

JavaONE 2009 has ended now. It was fun meeting all the people who came by our booth and congrats to the next batch of JavaRebel license winners.

  • Prasanja Gopwath
  • Jonathan Hair
  • Dewagu Johnson
  • Jesper Hasselström
  • Jordan Laughlin

We will contact all the lucky winners during next week after the conference. The licenses are personal 1 year licenses of JavaRebel.

JavaRebel JavaONE license winners

Wednesday, June 3rd, 2009

JavaOne 2009 has been going great for us so far. We have a booth at the pavilion, we’re doing demos, talking to current and new customers and having a blast. We also have a raffle for JavaRebel licenses. The first 5 winners of the JavaONE JavaRebel license are:

  • Cliff Janson
  • Mahesh Purushothaman
  • Ashok Mudgapalli
  • Kartik Lakshminarayanan
  • Ove Scheel

We will contact all the lucky winners during next week after the conference. The licenses are personal 1 year licenses of JavaRebel.

If you’re interested in winning a license or just chatting with the developers drop by our booth 221 in the exhibition area of Moscone North.

JavaRebel Eclipse Plugin Released

Thursday, April 30th, 2009

The JavaRebel Eclipse plugin was released into the wild today. Though JavaRebel does not depend on any IDE, it’s awesome when you can setup and configure JavaRebel with a single click. This plugin also includes better support for debugging JavaRebel enabled applications.

The plugin depends on Eclipse 3.4 and is available from the update site at http://www.zeroturnaround.com/update-site/ If you’re a not WTP user be sure not to include WTP support as it has a lot of dependencies.

For more info on the Eclipse plugin functionality, read the Eclipse Plugin Tutorial or check out the changelog.

Eclipse Plugin Tutorial

Thursday, April 30th, 2009

Though JavaRebel does not depend on any IDE or development tools in particular, (besides a compiler) it’s nice to have tight integration with your IDE. Enter – the JavaRebel Eclipse Plugin. Remember: as long as you overwrite your old class files with new ones, JavaRebel will reload your changes and cut down on time spent redeploying.

The JavaRebel Eclipse Plugin generates JavaRebel configuration automatically, enables JavaRebel in a single click, and improves the debugging support in Eclipse. This article will help you to set up the plugin and take advantage of the features.

Installation

JavaRebel Eclipse plugin requires Eclipse 3.4 or later. You can install the plugin from ZeroTurnaround update site by going to Help » Software updates » Available software » Add site and use the http://www.zeroturnaround.com/update-site/ URL as the update site. If you’re not a WTP user you can skip the optional WTP integration (dependencies are quite heavy in size if no WTP is installed).

install

Configuring JavaRebel Eclipse plugin

To use JavaRebel in the Run Configurations later on we’ll need to set a global location of the javarebel.jar. You can do this from Window » Preferences » JavaRebel. Just pinpoint the path to your javarebel.jar location.

preferences

Launching applications

Whenever you run a program you can enable JavaRebel for that run configuration. This means that once enabled then the -javaagent:your_location/javarebel.jar will be added automatically to the startup flags. Checking the debug checkbox will also generate a JavaRebel.log to the location of the javarebel.jar file.

To enable, disable JavaRebel just navigate to the JavaRebel tab for your run configuration and use the checkboxes.

launch

Generating rebel.xml

Applications can be Right click on your project and pick Generate rebel.xml. Place the generated rebel.xml to the root of a project source folder or to a project output folder. If you place rebel.xml to a project output folder you’ll have to make sure that Eclipse doesn’t delete it while cleaning project, open Window » Preferences »; Java » Compiler » Building and uncheck Scrub output folders when cleaning projects.
This generates a basic rebel.xml for your project, have a look at JavaRebel configuration manual for more options.
Maven projects should use JavaRebel maven plugin to generate rebel.xml.

generate

Configuring WTP

Automatic publishing should be disabled in the server configuration. Double click on your server name and a configuration page opens. Under the Publish section you should have the Automatically publish when resources change option selected. I’ve outlined the automatic publishing settings in the following screenshot.

wtp-server

Don’t forget to generate rebel.xml for webapps, otherwise JavaRebel may not be able to pick up changes to static resources.

ZeroTurnaround exhibiting at Jax.de

Saturday, April 18th, 2009

We will be exhibiting at Jax.de 2009, Germany next week. JAX is the leading conference on Java, software architecture and agility in Europe. It offers a special blend of topics that signal the direction of the Java Enterprise Community in the upcoming years.

At the conference we’ll have a booth to show demos, answer questions and meet our friends and clients. Our Lead Rebel, Jevgeni Kabanov, will also be presenting a session on Wednesday from 13:45 at Gutenbergsaal II titled Watching the logs roll by.

Any framework or application developers who are looking for help with integration with JavaRebel just drop by the booth, we have two core developers present.

You can follow the updates in realtime at twitter.com/javarebel.

DNArebel — Improve Yourself, Today

Wednesday, April 1st, 2009

We at ZeroTurnaround believe that all bugs must be corrected as soon as possible. However often it just doesn’t seem possible to do that immediately (if ever). Usually in such cases the bugs are not so much in the code of the program as in the DNA of the engineer.

Although you can try to improve the engineer by breeding him or her with another engineer, this process is lengthy and can take up to 20 years. Moreover it is likely that the engineer will get distracted and watch TV, play games, breed with non-engineers and otherwise avoid work during that time. It is also not a reliable process, producing better engineers only half of the time.

With the new DNArebel it all is about to change. Based on our award winning JavaRebel engine, DNArebel allows you to edit your genes on the fly, save and continue working. If you’re tackling a complicated problem that is clearly beyond you there no more need to leave it for the future generations. Just hack on your spacial imagination and abstract thinking genes and get it done now.

“We have tested the product extensively”, says ZeroTurnaround marketing captain David Booth, “and for those that survive the process, it increases developer productivity by more than 3000% on average. Using time saved and developer salaries to calculate ROI, we’re talking about replacing hundreds of unmodified engineers with a single DNArebel user.”

While the cost savings are beneficial in any economic climate, developers report results of another nature. “We’re hearing that the folks who used to look with envy at their smarter peers, are feeling much more comfortable with their skillset now”, mentions ZeroTurnaround founder, Jevgeni Kabanov, “they’re enjoying the greatly improved cognition skills by making glorious fun of those still not using DNArebel.”

Based on customer feedback, ZeroTurnaround has priced DNArebel for the cost-conscious at 149 999 USD per concurrent user, per annum. They expect most firms will see the tool pay for itself within the first month of use, and offer a 30-day no-questions-asked money-back policy.

~~~

ZeroTurnaround is not liable for any damage that incorrect usage of DNArebel may cause. If your coworker has mutated into a terrifying monster please use the emergency superstrength/superspeed patch. If it feels that your brains are dissolving into goo, they most probably are and you may be eligible for a full refund. And there is no such thing as zombies, please stop flooding our forums with reports of their sightings, it’s probably just you going insane.

JavaRebel 2.0 released – improves upon the award-winning 1.0

Wednesday, March 25th, 2009

ZeroTurnaround today announced the release of JavaRebel 2.0, a JVM plugin that enables Java developers to see changes to their code immediately, without the need for application or container restarts.

Two weeks ago, JavaRebel 1.0 won a JOLT Productivity Award for its role in cutting development time and development team costs — recognition of the significant productivity gains that current customers are reporting. “We’re hearing that teams are saving an average of 10-40 minutes per developer, per day, in time otherwise wasted on application restarts”, said ZeroTurnaround marketing captain, David Booth, “Using time saved and developer salaries to calculate ROI, we’re talking about thousands of dollars in savings, per year, from each member of the team using JavaRebel in their development.” With JavaRebel 2.0’s expanded feature set, easy installation, and dramatically improved performance, ZeroTurnaround looks to build upon the success of the first version.

While the cost savings are beneficial in any economic climate, developers report results of another nature. “We’re hearing that the folks who used to look with envy at this feature in dynamic languages like Ruby and Python, are feeling much more comfortable with their Java applications now”, mentions ZeroTurnaround founder, Jevgeni Kabanov, “they’re enjoying the quick feedback and the incremental development techniques that flow naturally from a lightweight coding style like this.”

JavaRebel 2.0 supports:

  • Changes to method bodies
  • Changes to class structure, including adding methods, fields, constructors, changing/adding annotations, and changing interfaces
  • Changes to configurations in Spring, Guice, Wicket, Stripes, Tapestry 4, and Struts2, with an open API for adding further support
  • All major JVMs and containers
  • Exploded and Unexploded Development practices – what does this mean?

ZeroTurnaround has priced JavaRebel 2.0 for the cost-conscious at 149USD per concurrent user, per annum. Based on customer feedback, they expect most firms will see the tool pay for itself within the first month of use, and offer a 30-day no-questions-asked money-back policy.

New and Noteworthy in JavaRebel 2.0
Download JavaRebel 2.0 Trial
www.zeroturnaround.com/javarebel

~~
About ZeroTurnaround
ZeroTurnaround is a trademark of a prominent Baltic company, Webmedia, Ltd. that focuses on improving developer productivity. Turnaround is the time it takes for the changes in code to propagate to a running application. It includes build time, deploy time and initialization time.