Errai: The browser as a platform

Saturday, December 17, 2011

Thoughts on HTML5 and Development Methodologies

Over the past few months the Errai team has been busy at work preparing the next version of the Errai Framework, Errai 2.0.

It is a significant update that leverages all the best ideas that Errai 1.x had, while retiring some ideas and approaches that didn’t quite work out the way we’d planned.

Errai has developed a philosophy about rich application development in the browser. That philosophy might be summed up as: Your Application. Everywhere. Literally.

However, there’s been some people who’ve criticized this methodology. I’d like to respond to some of this now.

We have eschewed much of the conventional wisdom about how you should architect a web application by focusing on not just rich user experience, but rich developer experience. We believe that the latter ultimately leads to a better former.

We reject the need for polyglot applications as necessary -- the idea that the best way to build an application is to arrange a constellation of disparate languages and frameworks into a coherent single application is simply the “best approach” is something we don’t agree with.

You’re building your application in Java on the server. Why do you build the other part of it in JavaScript? The common response to this is, well, “that’s just the best way to do it”. But is it?

We don’t think it is. At the end of the day, the whole HTML5 group of technologies is just a specification that tells us how to make a browser do things.

Whether we write HTML and JavaScript directly or not, whether it’s translated from CoffeeScript, Dart, or in the case of Errai -- Java -- is immaterial. And it’s wrong to even suggest that Errai, with its use of the GWT compiler, sandboxes you into a world that proscribes any of these things. It doesn’t.

With Errai, your application can contain no JavaScript, or be almost all JavaScript.

The important part is how Errai helps you share not just model between the client and the server, but functionality. Without the need to write it twice, or write marshalling code, or worry about setting up your own comet or websockets. The communication model is central to the application development model.

Being able to share functionality, using the same code, with the same functionality is a good thing. You get all the benefits of type checking, code reuse, and productivity.

The implication that some make that, this sort of thing “hides the true nature of the web” is always one that puzzled me among those who advocate for a pure JavaScript approach.

I’ve always been of the opinion that such essentialist notions of pretty much anything are probably notions you should be suspicious of. I mean, the Java compiler hides bytecode. The C++ and C that the JVM is written in hides machine code.

It goes without saying that JavaScript itself is hiding all of this.

Moreover, JavaScript isn’t a terribly good language for large applications. And it surprises me that some of the very same people who trumpet the advantages of Java over other languages, will so willingly jettison their arguments in favor Java when it comes to JavaScript. There’s no immutability, side effects are hard to control, the object model is a mess, there’s nothing resembling a threading model, etc.

To which, counterarguments often include techniques about how JavaScript prototypes can be used in ways that simulate classes and inheritance, unit testing can guard against unintended side effects in large codebase, concurrency concerns do not apply in the world of the future, etc -- as if any of this somehow redeems JavaScript in any way in the eyes of someone who buys into these notions as being intrinsically good parts of a language.

JavaScript isn’t a bad language. Don’t get me wrong. It is mature and well understood. It does what its supposed to do. But the problem is, it was never designed with large application development in mind. Its designers did not envision a world where there’d be codebases of 100,000 lines of JavaScript code.

Yet, this is the world we’re quickly moving into. And the reality is, that technologies like GWT are extremely good solutions to manage these sorts of projects.

Over the next few weeks we’re going to show you why. Watch this space.

Wednesday, November 23, 2011

Setting the Record Straight on GWT

Since joining the Errai team, I've been telling lots of people about our project. Every time I do this, I find myself dispelling some common misconceptions about what GWT is and how it can be used. I also find people are surprised that GWT code has easy access to the browser's native environment: although GWT smooths out implementation details between browsers, it is not a firewall that cuts you off from the underlying environment.

So what is GWT?

GWT, the Google Web Toolkit, is a project with many independent parts. Here's a partial list:
  1. A Java-to-JavaScript compiler
  2. A class library providing:
    • a subset of the Java SE 5 standard library (most notably java.lang and java.util)
    • A programmatic UI framework (somewhat like Swing)
    • Java wrappers for native browser functionality such as JSON and XML manipulation, XMLHttpRequest (AJAX and Comet), and HTML 5 features like Canvas, Local storage, Audio and Video.
    • An RPC mechanism you can use if your application's backend happens to be written in Java (GWT RPC can't easily be retrofitted on an existing object model, but you can use it to build a server-side RPC layer)
  3. GWT Designer, a visual UI layout tool that generates code for the Swing-like UI framework
  4. UiBinder, a system for declarative UI (you define layout in files that are essentially XHTML interspersed with GWT widgets, with named elements automatically bound to fields in a companion Java class)
  5. Plugins for Eclipse, Maven, and Ant that help with creating, building, testing, and debugging GWT applications
