WHAT

DEVELOPERS

WANT:

THE END OF APPLICATION REDEPLOYS

y r o t S e Tru

BRIEF INTRODUCTION
Email. Even 90-year-old grandmothers use it. We use email because its 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.

A HISTORY
way. Java is a powerhouse in the programming world, based on widespread applicabehind the JVM platform, the clarity of syn-

LITTLE

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

bility and use, some excellent engineering 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 isnt possible by default. When Java code is added or changed, the developer must build/compile and then deploy the code in a cycle that allows changes to be visible only after restarting the application server. Every time.

SO WHATS THE PROBLEM WITH

ANYWAY?

APPLICATION RESTARTS
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, weve heard this before!)

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].

Ideally, a developer would make a single change and then quickly verify it is correct before moving on. This would consequently lead to less bugs and service requests later on, but the time drain would be intolerable and weve 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 because to do otherwise is time consuming and highly disruptive to a developers concentration; however, now we see the slow feedback cycle come into play. JRebel is a product designed to provide developers with a rapid feedback cycle, while also
[1] Java Productivity Report 2011

getting rid of the constant interruptions due to application server restarts (keep in mind, even a 30 second restart is enough of an interruption to break concentration for as much as 15 minutes) JRebel provides this unique development experience 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 individual changes to class structures, resources and framework configurations instead of committing 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.

WHERE DO THESE COME

STATISTICS FROM
asked the following two questions:

Approximately 1100 Java developers from all over the world shared their development environment in ZeroTurnarounds Java EE Productivity Report in 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 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 frequency 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.

The normalized data shows that an average of 10.5 minutes per coding hour, per developer, is forfeited to application restarts. Of course, this does not include build/compile time, nor the time is takes to get back into the flow a 5-hour coding day, with the other 3

Time Redeploying in an Hour

5%

5%

8%

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

14%

hours dedicated to planning, meetings,

30%

after the interruption. If we assume

34%
1-5 <1

26-30

1%

21-25

16-20

11-15

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?

6-10

30+

3%

THE

SOLUTION

JRebel eliminates redeploys, saving hours each week of time otherwise forfeited to redeployment.
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.

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.

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,developer fields or constructors, JRebel will immediately reloadIDE the individual change, making a makes a change t o a ny class r esou or r ce in their the change at ely is immedi full application redeploy unnecessary. Below, you can see the typical Java EE development cycle:
J Rebel maps your r p oje ctw or kspa ce di r ectly t o your running applic ation. W hen a

The Java EE Development cycle

PHASE ONE
Add feature, x bug, or improve code using IDE of choice:

PHASE TWO
Changes are compiled and optionally packaged into EARs / WARs. (Incremental builds comsume 60-260 hours annually) 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.

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

PHASE THREE

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

In Phase 1, code changes are added in the developers 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.

HOW DOES
IDEs Application Servers

JREBEL WORK

To put it briefly, Integration, Integration, Integration!

FRAMEWORKS

BUILD TOOLS

Without going too deeply into the technical side of things, JRebel works based on three specific areas of Java and the JVM: 1. Java Classes 2. Framework configuration changes 3. Workspace mapping

Java Classes
JRebel 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.

MyClass

MyClass

MyClass_3

Framework configuration changes

JRebel integrates directly with application servers and frameworks to propagate configuration changes from the changed classes and resources, and annotation changes are always visible in Reflection 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.

Workspace mapping
JRebel maps a deployed application to the developers 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.

THE UNAVOIDABLE OF REDEPLOY TIME

COSTS
week [2]? Try this formula:

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 redeploy times in development teams. Want to find out how much restarts are costing your team each

Cost = [(r*n)/60]s*25] r = length of a single restart in minutes n = average number of restarts committed per hour s = approximate hourly wage (i.e. in USD or EUR)
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 redeploying 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 process that JRebel eradicates. And if this developer works 48 out of 52 weeks per year (holidays, vacation etc), then this is USD $9600 in losses for just one year. How many developers are on your team? 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 correction, 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 interruptions 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

FAQ ABOUT

JREBEL
some common queries

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. Its approximately 15 MB in size as a downloadable .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 designed 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 perspective, HotSwap only allows developers to update code on-the-fly during debugging, and is limited to updating 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 ability 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:

Comparison Matrix JRebel uses ZeroTurnaround's award-winning Rebellion Technology to Comparison Matrix instantly let you see changes to code without having to restart your container.
JRebel
No < 1s No Time to reload Leaks Time memory to reload Changes to method bodies Leaks memory < 1s JRebel No < 1s No

JRebel uses ZeroTurnaround's award-winning Rebellion Technology to instantly let you see changes to code without having to restart your container. JVM HotSwap
< 1s JVM HotSwap

Containers Containers

Changes Class Structures Changes toTo method bodies

Adding/removing methods Changes To Class Structures Adding/removing Adding/removingconstructors methods Adding/removing elds Adding/removing constructors Adding/removing Adding/removingclasses elds Adding/removing Adding/removingannotations classes

Changing static eld value Adding/removing annotations Adding/removing enum values Changing static eld value

Changing interfaces Adding/removing enum values Replacing Changingsuperclass interfaces

Adding/removing implemented Replacing superclass interfaces Adding/removing implemented interfaces

Instant Builds
Skip builds for WAR directories Instant Builds Skip class & Skipbuilds buildsfor for.WAR/.EAR WAR directories resource updates Skip builds for .WAR/.EAR class & Map multiple source dirs to one resource updates .WAR/.EAR target dir Map multiple source dirs to one Map classestarget and resources with .WAR/.EAR dir include/exclude Ant-style patterns Map classes and resources with Use system properties to make include/exclude Ant-style patterns mapping machine-independent Use system properties to make Maven plugin mapping machine-independent Maven plugin

Java EE support Java EE support JSP EL changes

Support for OSS frameworks Support for OSS Spring Framework 2.xframeworks or later
IDEs

Map classes and resources with include/exclude Ant-style patterns Use system properties to make mapping machine-independent Maven plugin

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

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

3. Cant 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 dont 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 organizations and development teams cannot afford to do. Its 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. Im using OSGi so doesnt that mean I dont need JRebel? In the article JRebel vs. OSGi: Use the right tool for the right job, we review the differences between 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 NetBeans, 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.

FINAL

WORDS
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 cant afford to face any delays are definitely not benefiting.

Its 2012 time to eliminate redeployment time from your teams Java development cycle

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

support@zeroturnaround.com sales@zeroturnaround.com likooli 2, Tartu 51003 Estonia +372 653 6099 (Tallinn) 545 Boylston, 4th floor Boston MA 02116 1(857)277-1199