vert.x – JVM Polyglot Alternative to Node.js

| by Dio Synodinos on May 04, 2012. Estimated reading time: 3 minutes |

Vert.x is a framework for the next generation of asynchronous, scalable, concurrent applications, which aims to provide an alternative to Node.js for the JVM. It allows developers to write their application using JavaScript, Ruby, Groovy, Java or even mix and match.

Here’s how a web server that serves static files looks like in vert.x:

// JavaScript
vertx.createHttpServer().requestHandler(function(req) {
  var file = req.path === '/' ? 'index.html' : req.path;
  req.response.sendFile('webroot/' + file);

# Ruby
require "vertx" do |req|
  file = req.uri == "/" ? "index.html" : req.uri
  req.response.send_file "webroot/#{file}"

// Groovy
vertx.createHttpServer().requestHandler { req ->
  def file = req.uri == "/" ? "index.html" : req.uri
  req.response.sendFile "webroot/$file"

// Java
public class Server extends Verticle {
  public void start() {
    vertx.createHttpServer().requestHandler(new Handler() {
      public void handle(HttpServerRequest req) {
        String file = req.path.equals("/") ? "index.html" : req.path;
        req.response.sendFile("webroot/" + file);

Internally, a vert.x instance manages a small set of threads, one for every available core on the server. Each one of these threads basically implements an event loop. When a vert.x app instance (aka verticle) is deployed, the server chooses an event loop which will be assigned to that instance. Any subsequent work to be done for that instance will always be dispatched using that thread. Since there are potentially many thousands of verticles running at any one time, a single event loop is assigned to many verticles at the same time.

Verticles can communicate with other verticles running in the same, or different vert.x instances using the event bus with messages, something that resembles Erlang’s actor model. Message-passing aims to allow the system to scale over the number of the available cores, without having to allow multi-threaded execution of any verticle code.

The event bus is distributed and does not only span the server, but also penetrates into client side JavaScript for 'real-time' web applications.

Besides concurrency and message-passing, vert.x features include:

  • TCP/SSL servers and clients
  • HTTP/HTTPS servers and clients
  • WebSockets/SockJS support

InfoQ had a small Q&A with Tim Fox, Senior Staff Engineer at VMWare, about vert.x:

InfoQ: Can you give us an architectural overview of vert.x and how it is build?

Tim: The core of vert.x is written in Java, and then we write a thin API shim for each JVM language that we support, so that each language has an API that is idiomatic for that language. We do not expose the Java API directly to each of the languages. This means Ruby users see things done in a Ruby-ish way, JS users see things done in a JS-ish way, etc

InfoQ: Can you describe a typical developer's workflow on vert.x, especially compared the experience that a developer might have with Node.js?

I imagine it is quite similar to node.js. The actual workflow would really depend on whether you're running locally or on a cloud. But it's not really specific to vert.x

InfoQ: What about running a real-time app on the JVM vs. on Node.js, with respect to debugging, monitoring and operations?

I'd say monitoring and operations are really the concern of the environment in which you deploy vert.x than vert.x itself. E.g. if you deployed vert.x in a cloud, the cloud provider would probably provide monitoring for you. BTW, community members have so far got Vert.x running in OpenShift and Heroku. CloudFoundry support coming soon hopefully :)

InfoQ: Are there any benchmarks that compare it with Node.js?

We haven't any official benchmarks yet. But I've done some basic ones privately and vert.x performance and scalability far exceeds node.js in the tests I conducted. I hope to release some benchmarks with the release, or shortly after.

InfoQ: How does vert.x compare to Netty?

Netty is a great low level IO library. Vert.x actually uses Netty. But vert.x is a complete platform for writing asychronous applications. Vert.x also provides a component model, file IO, and various other things you won't find in Netty. I'd say, in the JVM space Vert.x competes more with, say, something like Akka (akka also uses Netty), i.e. it's a complete framework.

Vert.x is licensed under the Apache License version 2.0, sponsored by VMware and contribution is governed by the SpringSource Individual Contributor License Agreement.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Lines by Roopesh Shenoy

4 lines in Groovy
5 in JS, Ruby
13 in Java

Feel free to draw your own conclusions :-).

Re: Lines by Narayan Bala

Just concluded that you've learned to count!!! Kudos

Re: Lines by arnaud m

Maybe when you write all your code in NotePad,
line count is critical...

Node.js by Vic Cekvenich

Node.js already does a good job, no need for a java port. Ideally Jave enterprise developers stick w/ EJB or Spring xml configurations, ORM a frameworks, let them be.

Re: Node.js by Roopesh Shenoy

I maybe wrong, but I think the advantage they are looking for are the ability to use the already mature JVM libraries.

Re: Node.js by Paulo Pinto

node.js is just the fad of the year technology.

The same way Rails was before it.

Meanwhile, enterprise software is already making use of mature technologies, that while not as fashionable, are able to deliver the required performance and development support required on the enterprise world.

Re: Node.js by arnaud m

It's funny that while GWT brings Java to the browser to avoid JS,
Node.js brings JS to the server.

I think it's good to have other ways to use Java (or any JVM language) on the server than traditional EJB, ORM,...
I have done a lot of JS on the client-side, but I think it's not very efficient compared to java (or C#,...) because of the lack of static typing and advanced IDE support (that's why GWT or Dart were created after all).

Security by Jacob Hookom

In the example above, what would be preventing someone passing a path like '../../../ -...' and just blindly executing code or pulling password files?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

8 Discuss