The compiler itself is fundamental to any usage of GWT. Everything that follows is optional: you can take it or leave it, mix and match, use third-party alternatives, or invent your own replacements.

And what isn't GWT?

Now that we've listed off the highlights of what is included in GWT, it's important to address what it's not:
  1. GWT doesn't mandate a single, prescribed way of creating user interfaces. In particular, you don't have to create UIs in a "Swing for the browser" mindset unless you want to.
  2. GWT is not a server-centric system like JSF. Your GWT application compiles down to a collection of static files: HTML, CSS, images, and JavaScript. The application runs autonomously in the browser, communicating with the server only when it wants to. If you're not using GWT RPC, your apps need not be hosted on a Java web server.
  3. GWT does not require any browser plugins. Your compiled app is just one or more standards-based web pages.
  4. GWT does not prevent you from writing JavaScript directly. You can write inline JavaScript in your Java classes using JSNI, you can expose your Java APIs to JavaScript, and you can call JavaScript APIs from Java.
  5. GWT is not a dead project. Rumours of its demise are greatly exaggerated. 

If my GWT app just boils down to JavaScript and HTML, why bother with all this?

That's a great question. Thanks for asking. There are many compelling reasons to use GWT over raw HTML and JavaScript. I will address my favourite reasons in a future post, along with another question that I hope is burning in your mind: if GWT does all this, what does Errai add to the mix?

Monday, October 17, 2011

Errai 1.3.0.GA released!

The Errai team is proud to announce the release of 1.3.0.GA. This is the final 1.3.0 release and includes improvements and fixes based on community feedback. We would like to thank the Errai community for raising questions, suggesting improvements and reporting problems. Please stay tuned, there's a lot more to come in the near future.

Furthermore, Mike Brock's hard work and epic late-night battle with the Maven Release Plugin (which he demonstrably won) deserves a big thank you from the rest of the Errai team (Jonathan Fuerth and myself).

Tuesday, October 4, 2011

JAX-RS in GWT with Errai

The JAX-RS integration module is our latest extension to the Errai Framework. It brings another enterprise standard to the browser and simplifies the integration of REST-based services in GWT client applications.

How does it work?
To jump right in, let's assume we have the following JAX-RS interface which we want our clients to send requests to:

We simply put this interface somewhere in our client packages (e.g. client.shared) where the GWT compiler can find it. To create a request all that needs to be done is to invoke RestClient.create(), thereby providing the JAX-RS interface, a response callback and to invoke the corresponding interface method.

Error Handling

For handling errors, the existing error callback mechanism can be reused and the error callback can be passed to the RestClient.create() call. The ResponseException provides access to the Response object containing all details of the underlying HTTP response.

What does this buy you?

Errai will take care of generating the HTTP request logic for you and will automatically serialize/deserialize your method parameters. This helps alleviating boilerplate code for creating the URL, setting the HTTP headers, parsing the response, etc. By default, Errai's wire format will be used, but don't be dissuaded by that fact. Errai's wire format really is just simple JSON.

Future work
We are currently improving Errai's marshalling capabilities. One outcome of this will be a mechanism for pluggable custom serializers. So in the near future you will have the flexibility to choose your serialization format.

Interested and want to give it a try?
We have prepared a maven archetype, which generates a working JAX-RS CRUD application: This should help getting you started quickly.

As always, feedback is welcome and appreciated!

Saturday, September 10, 2011

Welcome Jonathan Fuerth

On behalf of the Errai team and the rest of Red Hat, and JBoss, I would like to extend my warm welcome to Jonathan Fuerth who joins the team, right here in Toronto.

Jonathan has an extensive background in software engineering, and has been actively involved in open source Java development for years, as well as being a community builder here in the Toronto area as a co-organizer of the Toronto Java User's Group.

Expect to here more from Jonathan in the coming weeks and months, right here in this space.

Friday, August 26, 2011

Speaking at FOSSLC: SC2011 Ottawa

If you're in the Ottawa area, stop by and check out my Errai talk at FOSSCL's Software Developers' Haven on Saturday August 27th.

You can find details here:

I'll also be hanging around for beers and talk afterwards.

Thursday, August 25, 2011

Errai 1.3 CR1

We're almost there. Today we have release Errai 1.3 Candidate Release 1. There's no new features to talk about since the beta release, of course. But the bug fixes are in, and we're excited to be closing in on the final!

Friday, August 5, 2011

Errai 1.3 Beta is Here!

About four months of hardcore, heads down work, I am pleased to announce the first official beta release of Errai 1.3. Don’t be dissuaded by the relatively small increment to the version number -- this is a big release!

