WHAT DEVELOPERS WANT: THE END OF APPLICATION REDEPLOYS

True Story BRIEF INTRODUC- TION

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 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. LITTLE HISTORYA 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? 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!)

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 getting rid of the constant interruptions due to change and then quickly verify it is correct be- application server restarts (keep in mind, even fore moving on. This would consequently lead a 30 second restart is enough of an interrup- to less bugs and service requests later on, but tion to break concentration for as much as 15 the time drain would be intolerable – and we’ve minutes) seen the horrified faces of developers who JRebel provides this unique development expe- report having to spend 25-50% of each coding rience through eliminating the need to restart hour redeploying their application. Java applications in order to see code changes. To avoid that, developers line up a lot of new The ripple effect of eliminating interruptions code changes to launch in a single batch be- of this kind is well-proven since 2008; using cause to do otherwise is time consuming and JRebel developers can instantly reload indi- highly disruptive to a developers’ concentra- vidual changes to class structures, resources tion; however, now we see the slow feedback and framework configurations instead of com- cycle come into play. mitting a full application restart. This saves an average of 10.5 minutes per coding hour, which JRebel is a product designed to provide devel- comes out to over 5 work weeks each year. opers with a rapid feedback cycle, while also

[1] Java Productivity Report 2011 WHERE DO THESE COME STATISTICS FROM Approximately 1100 Java developers from all over the world? shared their development environment in ZeroTurnaround’s 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 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.

The normalized data shows that an Time Redeploying in an Hour 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 34%

a 5-hour coding day, with the other 3 30% hours dedicated to planning, meetings,

breaks, etc, then losses are: 14% 8% 5% • 52.5 minutes each day 5% 3%

• Over 4.3 hours per week 1% • Almost 18 hours per month < 1 1-5

• More than five, 40-hour work 30+ 6-10 11-15 16-20 21-25 weeks each year 26-30

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?” SOLUTION JRebel eliminates redeploys, saving hours each week of time

THE otherwise forfeited to redeployment.

The first version of JRebel was created Since then, over 3000 companies have in a secret Estonian basement cubicle purchased JRebel, and at the time of under an even more secret codename this white paper the current version is in 2006 by Jevgeni Kabanov. It was JRebel 4.6. JRebel now supports every designed to be an internal tool to cut major application server available down on redeploy times in a software on the market, six different IDEs and company, which was suffering from nearly 50 web and server-side Java 10+ minute redeploy times. frameworks.

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, JR ebel mapsyour rpojectwo rkspace directlyto your running application. W hen a annotations,de fieldsveloper or constructors,makes a changeto JRebel any class will rimmediately esouor rce in their reload IDE the theindividual change atchange, elyis immedi making a full application redeploy unnecessary. Below, you can see the typical Java EE development cycle:

The Java EE Development cycle

PHASE ONE Add feature, Þx bug, or improve PHASE TWO code using IDE of choice: 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 PHASE THREE The application is redeployed to the and choose to improve the container. This phase consumes on change or move on to something average, 17% of development time new. Either way, go to Phase One. (210 hours - over 5 weeks annually).

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. HOW DOES ? JREBEL WORK To put it briefly, Integration, Integration, Integration!

IDEs Application Servers 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 Re- flection API.

JRebel also provides an extensible SDK to allow contributions from third parties. Spring MVC, JSF, Struts, GWT, Velocity, Play!, and dozens of other integrations have already been contributed. Workspace mapping JRebel 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. THE UNAVOIDABLE OF REDEPLOY TIME COSTS 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 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 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?

