Eclipse Vert.x 3.5.0 released!

The Vert.x team is pleased to an­nounce the re­lease of Eclipse Vert.x 3.5.0.

As usual it de­liv­ers an im­pres­sive num­ber of high qual­ity fea­tures.

Let’s go RxJava2

First and fore­most this re­lease de­liv­ers the Rx­Java2 API with sup­port of its full range of types.

In ad­di­tion of Single, Rx­i­fied APIs also ex­pose theCompletable and Maybe types:

// expose Handler<AsyncResult<Void>>
Completable completable = server.rxClose();

completable.subscribe(() -> System.out.println("closed"));

// expose Handler<AsyncResult<String>> where the result can be null
Maybe<String> ipAddress = dnsClient.rxLookup("www.google.com");
ipAddress.subscribe(
  value -> System.out.println("resolved to " + value),
  err -> err.printStackTrace(),
  () -> System.out.println("does not resolve"));

Rx­Java aug­ments Vert.x streams with a toObservable() method, like­wise Rx­Java2 adds the toFlowable() method:

// Flowable<Buffer> maps to a ReadStream<Buffer>
// back-pressured stream
Flowable<Buffer> flowable = asyncFile.toFlowable();

// but we still can get an Observable<Buffer>
// non back-pressured stream
Observable<Buffer> flowable = asyncFile.toObservable();

What’s so dif­fer­ent be­tween Flowable and Observable? the for­mer han­dles back-​pressure, i.e the sub­scriber can con­trol the flow of items and the later can not!!!

You can read the doc­u­men­ta­tion in the sec­tion of the docs or go straight to the ex­am­ples

Kotlin coroutines

Sup­port for Kotlin Corou­tines is one of my favourite 3.5 fea­tures (by the way I’ll present a talk about Vert.x and corou­tines at Kotlin­Conf).

Corou­tines al­lows you to rea­son about asyn­chro­nous flow the same way you do with tra­di­tional se­quen­tial flow with the extra bonus to use try/catch/finally super combo:

val movie = ctx.pathParam("id")
val rating = Integer.parseInt(ctx.queryParam("getRating")[0])
val connection = awaitResult<SQLConnection> { client.getConnection(it) }
try {
  val result = awaitResult<ResultSet> { connection.queryWithParams("SELECT TITLE FROM MOVIE WHERE ID=?", json { array(movie) }, it) }
  if (result.rows.size == 1) {
    awaitResult<UpdateResult> { connection.updateWithParams("INSERT INTO RATING (VALUE, MOVIE_ID) VALUES ?, ?", json { array(rating, movie) }, it) }
    ctx.response().setStatusCode(200).end()
  } else {
    ctx.response().setStatusCode(404).end()
  }
} finally {
  connection.close()
}

This ex­am­ple is bor­rowed from our ex­am­ples.

MQTT Client

In Vert.x 3.4 we added the MQTT server, 3.5 com­pletes the MQTT story with the MQTT client:

MqttClient mqttClient = MqttClient.create(vertx,
   new MqttClientOptions()
     .setPort(BROKER_PORT)
     .setHost(BROKER_HOST)).connect(ar ->
  if (ar.succeeded()) {
    System.out.println("Connected to a server");

    mqttClient.publish(
      MQTT_TOPIC,
      Buffer.buffer(MQTT_MESSAGE),
      MqttQoS.AT_MOST_ONCE,
      false,
      false,
      s -> mqttClient.disconnect(d -> System.out.println("Disconnected from server")));
  } else {
    System.out.println("Failed to connect to a server");
    ar.cause().printStackTrace();
  }
});

You can find MQTT client and server ex­am­ples here

Web API contracts

With the new Ope­nAPI router fac­tory we can focus on the API im­ple­men­ta­tion and not on the val­i­da­tion of the input. The usage is quite sim­ple:

OpenAPI3RouterFactory.createRouterFactoryFromFile(vertx, "petstore.yaml", ar -> {
  if (ar.succeeded()) {
    // Spec loaded with success
    OpenAPI3RouterFactory routerFactory = ar.result();

    // add your API and security handlers to the factory

    // add it to a server
    vertx.createHttpServer()
      .requestHandler(routerFactory.getRouter()::accept)
      .listen();
  } else {
    // Something went wrong during router factory initialization
  }
});

