JRebel Busts 5 Java Code Development Myths
We’ve said it before, and we’ll say it again: redeploys are the hidden productivity killer in Java code development. Studies consistently show that the process of going from a code change to seeing that change averages around more than eight minutes – and this is repeated several times an hour. This adds up to about 20% of a developer’s time that is spent waiting. This fact has spawned a myth: waiting around for redeploys is just an unavoidable part of every Java developer’s daily life. Redeploys may be a major drain on productivity, but it’s a myth that nothing can be done about them.
JRebel Accelerates Code Development
JRebel fast tracks Java application development by skipping the time-consuming build and redeploy steps. JRebel helps developers be more productive since they can view code changes in real time and maintain application state. Unfortunately, there are now several myths surrounding JRebel. And in our latest eBook, we bust five of them with glee by walking you through five popular use cases for Java developers and demonstrating how JRebel can work in those environments to transform your development process for huge productivity gains and cleaner, better code. Download the eBook, MythBusters: Five scenarios where JRebel helps developers create more, higher-quality Java code, to witness these five myths get thoroughly busted:
- Spring Boot is “fast enough” without JRebel
- Your IBM WebSphere and Oracle WebLogic applications are too mature for JRebel
- JRebel doesn’t integrate with SAP Hybris
- JRebel doesn’t work in complex environments and custom architectures
- Remote development on virtual machines or cloud environments is too much for JRebel to handle
Sneak Peak: Two Java Code Development Myths Busted
Want a sneak peak at the eBook? Here's a preview of some of the content we have featured in the eBook.
To get the full eBook, including sections on SAP Hybris, complex environments and custom architectures,and remote development on VMs and cloud environments, click the link above.
Spring Boot Redeploys Add Up
One of the biggest misconceptions about Spring Boot is that the application restart time there is “fast enough” such that there are no benefits from using JRebel. This might be true for a fresh Spring Boot app, which might take only 10 seconds to restart.
However, as soon as you start adding more classes, endpoints, logic, databases, etc., the restart time steadily increases as well. For many developers, that restart time grows beyond their acceptable painthreshold at which they would benefit from a class-reloading technology such as JRebel.
We ask our JRebel users to report the restart/ redeploy time for their app without JRebel, which we use for ROI calculations. For Spring Boot users, the average app restart time is 151 seconds, or 2.5 minutes. That’s far longer than the 10 second redeploy time of a fresh/empty Spring Boot app. Clearly, there is room for improvement — which JRebel can help provide.
JRebel for IBM WebSphere and Oracle WebLogic
It’s no secret: the bigger the application, the longer it takes to redeploy. And established enterprise applications, the kind using WebSphere or WebLogic as application servers, can be huge. That can sap the productivity of your developer team.
According to JRebel users working with WebSphere apps, it takes an average of 6.6 minutes for an app restart. For the average WebLogic user, it’s 7.5 minutes. With a reported average of 3.1 redeployments and tests per hour, the average WebLogic user spends 23 minutes per hour, or 38% of their 8-hour workday, on redeployment (it’s only 25% of the workday for WebSphere users). With a 5 team of just 10 developers, your annual cost from redeploys could easily run between $200,000 and $400,000 in lost productivity.
Clearly, there’s a huge cost in time and money from redeployments. However, many developers have been using WebSphere or WebLogic for so long without JRebel that they’ve gotten used to the enforced delays, the mid-afternoon-redeployment-coffeeruns, the dubious hacks such as running a lighter-weight alternative application server during development that creates hard-to-track-down bugs when they try to move the code into production.
Gain an Edge Over the Competition
We hope this eBook shows you how JRebel speeds up Java development across diverse environments. Read the evidence about why it works and take the next steps to seize finer control of your development velocity, so you can bring products to market faster and gain a vital edge over the competition.
Want to see how JRebel can save you hours (maybe even days) of development time?
Try free with a 14-day trial.