Stop wasting time on redeploys

A common question we get after our webinars or other live coding exercises is, how we make our live coding look so fluent. Why don’t you need to redeploy your war file to show the changes?

It is no stunt or a specially crafted marketing JVM – we're doing the real stuff. The “secret” is JRebel. JRebel is a commonly used tool among Java developer to speed up the development process by greatly improving the standard code “hot swap” features provided default by IDEs. 

Our friends at ZeroTurnaround just published a new 6.2 version, with features helping many Vaadin developers, so it is a perfect time to remind you how to become a more productive Java/Vaadin developer: Grab a free trial license and Install JRebel into your favorite IDE. That's it!

Improved GWT Support in JRebel

Many Vaadin users are at least some point involved with client side development with GWT. Typically when you are working with a fine-tuned custom component, you’ll build a custom client side counterpart for your server side API. With JRebel 6.2 you can skip redeploys in your client side code as well. JRebel supports both the traditional development mode and the newer “super-dev-mode” (that uses no browser plugins).

Many Vaadin add-ons depend on some third party JS libraries. In these cases it can be that the major part of your add-on code is about GWT-JS integration, typically written using JSNI. You can now add, remove and change JSNI methods with the same fluency that existing JRebel users have taken as granted with server side Vaadin code.

If you are writing pure client side applications or offline modes for Vaadin TouchKit apps, there are lots of other GWT related enhancements like support for GWT-RPC and AutoBeans. JRebel 6.2 also supports dynamic changes to CssResource interfaces (not just to the css file), that will dramatically speed up theme building for your TouchKit app.

What else is new in 6.2?

JRebel 6.2 not only includes the GWT and Vaadin improvements from above, but also includes better support for all of the flavors of TomEE.

Check out JRebel with Vaadin

Create UIs from data models using EMF

Are you sick of coding your UIs manually? Model them instead from a domain model to an application. One approach is model-driven development of user interfaces. With the Eclipse Modeling Framework (EMF) and EMF Forms, you can generate a domain model and a form based UI without manual coding. In this blogpost I'll give you a quick introduction on what the idea is.

Introduction to EMF

EMF is a pragmatic framework for modeling entity classes and generate code based on them. It all revolves around a Code generator for Java classes and it’s a standard framework for many model-related technologies.

The EMF Workflow looks as follows:

The main benefits of using EMF are:


  • No hand-written code
  • Model objects follow a common scheme
  • Model objects provide common functionality and API
  • Model can be validated before the code generation


Another advantage of Model Driven Development (MDD) is better code quality.

EMF provides Bi-Directional References and containment constraints. Additionally there are some validation constraints like Required Attributes, Lower Bound / Upper Bound and Custom validation rule. Furthermore, EMF provides a standardized API for Notifications for binding UI Elements, Reflection, to copy Elements, Serialization, to transfer Elements to a server and UI Support and to create Tree Views.

A small EMF Tutorial is available at the Eclipsesource blog.

Introduction to EMF Client Platform (ECP)

ECP is a framework for supporting the development of applications based on EMF entity instances. The UIs are described in a separate model (view model) and are not developed in source code. The view model contains all layout and controls, like fields, vertical layout, group etc. This view model is independent of a concrete UI Toolkit so you could use Eclipse RCP/RAP or even JavaFX. In this blogpost I will show you how to use Vaadin for the UI.

The benefits of ECP are the following:
  • Extensibility and Adaptability, you can create custom controls
  • UI Model is independent of renderer technology
  • less handwritten code
  • JFace Databinding for Vaadin
  • Modularity with OSGi

In the next steps, we want to create a UI for the user entity.

The view model describes a view with 2 columns.

The Vaadin view looks like this:

The Code for this UI is just:
ECPVaadinView ecpVaadinView = ECPVaadinViewRenderer.INSTANCE.render(USER); 

Every element can be customized such as for instance the email element. We want to send an E-Mail after submit.

There are no surprises or magic. The Code is:

final Component textComponent = super.createControl(); 
textComponent.setWidth(100f, Unit.PERCENTAGE); 
final Button button = new Button("Send Mail"); 
final HorizontalLayout horizontalLayout = new HorizontalLayout(textComponent, button);

For more information, there is a tutorial available at the EMF blog. The tutorial contains the described example to test and play around with.

Conclusion and resources

The conclusion is you can create a UI much easier and faster, when you describe it.
You reduce errors because reoccurring problems like data binding are no longer done manually. I've collected some pointers on when you should and shouldn't consider using modeling below.

When to use UI Modeling:

  • Large Domain Model with a huge amount of input fields
  • Form based Views
  • Frequent Domain Model changes
  • Homogenous UI
  • UI Technology Independence
  • Improved Customer Involvement
  • Fast Turnaround + Rapid Prototyping


When not to use UI Modeling:

  • pixel perfect UI
  • Many Actions and Buttons in the UI


Please also note that this isn't a full Application. For a full application you need more around the generated views such as implement navigation, persistence and so on. The first company that created an application with the Vaadin renderer is Compart AG.
The Vaadin Renderer is open source and available in Github.

Currently the renderer's registration is done within Equinox (OSGi) to build dynamic web apps. The approach can be adapted to a non-OSGi environment by manually doing this registration with a Map. For comments and questions please leave a comment below.

Vaadin Dev Day is here (in Frankfurt)!

Lots of people have been asking for a dedicated Vaadin Dev Day with hands-on trainings on how to use Vaadin with MVP, Java EE, Spring as well as how to use the theme engine Valo, how to test Vaadin apps, how to extend Vaadin, how to create declarative UIs with the Designer and how to optimize Vaadin apps.

Vaadin Dev Day is the first time we’re going to answer those questions live and personal with you. Dev Day as a concept is a very personal event with limited attendance. It’s a one-day event full of down to earth workshops and lectures. You’ll get answers to your questions, whether you’re new to Vaadin or further down the road. If you're attending one Vaadin event this year, you'll definitely get the most "bang for the buck" at Vaadin Dev Day.

Vaadin Dev Day will be arranged on September 22nd in Frankfurt, Germany. Vaadin’s very own Artur Signell (CTO) and Peter Lehto (Vaadin Expert and trainer) are going to be your hosts throughout the day and ensure you’ll learn all you need to create your full stack app with a sound architecture. We have reserved some 100 seats so it’s all on a first come, first served basis. The price for attending is 750€ but when signing up with the campaign code BLOG before May 31st you get a 15% discount (Click on "Click here to enter a promotion code").

Check out the whole agenda and content at

Sign up for Vaadin Dev Day