The number one philosophy of Errai is to erase boilerplate and bring the power of server-side programming to the browser. In 1.3, we’ve made great strides in this area.

The Enterprise

First and foremost, much of our efforts have been focused on our Errai enterprise integration around Java EE6 technologies. We wanted more than just dependency-injection in the browser, we wanted the full power of CDI in the browser. And while we still fall short of 100% of the CDI specification being implemented, we have managed to implement a significant footprint of the specification.

A big priority for 1.3 was making the CDI integration even more invisible. So, if you’re going to do CDI in the browser, than it should be against the standard APIs. So, gone if the old client Event interface, and in is use of the javax.enterprise.event.Event interface for CDI events.

Qualifiers for events and injection are now fully supported in Errai client code. And even for server-client events, in both directions!

We also now have support for CDI Producers and private-method PostConstructs.

The Framework

Implementing the aforementioned requires a lot of framework infrastructure. So we went back to the drawing board and revisited the way in which Errai generates code. And in so doing, we implemented a brand new class meta model, which completely abstracts away the GWT generator API, and we then implemented our core IOC engine on top of it. The end result is all the ridiculously awesome stuff we’re doing with CDI!

This new code generation framework, forms the basis for how we foresee going forward and implementing integration for more of the EE6 stack, as well as other great technologies like Infinispan, for instance.

Our latest team member to join, Christian Sadilek, has put a lot of effort into developing our test harness and getting our test coverage up to a respectable level, and I think that will pay dividends in the quality of this release as well as future releases.

The Docs

We are renovating our documentation. And we’ve already done a lot. But there’s more to do. For the latest docs -- which we’ll be updating frequently in the coming weeks -- please check out or Confluence Wiki here.

The Archetype

To get started with Errai SE, you can run this command right now:

mvn archetype:generate \
-DarchetypeGroupId=org.jboss.errai.archetypes \
-DarchetypeArtifactId=bus-quickstart \
-DarchetypeVersion=1.3.0-SNAPSHOT \

To get started with Errai EE, you can run this command right now:

mvn archetype:generate \
-DarchetypeGroupId=org.jboss.errai.archetypes \
-DarchetypeArtifactId=cdi-quickstart \
-DarchetypeVersion=1.3.0-SNAPSHOT \

The Downloads

If you’re allergic to Maven, our downloads page is here:

Also, expect an awesome Forge plugin to be on the horizon -- especially considering that I co-founded that project (I know, I know… it’s embarrassing that i don’t have a plugin yet. But i’m a busy guy!)

The Future

We are only at the beginning. We expect to add a third team member in the next few weeks, and we are working closely with other JBoss projects, like Seam and RichFaces to expand the reach of the benefits which we bring to the JBoss web technology ecosystem.

Since we’re a framework which looks so heavily to the power of the browser, you can expect that over the next few months, our focus will shift intensely to leveraging the scope of capabilities that HTML5 brings to the table for developing rich applications.

Our ideas are vast, and we hope to share them with you going forward. So stay tuned.

The Gratitude

Thank you for everyone in the community who has given us feedback, reported bugs and supported us. Thanks to Heiko Braun for helping to get this project off the ground, and we’ll miss him as he moves on to work on other things. Thanks to Christian Sadilek for coming out of left-field and being incredibly awesome in every way. Thanks to Rodney Russ for being the world’s awesomest manager. Thanks to Mark Little for supporting all this from day one. Thanks to Dan Allen for his evangelization. Thanks to Pete Muir for his support. Thanks to Lincoln Baxter, Jay Balunas, and Shane Bryzak! And thanks to you for reading this.

Tuesday, June 21, 2011

Pervasive CDI: Errai at the JBoss World Keynote

JBoss World kicked off with a real cool keynote presentation which represented a confluence of JBoss’s cutting-edge technology.

The demo brought together JBoss AS, Infinispan, HibernateOGM, CDI and Errai.

Of course, our little part of the presentation was the demonstration of Errai powering a real-time tag cloud which really brought home the concept of the "real-time web"; most certainly not something which hasn’t been done before, but it was how we did it that makes it interesting.

I'm not going to rehash too much of what has already been said in the aforementioned blog posts, and I highly recommend you click the hyperlinks and check them out. Instead, I'm going to talk about CDI and Errai.

CDI is a technology we’re pushing really aggressively at JBoss, and Errai is no exception. In fact, we’re relatively sure that we’re the one and only in-browser CDI engine.

It was only natural we’d want to show this off at JBoss World. And that we did.

The demo involved bringing in a live tweet stream from Twitter and then producing real-time information based on what hashtags were most popular. The key was to have a fully dynamic tag cloud which would be updated the instant that the information was available. And as such, we used Errai’s push technology to display the information to every browser simultaneously and in real time.

