True Story

WHAT DEVELOPERS WANT: THE END OF APPLICATION REDEPLOYS

Email. Even 90-year-old grandmothers use it. We use email because it’s convenient and, in most cases, faster and more reliable than sending letters by post. And to some young people, even email is starting to seem antiquated and inefficient as a means of communication.

But imagine that every time you wanted to write, send or receive an email, you needed to restart your computer. How much time would this take, and how annoying would that be?

There is a similar threat faced by Java development teams worldwide: that of turnaround time due to application deployments (or restarts). This is a time drain that, according to over 1100 developers recently surveyed, forces the average coder to forfeit over 5, full 40-hour work weeks each year, time that could otherwise be spent writing code, testing and/or learning new things.

This document presents a technology overview and business case for JRebel, as a commercial solution for eliminating the need to redeploy Java applications in order to see changes to code, such as when adding new features or fixing bugs.

BRIEFINTRODUC-TION

A LITTLEHISTORY

Introduced in 1995 by Sun Microsystems, the Java programming language and Java Virtual Machine (JVM) is a highly regarded and well-respected piece of engineering. Not only is it widely adopted among Web

and Enterprise App producers, Java benefits from continual improvements in recent

years and even more good stuff is on the way. Java is a powerhouse in the program-ming world, based on widespread applica-bility and use, some excellent engineering

behind the JVM platform, the clarity of syn-tax, the rich ecosystem of tools and libraries and the fact that Oracle says there are over

9 million Java developers out there (and many billions of app/device users).

However, Java code changes cannot be dynamically reloaded, which means that quickly seeing what you do isn’t possible

by default. When Java code is added or changed, the developer must build/compile and then deploy the code in a cycle that al-

lows changes to be visible only after restart-ing the application server. Every time.

SO WHAT’S THE PROBLEM WITH APPLICATION RESTARTS ANYWAY?

So what do redeploys and application restarts mean for developers? A few things:

• Constant interruptions instead of focusing on writing code

• Slow feedback cycle to new changes

• An average of 10.5 minutes per coding hour (over five 40-hour work weeks per year - yep!) of time forfeited to application restarts [1].

For most changes a developer makes to their code – for example, adding a new feature, fixing a bug or improving functionality – a full application restart (or redeploy) is required for the changes to take effect. Depending on the size of the application, the application server, build tools, frameworks and hardware used, this can take anywhere from 30 seconds to 30 minutes (yep, we’ve heard this before!)

Ideally, a developer would make a single change and then quickly verify it is correct be-fore moving on. This would consequently lead to less bugs and service requests later on, but the time drain would be intolerable – and we’ve seen the horrified faces of developers who report having to spend 25-50% of each coding hour redeploying their application.

To avoid that, developers line up a lot of new code changes to launch in a single batch be-cause to do otherwise is time consuming and highly disruptive to a developers’ concentra-tion; however, now we see the slow feedback cycle come into play.

JRebel is a product designed to provide devel-opers with a rapid feedback cycle, while also

getting rid of the constant interruptions due to application server restarts (keep in mind, even a 30 second restart is enough of an interrup-tion to break concentration for as much as 15 minutes)

JRebel provides this unique development expe-rience through eliminating the need to restart Java applications in order to see code changes. The ripple effect of eliminating interruptions of this kind is well-proven since 2008; using JRebel developers can instantly reload indi-vidual changes to class structures, resources and framework configurations instead of com-mitting a full application restart. This saves an average of 10.5 minutes per coding hour, which comes out to over 5 work weeks each year.

[1] Java Productivity Report 2011

From this report we gathered information on the popularity and usage of build tools, Java IDEs, Java EE standards, Java application servers and web and server-side frameworks. In addition we asked the following two questions:

• How long does it take to restart your Application Server and redeploy your app?• In an hour of coding, how many times do you redeploy?