Now as a de­vel­oper you only need to care about the API and not on the val­i­da­tion. The Ope­nAPI router will en­sure that a re­quest to an API will first to the con­tract be­fore your han­dler is in­voked.

Java 9 support

Java 9 was re­leased a few days ago and the Vert.x stack has been care­fully tested on Java 9 and most of our com­po­nents run on Java 9 (Groovy does not run well on Java 9, please see the sup­port ma­trix)

As a bonus you can now use HTTP/2 out of the box with JDK SSL!

You can also use Vert.x jars as anony­mous mod­ules.

Event driven JSON Parsing

We pro­vide now an event dri­ven JSON Parser emit­ting parse events that is very handy when you need to han­dle very large JSON struc­tures and you don’t want to buffer it which in­tro­duce extra la­tency and in­crease the mem­ory con­sump­tion.

The parser al­lows you to switch be­tween fine grained JSON parse events or full struc­tures, for in­stance you can parse an array of ob­ject very ef­fi­ciently:

JsonParser parser = JsonParser.newParser();

// The parser will handle JSON objects as values
parser.objectValueMode();

parser.handler(event -> {
  switch (event.type()) {
    case START_ARRAY:
      // Start the array
      break;
    case END_ARRAY:
      // End the array
      break;
    case VALUE:
      // Handle each object
      break;
  }
});

Single SQL operations

Sin­gle SQL op­er­a­tions (aka one-​shot) have been dras­ti­cally sim­pli­fied: most of the SQLOperations op­er­a­tions can now be per­formed di­rectly on the SQLClient:

client.queryWithParams("SELECT AVG(VALUE) AS VALUE FROM RATING WHERE MOVIE_ID=?", new JsonArray().add(id), ar2 -> {
  if (ar.succeeded()) {
    int value = ar.result().get(0).getInteger("VALUE");
    // Continue
  }
});

Under the hood, the client takes care of the pool ac­quire/re­lease in­ter­ac­tion for you.

Native transport and domain sockets

We now sup­port na­tive trans­ports on Linux (Epoll) and MacOS (KQueue), as well as UNIX do­main sock­ets for NetServer/NetClient (HttpServer/HttpClient should sup­port UNIX do­main sock­ets soon).

Auth handler chaining

There are times when you want to sup­port mul­ti­ple authN/authZ mech­a­nisms in a sin­gle ap­pli­ca­tion.

Vert.x Web sup­ports auth han­dlers chain­ing

Vert.x config improvements

Vert.x Con­fig al­lows con­fig­ur­ing your ap­pli­ca­tion by as­sem­bling con­fig chunks from dif­fer­ent lo­ca­tions such as file, http, zookeeper…

In this ver­sion, we have added the sup­port for Con­sul and Vault.

With the Con­sul con­fig store, you can re­trieve your con­fig­u­ra­tion from a Con­sul server - so in other words, dis­trib­ute the con­fig­u­ra­tion from your or­ches­tra­tion in­fra­struc­ture.

The Vault con­fig store lets you re­trieve se­crets avoid­ing hard cod­ing se­crets or dis­trib­ut­ing cre­den­tials using an in­se­cure way. Vault en­forces the se­cu­rity of your se­crets and only al­lowed ap­pli­ca­tions can re­trieve them. In other words, now you can keep your se­crets se­cret.

ACKs

I want on be­half of the team to thank all the con­trib­u­tors for this re­lease in­clud­ing the Google Sum­mer of Code stu­dents (Pavel Drankov, Francesco Guardiani and Yunyu Lin) that de­liv­ered an im­pres­sive work.

Finally

The re­lease notes

• https://github.com/vert-​x3/wiki/wiki/3.5.0-​Release-Notes

Docker im­ages are also avail­able on the Docker Hub. The Vert.x dis­tri­b­u­tion is also avail­able from SD­KMan and Home­Brew.

The event bus client using the SockJS bridge are avail­able from NPM, Bower and as a We­b­Jar:

• https://www.npmjs.com/pack­age/vertx3-​eventbus-client
• https://github.com/vert-​x3/vertx-​bus-bower
• http://www.we­b­jars.org/

The ar­ti­facts have been de­ployed to Maven Cen­tral and you can get the dis­tri­b­u­tion on Bin­tray.