Enterprise Development with GWT, JEE and Errai


This post is meant to document our experience developing a demanding UI for a large enterprise application using GWT and Errai as our client technologies.

We began looking at GWT over 4 years ago. Immediately we were attracted by its promise to harmonize server and client development into a single environment (Java).  It is interesting to me how controversial this approach has proven to be. We have been big believers in what GWT represents, and depending on the type of project you are embarking on, I would definitely recommend its use.

Part of the debate around using GWT vs straight-up JavaScript comes from a simplification of what it means to create a “web application”. JavaScript began as a way of dynamically enhancing functionality on a webpage and has progressed to support the most creative and ambitious endeavours. There used to be a clear delineation between what could be done in a browser and what could be done in a native app. I can remember being in attendance at the first Google I/O conference and seeing the in-person reaction to the unveiling of Google Wave. While the product never took off, the room full of technical people marvelled at what Google had made possible in a browser. Google in particular should receive a lot of credit for pushing browser technology, both in terms of performance and developer tools.

Consumer vs. Enterprise

There is a world of difference between building a consumer-facing application and an enterprise application. As a general rule, consumer applications (in today’s world) have relatively narrow user experiences, often comprising less than 10 screens (think Twitter, Pintrest, Instagram and even Facebook) with often millions of low-value users.  Countless hours are spent refining the user experience, but from a technical level, the UI is pretty contained. The real challenges lie in the backend infrastructure and scale.  

Enterprise applications are a completely different animal. Users are often charged significant amounts of money to use the application (upwards of $100/month), and the number of  interaction screens will often run into the hundreds. Our new application has over 500 screens, and this number will continue to grow. It was our intention to develop an enterprise application that would “blow people away” when they first saw it. The user experience was critical, and providing a top notch, consistent interface across so many screens became a top priority and challenge.

Key to Success – Functionality

We set out a number of very ambitious goals for our user environment.  Coming from a client-server application, we wanted our first “web version” to take all of the positive things from that environment, and combine it with all of the strengths of a web environment.  This meant building our own desktop environment, including a window manager, universal keystroke management and a series of widgets to manage the consistent presentation of information.  GWT enabled us to develop a very complex desktop library, and do so easily.  Because we were able to write it in Java, we got all the benefits of the Java Environment:  IDE auto-completion, refactoring, and type safety.  This meant that even with a minimal amount of external documentation and testing, we were able to get a desktop library usable and stable quite quickly.  Versions could also be maintained and controlled via Maven.

Key to Success – Simplicity

Architecting enterprise applications is a significant challenge.  Once the balls start getting thrown up in the air, it can get overwhelming pretty quickly.  I saw a Forrester researcher give a talk a few years back mentioning how in the late 1990’s, the web really threw the development world back about 15 years.  As people started pushing more and more functionality into the browser, the gap in maturity between server-side tools and front-end tools became increasingly apparent.  In the past 5 years, this gap has started to close dramatically with the advent of technologies like AngularJS and Node.js.  However,  I have yet to see (or experience) anything for javascript that comes close to writing server-side code in a mature IDE (Eclipse, IntelliJ, etc).

As a result, two very different skill sets have emerged.  Backend development, whose focus is using a more traditional toolset, and front end developers who develop an expertise in HTML/CSS/Javascript.  While companies have often divided themselves loosely between frontend and backend, never before had the technologies that were employed been so different.  

GWT promised to minimize, if not completely erase this problem.  This is no small gain, both for growing teams trying to accomplish big things and large teams hoping to maintain what they’ve built.  By unifying the environment around one technology (Java), it meant that a huge amount of the client-specific challenges could be eliminated, or at least isolated from the majority of development.

Key to Success – Efficiency

This is the one where GWT skeptics will probably get their backs up.  One of the complaints I see most often is that GWT is not efficient – you have to write too much code, and it takes too long.  One of the challenges that GWT has had I believe is of (marketing) messaging and communication as to what it is and how it is best used.  I believe GWT (and Errai) suffer from the reverse problems of many frameworks.  Many frameworks excel in the Hello World examples, but as things get more complicated, they start to fall apart.  With GWT (and Errai) there is a pretty steep learning curve to really start to architect applications.  However, as you begin to get your feet wet and the application grows in complexity, this is where the technologies really begin to shine.