CDI in the Browser

So what does CDI in the browser look like? Well, this might come as a shock: it looks exactly as it does in your server-side code. Consider the following server code:

public class MyService {
    @Inject @Updated
    private <>Event updatedTagEvent; 



And now consider the following client GWT code:

public void onTagUpdated(@Observes @Updated Tag tag) {
    System.out.println("Tag was updated: " + tag)

In the former code snipped we setup a CDI event consumer, and in the latter, we setup a CDI event observer. Believe it or not, that’s pretty much everything you need to know about push messaging with Errai CDI.

In fact, this is exactly how our tag cloud was updated. Using our transparent push mechanism, serialization and bus framework, all of the boilerplate associated with doing “push” is eliminated.

Yes, it’s that cool. I’m not going to show you a bunch of XML , property or boilerplate class files because, well, there are none.

As a developer you simply want to think about your logic and your data. Utilizing Errai and CDI to build your rich web applications allows you to do just that.

How does it work?

Errai is very much a compile-time framework. In order to provide the runtime infrastructure to transparently communicate between browser code (written in GWT) and the server, we provide a significant amount of code generation to support functionality based on declarative configuration.

For instance, we provide a straight forward annotation, @ExposeEntity which effectively instructs Errai to produce marshaller and demarshaller wrappers -- ultimately compiled down to JavaScript -- for the entity.

The other aspect of Errai is a powerful messaging bus which, consistently with Errai’s “pervasive” theme, runs concurrently in the browser and on the server. As opposed to thinking about client vs server, we have aggressively pursued a flat architecture where the client and server APIs are common and shared. So there isn’t one way to write server code for Errai and another way to write client code.

This also provides the underlying application with transport agnosticism. That is to say, this only contract is between the bus APIs and the client code for all client-server communication. Or even more high-level in the case of Errai CDI, between the application and the CDI eventing system. This means the method of communication, be it WebSockets or COMET is invisible to the application. Developers no longer need to worry about the particularities of working with those technologies.

The future?

We think the future of the web is rich applications. But not only that pervasive applications. And the demo we showed at JBoss World which can be viewed here at about 35 minutes into the presentation is merely a taste of how powerful pervasive computing can be.

Thursday, April 21, 2011

Latest enhancements to the Errai CDI integration module

CDI event qualifiers
The Errai CDI integration module (see a previous blog post) has support for event qualifiers now, both for event producers and observers. Multiple qualifiers can be specified for an event and of course custom qualifiers can be used.
CDI conversations
The simple use of @Conversational allows a server to directly address a single client in response to an event.
Clients can observe a BusReadyEvent to be notified when the CDI event system has been initialized and the message bus is ready to be used.

The example code below shows how to use these new features. Notice again the use of a uniform API on both the client and server.  For more details on Errai's CDI support see the online documentation. Any feedback is appreciated!

public class SimpleDocumentClient extends LayoutPanel {

    private Event<DocumentSubscription> documentSubscriptionEvent;

    @Inject @Published
    private Event<Document> publishedDocumentEvent;

    public void buildUI(@Observes BusReadyEvent busReadyEvent) { DocumentSubscription());
        // ...
        new Button().addClickHandler(new ClickHandler() {
            public void onClick(ClickEvent event) {

    public void onDocumentsReceived(@Observes Documents document) {
        // this event is received as a direct response to the subscription event
        // ...

    public void onDocumentCreated(@Observes @New Document document) {
       // ...

    public void onDocumentUpdated(@Observes @Updated Document document) {
       // ...

    public void onDocumentDeleted(@Observes @Deleted Document document) {
       // ...

public class SimpleDocumentService {

    private Event<Documents> subscriptionResponseEvent;
    @Inject @New
    private Event<Document> documentCreatedEvent;

    @Inject @Updated
    private Event<Document> documentUpdatedEvent;

    @Inject @Deleted
    private Event<Document> documentDeletedEvent;
    public void onDocumentSubscription(@Observes DocumentSubscription subscription) {
        Documents documents = new Documents();
        // respond to the client directly;

    public void onDocumentPublished(@Observes @Published Document document) {
        // receive document published events from the clients
    private void createDocument(Document document) {
        // ...;
    private void updateDocument(Document document) {
        // ...;
    private void deleteDocument(Document document) {
        // ...;

Thursday, March 24, 2011

Errai 1.2 released.

I am pleased to announce the public release of Errai 1.2. This is a maintenance release on Errai, with big fixes, better support for CDI integration and so on.

Existing users of Errai 1.1 should be able to directly upgrade to 1.2.

We have recently expanded our team and we plan on aggressively pushing the project in new and exciting directions going forward. So please check this space often. There's a lot in the offing.