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 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. 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!, Vaadin 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.