We're a UK Collective, doing our bit to help increase that distribution, by bringing the future that already exists to a wider audience.

Crunch, save time, save tax, save money
London Tech Jobs at Career 2.0

Event Driven Java with Vert.x

Node.js has taken the JavaScript developer world by storm allowing fast non-blocking JavaScript to be deployed server side.

Vert.x provides much of the same functionality (and speed) as node.js with support for multiple languages - JavaScript, CoffeeScript, Ruby, Python, Groovy or Java.

Vert.x is uses the Java Virtual Machine the facilitates the pretty much means it can run anywhere and doesn't require the node.js compilation. It also facilitates the out of the box multi-languages support and performance.

The new JavaScript orientated web model means single pages html support dynamic updates based on on JavaScript (ajax) requests rather than the traditional GET/POST summit requests.

Vert.x supports WebSockets and SockJS, an additional JavaScript communications library. This allows the browser's JavaScript to pull data snippets directly from the Server rather than full pages. The requests are accessed via a REST/Json interface which in turn uses functionality from the HTTP protocol.

Back to the future with Asynchronous and Event-driven

Traditional 'real time' like erlang allowed for very fast response times (on telephone switches) using an event driven paradigm.

Event driven applications on the web provide two (at least) key (theoretical) advantages.

  • Better cpu utilization
  • Better/Faster user experience

Traditional web requests involve parsing the request, checking and updating backend systems like databases, building the response and posting it back to the client. This process spawns multiple threads to handle the requests that are left idle for relativity long periods of times waiting for the back end response. The event driven approach breaks each step adding a callback to pick up the response when it is available. This allows the cpu/thread to handle more work the threads are not blocked.

As a result of faster responses the end user should see faster response. The traditional web page model is also now broken down where users see the most relevant partial results first and subsequent results are dynamically added via JavaScript.

All of this change and performance comes with some costs:

  • WebSockets and SockJS can make multiple requests per page and user interaction making the application very 'chatty'. Other IO bottle necks may become overloaded by the extra requests.
  • There is also a considerable developer thinking shift to organize callbacks and handle out of sequence responses.
  • The code can become deeply nested with callback and difficult to debug, as we can kind of see already in the following example:
public class HttpServerExample extends Verticle {
  public void start() {
     new Handler<HttpServerRequest>() {
      public void handle(HttpServerRequest req) {
         put("Content-Type", "text/html; charset=UTF-8");

The Verticle super-class initiates an application in vert.x. When launched, the application registers a callback which is called for every HTTP request. In response, the callback outputs an HTML file. Finally, an HTTP server running this logic is launched on port 8080.

Events in Vert.x are processed in an 'event loop' thread. Vert.x can run multiple event loops in parallel depending on the number of processor cores in the system.

The event driven approach can be seen as an alternative to parallel programming. A verticle is always assigned to a single thread which can be used to capacity handling events. If this is sufficient the developer is spared developing thread synchronization locks and blocks required by traditional concurrent programming.