The results from these questions showed that the average redeploy time is 3.1 minutes, but the standard deviation is 2.8, which means that the redeploy time varies greatly. The average frequen-cy is 4 times an hour with the standard deviation of 3.2.

Another interesting fact pointed to the statistically significant segment of respondents (just over 1 in every 10 developers) responded that it takes over 10 minutes to redeploy.

At this point, a good question to ask would be: “What can every developer in your team do with an extra 5+ weeks of development time each year?”

WHERE DO THESE STATISTICS ?Approximately 1100 Java developers from all over the world shared their development environment in ZeroTurnaround’s Java EE Productivity Report in 2011.

Time Redeploying in an Hour

5%

8% 14%

30% 34

%

3%

30+

21-2

5

26-3

0

16-2

0

6-10

11-1

5 < 11-5

1%

5%

The normalized data shows that an average of 10.5 minutes per coding hour, per developer, is forfeited to ap-plication restarts. Of course, this does not include build/compile time, nor the time is takes to get back into the “flow” after the interruption. If we assume a 5-hour coding day, with the other 3 hours dedicated to planning, meetings, breaks, etc, then losses are:

• 52.5 minutes each day• Over 4.3 hours per week• Almost 18 hours per month• More than five, 40-hour work weeks each year

COME FROM

SOLUTION

But what does JRebel do?The beauty of JRebel is its simplicity - JRebel instantly reloads changes to class files, resources and framework configuration files. Whenever a developer adds/removes/changes methods, classes, annotations, fields or constructors, JRebel will immediately reload the individual change, making a full application redeploy unnecessary. Below, you can see the typical Java EE development cycle:

In Phase 1, code changes are added in the developer’s IDE. Then, the code is compiled or built in Phase 2. In Phase 3, the code is deployed, e.g. via application deploy, which can be only be done a few times before an OutOfMemoryException occurs. In that case, the application server itself must be restarted, which is when the time drain typically happens. Only after restarting in Phase 4 can the developer see the changes were committed.

THE

JRebel eliminates redeploys, saving hours each week of time otherwise forfeited to redeployment.

The first version of JRebel was created in a secret Estonian basement cubicle under an even more secret codename in 2006 by Jevgeni Kabanov. It was designed to be an internal tool to cut down on redeploy times in a software company, which was suffering from 10+ minute redeploy times.

Since then, over 3000 companies have purchased JRebel, and at the time of this white paper the current version is JRebel 4.6. JRebel now supports every major application server available on the market, six different IDEs and nearly 50 web and server-side Java frameworks.

Add feature, Þx bug, or improve code using IDE of choice: Changes are compiled and optionally

packaged into EARs / WARs. (Incremental builds comsume 60-260 hours annually)

The application is redeployed to the container. This phase consumes on average, 17% of development time (210 hours - over 5 weeks annually).

and choose to improve the change or move on to something new. Either way, go to Phase One.

JRebel integrates directly with your IDE, app servers and frameworks of choice, letting you and your team skip Phases 2 & 3 and reclaiming over 5 weeks per year of lost time.

The Java EE Development cycle

PHASE FOUR PHASE THREE

PHASE TWOPHASE ONE

JRebel maps your project workspace directly to your running application. W hen a developer makes a change to any class or resource in their IDE the change is immediately

Without going too deeply into the technical side of things, JRebel works based on three specific areas of Java and the JVM:

1. Java Classes2. Framework configuration changes3. Workspace mapping

Java ClassesJRebel is a –javaagent that integrates with the JVM and rewrites each class to be updateable. JRebel versions each class individually, instead of an entire application or module at a time – and it does not use classloaders. With JRebel, changes to classes are always visible in the Reflection API.

Framework configuration changesJRebel integrates directly with application servers and frameworks to propagate configuration changes from the changed classes and resources, and annotation changes are always visible in Re-flection API.

JRebel also provides an extensible SDK to allow contributions from third parties. Spring MVC, JSF, Struts, GWT, Velocity, Play!, Vaadin and dozens of other integrations have already been contributed.