Redeployment costs are a regular Other opportunities are missed from from losing drain on wage expenses, but can 5 or 6 work weeks per developer, per year to redeploy be particularly critical on projects times. For example, new features may not get added to with tight deadlines, especially in future application versions, bug fixes could escape cor- contracts that penalize delays to the rection, and there is always the time lost that your team release. 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 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. It’s approximately 15 MB in size as a download- able .jar file, and features special plugin versions for the 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: Comparison Matrix JRebelComparison uses ZeroTurnaround's Matrix award-winning Rebellion Technology to instantly let you see changes to code without having to restart your container. JRebel uses ZeroTurnaround's award-winning Rebellion Technology to instantly let you see changes to code withoutJRebel having to restartJVM your HotSwap container. Containers Time to reload JRebel< 1s JVM HotSwap< 1s Containers LeaksTime memoryto reload No< 1s No< 1s ChangesLeaks memory to method bodies No No ChangesChanges to To method Class bodies Structures Adding/removingChanges To Class methods Structures Adding/removingAdding/removing constructors methods Adding/removingAdding/removing elds constructors Adding/removingAdding/removing classes elds Adding/removingAdding/removing annotations classes ChangingAdding/removing static eld annotations value Adding/removingChanging static eld enum value values ChangingAdding/removing interfaces enum values ReplacingChanging superclass interfaces Adding/removingReplacing superclass implemented interfaces Adding/removing implemented interfaces Instant Builds SkipInstant builds Builds for WAR directories SkipSkip builds builds for for .WAR/.EAR WAR directories class & resource updates Skip builds for .WAR/.EAR class & Mapresource multiple updates source dirs to one .WAR/.EAR target dir Map multiple source dirs to one Map.WAR/.EAR classes targetand resources dir with include/exclude Ant-style patterns Map classes and resources with Useinclude/exclude system properties Ant-style to make patterns mapping machine-independent Use system properties to make Mavenmapping plugin machine-independent Maven plugin

Java EE support Support for OSS frameworks

JSPJava EL changesEE support SpringSupport Framework for OSS 2.x frameworks or later IDEs JBoss Seam 2.x or later JSPJSP Scriplet EL changes changes 2.x or later IDEs JSFJSP changes Scriplet (Mojarra,changes ADF) JBoss Seam 2.x or later Google Guice EJBJSF session changes bean (Mojarra, interface ADF) changes Hibernate AspectJ AddingEJB session new beanEJB 3.x interface components changes at runtime Google Guice Struts 1.x SupportAdding fornew EJB EJB 3.x 3.x injection components at runtime AspectJ Struts 2.x or later JPASupport changes for (OpenJPA,EJB 3.x injection EclipseLink, TopLink, Struts 1.x Hibernate) JPA changes (OpenJPA, EclipseLink, TopLink, Struts 2.x or later CDI support (Weld) Hibernate) TilesStripes 1/2 BeanCDI supportvalidation (Weld) annotation changes Wicket (Hibernate Validator) Tiles 1/2 Bean validation annotation changes VelocityWicket JAX-RS(Hibernate (Jersey, Validator) RESTEasy) FreeMarkerVelocity JAX-WSJAX-RS (Metro)(Jersey, RESTEasy) Log4jFreeMarker JAXBJAX-WS annotation (Metro) changes Log4j JAXB annotation changes Comparison Matrix JRebel uses ZeroTurnaround's award-winning Rebellion Technology to instantly let you see changes to code without having to restart your container.

JRebel JVM HotSwap Containers Time to reload < 1s < 1s Leaks memory No No Changes to method bodies Changes To Class Structures 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

Instant Builds 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

Java EE support Support for OSS frameworks

JSP EL changes Spring Framework 2.x or later IDEs JSP Scriplet changes JBoss Seam 2.x or later JSF changes (Mojarra, ADF) Hibernate EJB session bean interface changes Google Guice Adding new EJB 3.x components at runtime AspectJ Support for EJB 3.x injection Struts 1.x JPA changes (OpenJPA, EclipseLink, TopLink, Struts 2.x or later Hibernate) Stripes CDI support (Weld) Tiles 1/2 Bean validation annotation changes Wicket (Hibernate Validator) Velocity JAX-RS (Jersey, RESTEasy) FreeMarker JAX-WS (Metro) Log4j JAXB annotation changes

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

3. Can’t I just use frameworks like Play! or 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. FINAL WORDS It’s 2012 – time to eliminate redeployment time from your team’s Java development cycle

Email could have faced an early death if In the end, your development team suffers, we needed to restart our computers every your organization suffers, and thus your time you wanted to write, send or receive customers suffer too. an electronic message. But Java continues to grow as a programming language and the Redeploys are no longer a necessary evil. JVM is more powerful than ever before. And Terminate them with JRebel and complete it seems like a new or JVM projects 17.5% faster, saving an average of 5 language is being introduced each week. work-weeks per year, per developer.

Redeployment time is unwelcome to all Get started with a free trial license today – players in the game – developers lose set up and installation should take 15 minutes focus and productivity with constant or less! interruptions, not to mention precious http://zeroturnaround.com/jrebel/current 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.

[email protected] [email protected]

Ülikooli 2, Tartu 51003 Estonia +372 653 6099 (Tallinn)

545 Boylston, 4th floor Boston MA 02116 1(857)277-1199