-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Vert.x 5
Vert.x 4 was released two years ago (december 2020) and brought key features such as a future based programming model, microservices monitoring, a fully non-blocking and high performance SQL client, a redesigned Redis client to name a few. Since its release, new features were gradually added to the stack.
Reactive stacks have been recognised as strategic when it comes to performance, resource efficiency and scalability, they are continuing to evolve. External factors influencing the design of Vert.x are well known: virtual thread support (for which Vert.x has an incubator project) and Netty 5 (for which we did a small prototype) are the most impacting ones.
After two years and a few minor versions, it is time to deliver a new major Vert.x version. We think that it is too early to commit to virtual threads or Netty 5. Instead we want Vert.x 5 to revise and improve some of its parts, while at the same time preparing Netty 5 and virtual threads.
- This document is not a formal roadmap, rather a description of what Vert.x 5 shall be and not be, defining the major themes of the release
- We recognise that sometimes the landscape changes and a project needs to adapt, therefore the scope of Vert.x 5 is subject to potential changes
- This document targets Vert.x 5 (i.e 5.x releases)
The future programming model has been introduced in Vert.x 4 as an alternative to callbacks, components introduced in Vert.x 4 (like HTTP proxy, gRPC or OpenAPI) exlusively support futures. Vert.x 5 removes the callback model from the entire stack impacting all components that have been in the Vert.x 3 stack. This impacts the Vert.x API but also code generators.
Vert.x 3 was written for Java 8, Vert.x kept the Java 8 compatiblity to ease migration since at this time Java 8 was still the most ubiquitous Java version. Per se, Vert.x does not require very recent Java features (until virtual thread will be required) and Vert.x 5 choses Java 11 as base version. Note that we actually advocate to use the LTS but we want to remain compatible with Java 11.
The Java stack has evolved and Vert.x needs to modernize in a few areas such has biased locking, finalizer.
A few components needs to be upgraded and provide a better API which includes OpenAPI, Mongo client and RabbitMQ client.
In a few areas, the Vert.x API should be cleaned up and/or improved.
The Netty 4 API is apparent in a few public API classes, this should be removed to have the opportunity to provide an alternative Netty 5 version. A few components will be also removed from the stack, such components were actually not documented anymore.
We expect Vert.x 5 to be released in 2023.
After the Vert.x 4.4 release, the 4.4 branches will be created and the master/main branches will be switched to 5.0.0-SNAPSHOT. 4.x, x > 4 branches will be created from the 4.x branches when necessary.
Vert.x 4 will continue to get new features while Vert.x 5 is in development.
After Vert.x 5 is released, Vert.x 4 will remain supported for 2 years.
We will recommend using the latest Java LTS version and support Java 11 as minimum Java version.
- Biased locking removal: Address biased locking removal in Java 15.
- Finalizer removal: Replace various usage of Java finalizer with Java cleaner.
- Cleanup: Some code present in Vert.x 4 for Java 8 will be removed
- Codegen Java 8 compiler bug fixes
- Verticle extra classpath support based on multi release jar
- Asynchronous callbacks removal
- Permitted types is the new default
- Buffer might become a data object instead of being a generated type
- API improvements
- TCP write handler removal
The Vert.x public API is coupled to Netty 4, by a small degree yet it is. This coupling will be removed from the public API providing the opportunity to provide an alternative implementation of Vert.x 5 based on Netty 5 during the lifetime of Vert.x 5.
Vert.x 5 will provide the opportunity to provide a Netty 5 implementation along with a Netty 4 version at a later stage of the 5.x development.
Code duplication for Netty 5 might be necessary in a few places
- SQL clients relies on custom handlers
- MQTT client relies on Netty codecs
Such duplication shall be kept to the minimum and likely require a refactoring.
SQL client is mature, no major changes happening, a few enhancements
- TestContainer integration usability
- Improvement of the query API that does not allow to chain mapper/collector
- Prepared query builder to help building SQL query parameter placeholder syntax
Vert.x 4 has developed a new gRPC stack based on Vert.x HTTP/2 stack, the existing gRPC stack (based on Netty 4) becomes legacy and goes away in Vert.x 5.
Support for grpc-web without the need of a sidecar proxy.
Addresses a few concerns
- Using service proxies with EventBus serialization when exposing gRPC services requires transcoding Protobuf to JSON
- Provides an alternative to EventBus to use with service proxies
The implementation can be achieved in several steps
- Code generated Protobuf codec: a service proxy/handler implementation can serialize/deserialize to/from Protobuf.
- Transport switch: Vert.x gRPC client and server
- Protofile generation: generate a Protofile from the service proxy interfaces (services and messages).
Initial implementation supports request/response paradigm, we should add event streaming support on Vert.x event-bus to support the streaming use case.
Vert.x already supports SockJS or TCP bridge in various languages. A gRPC bridge complements this bridge offering with minimal maintenance of the client, as only a protofile is required.
Combined with grpc-web, it extends the Vert.x event-bus to the browser in a similar fashion than the SockJS event-bus bridge does. This does not replace the SockJS bridge, rather it complements it.
- RxJava 1 should either be dropped or kept but removed from the docs
- Despite RxJava 3,the use RxJava 2 is still dominant
- Prune callback support
Dropping dynamic resolution of metric ids is under consideration, because the performance impact is not negligible.
The Vert.x CLI was popular a few years ago while it was the most prominent way to use Vert.x. Vert.x 3 started to embrace the fat jar approach and since then grew in popularity to the point that maintaining the CLI support is no longer necessary. Vert.x 5 will drop the CLI support, yet it will keep the Vert.x launcher feature and the convergence of its jar dependencies to provide a coherent stack to integrate with.
Superseded by the virtual thread incubator project.
Service factory is no longer adapted for delivering Vert.x services. For the most part it relies on classloading and clearly the Java platform has evolved toward a path that does not encourage classloading.
- vertx-service-factory
- vertx-maven-service-factory
- vertx-http-service-factory
- Cleanup sharedXXX API and instead go through options.
- JDBC client API is removed
- the SQL client implementation is kept
We continue to support it, although we won't encourage to use it. Modern micro services usually rely on Kubernetes instead.
- CLI and documentation removal
- Deprecate corresponding configuration (VertxOptions)
The project has odd dependencies, like vertx-web, vertx-jdbc-client, vertx-service-discovery. Such dependencies are brought onto cluster managers. We should somehow handle this more gracefully.
The current OpenAPI module has many dependencies on several modules and makes many assumptions (both at the spec level and at the implementation level). This is a major blocker for the upgrade to OpenAPI 3.1.
A rewrite of OpenAPI is currently developed, it will be available astech preview in Vert.x 4.4 to replace the current implementation with full support in 5, the goals are:
- use vertx-json-schema which already supports the latest required schema version
- avoid randomly loading network resources to comply with security best practices
- document analysis and and validators generation shall be independent from Vert.x Web, to allow potential AsyncAPI support use this module in a wider range of components (e.g.: kafka, schemaless databases, etc…)
- provide response responses validation
We expect a rewrite of the Mongo client that would be developed in Vert.x 4 in tech preview to replace the current client with full support in 5.
We expect a rewrite of the RabbitMQ client that would be developed in Vert.x 4 in tech preview to replace the current client with full support in 5.
The current routing algorithm uses a list of routes and each route a list of handlers. It has some drawbacks leading to serious configuration problems that are not easily detectable, e.g route shading, when a top-level route catches more requests than the routes expected to catch later on the list does. Rendering the last added routes unreachable.
For Vert.x 5 the router shall be replaced with a compressed tree (CTrie) algorithm. This algorithm as several advantages at runtime over the current implementation:
- No route shadowing: since routes are tree leafs, reachability can be computed for any request.
- Optimized lookup:
- it only happens once
- avoids the current chain of regular expression checks and can be done in less than O(log n) where n is the of the path to search
- Filter and handlers can be optimized with a “build/compile” method to be propagated in the right order to the leafs, which ensures that in terms of memory/allocations we can run in O(1)
- Imperative lookup/build algorithm: given that we expect the lookup/insert operations to be fast, we allow the handler execution to be either synchronous or asynchronous, paving the way to future developments
Docker image generation is dropped.
The current wiki currently is used for multiple purposes, among all the release notes and deprecations changes are stored there, which makes the wiki barely usable.
A new wiki should be used to contain actual useful content (RFCs).