HOW DOES JREBEL WORK

?To put it briefly, Integration, Integration, Integration!

MyClass MyClass MyClass_3

IDEs

BUILD TOOLS

Application Servers FRAMEWORKS

Workspace mappingJRebel maps a deployed application to the developer’s active workspace, which is how changes can be instantly visible during development. Thanks to this feature, developers can not only avoid the full build, but only recompile the classes that have really changed.

Note: We estimate that JRebel eliminates ~95% of redeploys, so feel free to use a multiplier of 0.95 in your own calculations.

For example:

If a full restart takes 3 minutes and this happens 4 times per hour (this is the average taken from the Java EE Productivity Report), then they spend 12 minutes out of each 60-minute coding hour rede-ploying – or 20% of coding time. If this developer earns USD $40 per hour, then they are getting paid USD $8 for watching their application restart - almost the price of a movie ticket!

In a 25-hour coding week, this would amount to USD $200 of salary forfeited to a redeployment pro-cess that JRebel eradicates. And if this developer works 48 out of 52 weeks per year (holidays, vaca-

tion etc), then this is USD $9600 in losses for just one year. How many developers are on your team?

THE UNAVOIDABLE COSTS OF REDEPLOY TIME

How can I tell if redeployment time is affecting my team?

This is fair to ask at this point. From the boardroom perspective, there is a clear financial cost to re-deploy times in development teams. Want to find out how much restarts are costing your team each week [2]? Try this formula:

Cost = [(r*n)/60]s*25]r = length of a single restart in minutes

n = average number of restarts committed per hours = approximate hourly wage (i.e. in USD or EUR)

Redeployment costs are a regular drain on wage expenses, but can be particularly critical on projects with tight deadlines, especially in contracts that penalize delays to the release.

Other opportunities are missed from from losing 5 or 6 work weeks per developer, per year to redeploy times. For example, new features may not get added to future application versions, bug fixes could escape cor-rection, and there is always the time lost that your team could be billing for new projects.

Developer satisfaction is another cost that is sometimes less considered than the effect on the bottom line and customer service. Think of developers as authors – and just like authors, there are those that write amazing code and those that do not. Developers like writing code, and a coding environment that is highly productive, more iterative and less distracting due to constant interrup-tions will certainly improve code quality and developer work satisfaction. Just ask a developer!

[2] Assuming a 5-hour coding day, a developer should have 25 coding hours per work week

1. What is JRebel exactly, and what kind of effect can I expect it to have on my environment?To review: JRebel is a –javaagent plugin for the JVM. It’s approximately 15 MB in size as a download-able .jar file, and features special plugin versions for the Eclipse IDE, IntelliJ IDEA, NetBeans IDE and MyEclipse IDE. JRebel will cause around 10-15% performance overhead, however during development this is more or less unnoticeable, unlike in the production environment. As a –javaagent, JRebel is de-signed with work with “anything Java”, including multiple JVMs and JVM-based languages like Scala and Groovy, and will fit into your existing technology stack with ease, out-of-the-box ready for your IDEs, application servers and frameworks of choice.

2. How does JRebel compare to HotSwap?The JRebel experience is based on instant feedback and developer focus. From a functional perspec-tive, HotSwap only allows developers to update code on-the-fly during debugging, and is limited to up-dating method bodies only; trying to add methods and fields to classes will not succeed. With JRebel, the project workspace is mapped directly to the application in development, supporting different types of framework configurations, and developers can go considerably further than HotSwap with the abil-ity to add/remove/change method bodies, classes, constructors, annotations, fields, static field values, enum values and interfaces. Below you can see a comparison matrix between JRebel and HotSwap:

Skip builds for WAR directories

Skip builds for .WAR/.EAR class & resource updates

Map multiple source dirs to one .WAR/.EAR target dir

