Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Podcasts Julien Viet on Reactive Programming with Eclipse Vert.x, Including 3.5.0, History, and Future Plans

Julien Viet on Reactive Programming with Eclipse Vert.x, Including 3.5.0, History, and Future Plans

In this podcast, QCon Chair Wesley Reisz talks to Julien Viet.  Viet is the project lead for Vert.x and a principal engineer at RedHat having taken over as project lead for Vert.x from Tim Fox in January 2016.  They talk about the newly released Vert.x 3.5.0, and the plans for Vert.x 4.0.

Key Takeaways

  • Vert.x adds RxJava2 support for streams and backpressure.
  • Vert.x is a polyglot set of APIs, custom aligned for the specific language.
  • It is unopinionated and can be used with any environments, since it doesn’t enforce a particular framework.
  • Verticles communicate in-VM or through peer-to-peer networking for distributed applications.
  • Vert.x 4.0 is on the roadmap for the future.

What’s new in Vert.x 3.5?

  • 1:50 The key feature in Vert.x 3.5 is support for RxJava2 — we have supported RxJava1 since the start.
  • 2:05 The other key feature is support for Kotlin co-routines. 

What’s new with RxJava2?

  • 2:20 It has been rewritten with support for the reactive streams library
  • 2:25 Mostly it’s the same API, but in a different package.
  • 2:35 One of the key things is back-pressure support - it wasn’t added in the initial release of RxJava, and was added later.

What about Kotlin co-routines?

  • 3:00 We had a very similar API already available called vertx-sync, and Kotlin support was added in Vert.x 3.4.
  • 3:30 The zookeeper maintainer was interested in adding co-routine support and so added it for this release.
  • 3:40 My job as project lead was to review and help improve it, but it’s a contribution to the project.
  • 3:55 I'm going to talk at Kotlin Conf on co-routines.
  • 4:25 JetBrains and Romain used the well documented co-routines support and added it into Vert.x.
  • 4:35 It's well integrated into the compiler, and in the IDE - so it’s totally transparent to the user.
  • 6:25 The key part is the integration of the Vert.x event loop with Kotlin co-routine support.
  • 6:40 We also have support for specific types - read and write streams, for example.
  • 7:00 You can use these as channels to read and write steamed data.

What’s the history of Vert.x?

  • 7:35 Vert.x was created by Tim Fox in 2012.
  • 8:00 Tim went to Pivotal to work on RabbitMQ.
  • 8:15 If you take Node.JS, Erlang, messaging, actor model, Netty and shake them together, you end up with something that looks like Vert.x.
  • 8:40 One of the goals was to provide a Node.JS-like model for the JVM.
  • 9:00 Vert.x is based on Netty and uses its event loop.
  • 9:10 Vert.x provides an asynchronous and non-blocking programming model.
  • 9:15 Those are the kinds of properties that you need to use with reactive programming systems.
  • 9:35 On top of that it’s a toolkit to write distributed applications.
  • 9:40 It provides primitives like counters, shared locks, distributed data.
  • 9:45 There’s an event bus which is used to distribute events in the application.
  • 9:50 For example, you can use a bridge to route events from the browser to the application or between languages.

What’s a Verticle?

  • 10:25 You can use an HTTP server or client in a Vert.x application.
  • 10:50 When your application becomes bigger and you want to modularise the application, that’s when Verticles become useful.
  • 11:00 A Verticle has two roles; to encapsulate logic, and to scale an application.
  • 11:15 When you create an application, Verticles are used to create different parts of your application which communicate through the event bus.
  • 11:25 When you deploy a single Verticle, it is given its own event loop.
  • 11:40 If you want to deploy the Verticle to different nodes, they have their own event loops, so you have scalability.
  • 12:00 Instead of sizing thread pools, you scale by modifying the number of Verticles deployed.
  • 12:15 You can distribute your application and move Verticles in different VMs to different nodes, because the event bus provides location transparency.

