Vert.x 5 comes with plenty of new exciting features, some of them have been developed in Vert.x 4 and made available as tech previews.

Here is an overview of the most important features supported in Vert.x 5.

Embracing the future based model

Vert.x 4 extended the 3.x callback asynchronous model to a future/callback hybrid model, to facilitate migration from Vert.x 3.

Vert.x 5 only retains the future model and thus the callback model is removed.

Since the good old AbstractVerticle class lifecycle API is not best suited for the future based model, a new VerticleBase base class is provided:

public class MyVerticle extends VerticleBase {
 
  private HttpServer server;
 
  @Override
  public Future<?> start() {
    server = vertx.createHttpServer().requestHandler(req ->
      req.response()
        .putHeader("content-type", "text/plain")
        .end("Hello from Vert.x!"));
 
    // Now bind the server:
    return server.listen(8080);
  }
}

Both VerticleBase and Verticle extends a new Deployable interface, since that interface is functional you can even write a one-liner verticle:

Deployable verticle = context -> vertx
  .createHttpServer()
  .requestHandler(req -> req.response()
    .putHeader("content-type", "text/plain")
    .end("Hello from Vert.x!"))
  .listen(8080);

NOTE: AbstractVerticle is still fine and not deprecated, we simply recommend to use the base class that best works for you

Java Modules

Vert.x 5 supports the Java Platform Module System (JPMS) with explicit modules (Vert.x 4 supports only automatic modules).

Most Vert.x components support modules (a few components though due to their dependencies cannot), the upcoming Modular Vert.x guide will give more information about it, in the meantime you can look at out JPMS examples.

gRPC improvements

Vert.x gRPC has a few great additions in this major release, propelling Vert.x gRPC as a first class choice for implementing gRPC services.

gRPC Web

The Vert.x gRPC Server supports the gRPC Web protocol by default (i.e. without an intermediate proxy).

On the Vert.x side, enabling the gRPC Web protocol support is a mere switch in options. In the near feature, we will provide a tutorial explaining how to generate a browser client with protoc and to communicate with the server.

gRPC deadlines

Vert.x gRPC handles timeout and deadlines in both client and server

Here is a simple example.

JSON wire format

gRPC implicitly assumes the usage of the Protobuf wire format, the Vert.x gRPC client supports the JSON wire format as well.

Here is a simple example.

OpenAPI & Vert.x OpenAPI Router

With Vert.X 5 the OpenAPI modules now also supports binary data.

Here you can find simple examples for Vert.x OpenAPI.

Here you can find simple examples for Vert.x OpenAPI Router.

io_uring support

Vert. 4 has been supporting io_uring in incubation for a while with a separate jar.

Netty 4.2 has promoted io_uring out of incubation, as a consequence Vert.x Core supports it out of the box.

Client side load balancing

Client side load balancing for HTTP based clients, with a wide variety of policies.

Here is a simple HTTP client example in Kubernetes as well as a gRPC client example.

Service resolver

Vert.x Service Resolver is a new addition to the Vert.x stack aiming to provide dynamic address resolution for clients, it extends the vertx core client side load balancing to a new set of service resolvers.

Enabled clients such as HTTP/Web/gRPC clients can use a service resolver to dynamically map a service address to a list of network addresses.

You can find here a few examples

HTTP proxy

The interception side of our HTTP proxy has been improved with out-of-the-box transformations and interceptor in WebSocket upgrades.

In addition, the caching part gets a proper caching Service Provider Interface (SPI) as well as extended support for caching specifications.

You can find here a few examples

Miscellaneous changes

Unix domain sockets

Unix domain sockets have historically supported exclusively by native transports, they are now available for JDK 16 or greater.

Connect options

TCP and HTTP clients have finer grained Connect capabilities, providing per connection SSL and proxy options. Previously such configuration was only possible client wide.

Un-pooled HTTP connection

Default interactions with an HTTP servers involves providing a request object and let Vert.x HTTP client establish the connection to the actual server and then pool it for subsequent uses.

Sometimes it is desirable to manage such connections instead of reusing pooled connections, for this use case the Vert.x HTTP client provides un-pooled connections.

You can find here an example

Micrometer Metrics performance improvements

Our integration of Micrometer Metrics overhead has been reduced, you can learn more about that in this blog post.

TCP shutdown

HTTP server and client support graceful shutdown.

You can shut down a server or a client.

Calling shutdown initiates the shut-down phase whereby the server or client are given the opportunity to perform clean-up actions.

• A standalone HTTP server unbinds
• A shared HTTP server is removed from the set of accepting servers
• An HTTP client refuses to send any new requests

When all connections inflight requests are processed, the server or client is then closed.

You can find here an example

Application Launcher

Application launcher is a new tool which addresses the concern of launching a Vert.x application packaged as a far jar. It replaces the Vert.x 4 io.vertx.core.Launcher.

Sunsets and removals

A few components are sunsetting in 5.0, that means they are still supported for the lifetime of the 5.x series, but we don’t encourage using them anymore since we provide replacements for them. Such components are scheduled to go away in the next major release (Vert.x 6).

Here is the list of components we sunset in 5.x

Here is the list of components removed in 5.x, that were sunset in 4.x series.

• Vert.x Sync, replaced by Vert.x virtual threads
• Service Factories / Maven Service Factory / HTTP Service Factory
• RxJava 1, replaced by SmallRye Mutiny or RxJava 3

Tooling

Vert.x Maven Plugin

The Vert.x Maven Plugin, a Reactiverse project, is a plugin for Apache Maven that helps to develop and/or to package Vert.x applications.

Its new major version, 2.0, supports both Vert.x 4 and Vert.x 5. Therefore, if you already use this Maven plugin and Vert.x 4, you can upgrade the plugin before upgrading Vert.x. This can make the migration process incremental.

Contextual logging

Reactiverse Contextual logging version 2.0 supports Vert.x 5.

Like the Vert.x stack, it has been updated for better integration with the Java Platform Module System (JPMS).

Before upgrading from version 1, checkout the migration guide.