Map classes and resources with include/exclude Ant-style patterns

Use system properties to make mapping machine-independent

Maven plugin

Adding/removing methods

Adding/removing constructors

Adding/removing �elds

Adding/removing classes

Adding/removing annotations

Changing static �eld value

Adding/removing enum values

Changing interfaces

Replacing superclass

Adding/removing implemented interfaces

Time to reload

Leaks memory

Changes to method bodies

< 1s

No

< 1s

No

Changes To Class Structures

JVM HotSwapJRebel

Instant Builds

Java EE support

JSP EL changes

JSP Scriplet changes

JSF changes (Mojarra, ADF)

EJB session bean interface changes

Adding new EJB 3.x components at runtime

Support for EJB 3.x injection

JPA changes (OpenJPA, EclipseLink, TopLink, Hibernate)

CDI support (Weld)

Bean validation annotation changes (Hibernate Validator)

JAX-RS (Jersey, RESTEasy)

JAX-WS (Metro)

JAXB annotation changes

Support for OSS frameworks

Spring Framework 2.x or later

JBoss Seam 2.x or later

Hibernate

Google Guice

AspectJ

Struts 1.x

Struts 2.x or later

Stripes

Tiles 1/2

Wicket

Velocity

FreeMarker

Log4j

IDEs

Containers

Comparison MatrixJRebel uses ZeroTurnaround's award-winning Rebellion Technology to instantly let you see changes to code without having to restart your container.

FAQ ABOUT JREBELsome common queries

Skip builds for WAR directories

Skip builds for .WAR/.EAR class & resource updates

Map multiple source dirs to one .WAR/.EAR target dir

Map classes and resources with include/exclude Ant-style patterns

Use system properties to make mapping machine-independent

Maven plugin

Adding/removing methods

Adding/removing constructors

Adding/removing �elds

Adding/removing classes

Adding/removing annotations

Changing static �eld value

Adding/removing enum values

Changing interfaces

Replacing superclass

Adding/removing implemented interfaces

Time to reload

Leaks memory

Changes to method bodies

< 1s

No

< 1s

No

Changes To Class Structures

JVM HotSwapJRebel

Instant Builds

Java EE support

JSP EL changes

JSP Scriplet changes

JSF changes (Mojarra, ADF)

EJB session bean interface changes

Adding new EJB 3.x components at runtime

Support for EJB 3.x injection

JPA changes (OpenJPA, EclipseLink, TopLink, Hibernate)

CDI support (Weld)

Bean validation annotation changes (Hibernate Validator)

JAX-RS (Jersey, RESTEasy)

JAX-WS (Metro)

JAXB annotation changes

Support for OSS frameworks

Spring Framework 2.x or later

JBoss Seam 2.x or later

Hibernate

Google Guice

AspectJ

Struts 1.x

Struts 2.x or later

Stripes

Tiles 1/2

Wicket

Velocity

FreeMarker

Log4j

IDEs

Containers

Comparison MatrixJRebel uses ZeroTurnaround's award-winning Rebellion Technology to instantly let you see changes to code without having to restart your container.

3. Can’t I just use frameworks like Play! or Grails to get the same effect as JRebel?Sure - these technologies are forward-thinking about classloaders and good to know about. They don’t provide the same experience as JRebel, since after refreshing in Play! or Grails the user must still navigate to their previous place in the application (whereas JRebel maintains application state).

In the end, it requires switching to a new technology, a very disruptive process that many organi-zations and development teams cannot afford to do. It’s a bit like switching from a pick-up truck to a forklift for loading heavy goods. Both a useful for heavy lifting, but can anyone just hop on a forklift and start working with it? JRebel lets you keep your existing technologies in place, whatever they are, bringing equal or greater benefits than frameworks or technologies that appear to offer a similar experience.