I believe many people come across GWT and spend a few hours playing with it and get frustrated by the time it takes to get going (unlike say JavaScript framework XYZ).  As a general rule of thumb, I would say that if you are developing smaller applications < 20 screens, or less than one or two months of work at a time, GWT will probably provide less benefit to you (although at this point, I would use it for almost anything, big or small).   

One of GWT’s secret sauces is Deferred Binding, and generators (http://www.gwtproject.org/doc/latest/DevGuideCodingBasicsDeferred.html).  This feature allows you to generate code, and once mastered, is an incredible asset to reducing boilerplate and building a solid, consistent framework.  In fact, it is the foundation of most features of GWT (UiBinder/Editor), and also libraries such as Errai. However, it is only after using and understanding GWT that this feature can really be exploited.

Problems with GWT

GWT has had its marketing/product challenges along the way.  As a child of Google, its strength and focus has really been the Java-to-JavaScript compiler.  One of the biggest complaints has been its lack of a robust (and attractive) widget set.  In general, I have always felt that much of the project, from widgets to the website itself have been under-resourced.  Features that were introduced, such as GWT-RPC, UiBinder, RequestFactory seemed to fall short of their promise, and at times felt awkward (or in the case of RequestFactory, uncomfortable) to use.

Google was developing the functionality and releasing versions, but was ultimately working to support internal projects.  It was as if it didn’t really care about external adoption (this is perhaps unfair, but it represents an impression more than reality.  For a comparison, take a look at the Dart Language website/IDE).  The community was left to its own to develop frameworks, best practices, and much of the higher functionality required to make it a more easily adoptable framework.  I always wonder what would have been if Google had invested a little more in GWT as a (free) product, as opposed to an opensource project.


When I stumbled upon Errai, I was re-introduced to JEE.  We had previously explored a variety of backend frameworks, including Spring and most recently Guice.  I was instantly amazed and attracted to the simplicity and elegance of JEE – in particular the CDI API.  Once I had my JBoss AS 7 environment set up, I was incredibly pleased with how neatly everything just seemed to “work” – REST, Persistence/Transactions, CDI, and how little configuration was required.  It almost didn’t seem possible.  


If I was first attracted to GWT because of its promise of “Java in the browser”, I was attracted to Errai because of its appearance as the natural progression of that promise.  Errai basically treats GWT as a Java-to-JavaScript compiler and builds its own modular functionality layer on top, often replacing stock GWT modules.  Without exception, the Errai modules exceed the GWT modules in terms of functionality, ease of use, and downright elegance.  As I went through the documentation for the first time, I remember saying to myself “that is how GWT should have done it in the first place!” on more than one occasion.  Since we started heavy development in the Spring of 2012, the Errai project has grown a lot in terms of functionality.  With its roots at JBoss and their commitment to JEE, a driving principle is to extend the JEE API’s to GWT, and this is done with Messaging (REST), Dependency Injection/Events (CDI) and Persistence (JPA).  Now, not only are we as developers able to reuse our tools and techniques from Java, but our client-side JavaScript can actually share many of the same API’s as are used on the server.  We were already fairly sold on the simplicity and elegance of the JEE API’s (words I never thought I would/could say 5 or 10 years ago), and now, the idea of being able to use them seamlessly on both client and server was very attractive.

Errai Message Bus

If GWT is at its essence a Java-to-JavaScript compiler, for me, Errai’s star feature (or co-star, along with CDI) is its message bus.  Errai does away with the entire GWT-RPC/serialization mechanism, and implements its own.  The MessageBus itself is a low-level way of two way communication (client-to-server, server-to-client).  There are other third party libraries that allow for server-side push to the client, but Errai’s is integrated with what it calls ErraiRPC, and CDI events.  

Errai RPC is a much more elegant service oriented communication protocol.  In stock GWT, three classes are needed to implement a service (two interfaces, almost the same, but one asynchronous, along with a server Implementation).  The server implementation is a servlet, so typically some more work is needed.  In Errai, a service is created with an interface and implementation.  No special asynchronous interface is required.  Using the magic of Deferred Binding and Errai CDI, an Errai service caller is injected on the client and is able to make the asynchronous call using the synchronous service.  On the server side, the service need only be annotated with an Errai @Service annotation.  Errai then handles all of the routing.  This made setting up new services completely painless and easy.  On top of that, using the same interface and calling mechanism, Errai can talk directly to existing REST endpoints.  


Errai Marshalling

GWT-RPC requires all marshallable classes (classes that can be translated into JavaScript) to implement the Serializable interface.  This always felt awkward to me, as being serializable did not ensure that something was really meant (or destined) to go over the wire.  Also, there may be classes that are potentially/required to be GWT-serializable, but do not themselves implement Serializable.  Errai opts for a @Portable annotation that is used to mark that a class is serializable.  Alternatively, you can create a whitelist of Portable annotations if you are using classes from an existing JAR from which you have no/little control.  Nice touch.


Errai CDI Events

When looking back into JEE, I really was taken by the simplicity and effectiveness of CDI Events (if you are unfamiliar with CDI events, you can learn about them here: http://docs.oracle.com/javaee/6/tutorial/doc/gkhic.html.  It takes about 2 minutes, that’s how easy they are to understand and use).  When I saw what I could do with Errai+CDI, I was truly blown away.  CDI Events represent a way of broadcasting server-side events to a number of listening clients (and vice-versa – client’s can broadcast events back to a listening server).  This is a feature that has become crucial to our desktop environment.  One of the features of our interface, is that screens are loaded and kept in memory in the browser.  This raises the issue of stale data.  With a single annotation, we are able to set up listeners for events in the browser.  


Errai Dependency Injection

Previously, we had architected our application using Google Guice on the backend and Gin (a Guice GWT port) in the browser.  At first we were quite happy with Guice, and found that it was not easy to get a direct replica of the server-side functionality.  Furthermore, the level of configuration that was required made it overall more complicated to use.  JEE CDI, on the other hand, felt somewhat limited coming from the Spring/Guice environments.  However, it did not take long to accept its limitations, and I can honestly say we have had no issues with functionality using server-side CDI, and have grown to appreciate the lack of configuration that is required to make it hum.


Errai UI

Errai UI is Errai’s replacement for GWT’s own UiBinder.  It is a very clever take, and in keeping with the framework, relies heavily on tried and true standards.  Unlike UiBinder, which uses an XML template with its own namespaces to define layouts, ErraiUI uses strict HTML.  This makes working with designers much (much!) easier, as they can define screens, update screens, etc, that can just be ‘dropped’ into your java project.

Another nice advantage is that one HTML file can actually support multiple java classes (each java component can reference which dom Id represents the the root of the component).  This means the designer can have a single HTML page that contains multiple widgets, screens – another big win.

Finally, another thing that is nice about ErraiUI is that is builds on Errai’s dependency injection.

Using GWT’s UiBinder, you typically need to declare an interface, and then use deferred binding to create it:


public class PurchaseOrderEditor extends Composite {
private static PurchaseOrderEditorUiBinder uiBinder = GWT.create(PurchaseOrderEditorUiBinder.class);
interface PurchaseOrderEditorUiBinder extends UiBinder<Widget, PurchaseOrderEditor> {}

Then in your code, you would call uiBinder.createAndBindUi(this) to actually make the widget.  This actually gets tedious after a while (even using the GWT Eclipse plugin, which is not ideal).

Errai Data Binding

Data Binding is another relatively new entrant into the Errai Framework.  Like its name suggests, it enables the binding of editing widgets to POJOs.  This is a loose replacement of the stock GWT Editor framework.  The GWT Editing framework was a good attempt at this functionality, but falls short on many levels, and we have found it very hard to work with, especially using an MVP architecture.  Unlike the GWT Editor, Errai Databinding keeps the backing bean in sync with the contents of the editors.  It also has useful tools like global property listeners.  Lastly, combined with Errai CDI, it is incredibly easy to set up and use.


We have been extremely happy with our experience building a large enterprise application with GWT and Errai.  Both GWT and Errai continue to evolve and improve, but they already represent invaluable tools to enable development teams to produce high quality software and do so productively.  


About author


Josh has been working with Web Technologies for over 18 years. He is currently the CTO at Blinco Systems. He can be reached at jblinick -at sign - blinco.com, and @JoshIsOnIt75 on Twitter

View all posts by Josh


No comments yet.

Be first to leave your comment!




Your comment:

Add your comment