Skip to content

4.0.0 Deprecations and breaking changes

Julien Viet edited this page Aug 8, 2019 · 37 revisions

Vert.x Core

☑️ EventBus request-response send is removed

The EventBus#send(..., Handler<AsyncResult<Message<T>>>) and Message#reply(..., Handler<AsyncResult<Message<T>>>) methods are revmoed. Such methods raise overloading issues in Vert.x 4 because the version returning a Future<Message<T>> would collide with the fire and forget version.

The request-response messaging pattern should now use the new request and replyAndRequest methods:

// 3.8
eventBus.send("the-address", body, ar -> ...);

// 4.0
eventBus.request("the-address", body, ar -> ...);

Likewise with replies

// 3.8
eventBus.consumer("the-address", message -> {
  message.reply(body, ar -> ...);

// 4.0
eventBus.consumer("the-address", message -> {
  message.replyAndRequest(body, ar -> ...);

☑️ MessageProducer send methods are removed

The MessageProducer interface declares two send methods, such methods are removed. MessageProducer#write(T) should be used instead of MessageProducer#send(T), EventBus#request(String,Object,Handler) should be used instead of MessageProducer#send(T,Handler).

☑️ WriteStream write and end methods fluency

WriteStream#write and WriteStream#end methods are not fluent anymore:

  • the callback version now returns void
  • the other now returns a Future<Void

This is a breaking change that removes the fluent write aspect of write streams. Note that the end method accept as parameter a last argument so stream.write(T).end() can actually be stream.end(T)

☑️ NetSocket upgradeToSsl uses Handler<AsyncResult> instead of Handler

Currently the NetSocket#upgradeToSsl method uses an Handler completion. The only way to determine whether the upgrade fails is to set an exception handler on the socket which will replace the current handler and complicate the code.

This method should instead use an Handler<AsyncResult>.

☑️ HttpClient request/response use Handler<AsyncResult> instead of Handler<HttpClientResponse

HttpClient request/response methods are using in Vert.x 3 patterns following Handler<HttpClientResponse>. For obvious reasons we want to use instead Handler<AsyncResult<HttpClientResponse>> in Vert.x 4. The WebClient provides already this in Vert.x 3.x and it is the advocated client for high level operations so we don't need to provide replacement for these operations, only to deprecate them.

☑️ HttpClient WebSocket use Handler<AsyncResult< WebSocket >> instead of Handler / Handler<Throwable)

HttpClient WebSocket methods are using in Vert.x 3 patterns following Handler<WebSocket>/Handler<Throwable>. For obvious reasons we want to use instead Handler<AsyncResult< WebSocket >> in Vert.x 4. These new methods are named webSocket(...). The number of overloaded methods has also been reduced using WebSocketConnectOptions.

☑️ Remove pooled buffer option

Vert.x provides the option on TCPSSLOptions to configure the usage of pooled buffers. This option has no effect whatsoever and has marked as deprecated in 3.6. We should simply remove it from Vert.x. This option might be overridden by TCPSSLOptions sub classes in other modules of the stack, so the stack should be checked and provide corresponding PR along with this one.

☑️ Remove Future completer method

The Future#completer() method is deprecated since Future<T> extends Handler<AsyncResult<T>> for some time now (and the default implementation actually returns this).

☑️ Remove multithreaded worker verticles


MultiThreaded worker verticles are an extension to worker verticles. Like with usual worker verticles, events are handled on worker pool threads. But they can be executed by different threads concurrently, which means the verticle must manage its own state to be visible between threads.

There are many parts of Vert.x which simply doesn't support them. For example, you can't create an HTTP server on a MT worker verticle.

Also, we have seen many new users, in particular those experienced with Spring or Java EE, starting directly with MT worker verticles and adding as many threads as possible with the impression it would help get the best performance results. But this is really counter-productive.

In 3.6.0 we deprecate the usage of multi-threader worker verticles and we document how to replace them. The feature will is dropped in Vert.x 4.

☑️ Deprecate logging API


The Vert.x logging API is public and advertised in the docs. Besides, there are a couple of issues as it supports parameterised logging methods without standardising on a message format (it delegates this to the logging backend so messages are not portable).

Therefore, we regularly get questions/bug reports about this, which increases the maintenance effort. Also, it's not good to provide a non-working feature only to cause users' disappointment.

Considering it's not a programming toolkit responsibility to provide yet another logging API, the Vert.x loggers shall be deprecated and, in a later major version made internal.

☑️ Remove options clone methods

See and

KeyCertOptions#clone(), TrustOptions#clone() and SSLEngineOptions#clone() methods are deprecated in 3.7 and are replaced by KeyCertOptions#copy(), TrustOptions#copy() and SSLEngineOptions#copy()` methods in 4.0.

☑️ Remove equals/hashCode method from options


There is no deprecation in 3.x, users should simply not use it.

☑️ Remove deprecated Metrics#isEnabled() method


This is an internal SPI method.

☑️ Remove deprecated NetServerOptions#isClientAuthRequired()


The 3.x version will point to the new method to use instead.

☑️ Remove deprecated VertxOptions#fileResolverCachingEnabled


The 3.x version will point to the new method to use instead.

Encapsulate Jackson


Remove cluster reply address


There are still references in the code and docs to the event bus reply address. But it's actually only used now to provide the origin server ID.

Vert.x gRPC

☑️ Remove usage of Vert.x gRPC Java Compiler

In Vert.x 3.x, Vert.x provides its own compiled gRPC stubs for Vert.x API. This leads to maintain a fork of the grpc compiler which cannot be trivially achieved by anyone. It is agreed in Vert.x 4 to drop this.

RxJava 1

☑️ Remove legacy XYZObservable method

These methods have been deprecated since rx prefixed version exist and should not be used normally. These methods are simply removed in Vert.x 4. In addition these methods were present on modules created before the introduction of rx prefixes, other modules don't carry it.

Dropwizard Metrics

☑️ JSON options: remove backward compatibility for monitoredServerUris, monitoredClientUris and monitoredClientEndpoints

In 3.3, monitoredServerUris, monitoredClientUris and monitoredClientEndpoints have been renamed to monitoredHttpServerUris, monitoredHttpClientUris and monitoredHttpClientEndpoints, respectively.

In the JSON to options constructor, there is code to support the old options format. It shall be removed now.

Vert.x Web

☑️ Merged the functionality of SessionHandler and UserSessionHandler

When working with session users always need to provide 2 handlers. The code is too fine grained and a common source of confusion for users. For this reason, the 2 handlers will be merged into a single SessionHandler.

☑️ Removed the deprecated cookie API

The vertx-core module introduced in 3.8.1 a cookie API borrowed from vertx-web. The vertx-web cookie support is deprecated in 3.8.1 and removed in 4.0.0.

Vert.x Kafka Client

☑️ Remove deprecated AdminUtils

The AdminUtils class, for doing administrative operations on a Kafka cluster, was removed. The new KafkaAdminClient class should be used for that.

Vert.x Mail Client

☑️ Attachement is now an API interface and not anymore a data object

In order to allow mail attachment streaming we converted the Attachment data object to be an API object instead which will allow the streaming implementation.

☑️ Vert.x Redis Client

The new API io.vertx.redis.client.Redis replaced the old one. The new API is connection oriented and supports all modern feature of Redis. In order to use an API similar to the old one an helper class: RedisAPI is available to expose all known commands as methods.

☑️ Vert.x MQTT

A few fluent methods return now Future instead of being fluent, e.g:

   .publish("hello", Buffer.buffer("hello"), MqttQoS.EXACTLY_ONCE, false, false)
   .publish("hello", Buffer.buffer("hello"), MqttQoS.AT_LEAST_ONCE, false, false);

Now should be

client.publish("hello", Buffer.buffer("hello"), MqttQoS.EXACTLY_ONCE, false, false);
client.publish("hello", Buffer.buffer("hello"), MqttQoS.AT_LEAST_ONCE, false, false);

☑️ Vert.x Kafka Client

The flush operations are declared with Handler<Void> argument instead of Handler<AsyncResult<Void>>. They have been changed to the correct type. In practice the user code will work equally well and will get an async result instead of null value.

☑️ Vert.x AMQP Client

Currently the client declares a few methods that takes an Handler<AmqpMessage> as parameter, this handler is then set on a ReadStream<AmqpMessage>. Such methods raise issues with futurisation as the futurised form has the same erased signature than other methods, e.g

Future<AmqpReceiver> createReceiver(String, Handler<AmqpMessage>);
void createReceiver(String, Handler<AsyncResult<AmqpReceiver>>);

Such methods are removed in Vert.x 4 and are deprecated in 3.x

Clone this wiki locally
You can’t perform that action at this time.