4. I’m using OSGi so doesn’t that mean I don’t need JRebel?In the article JRebel vs. OSGi: Use the right tool for the right job, we review the differences be-tween JRebel and OSGi. JRebel natively supports OSGi containers, and there has been a lot of buzz around OSGi as being the poster child for hot updates in development. But to compare them together is confusing; JRebel is simply a JVM plugin that works with your stack, and OSGi is a module system and a dynamic runtime where modules (also called bundles) can come and go, but your code has to conform to the strict requirements of the module system. Again, we see that this comes down to changing how your developers code and which tools they are using to do it.

5. I think my IDE does the same thing as JRebel?This is something often heard at trade shows. If you are using IntelliJ IDEA, Eclipse WTP or Net-Beans, all are able to copy resources automatically and complete automatic redeployment of the application. This is not the same as what JRebel is capable of. In the case Hotswap is used, then this means instant updates to method bodies only, and you must be in debug mode. Again, JRebel lets you add/remove/change methods, classes, constructors, annotations, fields and more. An automatic redeployment is a convenience enabled by your IDE, but it is not instant, nor does it support the various changes and features of JRebel.

Skip builds for WAR directories

Skip builds for .WAR/.EAR class & resource updates

Map multiple source dirs to one .WAR/.EAR target dir

Map classes and resources with include/exclude Ant-style patterns

Use system properties to make mapping machine-independent

Maven plugin

Adding/removing methods

Adding/removing constructors

Adding/removing �elds

Adding/removing classes

Adding/removing annotations

Changing static �eld value

Adding/removing enum values

Changing interfaces

Replacing superclass

Adding/removing implemented interfaces

Time to reload

Leaks memory

Changes to method bodies

< 1s

No

< 1s

No

Changes To Class Structures

JVM HotSwapJRebel

Instant Builds

Java EE support

JSP EL changes

JSP Scriplet changes

JSF changes (Mojarra, ADF)

EJB session bean interface changes

Adding new EJB 3.x components at runtime

Support for EJB 3.x injection

JPA changes (OpenJPA, EclipseLink, TopLink, Hibernate)

CDI support (Weld)

Bean validation annotation changes (Hibernate Validator)

JAX-RS (Jersey, RESTEasy)

JAX-WS (Metro)

JAXB annotation changes

Support for OSS frameworks

Spring Framework 2.x or later

JBoss Seam 2.x or later

Hibernate

Google Guice

AspectJ

Struts 1.x

Struts 2.x or later

Stripes

Tiles 1/2

Wicket

Velocity

FreeMarker

Log4j

IDEs

Containers

Comparison MatrixJRebel uses ZeroTurnaround's award-winning Rebellion Technology to instantly let you see changes to code without having to restart your container.

For the full list of support and features,go to http://zeroturnaround.com/jrebel/features/

Email could have faced an early death if we needed to restart our computers every time you wanted to write, send or receive an electronic message. But Java continues to grow as a programming language and the JVM is more powerful than ever before. And it seems like a new web framework or JVM language is being introduced each week.

Redeployment time is unwelcome to all players in the game – developers lose focus and productivity with constant interruptions, not to mention precious coding time during work hours. The bottom line suffers because developers are collecting wages for watching their application restart instead of writing code or learning new tricks of the trade. Projects that can’t afford to face any delays are definitely not benefiting.

In the end, your development team suffers, your organization suffers, and thus your customers suffer too.

Redeploys are no longer a necessary evil. Terminate them with JRebel and complete projects 17.5% faster, saving an average of 5 work-weeks per year, per developer.

Get started with a free trial license today – set up and installation should take 15 minutes or less!

http://zeroturnaround.com/jrebel/current

FINALWORDSIt’s 2012 – time to eliminate redeployment time from your team’s Java development cycle

support@zeroturnaround.comsales@zeroturnaround.com

Ülikooli 2, Tartu51003 Estonia

+372 653 6099 (Tallinn)

545 Boylston, 4th floorBoston MA 02116

1(857)277-1199