What is the event bus?

  • 12:45 If you’re in the same JVM, sending a message is just moving that message between two event loops.
  • 13:00 It’s a very efficient way of processing messages - the event loop can be running on one CPU core, and off-load the message to another event loop on a different CPU core.
  • 13:05 When you start to distribute your application, the cluster manager provides the topology and as a result can route messages to the appropriate location.
  • 13:35 There are different providers for the cluster manager; the Hazelcast one is the default implementation.
  • 13:40 There’s also an Infinispan provider, and contributions for Apache Zookeeper and Apache Ignite.
  • 13:55 Once Vert.x knows where to send the message, it uses peer-to-peer communication.
  • 14:05 The protocol is a custom one which uses prefix length encoding.
  • 14:15 I would like to write a plug-in for Wireshark that decodes the protocol, but I haven’t had time.

What languages does Vert.x support?

  • 14:40 Vert.x has been polyglot since the beginning.
  • 15:05 When you use the Vert.x core API, it’s all written in Java.
  • 15:15 We provide shims for different languages, and we try to respect idioms of the language as much as possible.
  • 15:35 For example, the Scala support uses Scala Futures for doing asynchronous support.
  • 15:54 When you use JavaScript, it will be a function - because that’s how you do that in JavaScript.
  • 16:05 When you’re running on a JVM language, you’re using the Java implementation.

Why did Vert.x decide to be unopinionated?

  • 16:45 When you are opinionated, you have to force people to do things in a certain way.
  • 16:50 But you can take Vert.x and use it with Spring, or even Java EE.
  • 16:55 Vert.x is just a library; it’s not framework - so we don’t impose certain protocols.
  • 17:15 Vert.x is very modular; we have a lot of different libraries.
  • 17:20 If you only use Vert.x core, then the only thing you are paying for is Vert.x core.
  • 17:30 We try to keep the list of dependencies very low, because we don’t do classloading.
  • 17:35 We recognise that classloading is a problem that we don’t want to solve.
  • 17:40 As soon as you try to do classloading, there is always another framework that wants to do classloading.

Does Vert.x support Java 9?

  • 18:50 It does in classpath mode, yes.
  • 19:00 Most of the libraries work well with Java 9 - but there are a few libraries that don’t work well.
  • 19:10 Those are the ones that do classloading.

What does getting started with Vert.x look like?

  • 19:35 Vert.x is a set of libraries; it’s not a framework.
  • 19:45 You can create a Maven or Gradle project, and add dependencies.
  • 20:00 You can test with JUnit, and create HttpServer or HttpClient.
  • 21:00 For users, we provide two GitHub projects that you can clone to get started.
  • 21:30 We also have a GitHub repository that provides examples of the APIs.
  • 21:55 The Vert.x website has a tool that you can use to generate a project.
  • 22:15 Documentation and examples are important things provided by the Vert.x project.
  • 22:40 We also have a gentle guide for developing asynchronous applications.
  • 23:15 There’s an O’Reilly book, which shows how to create microservices applications using Vert.x.

What about authentication?

  • 23:45 We have an authentication module that provides authentication.
  • 23:55 We can use either Vert.x web for website authentication or for shell with ssh authentication.

Where is Vert.x being used?

  • 24:2524:25 Whenever I go to a conference, I see Vert.x being used a lot in production.
  • 24:35 There’s a list of companies using Vert.x on the website, which we created for Vert.x 3.0.
  • 25:00 It tells a lot about the current usage of Vert.x.

What’s on the roadmap for the future?

  • 25:35 Vert.x 3.0 was released a couple of years ago, and we’ve been developing point releases since.
  • 26:05 Our mission is to provide a fully integrated reactive ecosystem.
  • 26:20 When components are important, we try and provide a convenient API for the user so that they don’t have to worry about threading.
  • 26:40 We can look to provide more database access, NoSQL and so on.
  • 26:50 We don’t have out-of-the-box solutions for Cassandra or CouchBase, for example.
  • 27:05 We’re starting to think about Vert.x 4.0.
  • 27:15 Vert.x is an Eclipse project, and we have a good community of contributors.
  • 27:35 For example, Vert.x for Scala was fully developed by a contributor.
  • 27:55 When we start to think about Vert.x 4.0, we’ll involve the community.
  • 28:05 Eclipse plays an important role; it tries to involve the community, even when the main commercial sponsor is RedHat.
  • 28:30 We had a face-to-face meeting last year, and it was a good opportunity for both the developers to meet; but it was open to anyone, so we had contributors coming along as well.
  • 28:45 With 4.0 we’ll look to do this again; to find out what we’re doing well and where to go.
  • 29:00 It will be an opportunity to think about what works, and what doesn’t work and can be improved.


More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article