Eliminating the Need for Constant Redeploying In Development

About the Vaadin Ltd JRebel Case Study

Vaadin Ltd is the company behind the popular Vaadin Framework, an open source software development tool for building high-quality web user interfaces for business software.

At Vaadin, JRebel is used during the development as well as the services work to create applications and solutions which use Vaadin. It eliminates the need for constant redeploying, providing an instant feedback loop between developing code and testing code.

Company Score Card

• Size of development team: 60
• Technologies in use: Jetty, Tomcat, GlassFish, JBoss, WebLogic, 
  WebSphere, Java EE, Spring, Vaadin… and many more
• Types of apps being built: various UI and system apps for customer projects
• App redeploy time before JRebel: 20s - 1m depending on environment
• Number of redeploys per hour: 2 (because they took time)
• Number of instant reloads with JRebel per hour: 60
• Time saved per day using JRebel: at least 10%

Company Profile

Vaadin Ltd is the company behind the popular Vaadin Framework, an 
open source software development tool for building high-quality web user 
interfaces for business software. Since 2000, the technology was originally 
developed based on the programming challenges in a large-scale health 
care system. Java was chosen to be the platform and the project was 
open sourced later in 2002. Today, Vaadin is used daily by thousands of 
professional software developers in more than 170 countries. While the 
free technology is used all around the world, the company is headquartered 
in Turku, Finland. Most of Vaadin’s 60+ developers work here, but the 
company also has offices in California and Frankfurt.

OUR VAADIN EXPERT 

Vaadin have both a services and a consulting team as well as an R&D/
Engineering team which make use of JRebel internally. We caught up with 
Petri Heinonen, a Vaadin Expert, program manager and team lead who 
has been with Vaadin for over 4 years. Petri works in services on customer 
projects, building UI and backend systems for customer projects, as well as 
consulting and training. He has used JRebel for over 2 years now. Projects 
he works on can range from anything between a week and a couple of 
years. As a result, Petri has used JRebel across a wide range of application 
servers, including Jetty, Tomcat (these two are his preference due to size 
and speed), JBoss, GlassFish and WebLogic.

DEVELOPMENT ENVIRONMENT 

Petri’s development environment itself also varies. The IDE he uses is Eclipse 
most of the time, but sometimes the project calls for IntelliJ IDEA. His build 
environment is usually Maven and Ant-oriented, and less frequently, Gradle. 
So he uses the JRebel support from the Ant and Maven plugins, so the 
configuration is all handled automatically on the build side.
 

Time Saved and Benefits Gained

The redeploy time for Petri varies on the environment and application which he is working on at the time, 
but all environments he has worked on give some kind of productivity hit as redeploys don’t go away easily.

I hate them so much, I actually try to architect my development 
environment to try to avoid them, particularly if the project uses 
Liferay. When I’m not using JRebel I redeploy and test my code 
once every 30 minutes or so, but when I use JRebel, I test every 
minute as my code is reloaded instantly.

This instant feedback lowers the number of bugs in your 
code because you test your features instantly, if you can't test 
instantly you sometimes forget to test some of the things 
you’ve effectively ‘coded blindly’.

Another area which Vaadin really gain value out of JRebel is in the 
persistence of state across a class reload. This maintains the point in time 
which the user is at throughout the reload of the underlying class.

State is very important during our 
testing. To get to a certain place in an 
application using a more complex UI 
design, you often have to follow a trail 
to get into a specific state - sometimes 
you can get to it easily, in just a few 
clicks, other times it’s very hard - JRebel 
you can just refresh and maintain state 
- this is one of the primary reasons as 
to why I use JRebel.

Time can be saved in many ways using JRebel, whether it’s the easilymeasurable waiting time for a application to redeploy, or the harder to 
measure early capture of bugs due to the instant testing cycles, or the 
maintained focus during a class reload

The time saving for me is significant. 
I’d say around 10% of my time in 
a day, sometimes more, is saved 
because of JRebel, depending on 
the project.

Before Vaadin introduced the Sass (Syntactically Awesome Stylesheets) 
compiler JRebel also updated the CSS updates in an application, meaning 
theme changes in an application were seen instantly when they were 
updated in your IDE.